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

Re: Updated Stats proposal - May 13

From: Varun Singh <vsingh.ietf@gmail.com>
Date: Tue, 13 May 2014 17:02:27 +0300
Message-ID: <CAEbPqryo6xkjM04pH9pkD3aqRr7T1YF26rcYXF2rZOmhs-xPXA@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Tue, May 13, 2014 at 3:58 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
> On 05/13/2014 02:39 PM, Varun Singh wrote:
>> On Tue, May 13, 2014 at 2:56 PM, Harald Alvestrand <harald@alvestrand.no>
>> wrote:
>>> 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.

yes the one in RFC5104.

> 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?

If the encoder-decoder synchronization is broken, it would help any algorithm
trying to estimate QoE from the network parameters. But this depends on any
implementation sending RPSI.

Similarly, it would be nice to know if frames got discarded by the decoder.
I suppose one can get these from

>>> - 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.

Wouldn't the target bitrate vary with time, depending on the variation
in the available bitrate? And the available bitrate is something measured
by the congestion control algorithm?

I guess what I want to know was how to interpret the value in the
target bitrate. i.e., I assumed that this would potentially mean the bitrate
the codec was configured to meet (it may or may not) and the value may
vary with time.

>>> - 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.

I don't know enough about change control, etc. so I'll let someone else
weigh in on what works better for the community.

>>> 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 14:03:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:58 UTC