[ippm] comments on draft-ietf-ippm-bw-capacity-03.txt

The IPPM Capacity draft authors have asked us to last call the document.
 As part of that, I re-read the draft, and have some comments, which I
already sent to the authors.  I mentioned this in the WG meeting today,
and repeat them here in case they stir up any other comments.

[chair hat off][except, maybe, for the security considerations section
at the end...]

--Matt

-=-=-
Nits
----

p3 "even ATM", strike the "even"

"affect the capacity also"; I don't like the dangling also,
how about dropping it or "also affect the capacity".
[I also didn't look up the right thing to do with the "also :)]

"roughly 155 Mbps": maybe we should be more precise.

Slightly More Substantial
-------------------------

I found the whole definitions section a bit backwards.  I don't have a
problem with the definitions themselves, but rather the sequence in
which requirements to understand the definitions generally follow the
definitions.

I think i'd reorganize section 2.  Here's one cut...  use it (or modify)
if you think it's better.

---snip---
2.  Definitions

   In this section, we specify definitions for capacity.  We begin by
   first defining "link" and "path" in our context, and then defining
   a baseline capacity that is simply tied to the physical properties
   of the link.

2.1 Paths and Links

   To properly define capacity, we need a notion of link and path that
   is broader, but yet still consistent with, the definitions in the
   IPPM Framework document [RFC2330].  In particular, we need to be
   able to have a link between two network devices that are not
   necessarily IP-aware.  (Consider, for example, an Ethernet switch
   where the router uplink is 1000baseT, but hosts are connected using
   100baseT.)

   A link L connects two network devices, called nodes.  Nodes
   could be hosts, routers, Ethernet switches, or any other device where
   input links could have different characteristics than the output
   link.  It is not useful in this context to disambiguate layer 1
   circuits into component parts (such as connections between two dense
   wave division multiplexing nodes).

   We define a path P of length n as a series of links (L1, L2,
   ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1).  A
   source, S, and destination, D, reside at N1 and Nn+1 respectively.
   Furthermore, we define a link L as a special case where the path size
   is one.

2.2 Definition: Nominal Physical Link Capacity

   The nominal physical link capacity, NomCap(L), is the theoretical
   maximum amount of data that the link L can support.  For example,
   an OC 3 link would be capable of roughly 155 Mbps.  We stress that
   this is a measurement at the physical layer and not the network
   IP layer, which we will define separately.  While NomCap(L) is
   typically constant over time, there are links whose characteristics
   may allow otherwise, such as the dynamic activation of additional
   transponders for a satellite link.

   The nominal physical link capacity is provided as a means to help
   distinguish between the commonly used link layer capacities and the
   remaining definitions for IP layer capacity.  As a result, the value
   of NomCap(L) does not influence the other definitions presented in
   this document.

2.3 Capacity at the IP Layer

   There are many factors that can reduce the IP information carrying
   capacity of the link, some of which have already been discussed in
   the introduction.  However, the goal of this document is not to
   become an exhaustive list of of such factors.  Rather, we outline
   some of the major examples in the following section, thus providing
   food for thought to those implementing the algorithms or tools that
   attempt to measure capacity accurately.

   The remaining definitions are all given in terms of "IP layer bits"
   in order to distinguish these definitions from the nominal physical
   capacity of the link.

2.3.1 Definition: IP Layer Bits
   IP layer bits are defined as eight (8) times the number of octets
   in all IP packets received, from the first octet of the IP header
   to the last octet of the IP packet payload, inclusive.
{mjz this is another "seems backwards" thing, but I guess IP does define
 everything in terms of octets...}

   IP layer bits are recorded at the destination, D, beginning at time T
   and ending at a time T+I. Since the definitions are based on
   averages, the two time parameters, T and I, must accompany any report
   or estimate of the following values in order for them to remain
   meaningful.  It is not required that the interval boundary points
   fall between packet arrivals at D. However, boundaries that fall
   within a packet will invalidate the packets on which they fall.
   Specifically, the data from the partial packet that is contained
   within the interval will not be counted.  This may artificially bias
   some of the values, depending on the length of the interval and the
   amount of data received during that interval.  We elaborate on what
   constitutes correctly received data in the next section.

2.3.2 Definition: IP Layer Link Capacity

   We define the IP Layer link capacity, C(L,T,I), to be the maximum
   number of IP layer bits that can be transmitted from the source S
   and correctly received by the destination D over the link L during
   the interval [T, T+I], divided by I.

   Using this, we can then extend this notion to an entire path, such
   that the IP layer path capacity simply becomes that of the link with
   the smallest capacity along that path.

2.3.3 Definition: IP Layer Path Capacity

      C(P,T,I) = min {1..n} {C(Ln,T,I)}

   The previous definitions specify a link's capacity, namely the IP
   information 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.

2.3.4 Definition: IP Layer Link Usage

   The average usage of a link L, Used(L,T,I), is the actual number
   of IP layer bits from any source, correctly received over link L
   during the interval [T, T+I], divided by I.

   An important distinction between usage and capacity is that
   Used(L,T,I) is not the maximum amount, but rather, the actual amount
{mjz: inserted "sent" below, since that is important, as in 3.1}
   of IP bits sent that are correctly received.  The information
   transmitted across the link can be generated by any source,
   including those who may not be directly attached to either side of
   the link.  In addition, each information flow from these sources may
   share any number (from one to n) of links in the overall path between
   S and D. Next, we express usage as a fraction of the overall IP layer
   link capacity.

2.3.5 Definition: Average IP Layer Link Utilization

      Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) )

   Thus, the utilization now represents the fraction of the capacity
   that is being used and is a value between zero, meaning nothing is
   used, and one, meaning the link is fully saturated.  Multiplying the
   utilization by 100 yields the percent utilization of the link.  By
   using the above, we can now define the capacity available over the
   link as well as the path between S and D. Note that this is
   essentially the definition in [PDM].

2.3.6 Definition: IP Layer Available Link Capacity

      AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) )

2.3.7 Definition: IP Layer Available Path Capacity

      AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)}

   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.

---snip---
The notion of "sent and correctly received" is central to all of
these definitions, and I wonder if it shouldn't be moved up to section 2.
Similarly the notion of time is central, and I think I would also move that
up in section 3.

the duplicate discussion was also a bit confusing.

   depending on framing overhead to send the duplicates, etc.  Thus, a
   value for C(L,T,I) and AvailCap(L,T,I) will reflect the duplication
   with the lower value.

   depending on framing overhead to send the duplicates, etc.  Since
   all the definitions are based on SENT bits that are correctly
   received, duplicates are not counted, either in usage or capacity.
   Thus, a value for C(L,T,I) and AvailCap(L,T,I) will reflect the
   duplication,  reporting X instead of 2X.

Security considerations: while I believe what you wrote is technically
correct, we've always given advice to those that might actually
implement something to report the definitions.  I've added words mostly
stolen from 2330.

   This document specifies definitions regarding IP traffic traveling
   between a source and destination in an IP network.  Since they are
   only definitions, they do not raise any security issues and do not
   have a direct impact on the networking protocol suite.

   That said, it should be recognized that actually measuring these
   quantities by conducting Internet measurements can raise both
   security and privacy concerns.  Active techniques, in which traffic
   is injected into the network, can be abused for denial-of-service
   attacks disguised as legitimate measurement activity.  If
   recognizable, the active techniques themselves could lend themselves
   to malicous manipulation. Passive techniques, in which existing
   traffic is examined, can expose the contents of Internet traffic to
   unintended recipients.  Thus any specification of measurement
   techniques must include a corresponding discussion of security
   considerations.

References:

The reference to 2119 is dangling, and should be deleted.

I think 1812, at least, needs to be "normative" (although you could
argue about whether normative is necessary for an informational draft
too).  You need to understand the IP header validation requirements.
You could make the ref informative by importing the text, and then
including a reference to note where it came from.

2330, maybe, as well, since the document talks about differences from
that document (although I'm less positive it's needed; I *think* the doc
stands alone w/o reading 2330).

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