Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt

Qin Wu <bill.wu@huawei.com> Thu, 26 July 2012 04:54 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F060021F8594 for <xrblock@ietfa.amsl.com>; Wed, 25 Jul 2012 21:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.012
X-Spam-Level:
X-Spam-Status: No, score=-4.012 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-Pw-6eYXEIc for <xrblock@ietfa.amsl.com>; Wed, 25 Jul 2012 21:54:38 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 49CF421F8592 for <xrblock@ietf.org>; Wed, 25 Jul 2012 21:54:38 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIB90100; Thu, 26 Jul 2012 00:54:38 -0400 (EDT)
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Jul 2012 21:51:09 -0700
Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Jul 2012 21:50:59 -0700
Received: from w53375 (10.138.41.149) by szxeml423-hub.china.huawei.com (10.82.67.162) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Jul 2012 12:50:55 +0800
Message-ID: <B5019AC88FDD4BCDA6516222DF0A1419@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Colin Perkins <csp@csperkins.org>
References: <D8C720B9E77243D0BE6C58CA45A2A735@china.huawei.com> <88D9BF6DCE6840D3B896E0C0445265B9@china.huawei.com> <B0CC02A1-26A5-4089-A2C8-BDFEBAD941BE@csperkins.org>
Date: Thu, 26 Jul 2012 12:50:54 +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: xrblock@ietf.org
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jul 2012 04:54:40 -0000

I can see duplicating RTP packets in this way is different from what draft-ietf-avtext-rtp-duplication-00 is doing.
Duplicated RTP packet in this way is just a copy of the RTP packet that is duplicated and has the same SSRC,seqence number and
the whole payload while duplicated stream described in draft-ietf-avtext-rtp-duplication-00 is not.
One one hand, as discussed on the list, these injected duplicated traffic can be useful for the user to determine what
proportion of lost packets are being concealed by the process and improve receiving quality, 

On the other hand, inject too much such duplicated traffic may
challenge or overload network  which looks to me, is also applicable to the draft-ietf-avtext-rtp-duplication-00.
What am I missing? 

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <csp@csperkins.org>
To: "Qin Wu" <bill.wu@huawei.com>
Cc: <xrblock@ietf.org>
Sent: Wednesday, July 25, 2012 3:58 PM
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt


On 25 Jul 2012, at 07:49, Qin Wu wrote:
> Based on Alan's proposal to the open issue mentioed below, we like to add one new section after SDP signaling section as follows:
> "
> 6. Consideration for duplicate packets discards
> 
> Early/ late discards are usually regarded as a symptom of PDV due to congestion (or route changes) however duplicate packets discards have quite different causes.
> 
> (a) A few duplicate packets can indicate some form of Layer 1/2 LAN problem. This would not need to be an accurate measure - more of a general barometer.
> 
> (b) If the number of duplicate packets is very high then this may be due to RTP replication - and if this is the case then you would want to compare the number of duplicate packets to the number of received packets in the same time interval. If the duplicate packet count is X% of the received packet count, this indicates that a (100-X)% packet loss rate is being "hidden" by the replicated packets, and  it is very useful to know the actual loss rate(useful to indicate that replication should be kept "on" and helpful to know that there are some network issues that need to be investigated).
> "

Duplicating RTP packets in this way for robustness is a very bad idea, since - as you note - it disrupts all the RTCP statistics. If you need to send duplicate streams, draft-ietf-avtext-rtp-duplication-00 describes how to do it without breakage. If you are going to mention duplication, I'd recommend including a reference to the working group draft to show how to do it right.

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