[Tsvwg] FW: LC review: draft-ietf-tsvwg-rsvp-bw-reduction-01.txt
Allison Mankin <mankin@psg.com> Sun, 22 January 2006 17:16 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ip2-0001Rr-2K; Sun, 22 Jan 2006 12:16:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ioy-0001Rf-NB for tsvwg@megatron.ietf.org; Sun, 22 Jan 2006 12:16:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02901 for <tsvwg@ietf.org>; Sun, 22 Jan 2006 12:14:39 -0500 (EST)
Message-Id: <200601221714.MAA02901@ietf.org>
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0iyA-0005nz-25 for tsvwg@ietf.org; Sun, 22 Jan 2006 12:25:38 -0500
Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <mankin@psg.com>) id 1F0iou-000PHn-Vh for tsvwg@ietf.org; Sun, 22 Jan 2006 17:16:04 +0000
To: tsvwg@ietf.org
Date: Sun, 22 Jan 2006 09:16:04 -0800
From: Allison Mankin <mankin@psg.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Subject: [Tsvwg] FW: LC review: draft-ietf-tsvwg-rsvp-bw-reduction-01.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mankin@psg.com
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Sender: tsvwg-bounces@ietf.org
Errors-To: tsvwg-bounces@ietf.org
Here's a Last Call Review for the RSVP Bandwidth Reduction draft from the General Area's Directorate Reviewer. Allison ------- Forwarded Message Date: Sat, 21 Jan 2006 22:53:57 -0500 To: "Mary Barnes" <mary.barnes@nortel.com>,<gen-art@ietf.org> From: "Joel M. Halpern" <joel@stevecrocker.com> Subject: Re: LC review: draft-ietf-tsvwg-rsvp-bw-reduction-01.txt Cc: Allison Mankin <mankin@psg.com>,jmpolk@cisco.com,sdhesika@cisco.com I was selected as General Area Review Team reviewer for this specification (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). This document is ready for publication as a proposed standard. One minor (but complicated) question does occur to me reading this document. There are also two nits that should be considered when and if there is a need to revise this document. The minor question is about the possible ill effects of support for this extensions. Suppose that all relevant routers support this extension. Suppose that there is a router with 40 units of reservation capacity, and two low priority flows each of 20 units. A new high priority request comes in requesting 20 units of capacity. Without this mechanism, there is no choice. One of the two low priority reservations would be thrown out. With this extension, the router might decide to ask both existing reservations to reduce themselves to 10 units. If the router could know that the flows could be throttled, this would probably be the right thing to do. However, if the flows can not be throttled, I think this will instead result in both flows being thrown off, and then a race to reestablish the flows. Thus, instead of disrupting one flow, two flows will be hurt for a time. I am not sure that is actually what this does. Even if I am correct, that is not a reason to refrain from publishing this. However, it would suggest a note of caution. Nit: In the example in section 3, it is confusing to use Flow A, Flow B and Aggregate A (Of Flows 1-5) and Aggregate B (Of flows A-E). Couldn't the aggregates be X and Y (or I and J, or...) Nit: In the example description in section 3.1, it would be helpful if the description of the 880k "offered" said "offered load". I was confused and thought it might mean offered capacity which would be completely backwards. Yours, Joel M. Halpern At 07:24 PM 1/17/2006, Mary Barnes wrote: >--------------------------- >Reviewer: Joel Halpern > >- 'A Resource Reservation Protocol Extension for the Reduction of >Bandwidth of > a Reservation Flow ' > <draft-ietf-tsvwg-rsvp-bw-reduction-01.txt> as a Proposed Standard > >IETF LC ends on 2006-01-26. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-bw-reduction-01.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg
- [Tsvwg] FW: LC review: draft-ietf-tsvwg-rsvp-bw-r… Allison Mankin
- Re: [Tsvwg] FW: LC review: draft-ietf-tsvwg-rsvp-… James M. Polk