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" <magnus.westerlund@ericsson.com>
> To: <rtcweb@ietf.org>
> Cc: "Colin Perkins" <csp@csperkins.org>
> 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  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

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