Cell Relay Archive

[murray@pa.dec.com (Hal Murray)]

In article <3884A99E.1E2F7E42@lucent.com>,
 Paul Koning <pkoning@lucent.com> writes:

> The price you pay is that ABR is extremely complex, sufficiently
> so that it has only been analyzed in simulations where a lot of
> simplifying assumptions were made.  Also, there is disagreement
> on whether the layer 2 flow control in ABR interacts well with 
> the layer 4 flow control in TCP.  As a result, I'm not sure that
> ABR has seen much real world use.  Certainly it has little or
> none in the WAN world, even though immense effort was spent in
> the ATM Forum specifically to fit it into that world.  (If you want
> LAN only service similar to ABR, you could do so VERY much more
> easily using completely different mechanisms, but those were
> rejected...)

We have about 50 machines in this building that are using
non-standard credit based flow control.  Works fine.

Yes, it's complex.  Our implementation doesn't scale to WANs.

What sort of "completely different mechanisms" did you have in
mind?  The pause type stuff used on Ethernet is simple to implement
and works fine in a lightly loaded case but it gets tangled up
with head-of-line blocking when the load isn't light.


I've done some testing with TCP over ATM with and without the flow
control.  It's actually harder than I expected to find cases that
screw up.  If the buffer in the switch is big enough to hold your
TCP window then TCP will probably work as expected even without
flow control.  If you make the TCP window bigger, it might even
seem to do what you want.  But 2 competing TCP streams will be
alternating back and forth at about a 1 second interval.  That
was with a dumb switch that didn't do any EPD/PPD.

With flow control, all worked great.  That's with end-to-end flow
control.  I'm sure there are ways to get in trouble if you have
other boxes in the system that aren't playing the game.

-- 
These are my opinions, not necessarily my employers.