Re: [Tsvwg] FW: LC review: draft-ietf-tsvwg-rsvp-bw-reduction-01.txt

["James M. Polk" <[e-mail]>]

Allison

Comments in-line

At 09:16 AM 1/22/2006 -0800, Allison Mankin wrote:
>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" <[e-mail]>,<[e-mail]>
>From: "Joel M. Halpern" <[e-mail]>
>Subject: Re:  LC review: draft-ietf-tsvwg-rsvp-bw-reduction-01.txt
>Cc: Allison Mankin <[e-mail]>,[e-mail],[e-mail]
>
>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.

This is not possible.  We purposely left out discussions of preemption, 
because that is not what this is doing *but* this is the way I read the 
example above, as a preemption event.  This ID is only discussing taking 
some BW from a flow, regardless of the type of flow (individual, aggregate 
or tunnel).

We also purposely left out how a router picks which flow to reduce 
from.  That is a separate idea, and there be dragons there, so we didn't 
want to go there with this doc.

Also, the router has no way of knowing either flow, meaning either set of 
endpoints per flow, is willing to accept this reduction, at least not in a 
reasonable timeframe.

>If the router could know that the flows could be throttled, this would
>probably be the right thing to do.

This seems like a new extension to be discussed, one in which there is 
something in the PATH and RESV messages indicating that a flow is willing 
to be reduced to some lower BW amount at a future time in the flow.  Only 
with this information can a router in the flow make a timely decision.

>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.

If this comment above, which seems a little out of context to me reading 
this, is stating a router can make a bad choice and reduce two flows by 10 
units each instead of one flow by 20, I have to ask where did a reader or 
coder come up with this idea?  I believe anyone who is trained in the art 
of RSVP coding will not code an implementation in this way without knowing 
of the pitfalls of this mistake to all flows they choose to reduce BW from.

If you want, I can add a comment something like this:

"Bandwidth SHOULD NOT be reduced across multiple reservations at the same 
time, in reaction to the same reduction event.  A router not knowing the 
impact of reservation bandwidth reduction on more than one flow may cause 
more wide spread ill effects than is necessary."

I think this leaves room for a future RSVP extension to "update" this 
document with how this can be done successfully.

>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...)

I could make this change as well, probably to Aggregates X and Y.

>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.

fair change request


>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
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/tsvwg

_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg