[Gen-art] Gen-ART review of draft-ietf-ippm-reporting-metrics-08
"Vijay K. Gurbani" <vkg@bell-labs.com> Tue, 08 May 2012 14:20 UTC
Return-Path: <vkg@bell-labs.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FD321F845C for <gen-art@ietfa.amsl.com>; Tue, 8 May 2012 07:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.69
X-Spam-Level:
X-Spam-Status: No, score=-109.69 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dWXLTdSWHsPx for <gen-art@ietfa.amsl.com>; Tue, 8 May 2012 07:20:16 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7703621F845A for <gen-art@ietf.org>; Tue, 8 May 2012 07:20:12 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q48EJT4g027392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 09:19:31 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q48EJTbo026092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2012 09:19:29 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q48EJOxH025958; Tue, 8 May 2012 09:19:24 -0500 (CDT)
Message-ID: <4FA92CA5.7020903@bell-labs.com>
Date: Tue, 08 May 2012 09:24:37 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: draft-ietf-ippm-reporting-metrics@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Cc: henk@uijterwaal.nl, Wesley Eddy <wes@mti-systems.com>, General Area Review Team <gen-art@ietf.org>, matt@internet2.edu
Subject: [Gen-art] Gen-ART review of draft-ietf-ippm-reporting-metrics-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 May 2012 14:20:17 -0000
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ippm-reporting-metrics-08 Reviewer: Vijay K. Gurbani Review Date: May-08-2012 IETF LC End Date: April-11-2012 IESG Telechat date: May-10-2012 Summary: This draft is ready as an Informational but has some minor issues and nits that should be fixed before publication. Major issues: 0 Minor issues: 6 Nits/editorial comments: 5 Minor issues: - S3.1: I suspect that the metrics like packet loss and packet delay discussed in S3.1 are for hosts on the (I)nternet and not in a laboratory setting, yes? If so, it may be good to state this. - S4.1: I would mention at the end of the paragraph that you intend to fill the gap in RFC2680 by providing a reasonable value for the waiting time. - S4.1.1: In Figure 1, t_0 is probably the delay in the initial link before you get to the first router. If so, please make this explicit. - S4.1.1: Just curious --- you provide a rationale for the choice of link delay of 100ms and queue length of 100ms. But n=5 and L=4 seem to be magic numbers. I suspect that the choice of these is sound, but a couple of words on why the values of these variables are set to the ones shown would be good. - S5.1.1: In the two bullet items here, you posit that processes are spawned when an unexpected condition occurs. Why should this be a process? Why not a thread? Or a light-weight process? Or an event loop? My point is to stay away from well known and contextual words that dictate a specific architecture; i.e., the receiver spawns processes to handle an event. Better to be generic, something like the following (please modify as you see fit): OLD: o Packets that arrive within expected tolerance are handled by processes that remove headers, restore smooth delivery timing (as in a de-jitter buffer), restore sending order, check for errors in payloads, and many other operations. o Packets that do not arrive when expected spawn other processes that attempt recovery from the apparent loss, such as retransmission requests, loss concealment, or forward error correction to replace the missing packet. NEW: o Packets that arrive within expected tolerance are handled by removing headers, restoring smooth delivery timing (as in a de-jitter buffer), restoring sending order, checking for errors in payloads, and many other operations. o Packets that do not arrive when expected lead to an attempted recovery from the apparent loss, such as retransmission requests, loss concealment, or forward error correction to replace the missing packet - S5.1.2: Figure 3 --- if I understand the surrounding text for Figure 3 correctly, then to show a "small fraction of packets are lost", the CDF curve should be asymptotic to the Y-axis and then become stable at the Y=1 value (i.e., be asymptotic to it). We want to denote that almost 100% of the packets exhibit a loss close to 0. Nits: - S1: While characterizing the main audience, I am not sure what "consumer" means --- is it synonymous with "user"? And if so, I think that replacing consumer with user may be better. If these terms are not synonymous, then please provide a definition (even a loose one) of what a consumer is. - S3.1, seems like a grammatical error in the sentence: "We have calculated a waiting time above that should be sufficient to differentiate between packets that are truly lost or have long finite delays under general measurement circumstances, 51 seconds." Probably better to rephrase as: "We have calculated that under general measurement circumstances, 51 seconds is an appropriate length of time to differentiate between packets that are truly lost from packets that are experiencing long finite delays." - S4.1.1: Right before Figure 1, you define D. My suggestion would be to replace the text: "The normal path delay across n hops without encountering a loop, D, is" with "The normal path delay, D, across n hops without encountering a loop is" Here, "D" is qualifying the delay, not the loop. So it is best close to the word "delay". - S5.1.2: In Figure 3, I would suggest using "+Inf" instead of "+o0" to denote infinity. It took me a while to figure out that the latter is an ASCII approximation to infinity. - S6.6: In the section heading, I would advise spelling out "Avail." completely. Truncating it as such serves no purpose that I could see and simply acts as a detraction. Thanks! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/
- [Gen-art] Gen-ART review of draft-ietf-ippm-repor… Vijay K. Gurbani
- Re: [Gen-art] Gen-ART review of draft-ietf-ippm-r… Al Morton
- Re: [Gen-art] Gen-ART review of draft-ietf-ippm-r… Vijay K. Gurbani