Subject: Re: TCP/SACK support.
To: Perry E. Metzger <firstname.lastname@example.org>
From: Jonathan Stone <email@example.com>
Date: 01/06/2005 14:48:36
In message <firstname.lastname@example.org>,
"Perry E. Metzger" writes:
>Jonathan Stone <email@example.com> writes:
>> But there are a number of other implementations of SACK for the BSD
>> TCP stack, some of which have been widely tested, deployed, and not
>> least, had some review by leading members TCP/IP research community.
>SACK is not like slow start or what have you -- it doesn't need
>careful tuning and there aren't subtle bugs you can introduce in
Nope. For starters, you should re-read the message Pavel already
cited, describing problems in OpenBSD-3.1's TCP performance due to
SACK. Then, take a look at RFC-3517. A modern SACK implementation
does in fact, require as much care as [sic] ``slow start or what have you''.
Another way to say the same thing is that these days, SACK implies not
just SACK, but SACK+FACK or SACK-plus-son-of-SACK.
I've read Kurahone-san's patch. They are very clean.
But they represent only very modest receiver-side changes. By far the
bulk of the work needed for SACK is in the TCP sender-side --- where
SACK retransmission and scoreboarding intimately affect the
transmission-policy portions of TCP. That's the part where I suggest
we don't reinvent wheels if we can re-lathe an existing wheel.
[[Hmmm. Looking ahead in my inbox, I see Kurahone-san says much the
>If the implementation works and is clean there is little harm in
Yes, exactly. So I assume that you have no objection in principle to
committing a clean version of SACK scoreboarding derived from, say, FreeBSD-5?