From: Chandrika Jayant (cjayant@cs.washington.edu)
Date: Tue Oct 26 2004 - 22:20:14 PDT
"Supporting Real-Time Applications in an Integrated Services Packet
Network:
Architecture and Mechanism"
Written by David D. Clark, Scott Shenker, and Lixia Zhang
Reviewed by Chandrika Jayant
This paper proposes an Integrated Services Packet Network (ISPN)
architecture that supports real-time services (guaranteed and predicted)
while also accommodating datagram traffic. Though guaranteed real-time
service is the ideal for users, the authors of this paper argue that
with cost benefits many users will be happy with a predicted but still
highly (successful) service especially with an incentive of lower cost.
The authors clearly show the needs of successful real-time streams (i.e.
appropriate playback point, dealing with jitter, and keeping packets in
order). How many packets can we lose? Do we need strict delay bounds or
just statistical ones? These questions lead to two main groups of
real-time apps: intolerant rigid (guaranteed) and tolerant adaptive
(predicted). The services shows make and commit services according to
their different needs. The authors make a logical distinction between
isolation and sharing. They show how isolation is natural for guaranteed
service (exemplified by WFQ) and sharing for predicted (ex. by FIFO). A
new scheme, FIFO+, is proposed to smoothes out jitter for multi-hop
sharing. Sharing is neatly wrapped in isolation to still protect from
malicious/greedy users so there are benefits from both properties.
Unified scheduling with FIFO+ is proposed to include all three types of
traffic- guaranteed rt, predicted rt, and datagram. Priority classes are
provided for isolation, jitter is "shifted" between classes.
Some problems I had with the paper: I would like to see more different
scheduling algorithms tested out (work-conserving and non). Some
percentage of bandwidth in unified scheduling needs to be reserved for
datagram traffic. 10% is suggested, I'd like to see more discussion.
Also, I am not completely convinced about the amount of users that will
use predicted service over guaranteed. I understand that making cost a
parameter, it gives an incentive for predicted service (and different
priority layers). But the authors do mention that the amount of
bandwidth and type of service requested can severely affect utilization-
if too many guaranteed services are requested, less users will be
satisfied. How can this be managed? I wanted more mechanism details
instead of all architecture.
At the time this paper was written, 1992, quality of service was
becoming a large issue as real-time networks were becoming increasingly
important and networks were expanding. The specific data for specific
network paradigm was becoming obsolete for many applications.
Future work mentioned included more solid work to do on admission
control, in a dynamic network setting. A sufficiently reliable predicted
service class needed to be better established. Also other scheduling and
queuing algorithms needed to be experimented with. A question which
seems to be in all the papers we are reading now, is this realistic to
implement? How easy would this be to deploy? How much to add to packets,
how much to make gateways do and end hosts do? It seems like adding all
this weight to the routers could be a hassle.
This archive was generated by hypermail 2.1.6 : Tue Oct 26 2004 - 22:20:28 PDT