Bill, or anyone,

On Mon, Nov 08, 2004 at 03:01:15PM -0800, Bill Studenmund wrote:
> On Mon, Nov 08, 2004 at 01:53:58PM -0800, Jonathan Stone wrote:
> > 
> > In message <75109204-31CC-11D9-ACC4-000A957650EC@shagadelic.org>Jason Thorpe wr
> > ites
> > 
> > >Basically, systems that have this bug implement a delayed ACK policy of 
> > >"ACK every 2 maximum-sized segments", and more or less count bytes 
> > >until they've received "2 * MSS" since their last transmitted ACK.
> > 
> > [snip text of Jason's scenario]
> > 
> > Yes, but if you get packet loss (e. g., due to congestion from
> > multiple flows crossing the router onto one or other subnet), then the
> > stretch-ACK bug breaks Fast Recovery, and you incur full slow
> > timeouts. Which sounds to me more like what Bill was seeing.
> 
> From what I understand of the stretch-ACK bug, it would be important if 
> the receiving OS has it. The receiving OS in this scenario is NetBSD, so I 
> am not clear if it will matter.
> 
> Note: as best I can tell from looking at the committs to FreeBSD, the fix 
> that got pulled into FreeBSD 4.5 was in fact a fix to not delay an ACK if 
> the last window advertizement was 0. In this case, the ACK gets sent now 
> so that the other side can start sending again. While this case can be 
> important for rapid input & output, I don't think it impacts what I was 
> seeing.
> 
> However the fact is that FreeBSD seems to have had the same New Reno code
> we have and found it to be broken & then fixed it. I think we should care. 
> :-) Does anyone else?

Concerns about the "Squashed ACK" bug notwithstanding, did the New
Reno issue ever get fixed in our tree?  I can't remember seeing any
commit messages, but I have to admit my mind was on other things in
November.

I'd like this to get into 3.0, if possible.

Thanks,
Alistair