Subject: Re: your mail

From: Scott Shenker <[email-masked]>
Date: Tue, 18 Jul 1995 10:40:18 PDT

During the past few weeks there has been a very useful discussion on
this mailing list.  I wanted to respond briefly to a few of the
comments about guaranteed service (which I will denote by G).  There
have been two particularly important issues raised; let me address them
individually.

1)  Why not offer CBR service instead?

I am assuming here that CBR service provides an absolutely reliable
delay bound just like G service; the difference lies in the fact that
CBR's traffic descriptor is a peak rate (as opposed to G's token
bucket, which allows the source to send bursts).  I don't see much
difference in complexity in the scheduling algorithms required to
support the two services.  One can view CBR service as queueing the
packets on the edge of the network (using a leaky bucket to convert the
token bucket filtered stream into a peak rate filtered stream), whereas
G service allows some of this queueing to occur within the network
(which results in lower actual delays, but not lower delay bounds).
Which design should we adopt?

If all traffic were G traffic, and all G applications were nonadaptive,
then I would have little objection to adopting CBR service.  However,
there may be some adaptive applications that use G service (even though
this is not the main intent) and these applications would benefit from
the decreased delays of G service.  Also, the network will have traffic
other than G traffic; there will be, presumably, a mixture of G,
Predictive, Controlled-Delay, and Best Effort.  Allowing the G traffic
to burst, and then use otherwise idle link capacity, will decrease the
delays seen by these other classes of traffic.  The extent of this
decrease has not been verified, however.

I consider these two reasons to be of marginal importance.  However,
there is a third and more important reason why I favor G service over
CBR service.  The source determines the traffic characteristics (i.e.,
whether it is peak constrained or not).  However, it is, at least with
the RSVP set-up protocol, the receiver who determines the quality of
service.  Not all receivers of a given source will necessarily choose
the same service class.  A receiver cannot request CBR service unless
the source has peak-constrained its flow.  However, peak-constraining
the flow is a disadvantage for receivers requesting predictive service
(because it increases the delays).  Thus, using CBR service rather than
G service forces the source to determine which QoS will be requested
and alter its traffic accordingly.  If we use the current G service,
then all the proposed services use the same traffic descriptor and so
the source need not alter its traffic based on the service requests.
This is a big advantage, especially in a multicast context where
different receivers can request different service.

2)  Why don't we separate delay from throughput?

The current G spec links the service requested to a throughput rate.
Recent work on scheduling algorithms (starting with the work of Hui
Zhang on rate controlled servers; Roch's paper has subsequently
generalized these results and I also think Pawan has results along this
line) has shown that one can provide a large schedulability region by
separating the throughput characteristics of the traffic from the delay
target at the router.  This is great work; why aren't we adopting it in
the spec?  First, the most important issue is whether the current spec
allows routers to use these algorithms, and I fully believe that is the
case; however, I will pursue discussions with Roch and others to verify
this.  A second issue is whether the spec allows one to use the full
power of these algorithms, and the answer there is definitely not;
there are parts of the schedulability region that the spec cannot
access.  Why?  This has to do with the nature of the service request
(RSpec).  The argument is somewhat cumbersome to make in email, but I
will give a very brief version of it.  If the service request were an
actual per-hop delay value, then we could make use of the entire
schedulability region.  However, to effectively use per-hop delay
values as the per-hop service request requires that the set-up protocol
split up the end-to-end delay among the various hops.  This explicit
segmentation of delay is not a universal characteristic of set-up
protocols, and in fact the RSVP design explicitly rejects that
approach.  Instead, RSVP allows the receivers to specify the service
request an RSpec which is interpreted by each router along the path.
In this case, it makes more sense for the RSpec to not be a per-hop
delay value but rather a throughput rate.  We wanted the G spec to
allow both approaches; we think it does, but again perhaps further
discussions would help ensure that.  But the cost of allowing both
approaches is that we can't specify the per-hop delays in complete
generality.
  
My basic point here is that while the current spec does not allow us to
take advantage of the complete range of flexibility of these scheduling
algorithms, I think little is lost.  We do not expect that G traffic
will comprise the vast majority of the traffic in most networks, and so
the ability to squeeze in the maximal schedulability region is of
limited value.  Other traffic will be taking up the slack.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Jul 95 15:49:27 JST

> bucket, which allows the source to send bursts).

???

As ATM service is celled, ATM CBR service allows for burstiness.

							Masataka Ohta