From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: clarifying the role of SSCOP?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 12 Nov 1992 12:23:56 GMT

goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
+---------------
| Will ATM be that bad?  I hope not.  I know how to keep it from being
| very lossy.  But I'm not sure the CCITT does.  And if it's cheaper in 
| the long run to run the circuits at 95% utilization with say 1% loss 
| (and selective retransmission) than to run them at 90% with 0.001% loss,
| then why not?  And if you run it even lossier (hey, it may not be
| _planned_), then local retransmission begins to look good.
+---------------

Fred, I think you're exaggerating the possibilities for raw cell loss due
to transmission effects [not congestion, but see below]. Remember, this same
ATM network has got to carry voice traffic with no AAL at all (well, AAL1
is practically no AAL). Every cell dropped will be a 6ms gap in the conver-
sation (12ms, if 32 Kb/s ADPCM is used). And depending on such a good error
rate should not be surprising; today we have *no* retransmission on *any*
long-haul voice channels. (We do have FEC on satellite circuits, but that's
not retransmission.)

I am quite confident that -- in the absence of congestion -- the global ATM
network will have a cell error rate low enough to allow traditional end-to-
end retransmission of AAL5 packets to be reasonable. And I am also confident
that the call setup procedures will not allow significant congestion-induced
cell loss on constant-bit-rate circuits [well, in the absence of TASI...].
It's just too easy to avoid it by simply not completing the call if the
requested bandwidth isn't there.

HOWEVER... I do not believe the same to be true if LAN-like bursty traffic
is allowed to create congestion in small-buffered ATM switches ["small" is
by comparison with the buffer sizes one would configure for a traditional
IP router with a similar load on it.]

I fear that because of the small buffers, the congestion (and thus, cell loss)
will be *far* worse than anything we have ever seen in the Intenet to date,
and that we *have* to have some form of hop-by-hop flow control on bursty
traffic so that the net simply does not *allow* congestion-induced cell loss.
When even *one* full-sized AAL5 PDU (64 KB) sent at the full link rate may
overflow some switches' output queues (after all, that's 1366 cells!),
end-to-end congestion avoidance is impossible. [It's always too late.]

We either have to either (1) do "leaky-bucket" rate control to never exceed
the call's guaranteed bandwidth, which reopens *all* the "dynamic bandwidth"
issues we have already with IP over X.25 or IP over multiple BRIs, and which
*never* lets a single connection get the full bandwidth of the ATM access
link (*boo* *hiss*), or (2) we have to have hop-by-hop flow control (call
it "back-pressure" if you prefer) on bursty traffic, at a pretty fine-grained
level (a few cells or a few 10's of cells).

+---------------
| I'm not saying everyone will need SSCOP.  Just that it may be a nice tool
| when things go wrong, and not a very expensive one to keep around anyway.
+---------------

But it's the *wrong* tool to try and solve burstiness-induced congestion.
Hop-by-hop flow control (or reasonable-sized buffers for bursty traffic,
which I don't hold much hope for) is a much better tool for this particular
problem.

[See a previous article for a proposed hop-by-hop flow control which would
be a lot simpler than per-VC credits but just as effective (I think).]


-Rob

p.s. Back at Dig. Comm. Assoc. circa 1972, we used hop-by-hop per-VC credits
(we called them "pre-ACKs") in our statistical multiplexers. Worked like a
charm! We *never* dropped data due to internal network "congestion" -- we
simply didn't permit it! But it took a lot of computes *and* large buffers,
which is why I don't recommend it for ATM.

If the sending host or terminal at the edge of the network wouldn't or
couldn't respond to the provided flow-control indications (XOFF/XON or CTS),
we of course were forced to drop data, but we also then "notified" the host
by dropping the virtual circuit! (*Boom*) "Carrier fail disconnect..."
[A reasonable policy for the stat-mux market at that time.]

[We also did hop-by-hop retransmission, but that's another issue. Link speeds
were slow then, and multi-hop latency was a big problem when echoing keyboards
through the network. Hop-by-hop retransmission, with NACKs, not timeouts,
helped keep the "stutter" due to error recovery short.]


-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.cell-relay