Re: [rtcweb] RTP Usage: RTCP XR metrics

[Qin Wu <[e-mail]>]

----- Original Message ----- 
From: "Magnus Westerlund" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "Colin Perkins" <[e-mail]>; <[e-mail]>
Sent: Friday, February 22, 2013 4:33 PM
Subject: Re: [rtcweb] RTP Usage: RTCP XR metrics


> On 2013-02-20 06:13, Qin Wu wrote:
>> Hi, Colin:
>> My aim is these block types are RECOMMENDED to be implemented, for
> justification on why they are recommened,
>> I think we can go to look at four RTCWeb communication requirements:
> 
>> "
>>    F5            The browser MUST be able to render good quality
>>                    audio and video even in the presence of
>>                    reasonable levels of jitter and packet losses.
>> 
>> 
>>    F6            The browser MUST be able to handle high loss and
>>                    jitter levels in a graceful way.
>> 
>>    F10           The browser MUST support synchronization of
>>                    audio and video.
>> 
>>    F38          The browser MUST be able to collect statistics,
>>                    related to the transport of audio and video
>>                    between peers, needed to estimate quality of
>>                    service.
>> " So my point is if you want to ask browser to ensure good quality
>> for both audio and video in the presence of centain level of jitter and losses,
>> you should be able to report jitter and losses to help you know what
>> current level of jitter and packet loss is. You may need to collect more
>> detailed statistics to help you decide what level of jitter and loss you
>> don't want to exceed? PDV metrics block tell you more higher resolution of
>> jitter comparing with using interarrival jitter provided by RTCP
>> SR/RR. Statistics Summary Report Block defined in RFC3611 tell you
>> how many packets are lost in a certain sequence number interval.
>> burst loss rate, gap loss rate defined in the
>> draft-ietf-xrblock-rtcp-xr-summary-stat tell you Proportion of packet
>> lost. Therefore these relevant metrics block SHOULD
>> be listed as "RECOMMENDED to be implemented", in my opinion.
>> 
> 
> I don't see the strong requirements of how the WebRTC endpoint
> implementation quality requirements (F5, F6 and F10) are strongly linked
> to the F38.
> 
> One type of arguments is that the peer endpoint being provided with RTCP
> XR reports will function better in providing media quality. I don't know
> if that is true for the metrics you listed.
> 
> A second line of reasoning is around how F38 is addressed. Especially in
> the light that the WebRTC endpoints that are browsers will have a stats
> API that allows one to get that side of information, assuming that one
> has access to influence the JS application and can upload the data to
> where it is needed.
> 
[Qin]:So you claim the Browser does not need to support RTCP XR in all implementation?

> For these stats I think the potential motivation for RTCP XR boils down
> to this:
> 1) The peer is not a Browser but has RTCP XR, and one wants to access
> its view of the session, thus receiving and gathering RTCP XR reports
> enables one to get a better view of the whole RTP session.
> 2) One want the collection to be in an WebRTC RTP media plane middlebox,
> and it should get the endpoints view also, thus RTCP XR is good.

[Qin]: Sounds good to me. 

> So do people have those reasons, and what information does one really
> need in these contexts?
> I think some clearer motivations around RTCP XR and each particular
> metrics needs to be stated from any proponent.

[Qin] : I think at least transport level metrics carried in RTCP XR need to be supported 
on the peer since they reflect transport impairement in the network affect media quality.
transport level metrics  include Statistics Summary Report Block defined in RFC3611, 
Delay metrics block and PDV metrics block defined in XRBLOCK WG.

For end system metrics, burst gap related metrics, jitter buffer metrics and packet loss 
concealment metrics are RECOMMENDED to be implemented on the peer since these
metrics extend from VOIP summary metrics block defined in RFC3611 and many VOIP
implementations have already support VOIP metrics block reporting.

For application level metrics, at least QoE metrics should be supported on the peer since 
MoS score provide easily understood numetric representation of media quality.

> 
>> In addtion, Browser need to support synchronization of audio and
> video, however how do you know a certain browser lost synchronization of
> audio and video. I think Synchronization delay and offset metrics can
> tell this. Therefore Synchronization delay and offset metrics, in my
> opinion, RECOMMENDED to be implemented.
> 
> The question is how needs to know that the receiving browser has failed
> or selected to not synchronize the media? I don't see that the sender
> can do anything different from what they are doing. 

[Qin]: RFC6051 defines three methods to reduce  the
  possible synchronisation delay. Two methods can be used by sender.

>As I see it all
> falls back to knowing what quality level did this session actually
> achieve. Especially for synchronization it might be that losing the sync
> was better than to increase the audio delay to 1 second as an example.


> Cheers
> 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>