Re: [Gen-art] Gen-ART review of draft-ietf-ippm-reporting-metrics-08
Al Morton <acmorton@att.com> Tue, 08 May 2012 15:12 UTC
Return-Path: <acmorton@att.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 BFE1711E807F for <gen-art@ietfa.amsl.com>; Tue, 8 May 2012 08:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.693
X-Spam-Level:
X-Spam-Status: No, score=-103.693 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, 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 F90HzVBIeWiF for <gen-art@ietfa.amsl.com>; Tue, 8 May 2012 08:12:53 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8D39B21F84E6 for <gen-art@ietf.org>; Tue, 8 May 2012 08:12:53 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 5f739af4.0.496717.00-438.1362821.nbfkord-smmo05.seg.att.com (envelope-from <acmorton@att.com>); Tue, 08 May 2012 15:12:53 +0000 (UTC)
X-MXL-Hash: 4fa937f541ab0ff8-85d97ab7abb825e47cdd893ee259976d3ec7bf0c
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q48FCqVx025016 for <gen-art@ietf.org>; Tue, 8 May 2012 11:12:53 -0400
Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q48FCmL3024966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <gen-art@ietf.org>; Tue, 8 May 2012 11:12:48 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for <gen-art@ietf.org>; Tue, 8 May 2012 11:12:26 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q48FCQhp010404 for <gen-art@ietf.org>; Tue, 8 May 2012 11:12:26 -0400
Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q48FCLX8009679 for <gen-art@ietf.org>; Tue, 8 May 2012 11:12:22 -0400
Message-Id: <201205081512.q48FCLX8009679@alpd052.aldc.att.com>
Received: from acmt.att.com (dn135-16-251-71.dhcpn.ugn.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120508150858gw10060lqoe>; Tue, 8 May 2012 15:08:59 +0000
X-Originating-IP: [135.16.251.71]
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 08 May 2012 11:13:31 -0400
To: "Vijay K. Gurbani" <vkg@bell-labs.com>, draft-ietf-ippm-reporting-metrics@tools.ietf.org
From: Al Morton <acmorton@att.com>
In-Reply-To: <4FA92CA5.7020903@bell-labs.com>
References: <4FA92CA5.7020903@bell-labs.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-RSA-Action: allow
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <acmorton@att.com>
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=1.0 c=1 a=dit6Jc5sqrAA:10 a=5BdZ5gd732QA:10 a=ofMgfj31e3]
X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8]
X-AnalysisOut: [UMqPvVAA==:17 a=azEeBXcERCOERiMjQvkA:9 a=RSA_syLTnGnTQ8z8b]
X-AnalysisOut: [wYA:7 a=CjuIK1q_8ugA:10 a=_W_S_7VecoQA:10 a=q4htw2QqTbiheL]
X-AnalysisOut: [az:21 a=X_4z4ktRHvr-via4:21]
Cc: henk@uijterwaal.nl, Wesley Eddy <wes@mti-systems.com>, General Area Review Team <gen-art@ietf.org>, matt@internet2.edu
Subject: Re: [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 15:12:54 -0000
Thanks for your review, please see replies below.
Al
At 10:24 AM 5/8/2012, Vijay K. Gurbani wrote:
...
- 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.
IPPM's metrics are able to be used in either the cap-I Internet
or the isolated test lab, and several BMWG RFCs reference IPPM
metric definitions. When the RFC 2330 considerations are followed,
these metrics are safe to use in any setting.
- - 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.
I'll add: "We estimate a practical bound on waiting time below."
- - 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.
To address Adrian Farrell's Comment, we've added path models for
the normal and loop cases, above each equation.
- - 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.
there's nothing special about n=5 and L=4.
Together n, L and TTL determine C_max, which I will note that
we use in the calculation, just to be clear.
- - 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):
I thought process *was* generic, but will try your suggested text.
Is "operations" sufficiently generic?
- 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.
I think that might be the Loss CDF, but this is the Delay CDF when
Lost Packets are assigned delay = +infinity.
The text says:
- "As further evidence of overlap, consider the Cumulative Distribution Function (CDF) of Delay when the value "positive infinity" is assigned to all lost packets."
on the same dimension...
- 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.
"user" is too vague and also has a strong precedent in the computer
networking context - we can add an adjective:
s/consumer/report consumer/
- - 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."
My grammar-checker accepted a slightly revised version,
with s/above/in section 4.1.1/
- - 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".
OK
- - 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.
So far, everybody else got it...
OK
- - 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.
- [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