Subject: Re: Nagle -- again

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jun 1999 13:59:15 -0700 (PDT)

> From [email-masked] Thu Jun 24 13:40:17 1999
> To: Joe Touch <[email-masked]>
> cc: [email-masked]
> Subject: Re: Nagle -- again 
> Date: Thu, 24 Jun 1999 13:01:55 -0700
> From: Greg Minshall <[email-masked]>
> 
> Joe,
> 
> > One observation - the paper indicates that there _must_ be at least
> > one ACK every two packets. This is not strictly required, at least
> > last time I checked. 
> 
> yes, sorry.
> 
> > Presuming that, would you propose to allow K-1 outstanding partial
> > packets, given one ACK per K packets?
> 
> no.
> 
> > 	- the paper uses analysis based on ethernet MSS's,
> >		how do things change if Internet default MSSs are assumed?
> 
> well, i suspect that ethernet MSS ~== Internet default MSS, however if you 
> mean 512 or 576 bytes, i'm not sure.  i'll (possibly) get back to you/the list 
> on this.

I mean 512 or 576. Internet default MSS is 576.

> >	- Table 3 doesn't match the other tables (either) for original nagle
> 
> yes, table 1 is from one run on one kernel; table 3 is from one run on a 
> kernel that had could switch between the two implementations.  also, note our 
> (rueful) disclaimer:

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

Joe

---

From: Greg Minshall <[email-masked]>
Date: Thu, 24 Jun 1999 14:28:30 -0700

Joe,

> (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; 2) Nagle + delayed ACKs (or, really, even + RTT) can slow down the 
timely transmission of some data, and maybe we could do better.

Greg