Re: [rtcweb] RTP Usage: RTCP XR metrics

Qin Wu <bill.wu@huawei.com> Tue, 19 February 2013 05:10 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B4921F8D46 for <rtcweb@ietfa.amsl.com>; Mon, 18 Feb 2013 21:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.029
X-Spam-Level:
X-Spam-Status: No, score=-5.029 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWaYKXFrwYUs for <rtcweb@ietfa.amsl.com>; Mon, 18 Feb 2013 21:10:37 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C070F21F8D0D for <rtcweb@ietf.org>; Mon, 18 Feb 2013 21:10:35 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOO83490; Tue, 19 Feb 2013 05:10:34 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Feb 2013 05:09:51 +0000
Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Feb 2013 05:10:31 +0000
Received: from w53375 (10.138.41.149) by szxeml449-hub.china.huawei.com (10.82.67.192) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Feb 2013 13:10:27 +0800
Message-ID: <BFCD1C49F8A7451C8A9279B1C95B58DD@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, rtcweb@ietf.org
References: <512235A8.4000700@ericsson.com>
Date: Tue, 19 Feb 2013 13:10:26 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Cc: Colin Perkins <csp@csperkins.org>
Subject: Re: [rtcweb] RTP Usage: RTCP XR metrics
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2013 05:10:37 -0000

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