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

Alan Clark <alan.d.clark@telchemy.com> Thu, 26 July 2012 01:00 UTC

Return-Path: <alan.d.clark@telchemy.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 BA97011E8073 for <xrblock@ietfa.amsl.com>; Wed, 25 Jul 2012 18:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_46=0.6]
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 tBUDXRgIjSA2 for <xrblock@ietfa.amsl.com>; Wed, 25 Jul 2012 18:00:40 -0700 (PDT)
Received: from smtp01.myhostedservice.com (smtp01.myhostedservice.com [216.134.213.70]) by ietfa.amsl.com (Postfix) with ESMTP id BA42F21F8606 for <xrblock@ietf.org>; Wed, 25 Jul 2012 18:00:39 -0700 (PDT)
Received: from mail01.netplexity.net (172.29.251.14) by SMTP01.netplexity.local (172.29.211.9) with Microsoft SMTP Server id 14.0.722.0; Wed, 25 Jul 2012 21:00:39 -0400
Received: from [192.168.1.7] (c-24-98-22-58.hsd1.ga.comcast.net [24.98.22.58]) by mail01.netplexity.net with SMTP; Wed, 25 Jul 2012 21:00:29 -0400
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Jul 2012 21:00:27 -0400
From: Alan Clark <alan.d.clark@telchemy.com>
To: Colin Perkins <csp@csperkins.org>, Qin Wu <bill.wu@huawei.com>
Message-ID: <CC360EEB.4859B%alan.d.clark@telchemy.com>
Thread-Topic: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt
Thread-Index: Ac1qygtaO8CrcpU/cUSwLW+LPG8VfA==
In-Reply-To: <B0CC02A1-26A5-4089-A2C8-BDFEBAD941BE@csperkins.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
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 01:00:40 -0000

Colin

I agree that it is a very inefficient way to do error correction and does
the network no good at all - however some widely available commercial
desktop videoconferencing products do this (and I don't think they use
draft-ietf-avtext-rtp-duplication-00 as using the simplistic approach
requires no changes to the receiver).

It would be a good idea to refer to draft-ietf-avtext-rtp-duplication-00 as
an informative reference - however as I don't think this would result in any
duplicate packets being counted for the report (as the redundant stream uses
a separate SSRC) we should still identify that "non-standard" approaches may
give a high duplicate packet count. For example


(b) If the number of duplicate packets is very high then this may be due to
a simple and non standard form of RTP redundancy - simple RTP replication.
Properly architected RTP redundancy such as
draft-ietf-avtext-rtp-duplication-00 would not lead to a redundant packets
being reported as duplicates.
In the former (non-standard) case the number of duplicate packets can be
compared 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).

Regards

Alan

On 7/25/12 3:58 AM, "Colin Perkins" <csp@csperkins.org> wrote:

> 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.