Cell Relay Archive

[Paul Koning <pkoning@lucent.com>]

Hal Murray wrote:
> 
> 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.

That's the one I was thinking about.  I'm not surprised it
works fine, considering its ancestry and logic.
 
> Yes, it's complex.  Our implementation doesn't scale to WANs.

Complex?  I always thought that QFC (credit based flow control)
was incredibly simple.  Certainly it's orders of magnitude
simpler than ABR.
 
> 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.  ...
> 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.

Which flow control, QFC or ABR?  Also, I think the suspicions
apply mostly to the WAN case (for ABR).  It seems reasonable,
intuitively, that embedding another servo loop below TCP is
fine when the time constants of that lower loop are substantially
smaller than those of the upper one -- as they can be for LANs.

	paul