Subject: Re: Squashed Ack, was Re: Concerns about our NewReno code
To: Bill Studenmund <email@example.com>
From: Alistair Crooks <firstname.lastname@example.org>
Date: 01/26/2005 14:02:46
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
> 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
I'd like this to get into 3.0, if possible.