Re: [rtcweb] RTP Usage: RTCP XR metrics

[Qin Wu <[e-mail]>]

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.

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.

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "Magnus Westerlund" <[e-mail]>; <[e-mail]>
Sent: Tuesday, February 19, 2013 11:21 PM
Subject: Re: [rtcweb] RTP Usage: RTCP XR metrics


I find the meaning of a lowercase "recommended" unclear. Do you mean an RFC 2119-style "RECOMMENDED", or a more general recommendation, akin to an RFC 2119 style "MAY"?

If the aim is that these block types are RECOMMENDED to be implemented, then I think more explanation is needed about why they're important for practically all WebRTC implementations, and under what circumstances it makes sense to omit these blocks. Such strong support for these metrics needs to be justified. 

Alternatively, if you mean that these RTCP XR blocks MAY be implemented, then I see little point in including such a long list, since it doesn't help interoperability. 

Colin


On 19 Feb 2013, at 05:10, Qin Wu wrote:
> I like to propose to add the following text to Section 8.
> For WebRTC application, audio and video are multiplexed onto a single RTP session. 
> the basic metrics for transport impairments provided in RTCP SR and RR packets
> should be mandatory to be implemented  in WebRTC end-points. However they may 
> be not adequate in some cases, e.g., transport impairement reported by RTCP SR and RR
> packets suggesting that quality is not an issue, such as the fact that interarrival jitter is not excessive. 
> However, problems may occur in the service layers leading to poor user experience.
> 
> To address the defeciency of RTCP SR and RR packets for performance monitoring, Packet Delay Metrics 
> Block, Packet Delay Variation Metrics Block, Burst Gap Loss Metrics Block, Burst Gap Loss Summary Metrics Block,
> Burst Gap Discard Metrics Block, Burst Gap Discard Summary Metrics Block, Jitter Buffer Metrics Block, Discard Metrics 
> Block, RLE Discard Metrics Block, QoE Metrics Block split from VOIP Metrics Block and all the Metrics Blocks defined in
> the RFC3611 other than VOIP Metrics Block are recommended to be implemented in WebRTC end-points if bandwidth is 
> not a concern since they are designed for both audio application and video application and can be used by network manager to
> troubleshoot network and ensure the quality of real-time application performance.
> 
> Regards!
> -Qin
> ----- Original Message ----- 
> From: "Magnus Westerlund" <[e-mail]>
> To: <[e-mail]>
> Cc: "Colin Perkins" <[e-mail]>
> Sent: Monday, February 18, 2013 10:07 PM
> Subject: [rtcweb] RTP Usage: RTCP XR metrics
> 
> 
> WG,
> 
> In Section 8 of
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ there is
> an open issue regarding RTCP XR.
> 
> The question is if any RTCP XR metrics should be mandated or recommended
> to be implemented in WebRTC end-points?
> 
> So far there has been some lukewarm interest in metrics, but no clear
> proposals on what to include.
> 
> As an author I like to either get some discussion going or be able to
> remove this open issue. So people, either make a proposal for what to
> include or we will remove the TBD and consider the question dealt with.
> Please note that there do exist signalling support for negotiating RTCP
> XR metrics to use in a particular session.
> 
> Submit any proposal no later than the 17th of March.
> 
> 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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Colin Perkins
http://csperkins.org/