From: Pravin Bhat (pravinb@u.washington.edu)
Date: Wed Oct 27 2004 - 07:57:50 PDT
Paper summary:
The paper proposes the Integrated Services Packet Network (ISPN) architecture
aimed at adding support for real-time applications that are
non-adaptive/fault-intolerant and adaptive/fault-tolerant applications. These
real-time applications cannot be accurately modeled in our current datagram
based model.
Limitations and Areas for improvement:
The algorithm assumes several things about the network
which may not be true.
- 85% of the traffic on the network shown in the paper
was real-time traffic. This is probably not true for
real world networks.
- The paper assumes that the network is guarded at the
edges to allow the rest of the network to work outside
a pure isolation model.
_ The paper assumes that network captivity in the recent
past is a good predictor of the services a network can
provide in the near future. However real-world networks
tend to have high variance in traffic load, self-similarity
and other complex behaviors.
The scheduling algorithm and the network architecture
presented in this paper would be really hard to deploy
in the real-world. The authors did not provide any
deployment plan on how their algorithm would work
with other existing technologies like the TCP during
the period of deployment. Also it would be very hard to
ensure that every network edge router enforced the
rule that no application violate the token-bucket filter
agreed upon at connection time.
The algorithm suffers from imprecise calculations of upper-bound on delays.
With TCP an application could figure out almost the exact delay for
the network at any given moment by sending some packets and checking their
RTTS. In the architecture proposed by the paper, the application would
provide its expected-rate/burst-bound and the network would return an
upper-bound on the max-delay. Unfortunately, to account for the worst case
scenario the network has to use an additive estimate (add delays for all
routers on the path). This can be grossly inaccurate and cause the application
to push-back playback for an unreasonable amount of time which would also require
a massive buffer.
While the bandwidth requirement for several applications
can be thought of as requiring a minimum rate of data transfer
it would be very hard to calculate the burst-bound for
many applications (which is required during the setup).
Video playback does not involve a lot human interaction and
such applications could potentially calculate their burstiness.
But application like multiplayer games or teleconferencing
involving real-time human-interactions would have a hard
time putting a tight bound on their burstiness.
Future work and relevance:
The paper is the right step in terms of thinking about the kind of
services the future internet would have to provide. Certainly
a growing number of applications can be modeled better using the
adaptive, fault-tolerant real-time networking model than the datagram
model we are used to.
As the paper admits for this architecture to be adopted a lot of
political, administrative and technical hurdles need to be overcome
first. Future work on this architecture would have to answer more
of the non-technical questions surrounding its deployment.
This archive was generated by hypermail 2.1.6 : Wed Oct 27 2004 - 07:57:51 PDT