Subject: guaranteed rate service specification 7/15/95 14:38:00

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Sat, 15 Jul 95 16:29:54 EDT

Reference:  Your note of Sat, 15 Jul 1995 14:38:00 -0500 (CDT)

A few quick comments.  I'll respond more completely on Monday.

>1. To provide a bound on end-to-end delay: As I had mentioned earlier, a network
>does not need to be aware of the traffic spec for this purpose; at least for a
>broad class of scheduling algorithms.

The last point is the main source of disagreement from my perspective.
What you consider a broad class of algorithms is in my mind a restrictive
one.  In general, I'd reiterate that the main design goal for the specs
should to be avoid specifying ANY discipline or algorithm on how the
service is to be provided.

>be rather weak. The validity of such a service in large networks may
>be questionable. Furthermore, this type of service may require all the
>sources to conform to one particular type of specification (which
>may not be sufficient).

You'll have to be more specific than that, especially for the first
point.

>Though it is clear that the difference between  S_1 and  S_2 may be significant,
>the difference between S_2 and S_3 is much less clear. Given that S_3 implies
>assumptions about the traffic, I am not sure whether a network should
>try to exploit the difference between S_2 and S_3. In any case, it is
>desirable to design  the baseline service with minimal assumptions; additional
>assumptions may be added to derive enhanced services.

Again, I would disagree here.   I believe that S_3 can provide
significant benefits.  The baseline service should have minimal
restrictions on how the service is to be implemented, not minimal
assumptions.

>3. To  provision resources: Since a network providing deterministic guaranteed
>rate service can not overbook its resources, it may be best left to the source
>to explicitly request the resources (for example: throughput and buffer).

I view buffer as quite different from throughput.  The latter is of
direct relevance to the source, while the former implies some approach
on how to deliver a service.  Again, I don't really think this should
be specified.

>2. Buffer:  in the current spec, the token bucket parameter indirectly requests
>buffer from the network. Hence, a change in interpretation may be sufficient.

Same comment as above, but have no problem is possibly different
interpretations if they don't impose specific requirement on how to
support things in the network.

>3. Delay - if  a source requires delay different from what is guaranteed
>by the rate reservation, it  may specify an e2e delay bound. This may require
>the network to employ a two pass connection establishment method (e.g.
>tenet groups work) and may impact the RSVP protocol.

Correct, but RSVP is in a sense already two-pass (PATH and RESERVATION
messages) and there are ways of taking advantage of this.

>The current spec does not have provision for delay specification.
>D is a parameter which is dependent on the scheduling algorithm employed
>and is independent of source characteristics. In the current specs, the
>source does not specify D, only the network is aware of it. Moreover, the
>source needs  the ability to specify an e2e delay bound which can be split
>suitably across the nodes. Finally, if D is interpreted as local delay
>bound, then its interpretation  becomes overloaded.

Agreed, this was the original motivation for the first note.

>If a source requests resources explicitly (e.g. buffer),
>a network need not define the notion of compliant and non-compliant traffic.

Again, same remark as before.

>A solution based on a particular traffic spec may be even more restrictive.

Maybe, we can have several traffic specs but a generic service
description

Roch