Cell Relay Archive

[Saso STOJANOVSKI <sassos@terry.res.enst.fr>]

On Mon, 28 Jul 1997, Jim Jackson wrote:

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


are you trying to tell us that abr is not a transport protocol?
gee, *this* is a news!


> > > > [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.

i did not say "the window mechanism". please re-read above:
"window-adjusting mechanism". by saying this, i was referring to the
"slow-start".

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

i agree. but these features are *by far* more important for "go-back-n"
transport protocols. wouldn't you agree?

--sS