NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/dcom/cellrel/246

Text File | 1992-07-25 | 3.5 KB | 68 lines

Newsgroups: comp.dcom.cell-relay
Path: sparky!uunet!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nntpd.lkg.dec.com!engage.pko.dec.com!e2big.mko.dec.com!cvg.enet.dec.com!pettengill
From: [e-mail] ()
Subject: Congestion Avoidance
Message-ID: <[e-mail]>
Sender: [e-mail] (Guest (DECnet))
Reply-To: [e-mail] ()
Organization: Digital Equipment Corporation
References: <[e-mail]> <[e-mail]>
Date: Sat, 25 Jul 92 09:28:23 GMT
Lines: 55

In article <[e-mail]>, [e-mail] (KEES VAN DER WAL) writes:

|>
|>I admit that there's an element of risk in developping networks that imply a
|>kind of "revolution". However, we can't play safe by waiting until all future
|>protocols have been proven to work. For me, at this moment, it's sufficient
|>that a number of people (not necessarily all) have confidence in that "it can
|>be done". If you're convinced that it's going the wrong way, please keep on
|>hammering on it. We'll try to find a solution that agrees to all our needs.
|>
|>Regards, <kees>
|>
|>PS. What worries me most at the moment is more the flow control measures to be
|>taken for the network's sake, ie. how to avoid or solve congestion. I haven't
|>seen any clear concepts on how to do that.
|>

Forget flow control; flow control deals with the buffers in the end stations.

Think about congestion avoidance.  Why avoidance?  Well, if you do congestion
control, then you incur large (relative to the normal data rate) timeouts,
and all sorts of other disruptions.  With congestion avoidance, you are
somehow detecting the possibility of loss and then taking action to prevent
this loss from occurring.

There is one sure way to avoid congestion loss: reserve sufficient bandwidth.
The problem with data communication is that, unlike voice which goes from
nothing to next to nothing, or video which is basically fixed at a constant
lot of data, data comm goes from nothing to mucho data and then back to nothing
in rather unpredictable patterns.  Reserving mucho capacity will be expensive,
but not reserving it leads to the likelihood that every user will want to
use mucho bandwidth at just about the same time.  I've monitored Ethernet
traffic, and I've seen it behave like sewer flow on Super Bowl Sunday, massive
flows during timeouts and halftime, but not much in between.

Some protocols are real bad news under these circumstances; faced with a
loss, they just add their retries on top of new requests.  This, of course,
just makes matters worse.  If you can see the global picture, the best
solution in an ATM kind of network would be discard everything from most
of the active circuit in sort of a rolling blackout kind of mode.  Anything
else, and you end up with either total congestion collapse or you end up
with the good citizens like TCP and DECnet giving up virtually all claim
to any bandwidth to the hogs like NFS.

While this situation can and does occur with frame switching (bridged or
routed Ethernet, token ring, or FDDI LANs), at least you can be fairly
sure that discarding a frame isn't going to result the retransmission of
hundreds of frames, and the number of packets is small enough so that a
discard policy that considers past history is conceivable.  In addition,
it is also reasonable to include sufficient buffering in the network
to handle seconds worth data to allow riding thru short periods of congestion.
This latter solution is not at all possible for ATM because of the timeliness
requirements of voice and video.

mulp