Re: [xrblock] proposed change to discard draft for the issue: duplication packet discards

Alan Clark <alan.d.clark@telchemy.com> Fri, 17 August 2012 12:30 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 DACC221F8499 for <xrblock@ietfa.amsl.com>; Fri, 17 Aug 2012 05:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Level:
X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_QP_LONG_LINE=1.396]
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 YHzjo1JuuIXs for <xrblock@ietfa.amsl.com>; Fri, 17 Aug 2012 05:30:55 -0700 (PDT)
Received: from smtp01.myhostedservice.com (smtp01.myhostedservice.com [216.134.213.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1975721F84B9 for <xrblock@ietf.org>; Fri, 17 Aug 2012 05:30:55 -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; Fri, 17 Aug 2012 08:30:45 -0400
Received: from [192.168.1.3] (c-24-98-22-58.hsd1.ga.comcast.net [24.98.22.58]) by mail01.netplexity.net with SMTP; Fri, 17 Aug 2012 08:30:43 -0400
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 17 Aug 2012 08:30:33 -0400
From: Alan Clark <alan.d.clark@telchemy.com>
To: Colin Perkins <csp@csperkins.org>, Qin Wu <bill.wu@huawei.com>
Message-ID: <CC53B1A9.4935B%alan.d.clark@telchemy.com>
Thread-Topic: [xrblock] proposed change to discard draft for the issue: duplication packet discards
Thread-Index: Ac18dBhWWZEZiZIQTU6uLXXoDbEwDA==
In-Reply-To: <B5993B33-80CB-49C6-87D6-DD10249488EE@csperkins.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="B_3428037044_4047401"
Cc: xrblock@ietf.org
Subject: Re: [xrblock] proposed change to discard draft for the issue: duplication packet discards
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: Fri, 17 Aug 2012 12:30:58 -0000

Colin

Since this draft is simply reporting measurements it may not be the right
place to make normative statements about the generation of RTP packets,
although it could of course comment on the approach.  The “MUST NOT” should
probably be incorporated in your draft related to RTP redundancy or into the
next rev of RFC3550.

Best Regards

Alan



On 8/17/12 8:02 AM, "Colin Perkins" <csp@csperkins.org> wrote:

> 
> On 16 Aug 2012, at 06:26, Qin Wu wrote:
> 
>> Hi,
>> Discard count metric block draft
>> (http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05)
>> supports reporting discards due to packet duplication.
>>  
>> It was suggested on the list to provide backgound information for duplication
>> packet discards.
>> In the Vancouver meeting,we re-discussed duplication packet discards issue.
>> It was pointed out
>> RTP packet duplication is not standard method and may break RTCP rules when
>> we do RTCP
>> statistics reporting.
>>  
>> Combining these comments and incorporated proposed change from Varun earlier
>> on the list,
>> I propose the following change to the defintion part of Discard Type.
>>  
>> OLD TEXT:
>> "
>>       An endpoint MAY send only one of the discard types (early, late,
>>       duplication packets discard) in one RTCP report or choose to
>>       report early (DT=1) and late (DT=2), duplication packets discard
>>       (DT=0) in separate block.  It MAY also send the combined early and
>>       late discard type (DT=2) in one RTCP compound packet, but not any
>>       other combination of the three Discard Types.  The endpoint MUST
>>       not report the the total number of discarded packets covering all
>>       three discard types.  Instead, two separate report blocks should
>>       be used to carry duplication packets discard and the combined
>>       early and late discard respectively.
>> "
>> NEW TEXT:
>> "
>>       An endpoint MAY report only one of the above four discard types
>>  blocks in an compound RTCP report in a reporting interval. It MAY
>>  also report a combination of discard types in a compound RTCP report
>>  but not all combinations are valid. The endpoint MAY report
>> duplicate packet discard (DT=0) block with any other discard (DT=1,
>> 2, or 3) block. Additionally, an endpoint MUST NOT report combined
>> discard (DT=3) block with early discard (DT=1) or late discard (DT=2)
>> report block. Note that duplicating RTP packets using RTP
>> replication may lead to breakage of RTP media streams or RTCP rules.
>>  In order not to disrupt all the RTCP statistics, it is recommended
>> to duplicate RTP packets as described in
>> [draft-ietf-avtext-rtp-duplication-00]
>>  which will not cause breakage.
>> "
> 
> This last sentence might be better written "In order not to disrupt RTCP
> statistics, systems MUST NOT blindly duplicate RTP packets. If it is essential
> to use duplication for robustness, the mechanism described in
> [draft-ietf-avext-rtp-duplication-00] MAY be used since it avoids breakage;
> however duplication is expensive, and is best avoided."
> 
> Colin
> 
> 
> 
>> Also in the meeting, Kevin raised we should add some text to clarify the use
>> cases and suggest to put into the section 1.4 applicability section.
>> I propose the following change to the section 1.4 as follows:
>> OLD TEXT:
>> "
>> 1.4 
>> <http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05#section-1.4
>> > .  Applicability
>> 
>>    This metric is believed to be applicable to a large class of RTP
>>    applications which use a jitter buffer.
>> "
>> NEW TEXT:
>> "
>> 1.4.  Applicability
>>  
>> This metric is believed to be applicable to a large class of RTP
>>  applications which use a jitter buffer. For example, in one reporting
>>  interval, when packets were received but dropped from the jitter buffer
>> due to either buffer underflow or buffer overflow or both, the discard count
>>  metric can be used to report such packet discards. In some other cases(e.g.,
>> desktop video conferencing), duplicating RTP packets using RTP replication
>> may be used by media receiver for error concealment.
>> These duplicated packets can be counted as discards when they are not used
>> and
>> dropped by application from jitter buffer, in such cases, the discard count
>> metric can be used to report such packet discards due to packet duplication.
>>  
>> "
>> Regards!
>> -Qin
>>  
>> _______________________________________________
>> xrblock mailing list
>> xrblock@ietf.org
>> https://www.ietf.org/mailman/listinfo/xrblock
> 
>