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

"Joseph Kopena" <tjkopena@cs.drexel.edu> Thu, 21 December 2006 14:18 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOkt-0005yw-KW; Thu, 21 Dec 2006 09:18:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOks-0005yr-Qw for ippm@ietf.org; Thu, 21 Dec 2006 09:18:42 -0500
Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxOkr-0000ox-I0 for ippm@ietf.org; Thu, 21 Dec 2006 09:18:42 -0500
Received: by wx-out-0506.google.com with SMTP id h27so2453483wxd for <ippm@ietf.org>; Thu, 21 Dec 2006 06:18:41 -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=VK0ajVdL5DIOo0WlKlw7Viv/TuDQ5VVs+AZfFs0qiEDC1LNcuxY9HLpTjObbuc+FzUPLhyf0iG3lbNz/r4EiXurwFY8TV5ZS2Gcvf7LNWlOkNuuBFNO1rGtBAf7ZLXV1Y/JZvgQ/m4Qu5SOiGbhgHZ+cOBO5CEhiORz1SJDeo3c=
Received: by 10.70.15.15 with SMTP id 15mr14344340wxo.1166710720079; Thu, 21 Dec 2006 06:18:40 -0800 (PST)
Received: by 10.70.113.6 with HTTP; Thu, 21 Dec 2006 06:18:40 -0800 (PST)
Message-ID: <13786f330612210618q28c3968j832ada79364f0d4e@mail.gmail.com>
Date: Thu, 21 Dec 2006 09:18:40 -0500
From: Joseph Kopena <tjkopena@cs.drexel.edu>
To: Henk Uijterwaal <henk@ripe.net>
Subject: Re: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04.txt
In-Reply-To: <458A32A6.8020506@ripe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45767D65.7000207@ripe.net> <458A32A6.8020506@ripe.net>
X-Google-Sender-Auth: 69c847b155e16906
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
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 12/21/06, Henk Uijterwaal <henk@ripe.net> wrote:
> 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,

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

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