In message <75109204-31CC-11D9-ACC4-000A957650EC@shagadelic.org>Jason Thorpe wr
ites
>
>--Apple-Mail-7--764748750
>Content-Transfer-Encoding: 7bit
>Content-Type: text/plain; charset=US-ASCII; format=flowed
>
>
>On Nov 8, 2004, at 11:27 AM, Bill Studenmund wrote:
>
>> I'll look at these. However what exactly is the "Squashed ACK" bug? (I
>> think I know, but I want to make sure we're talking about the same 
>> thing.)
>
>I think it's more commonly referred to as the stretch-ack bug.

Pretty much exclusively so. I misremembered the name.

>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.
>
>The problem is that MSS variable.  A receiver *cannot* know with any 
>certainty what the sender considers to be a maximum-sized segment.  You 
>can't go on what the peer advertised as MSS, since that is the largest 
>segment they are willing to *receive*, and has nothing to do with that 
>they'll send.  The receiver is forced to make an assumption, which may 
>or may not be valid.
>
>
>So, consider the following case:
>
>         Ethernet          Ethernet
>      A ---------- ROUTER ---------- B
>   No PMTUD                        PMTUD, stretch-ack bug

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

>Quite some time ago (December 1997), I changed NetBSD's TCP (based on 
>discussion in the IETF TCPIMPL-WG) to send an ACK for every two 
>segments, regardless of size.  Other suggestions were to build a 
>histogram of the session to try and intuit what the other side 
>considered a maximum-sized segment... but "ACK every 2 segments, 
>period" is very simple, and works quite well in practice.

Historical note: I seem to recall that back then, NetBSD's TCP would
actually send one ACK every 3 segments in steady-state; which was
fixed when you fixed the stretch-ACK bug.