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
- [ippm] WGLC on draft-ietf-ippm-bw-capacity-04.txt Henk Uijterwaal
- Re: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04… Mark Allman
- [ippm] AD review of draft-ietf-ippm-bw-capacity-0… Lars Eggert
- Re: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04… Matthew J Zekauskas
- RE: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04… Romascanu, Dan (Dan)
- Re: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04… Henk Uijterwaal
- Re: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04… Joseph Kopena