Subject: Re: Squashed Ack, was Re: Concerns about our NewReno code
To: Bill Studenmund <wrstuden@netbsd.org>
From: Jason Thorpe <thorpej@shagadelic.org>
List: tech-net
Date: 11/08/2004 13:23:39
--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.

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

A is a BSD system without PMTUD, which means that the stack will send a 
512 byte segment because the peer, B, is on a different subnet.  B 
considers 1500 to be the MSS, and so is going to wait for 3 packets 
from A before it sends an ACK, even though A considers 512 to be the 
maximum-sized segment for the transmission.  This is really the classic 
example of this bug.

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.

         -- Jason R. Thorpe <thorpej@shagadelic.org>


--Apple-Mail-7--764748750
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBj+PbOpVKkaBm8XkRAh8MAKCFKePFh+p3zxDt+y9++yeDbeL7fQCfWMXA
/Lvdaf3K/IlIUeI1yJyh7dc=
=kg9b
-----END PGP SIGNATURE-----

--Apple-Mail-7--764748750--