Return-Path: 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 ; 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 ; 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 ; 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 ); 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 ; 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 ; 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 ; 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 ; 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 ; 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" , draft-ietf-ippm-reporting-metrics@tools.ietf.org From: Al Morton 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: 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 , General Area Review Team , 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:12:54 -0000 Hi Vijay,

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."
I think you've helped make our case, it's confusing to mix Loss and Delay
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...

- 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.
OK