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

"Joseph Kopena" <tjkopena@cs.drexel.edu> Wed, 08 November 2006 06:56 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhhMg-0004MU-Cz; Wed, 08 Nov 2006 01:56:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhhMR-000492-Vq for ippm@ietf.org; Wed, 08 Nov 2006 01:56:36 -0500
Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhhJr-0001MD-PL for ippm@ietf.org; Wed, 08 Nov 2006 01:53:58 -0500
Received: by wx-out-0506.google.com with SMTP id t4so1697083wxc for <ippm@ietf.org>; Tue, 07 Nov 2006 22:53:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=anrQJPQRolEd3sgmov+1W+LPbeEqBbA9t0N2zFxFVWgR0Q1+lnL5bgSK2FENJBQu/tCL3VkYtRkxSBdnTKRJ3XZO+pXhiPoJC9MQMuvxZ7bNQXgVHfvd2S2y+1Sru8MzbnsAtc3c8xl9+ldhJjDcjDK8pKiPrBZkD/SEbhC7PI4=
Received: by 10.70.91.11 with SMTP id o11mr8830895wxb.1162968833256; Tue, 07 Nov 2006 22:53:53 -0800 (PST)
Received: by 10.70.110.14 with HTTP; Tue, 7 Nov 2006 22:53:53 -0800 (PST)
Message-ID: <13786f330611072253h4a27b73al73e02890f5c36174@mail.gmail.com>
Date: Wed, 08 Nov 2006 01:53:53 -0500
From: Joseph Kopena <tjkopena@cs.drexel.edu>
To: Matthew J Zekauskas <matt@internet2.edu>
Subject: Re: [ippm] comments on draft-ietf-ippm-bw-capacity-03.txt
In-Reply-To: <45515E56.9030606@internet2.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20061102204526.GA7641@firebird1.grc.nasa.gov> <45515E56.9030606@internet2.edu>
X-Google-Sender-Auth: 2a3bf5994aa9a646
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: ippm@ietf.org
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>
Errors-To: ippm-bounces@ietf.org

On 11/7/06, Matthew J Zekauskas <matt@internet2.edu> wrote:
> 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).

Hi,

After attending the IPPM meeting today for the first time (which was
quite interesting), I've been reading through some of the group's
standards and drafts.  I agree with this statement---the capacity
draft was the first I read, and it seemed perfectly reasonable on its
own.  For what they're worth, some comments follow.

Small nits:
* Pg. 5, "of of" has a redundant "of."
* Pg. 5, "IP layer bits" definition header is not capitalized.
* Pg. 6, in keeping with the rest of the document, "layer" in "We
define the IP Layer link capacity, C(L,T,I)" should not be
capitalized.
* Pg. 6, in the following "information" should perhaps be replaced with "layer":
   "The previous definitions specify a link's capacity, namely the IP
   information bits that can be transmitted across a link or path should"


Other thoughts:
* The definition of IP Layer Bits seems almost circular.  I don't
understand why it's defined as eight times the number of IP octets as
opposed to simply the bits received, unless that's a convention I'm
not aware of:

   IP layer bits:
      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.

Note also that the current definition defines IP Layer Bits as the
number of bits, wherease later in the document it's taken as the
actual bits, which makes more sense to me.  For example, note the
definition of IP Layer Link Capacity (emphasis added):

   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

I realize there's a history here I'm unaware of, but a definition I
would put forward would be something like:

  IP Layer Bits
    The bits received from the data link layer by the IP software of the
    destination's network layer.  This includes both the IP header as well as
    the packet payload.  Note that these are the information bits correctly
    received and able to be processed by the IP layer and are not
    necessarily equivalent to the non-frame bits transmitted over the
    physical medium.  This wolud be the case for example if the frame
    payload is compressed or padded to escape specific bit patterns, if
    errors are incurred during transmission rendering the data invalid as
    an IP packet, or if other non-IP data is being transmitted.

* The definiton of IP Layer Link Capacity defines it as the number of
correctly received IP Layer Bits.  Does this mean IP Layer Bits
includes incorrectly received bits?  Given Section 3.1 that would seem
to be the case, and should perhaps be the case (the definition above
includes this).

Just some thoughts.

Thx!

-- 
- joe kopena
  http://gicl.cs.drexel.edu/people/tjkopena/

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