Cell Relay Archive

[albert.e.manfredi@boeing.com]

In article <863e89rfs6.fsf@ironbridgenetworks.com>,
  James Carlson <carlson@ironbridgenetworks.com> wrote:

> ATM claims to solve problems with latency and jitter, but never
> addresses either (1) how complex the solution is relative to the
> problem at hand nor (2) other means to solve the problem.  Yes,
> latency and jitter do exist.  Any non-channelized system is going to
> see these effects.  Whether or not they're really a problem for
> well-designed applications is another matter entirely.
>
> (The problem with the concept of high-priority traffic is more easily
> illustrated with an analogy.  If I want a guaranteed seat on an
> airline, I have to pay extra AND I have to specify where I want to go.
> This works for large numbers of people, because we can, at least in
> principle, do global scheduling in advance.  If we had a system where
> I could say, "here's more money, but I won't tell you where I want to
> go until I show up," this would still work as long as there weren't
> very many people trying this -- in other words, if the price were high
> enough.  The problem with both SVCs in ATM and QoS in IP is that
> people are asking not to reveal where they want to travel, and they're
> apparently presuming that we can do this for large numbers of
> customers.  This just isn't true.  There is no solution to this
> problem except channelization, which is, to stretch that analogy,
> being able to pay for a Lear jet.)

But that's not exactly a good analogy. ATM will ask you what you want right
now, and will tell you yes you can have it or no you can't. And if it can't
find the required QoS in its first try, it tries other paths. If it can't give
you what you need, you can reduce your demands or wait until the required
services are available.

IP with RSVP and QoS routing attempts to do the same thing. It fudges here and
there, though (e.g. tunelling over non-RSVP routers), so I'm not sure how well
it would actually work.

Other IP solutions will instead simply degrade with congestion. I agree that
if you can provide a lot of spare capacity, and perhaps applications that can
degrade gracefully as network bandwidth is lost, the effect can be
controlled. But there are absolutely no guarantees. It'll take a lot of
bandwidth and a lot of excess to handle both low latency interactive comms
(that can't use big buffers) and high-bandwidth signals such as HDTV (which
can use buffers, but will need really big buffers).

In short, the frustration factor of a connection (session) that keeps falling
apart is what the IP solutions will have to resolve.

Bert
manfredi@arl.bna.boeing.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own