Cell Relay Archive

[Pete Flugstad <pete@see.sig.for.address>]

Fred R. Goldstein wrote:
> 
> In article <Pine.HPP.3.96.970724172152.3984C-100000@dizzy.res.enst.fr>,
> sassos@res.enst.fr says...
> 
> >> Sorry but abr does not fully reliably handle congestion - it attempts to
> >> minimise it only.
> >
> >why do you say this?
> >in an end-to-end atm connexion the abr mechanism does choke the sources as
> >tcp does.
> >so what is the problem with abr?
> 
> A lot of people doubt that ATM Forum Standard ABR/ER will work, and it does
> not even reasonably claim to prevent congestion, just reduce it.  ABR/QFC, on
> the other hand, pretty much prevents congestion loss en toto.  I wonder why
> Pete was so down on ABR - doesn't Nexion do QFC?  Or are you not calling that
> ABR as a result of that term's being hijacked by the Forum's ER advocates?
> Please correct me if I'm wrong but I thought QFC was considered (by its
> advocates) to be a way to implement an ABR service.

Sorry if I wasn't clear.  I tried to remember to write ABR/ER
everywhere,
but I must have missed it a few places.  I fully belive QFC will work,
very
well in fact.

> Re: timing, I don't think it would be a major deal to add dynamic timing to
> SSCOP, 

We've talked about it, but have not done anything with it.  It does not
seem
particularly hard, or even expensive.

> but I also don't think timing is as critical as with other protocols.
> Since SSCOP uses multiple-selective recovery, it doesn't choke while waiting
> for a recovery sequence to occur; it can be recovering and sending new data
> all at once, provided the receiver's buffer isn't full.  So I'd expect it to
> work okay if it were simply tuned to have, say, a timer that anticipated
> nearly worst-case delays, rather than TCP's dynamic optimization.

The real problem is the 7 second NoRespone timeout.  In any reasonable
network (or any network with congestion & ABR), that is rather short. 

> (I worked on SSCOP's first drafts but lost track of its details along the
> way.  Does anyone know if it's properly idempotent?)
>
> I suppose TCP has a multiple-selective recovery option, but I don't think
> I've ever seen it implemented.

Take a look at RFC 2001 for a good picture of current TCP implementation
options.  I belive that what it describes is implemented in 4.3/4.4 BSD, 
so many UNIXen have them, or will be picking them up.

Also, RFC 2018 describes "TCP Selective Acknowledgment Options", which,
if I read it correctly describes what you want.  RFC 2018 is on the
standards
track, but as you note, it has not been widely implemented.

> Most TCPs are pretty lame, and therefore would have trouble 
> with fast lossy ATM.  

Thank you Microsoft...

> ABR/QFC is nearly lossless so
> single-recovery might not be so bad after all, but ABR/ER or any other
> service class is more likely to require multiple-recovery.
> 
> That's the fun thing about ATM.  There are so many things you can put
> together in so many ways, most of which don't work well.

The nice thing about standards, there are so many to choose from.

I think SSCOP is a nice elegant protocol.  I just think that it needs
more time to "bake" in real world scenarios before I'd trust a lot
of data to it.  And it definately needs to be more flexible with timers
than it is now.

Pete
-- 
Peter J. Flugstad              Ascom Nexion
pete at stl dot nexen dot com  1807 Park 270 Drive, Suite 350
+1 XXX XXX XXXX                St. Louis, MO 63146  USA
#include <std/disclaimer>      #include <funny/saying>