W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: Updated Stats proposal - May 13

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 13 May 2014 14:58:54 +0200
Message-ID: <5372170E.2050609@alvestrand.no>
To: Varun Singh <vsingh.ietf@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 05/13/2014 02:39 PM, Varun Singh wrote:
> Hi Harald,
>
> Comments inline.
>
> Cheers,
> Varun
>
> On Tue, May 13, 2014 at 2:56 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
>> I have updated the Stats proposal to include a few more stats that the
>> Chrome team has found necessary and/or useful to their work.
>>
>> The proposal is at https://www.w3.org/2011/04/webrtc/wiki/Stats
>>
> Thank you for updating the document.
>
>> Changes include:
>>
>> - Added counters for FIR, PLI, NACK and SLI
> The reference to FIR should be changed to RFC5104
> http://tools.ietf.org/html/rfc5104#section-4.3.1
> Was there some discussion around including RPSI (Reference Picture
> Selection Indication) for implementations that support it?

Right - it seems that these two share an acronym, but not a codepoint....

It seems that the FIR in RFC 5104 is defined by PT=PSFB (206) and FMT=4, 
which makes the 2 first bytes 0x84CE. while the one in 2032 is defined 
by PT=RTCP_FIR, which makes the 2 first bytes 0x80C0.

I assume that it's the RFC 5104 FIRs we want to count, and the RFC 2032 
FIRs should be ignored.

WRT RPSI - no discussion, do you think it's needed?

>
>> - Added a "packets lost" counter
> In IETF 89 (Vancouver) and IETF 90 (London) XRBLOCK discussed
> additional statistics for WebRTC [1,2].
> Of these burst discard and burst loss were particularly found
> interesting, note that those documents are not WG documents and not
> all metrics documented there have WG consensus. But discussion about
> them in XRBLOCK would be really useful.
>
>> - Added "target bitrate" for an SSRC
> Clarification, target bitrate is calculated by the congestion control,
> and not necessarily the amount sent or produced by the SSRC.

Have to clarify this further - I meant this to indicate the target 
bitrate that the codec has been set to produce. This may be lower than 
the available bitrate, for application or implementation specific 
reasons, but it should never be higher, I think.
>
>> - Added RTT on a SSRC (RFC 3550 computation)
>> - Added audio level, Echo Return Loss and Echo Return Loss enhancement to a
>> MediaStreamTrack
>> - Added certificate information
>> - Added RTT, bytes sent, bytes received, available outgoing and incoming
>> bitrates to a candidate pair
>>
>> With these changes, I believe we have a reasonably complete set of stats for
>> version 1.
>>
>> Questions for the WG (apart from the obvious "are these well defined,
>> necessary and sufficient"):
>>
>> - Should this be a separate document? (I believe yes)
> A different document would definitely be useful.
>
>> - Do we need an IANA registry for later stats, or should we go with "living
>> document" approaches?
>>
> I dont know much about the living document or where it would hosted,
> in the wiki -- as it is now?
In the W3C document repository, I assume. The wiki doesn't produce 
documents in W3C format.

> But then there is the expired Internet draft:
> http://tools.ietf.org/html/draft-alvestrand-rtcweb-stats-registry-00
> I prefer the IETF document because it closely follows the metric
> naming conventions defined by IPPM in
> RFC6390 and all the metrics defined in XR Block follow those
> conventions as well.

Yes, that's the alternative.

>
>> Enjoy!
>>
>>        Harald
>>
>>
> [1]: http://tools.ietf.org/html/draft-huang-xrblock-rtcweb-rtcp-xr-metrics-01
> [2]: http://tools.ietf.org/html/draft-singh-xrblock-webrtc-additional-stats-02
>
>
Received on Tuesday, 13 May 2014 12:59:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC