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

Colin Perkins <> Fri, 17 August 2012 16:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 609C821F84EC for <>; Fri, 17 Aug 2012 09:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ej-HQMwu7ib6 for <>; Fri, 17 Aug 2012 09:12:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6241A21F84D2 for <>; Fri, 17 Aug 2012 09:12:27 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1T2P9u-0002NN-bm; Fri, 17 Aug 2012 16:12:26 +0000
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_631B152A-61EA-4A6A-842D-F2AFDCAFC082"
From: Colin Perkins <>
In-Reply-To: <>
Date: Fri, 17 Aug 2012 19:12:24 +0300
Message-Id: <>
References: <> <> <>
To: Kevin Gross <>
X-Mailer: Apple Mail (2.1278)
Subject: Re: [xrblock] proposed change to discard draft for the issue: duplication packet discards
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Aug 2012 16:12:28 -0000


On 17 Aug 2012, at 18:11, Kevin Gross wrote:
> I don't think it is necessary or appropriate to include this sort of value judgement. What is expensive? What is necessary? At best, this is getting tangential. I support the original wording of Qin's note though I think it should be a separate paragraph and perhaps marked as a note.

Qin's original wording seems to me to be encouraging duplication. I do not support that, since it does break RTCP statistics if done in the naïve way implied. I'm happy if someone wants to propose a more neutral wording, part-way between my suggestion and Qin's text.

> As for the applicability discussion, what I'm looking for is: how will this information be used by the entity or entities receiving it? It is already clear from the other text in the draft _what_ is being reported. We don't need to repeat that here. What needs to be clarified and justified is _why_ and to _whom_ this information is useful.
> Clearly the information is useful to receivers who may adjust their jitter buffers based on the information. But they can do this internally and I don't see a need for them to transmit the raw information on which they're acting.
> Clearly the information is useful to network managers who may wish to tune or troubleshoot their networks based on this feedback. But isn't SNMP, a more appropriate reporting channel for these purposes?
> To justify RTCP reporting of this information, I think it needs to be demonstrably useful to the sender(s) and other receivers in the session. I personally can't think of a direct use for this information by these entities. If there is one (or two...), that's what I wish to see included in the applicability discussion. If there isn't one, it calls into question the need to finish this work.

I generally agree, although RTCP is at least potentially appropriate for network management purposes. 

Colin Perkins