Subject: Re: Nagle -- again

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jun 1999 14:51:21 -0700 (PDT)

> From [email-masked] Thu Jun 24 14:28:25 1999
> To: Joe Touch <[email-masked]>
> cc: [email-masked]
> Subject: Re: Nagle -- again 
> Date: Thu, 24 Jun 1999 14:28:30 -0700
> From: Greg Minshall <[email-masked]>
> 
> Joe,
> 
> > It was just that the difference was high enough to 
> > raise the issue of variance, and whether Table 1's discrepencies
> > (partial being better than full buffering) were 'signal'.
> 
> a legitimate concern.  i don't focus on the minor differences, and the 
> "partial being better than full" is one of the minor differences that may well 
> be due to statistical fluctuations.
> 
> the keys points are: 1) turn off Nagle and you may become a very *bad* 
> netizen;

I don't follow that - it seems like it requires "and implement 
applications poorly), in which case you're bad anyway, no?

> 2) Nagle + delayed ACKs (or, really, even + RTT) can slow down the 
> timely transmission of some data, and maybe we could do better.

Agreed.

Joe

---

From: Greg Minshall <[email-masked]>
Date: Thu, 24 Jun 1999 18:18:35 -0700

Joe,

>applications poorly", in which case you're bad anyway, no?

the point of the paper (understated) and of much of my experience is that it 
is *very hard* to implement applications ``right'' (with respect to 
buffering).  most people are going to get it wrong.  and, even when it is done 
right, minor changes (bug fixes, adding features) are likely to make it wrong 
again (in a sense, "proper buffering" is an unstable point, whereas "improper 
buffering" is a stable point).  Nagle protects the net *not* from "poorly 
written" applications, but rather from applications that aren't "very well 
written".  this may seem like a subtle point, but i think the distinction is 
very important.

Greg