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

Colin Perkins <csp@csperkins.org> Fri, 17 August 2012 16:12 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 609C821F84EC for <xrblock@ietfa.amsl.com>; Fri, 17 Aug 2012 09:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej-HQMwu7ib6 for <xrblock@ietfa.amsl.com>; Fri, 17 Aug 2012 09:12:27 -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 6241A21F84D2 for <xrblock@ietf.org>; Fri, 17 Aug 2012 09:12:27 -0700 (PDT)
Received: from [194.86.25.98] (helo=[10.2.1.205]) by lon1-post-2.mail.demon.net 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 <csp@csperkins.org>
In-Reply-To: <CALw1_Q0EHyf98AFt4O=53BKAKtQAq4cyUZKqA1DeoPs1dovxNw@mail.gmail.com>
Date: Fri, 17 Aug 2012 19:12:24 +0300
Message-Id: <05210899-B3BD-4E02-99A4-71469B6B12E6@csperkins.org>
References: <CC53B1A9.4935B%alan.d.clark@telchemy.com> <D04380D1-7EC7-4F4C-A22B-EEE374A452A8@csperkins.org> <CALw1_Q0EHyf98AFt4O=53BKAKtQAq4cyUZKqA1DeoPs1dovxNw@mail.gmail.com>
To: Kevin Gross <kevin.gross@avanw.com>
X-Mailer: Apple Mail (2.1278)
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 16:12:28 -0000

Kevin,

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
http://csperkins.org/