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