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

Colin Perkins <csp@csperkins.org> Thu, 26 July 2012 07:09 UTC

Return-Path: <csp@csperkins.org>
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 3151511E8098 for <xrblock@ietfa.amsl.com>; Thu, 26 Jul 2012 00:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.261
X-Spam-Level:
X-Spam-Status: No, score=-103.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 wbA-i1WPVngH for <xrblock@ietfa.amsl.com>; Thu, 26 Jul 2012 00:09:34 -0700 (PDT)
Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 012F811E8093 for <xrblock@ietf.org>; Thu, 26 Jul 2012 00:09:34 -0700 (PDT)
Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SuICT-0003LN-Ze; Thu, 26 Jul 2012 07:09:33 +0000
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0407DBE958@307622ANEX5.global.avaya.com>
Date: Thu, 26 Jul 2012 08:09:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BA1DD8D-364F-4AE7-A9D5-CA596C526BB2@csperkins.org>
References: <D8C720B9E77243D0BE6C58CA45A2A735@china.huawei.com><88D9BF6DCE6840D3B896E0C0445265B9@china.huawei.com> <B0CC02A1-26A5-4089-A2C8-BDFEBAD941BE@csperkins.org> <EDC652A26FB23C4EB6384A4584434A0407DBE958@307622ANEX5.global.avaya.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
X-Mailer: Apple Mail (2.1278)
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 07:09:35 -0000

No, I think informative is fine. I wouldn't like to see this draft as encouraging the sort of duplication Alan Clark suggests is common, since it causes problem that are solved by using the rtp-duplication draft method.

Colin


On 26 Jul 2012, at 01:26, Romascanu, Dan (Dan) wrote:
> +1
> 
> ... but (question to Colin) - do you believe that this reference needs
> to be Normative? 
> 
> Dan
> 
> 
> 
> 
>> -----Original Message-----
>> From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On
>> Behalf Of Colin Perkins
>> Sent: Wednesday, July 25, 2012 10:59 AM
>> To: Qin Wu
>> Cc: xrblock@ietf.org
>> 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/
>> 
>> 
>> 
>> _______________________________________________
>> xrblock mailing list
>> xrblock@ietf.org
>> https://www.ietf.org/mailman/listinfo/xrblock



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