[ippm] AD review of draft-ietf-ippm-bw-capacity-04.txt

Lars Eggert <lars.eggert@netlab.nec.de> Thu, 14 December 2006 10:54 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoEM-0000tU-EA; Thu, 14 Dec 2006 05:54:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoEL-0000sx-EO for ippm@ietf.org; Thu, 14 Dec 2006 05:54:25 -0500
Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuoEI-0003Rl-Rx for ippm@ietf.org; Thu, 14 Dec 2006 05:54:25 -0500
Received: from lars.local (p54AD127F.dip0.t-ipconnect.de [84.173.18.127]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4BBC713CF82; Thu, 14 Dec 2006 11:59:14 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 5740A2AEAEA; Thu, 14 Dec 2006 11:54:17 +0100 (CET)
In-Reply-To: <45767D65.7000207@ripe.net>
References: <45767D65.7000207@ripe.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: <2AEEA246-0CF5-4AC1-BF4C-8D6328811257@netlab.nec.de>
From: Lars Eggert <lars.eggert@netlab.nec.de>
Date: Thu, 14 Dec 2006 11:54:14 +0100
To: Henk Uijterwaal <henk@ripe.net>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1
Cc: ippm@ietf.org
Subject: [ippm] AD review of draft-ietf-ippm-bw-capacity-04.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0029536310=="
Errors-To: ippm-bounces@ietf.org

Hi,

I did the AD review as part of the WGLC. Solid document, some  
editorial nits.

Lars

Section 2.3.1.1, paragraph 0:
2.3.1.1  Standard or Correctly Formed Packets

   The "shoulds" and "should nots" in this section need to be "musts"  
and
   "must nots", according to both the first sentence of this section and
   section 5.2.2 of RFC1812. (Nit: Since there is no section 2.3.1.2,
   omit the heading of 2.3.1.1?)


Section 2.3.3, paragraph 2:
 >    The previous definitions specify a link's capacity, namely the IP
 >    layer bits that can be transmitted across a link or path should  
the
 >    resource be free of any congestion.  Determining how much  
capacity is
 >    available for use on a congested link is potentially much more
 >    useful.  However, in order to define the available capacity we  
must
 >    first specify how much is being used.

   I think what is meant by "should the resource be free of any
   congestion" is actually "if the full capacity is available for  
traffic
   between the source and destination." Also, is this paragraph in the
   correct section? It doesn't seem to talk about the path capacity
   metric.


Section 2.3.5, paragraph 0:
 > 2.3.5  Definition: Average IP Layer Link Utilization

   Nit: This is the only heading that has "average" in it, but other
   sections also define averages. Align headings.


Section 2.3.6, paragraph 1:
 >    AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) )

   A bit of explanatory text may be good.


Section 2.3.7, paragraph 2:
 >    Since measurements of available capacity are more volatile than  
that
 >    of capacity, it is important that both the time and interval be
 >    specified as their values have a great deal of influence on the
 >    results.  In addition, a sequence of measurements may be  
beneficial
 >    in offsetting the volatility when attempting to characterize
 >    available capacity.

   This reads as if it should be the start of section 3?


Section 4., paragraph 0:
 > 4.  Conclusion

   Nit: Suggest to move this after the IANA and security considerations.


Section 4., paragraph 1:
 >    In this document, we have defined a set of quantities related  
to the
 >    capacity of links in an IP network.  In these definitions, we have
 >    tried to be as clear as possible and take into account various
 >    characteristics that links can have.  The goal of these  
definitions
 >    is to enable researchers who propose capacity metrics to relate  
those
 >    metrics to these definitions and to evaluate those metrics with
 >    respect to how well they approximate these quantities.

   Nit: s/links/links and paths/g


Section 8.2, paragraph 2:
 >    [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
 >               RFC 1812, June 1995.

   Probably needs to be cited normatively.


Section 8.2, paragraph 3:
 >    [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
 >               "Framework for IP Performance Metrics", RFC 2330,
 >               May 1998.

   Needs to be cited normatively.

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm