From: Erika Rice (erice@cs.washington.edu)
Date: Tue Oct 26 2004 - 11:51:22 PDT
"Supporting Real-Time Applications in an Integrated Services Packet
Network: Architecture and Mechanism" by David Clark, Scott Shenker, and
Lixia Zhang:
In "Supporting Real-Time Applications in an Integrated Services Packet
Network: Architecture and Mechanism" David Clark, Scott Shenker, and
Lixia Zhang discuss the need for networks to be able to handle different
types of traffic. The current best effort system works well for
transferring data, but it does not work well for real-time applications.
Even within the domain of real-time applications there are different
needs.
The authors identify what they feel are the two primary need classes of
real-time applications: "rigid and intolerant" and "adaptive and
tolerant". Rigid and intolerant traffic needs a fixed and guaranteed
rate and cannot handle any interruptions. Adaptive and tolerant traffic
and deal with variation in the delivery rate and some interruptions.
The most interesting point in this paper is that an architecture that
has the best guarantees for everyone is not always the best. Completely
separating flows from the effects of others (like with weighted fair
queuing) can under utilize network resources. It also has the problem
that a burst from a single source can create a very large amount of
jitter for that source. For adaptive and tolerant traffic, it may be
better to give everyone a little jitter (because the network knows they
can handle it) rather than penalizing one person.
The result of these observations is that the most flexible architecture
might be one that allows different levels of traffic. There are hard
guarantees for some (needed rate always given), predictive guarantees
for others (if the network does not change, rates are given), and no
guarantees for other (the current best effort approach). Better
services would cost more, thus using economics to ensure balanced use of
the network. Such a plan would provide a flexible network architecture
that would allow everyone the service they need, but give them incentive
to ask for the lowest level of service they can handle.
This archive was generated by hypermail 2.1.6 : Tue Oct 26 2004 - 11:51:23 PDT