Cell Relay Archive

[Jim Jackson <jj@scs.leeds.ac.uk>]

On 24 Jul 1997, Saso STOJANOVSKI wrote:

> > 
> > 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?
> 

I suggest you go away and read what ABR actually does do. Yes it chokes
sources but what it DOES NOT do is provide anysort of guarantee of data
transfer - it minimises the need for higher layer timeouts and
retransmits, it DOES NOT do away with the need for these.

> > > [hint: one of these combinations has a very naughty window-adjusting
> > > mechanism]
> > 
> > It's not naughty. 
> 
> isn't it? so how do you explain the fact that tons of papers have been
> published on the (non)efficiency od data transport in TCP over ATM cases?

Not the window mechanism per se, but some of the hueristics that were
added later - nagles algorithm, delayed acks etc. These can interact badly
in networks with large MTUs (not just ATM). The phenomenon is now very
well understood and trivially sorted.

> what did incite the definition of new atm features such as partial packet
> discard or early packet discard?

This is a different problem and would be needed for ANY protocol that used
AAL5. This is a heuristic that was bolted on in the light or real
experience.

> 
> you see, it is tcp that has "universal ambitions". people want to use it
> on every network. therefore, tcp has to make *estimations* about the
> network condition, which sometimes are inaccurate and lead to
> inefficiencies.

ANY ubiquitous transport would have to do the same.