NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/dcom/cellrel/1012

Text File | 1993-01-21 | 3.6 KB | 80 lines

Newsgroups: comp.dcom.cell-relay
Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!sgi!rigden.wpd.sgi.com!rpw3
From: [e-mail] (Rob Warnock)
Subject: Re: Bandwidth Control
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 22 Jan 1993 02:32:00 GMT
Lines: 69

[e-mail] (Matt J Young) writes:
+---------------
| Experts analysis has shown that statistical multiplexing
| over the WAN is simply not possible.
+---------------

Then they need some new experts. At DCA, we were doing "statistical
multiplexing over the WAN" with a cell-relay-like system in 1971, and
people have been doing it ever since. It is *easier* to do in a WAN
environment, since you are averaging more traffic sources.

Perhaps you meant to say, "statistical multiplexing of ATM traffic over
a WAN of ATM switches is simply not possible with the silly tiny output
buffers that the telcos seem to want to build into their switches." This
I could agree with.

It's even *less* possible in the LAN with such tiny buffers, which is why
some LAN ATM switch vendors are providing large (megabyte or more per port)
buffers and/or per-VCI flow-control [backpressure].

+---------------
| It has been recommended in a recent IEEE Network Issue that the best effort
| is to assign fixed bandwidth allowances on a per VCI basis.
+---------------

It may not be "best", but I'm sure it's "easiest". "Best" would be per-VCI
flow control, but it's costly. It's not at all "impossible", but would involve
significant addition hardware in the switches, *and* create a substantial
delay in deployment due to the necessity of working a flow-control standard
through "The Standards Process". [Again, DCA had per-VCI flow control in its
statistical multiplexors back in 1972, using a credit system. It worked fine,
but did use significant number of CPU cycles per "cell".]

I have previously proposed what I think is a reasonable compromise, namely,
provide a per-VCI attribute (set at call-setup time) to select between the
"guaranteed bandwidth" [whether CBR or not] traffic and the "non-guaranteed"
[i.e., bursty] traffic. Then provide separate output queues for the two types,
with *very* large queues for the bursty traffic. To save cost, the bursty
traffic could all use one big queue per ATM switch.

Yes, this makes the ATM switch be a "bridge" or "packet switch" or "frame
relay" (as far as congestion behavior) for bursty traffic, which is exactly
the point. It would behave (for better or worse) in well-known ways, like
current packet switches, and traditional end-to-end congestion-avoidance
algorithms would have a prayer of working [which they don't with tiny buffers].

Note: Without such dual-tier queueing (or fine-grained per-VCI flow-control),
ATM will be unable to compete with "gigabit packet switching" in the LAN
environment, and therefore ATM will lose much of its attraction (the ability
to share a common infrastructure between "computer data" and other services).
Happily, enough ATM LAN vendors are aware of this problem that ATM LANs
capable of doing very bursty "packet switching" are likely to manifest.

However, to bend an old saying, "the 'good enough' is the enemy of the best".
What will probably happen is that the ATM WANs *will* settle for providing
only the "guaranteed bandwidth" [whether CBR or not] service, in which case
the role -- for "computer data" traffic -- of ATM in the WAN will be reduced
to being just another way of getting (virtual) "leased lines" between LAN
routers.


-Rob

-----
Rob Warnock, MS-9U/510        [e-mail]
Silicon Graphics, Inc.        [phone]
2011 N. Shoreline Blvd.
Mountain View, CA  94043