The IP over ATM Mailing List Archive by date

[manfredi@engr05.comsys.rockwell.com (Albert E. Manfredi)]

> From:	myjak@tridis.ist.ucf.edu    26-MAR-1996 08:44

> > A more general case might have two-way voice circuits requiring
> > relatively little bandwidth each but fairly stringent latency, while
> > the MPEG video, if it's a one-way link, would accept considerably
> > more latency but needs much more bandwidth. Ideally, the router
> > would have different ports to choose from for each of these incoming
> > streams.
> 
> I think we'd be heading down the wrong road if we attempt to
> categorize routing strategies by any one particular application type.
> We need a general solution which embodies the right set of ideals for
> existing and future applications.  Otherwise... we would be finding a
> solution to a single problem (set) and not solving the general case.

Not sure what you mean, Michael. What I illustrated was two very different 
types of QoS requirements that a general QoS routing scheme ought to be 
able to support as _separate_ options. Not to say "all voice circuits use 
this, all video use that," but rather to show that high bandwidth and low 
latency ought to certainly be kept separate.

Doing so would have obvious advantages. Providing both high bandwidth and 
low latency takes a lot of network assets. But if latency is no big deal 
(e.g. to multicast high-bandwidth TV programs), one can install large 
buffers and put up with a relatively large amount of jitter. Which makes 
carrying that much bandwidth an easier task, right?

For telephone-type service, you would need a fraction of the bandwidth, 
small buffers, low latency (max ~100 msec). For interactive video games,
you'd be somewhere inbetween. I'm suggesting that when the QoS needs are
signaled to the router with RSVP, the router ought to be able to put the
info to good use _to find the most cost-effective route_. Not just to 
reserve its own assets.

Bert
manfredi@engr05.comsys.rockwell.com