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
- [ippm] comments on draft-ietf-ippm-bw-capacity-03… Matthew J Zekauskas
- Re: [ippm] comments on draft-ietf-ippm-bw-capacit… Joseph Kopena