Subject: Resubmit - Comments on Controlled Delay Service

From: [email-masked]
Date: Mon, 17 Jul 95 20:49 EDT

It looks like my earlier mail to int-serv on this subject
did not make it to everyone. I am resending this mail - my apologies
in advance for duplication

keshav
----

Some comments regarding Internet-Draft on "Specification of
Controlled Delay Quality of Service" 

M. Grossglauser and S. Keshav

AT&T Bell Laboratories, Murray Hill

Abstract

An Internet Draft (ID) on Controlled Delay Service was distributed for 
comment on the int-serv mailing list recently. We have serious concerns 
about the technical correctness of this ID. Specifically a) the draft 
ignores some critical problems with leaky-bucket characterization b) the 
draft is vague about important issues - such what controlled delay 
service actually offers c) the draft ignores some other issues- such as how 
admission control is to be done.

Some of our comments also apply to the Guaranteed Service ID.
We hope our comments will result in a better version of the IDs for
future standardization.

1. Introduction

We have serious concerns regarding the ID recently distributed on
the int-serv mailing list "Specification of Controlled Delay Quality of 
Service".

In this note, we will first discuss problems with Leaky bucket
characterization, and then specific issues not properly addressed
in the ID.

2. Leaky Bucket Based Traffic Description

Both Controlled Delay (CD) and Guaranteed Quality (GQ) services expect
sources to describe themselves with a leaky bucket (LB) descriptor. 
However, there are some well known problems with LB descriptors, that
we will summarize here [1].

First, even if a stream is completely known in advance, it can be
described by multiple LB descriptors. That is, there is a free choice
of (rate, bucket size) pairs. Since some pairs will result in call 
acceptance and others in call rejection, what descriptor should a
user choose? Given an application specific delay bound, a good
constraint is to have (sigma/rho < delay bound) if the service
discipline is WFQ or some variant. For CD service, there is no
guideline at all, since there is no bound on queueing delay.
That is, no matter what (sigma, rho) a user chooses, the end-to-end
delay could still be pretty large, since nothing is guaranteed by 
the network. Thus, no `optimal' (sigma, rho) pair can be chosen.

Second, for online traffic (such as traffic generated on the fly
by compressing a video stream for a videoconference), the choice of
LB parameters is not obvious. If the service rate (rho) is too small,
then end-to-end delays would be large, if it is too large, then
the network provider would be paid more revenue than strictly
necessary. What LB parameters should an online source use?

Third, recent work has shown that compressed video streams show 
sustained peaks -  periods of time where the traffic rate is close
to the peak rate [1]. The amount of data carried in such a burst can
be as large as 100 Mbits. An LB descriptor is not adequate to 
represent this feature of compressed video streams. If the
rho parameter is chosen to be close to the peak rate of the 
stream, then the burst can be carried away quickly, but this is 
expensive for the stream. If the rho parameter is chosen to 
be close to the average rate, then when the sustained
burst appears, the CD guarantees on delay (such as they are) are likely
to be violated. Moreover, the sigma parameter would be quite large, so 
that GQ service would need to either provision large buffers (leading to
delays) or would have to turn the source away. Thus, no matter what
sigma,rho characterization is used, the LB descriptor seems inadequate 
to describe streams with sustained bursts at the peak rate.

(We feel that our paper on renegotiated constant bitrate service (RCBR) [2]
offers a different solution to the problem.)

3. Service Specification

The CD service definition is very vague. While user's traffic descriptor 
needs to be described to high precision (0.1%),  in contrast the service
description is fuzzy (using words like typical delays, excessive delays...). 

Specifically, the CD draft says "the resulting end-to-end service is one 
that offers applications several levels of delay to choose from". What the 
user actually gets is a set of three measurements from each router along the 
path. What meaning do these numbers have? All they say is that in the past
time measurement interval (which can be as long as one hour), a maximal
queueing delay was estimated (not even measured!) to be some value. That does
not seem to amount to much. The network does not guarantee that it will 
turn away enough requests so that an accepted call will get the delays 
it thought it would get when it entered the network. Since the service allows 
the router to accept flows as long as delays are not "excessive" (not a 
precise characterization!) if any router along the path feels that it is not
providing "excessive" delays, all the admitted calls could get service far
worse than what they thought they would get when they entered the network. 
And all this after they spend a lot of time characterizing their source to
within 0.1% with an LB descriptor!

The CD service provides three levels of delay at each router. What is
the motivation for this magic number? Why not two levels, or four?

The service description does not mention that level 1 has "typically" 
lower delays than level 2, this is only mentioned in the data handling
requirements section. Even there, an element only has to ensure that
"typical" level 2 delays are larger or equal to "typical" level 1 delays.
What is the meaning of "typical"? Is this the mean, median, 75th percentile?

The CD service nowhere mentions any incentive schemes to prevent all
users from piling on to priority 1. What incentive is there to prevent
this? Perhaps there is a pricing policy that the authors have in mind?

4. Architecture and Implementation

The CD and GQ services invoke a policer. Who implements the policer?
Do the authors really want a policer on every flow at every router?
That is quite expensive (each policer needs to keep state per flow, and the 
data transfer hardware has to be aware of this state), and does 
not seem to buy a user much at all.
While the authors seem happy to use draconian measures ("the packet will
be dropped") to make sure that users will stick to their traffic description,
in return, the service makes no attempt to provide reasonable assurances of
service quality ("typical end-to-end delays will be smaller than for
best-effort service"). Nor do they give any description or refer to
other papers on how the traffic specification would change as the traffic 
goes through multiplexors (routers). So, whats a user to do? Send in nicely
controlled traffic, and then an over-eager policer drops all their traffic
two hops down the line! As far as we know, there is no good way to
characterize a traffic stream after is has been multiplexed with other
streams, particularly when the scheduling discipline is unknown (CD service
does not specify any discpline). Why, then, the insistence on policing
at each hop?

The CD service does not specify the admission control policy. Is this
a deliberate omission? 

How does the user of a CD service choose a route that provides
acceptable QOS? It looks like the delays are available only
during callsetup. Any interaction with routing should be mentioned.

Definition of "overload" is left up to the vendors. What will the vendors
do, given their economic interest?

5. Evaluation 

The "Evaluation Section" only sketches a way to do measurements, without any 
hint at what desirable performance is. That is, it tells us how to
measure the performance of a network element, but does not tell us how to 
evaluate it (whether the element is acceptable or not). This is a major 
oversight.
 
The traffic descriptor at a merging point can be either max or sum of
individual descriptors. Which one should be used when, and why?

The ID correctly pointed out that descriptor of a flow changes "somewhat" from 
hop to hop. But, the change has to be described to 0.1% precision!

The ID says that when a user sees poor service, it should request 
better service. But, poor service indicates overload. What the 
authors suggest is that as congestion increases, all users ask
for better service, probably making the service worse for users
that don't ask for better service.  This would soon lead to all
users moving to level 1, with no motivation to leave.

6. Specific comments

  	6.1 Motivation section: If an application is sensitive to packet 
delivery delay, how can it simulataneously be prepared to adapt to 
dynamically changing delays? This looks like an oxymoron.

	It is not clear how the motivation for CD service differs from
the motivation for predictive service. In other words, why is int-serv
specifying both?

	6.2 Data handling requirements section:

	If "no quantitive specification of average, statistical or maximal
delays is required", then what "service" does an endpoint see that is
different from best-effort? It seems to me all the user gets is a "trust
me- I know what I'm doing" service from the network. Is that really
what users want? CD service seems to have all the mechanism of ATM-style
guaranteed service (LB descriptors, policing, admission control) without
any of the guarantees. I guess the claim is that this results in better
network utilization - but this claim is being implicitly made with no
research to back it up.

	The CD network element must maintain a very low level of packet
loss. Since it only turns away flows when the delays are "excessive",
flows are turned away only when queue occupancy is pretty high already.
That means, for low losses, the buffer sizes in the networks have to
be quite large. How expensive is this likely to be? How are the buffers
to be sized? What admission control criterion is going to be used to
make sure that packet losses are small?

	6.4 Resulting Service section:

	The service description is vague (perhaps intentionally so?).
While the goal of making several levels of delay per router visible
to an end-point seem reasonable, the service description does not have
anything to say about 1) what are the relative delays at each level
(though this is mentioned elsewhere) 2) whether these delays mean
anything at all, since they could be loose estimates 3) how the
delays given to a source depend on its traffic specification (as it
reads now, a source gets the same set of delays no matter how much
traffic it sends in, which makes sense only if there is considerable
speedup within the network, something that is not mentioned anywhere
in the ID).

	6.5 Example of Implementation section:
	Admission control seems to have crept in here.
  
7. Suggestions
	CD service seems to be something that is only slightly better
than best-effort, with a weak attempt to provide multiple levels of delay 
priorities at each router. Given this, we suggest that the service NOT 
require a LB descriptor, and that this descriptor NOT be policed. All
a user should do is to request some delay level, and flows could be
turned away if the measured delay exceeds some threshold INDEPENDENT 
OF THE NEW FLOW'S BEHAVIOR. By getting rid of policing and LB descriptors,
many of our concerns would go away. The service specification would then
be much simpler too.
	Perhaps this kind of weak QoS is what the authors had in mind
anyway. We do not see why all the other mechanism was introduced,
since it does not buy much performance for the user.

8. Conclusion

Without considerably more work (precise definition + extensive evaluation),
we do not see the value of CD service. Our arguments about the inadequacy
of leaky bucket also apply to Guaranteed Service. We suggest another version
of CD service that eliminates source characterization and policing, but
still provides much of the flavor of CD service.

9. References

[1] E. P. Rathgeb, "Policing of Realistic VBR Video Traffic in an 
    ATM Network", International Journal of Digital and Analog Communications 
    Systems, vol. 6, pp. 213-226, 1993

[2] M. Grossglauser, S. Keshav, D. Tse, "RCBR: A Simple and Efficient
    Service for Multiple Time-Scale Traffic", to appear in ACM Sigcomm 95.
	available from http://www.cs.att.com/csrc/keshav/papers.html