Subject: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04.txt

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 06 Dec 2006 09:20:53 +0100

IPPM group,

The draft "Defining Network Capacity" (draft-ietf-ippm-bw-capacity-04.txt)
has been discussed extensively in this group and appears to be stable by
now.  We like to start a WGLC on it in order to move it forward.  Please
raise any remaining issues by Wednesday, December 20, 2006, 12:00 UTC.

An URL for the draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-04.txt

Matt & Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

# Lawyer: "Now sir, I'm sure you are an intelligent and honest man--"
# Witness: "Thank you. If I weren't under oath, I'd return the compliment."

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Mark Allman <[email-masked]>
Date: Tue, 12 Dec 2006 16:58:46 -0500

> We like to start a WGLC on it in order to move it forward.  Please

ship it

allman

---

From: Lars Eggert <[email-masked]>
Date: Thu, 14 Dec 2006 11:54:14 +0100

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.

---

From: Matthew J Zekauskas <[email-masked]>
Date: Tue, 19 Dec 2006 12:49:02 -0500

Just a reminder, we'd like any comment on the Defining Network Capacity
draft by COB Wednesday.  Thanks to those that have already commented...

--Matt

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 21 Dec 2006 08:07:18 +0100

IPPM group,

> http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-04.txt

We received a couple of last minute comments on the draft.  The authors
will address them in January, and we'll then decide if another WGLC is
needed or that the document can be moved to the IESG.  Happy holidays,

Henk

---

From: "Joseph Kopena" <[email-masked]>
Date: Thu, 21 Dec 2006 09:18:40 -0500

Hi,

Mostly just to add to the pool of people known to have read the draft,
I have also read through the latest version but was not able to get my
comments in on time yesterday.  The draft is reasonable, but I also
have some serious questions about it.

One minor point:

- pg 5, definition 2.1, "where the path size is one" should be "where
the path length is one."

- pg 10, discussion 3.4, the sentence "Also, the value of n that
satisfies..." can probably be worded more simply along the lines of
"Also, the link of minimum available capacity AvailCap(P, T, I) is
often referred to as the "tight link" within a path."

More serious points:

- There should perhaps be more emphasis or explanation that this is
really about path capacity.  The notions defined here are "network
capacity" from the perspective of one host to another specific host
along specific routes, not from the perspective of the network or even
across all hosts or all routes to one host.  In particular, MANET
literature often discusses network capacity in the sense of the entire
network, how many bits can be moving forward at one time between all
hosts.  This is particularly interesting in that setting because of
the conflicts in the following point.

- pg 7, definition 3.3, IP Layer Path Capacity.  This definition
assumes that the links are independent and do not affect each other.
The minimum capacity along the path does not necessarily provide a
lower bound on the path's capacity.  For example, this is the case on
multi-hop wireless networks, where each link may very well have
reasonable capacity, but communication (forwarding) on each link
hinders communication on the successor and predecessor links as they
can't both be live.  Note also that definitions which account for this
probably take care of congestion as well.  The note about congestion
in this definition is odd, although perhaps it's really trying to say
that this definiton does not address the above phenomenon of adjacent
links affecting each other?  In that case, this definition perhaps has
some value, but a metric which accounts for that would be more
intuitive and practically useful.

- pg 9, discussion 3.2, Hardware Duplicates.  This argument at least
needs more motivation.  It should point out that IP packets do have
IDs and can conceivably be identified as duplicates (do most
implementations set sensible IDs for non-fragmented packets or is it
ignored?).  Wouldn't most (all?) implementations simply pass duplicate
packets up the stack?  I would not have previously thought IP included
any checking for this.  In that case, it's not immediately obvious why
these are not included in the network capacity but corrupted data is.
Granted, it reduces the amount of data that can be transmitted.  But
so do corrupt packets.  That line of thought seems to rely on an
argument about measuring transport layer bits, which is not the goal
of this draft.  In short, I don't necessarily believe this definition
should be changed, but it's clear it will be a sticking point for most
readers and at a minimum needs to be stronger.  Also, the closing
sentence should read "reflect the duplication with a lower value" to
be slightly more clear, rather than "the lower value."

My apologies for the late comments.

Thx

-- 
- joe kopena
  shelter from the storm