In message <87llb68b2x.fsf@snark.piermont.com>,
"Perry E. Metzger" writes:

>Jonathan Stone <jonathan@dsg.stanford.edu> 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
>careful calculations.

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
same thing.]]


>If the implementation works and is clean there is little harm in
>adopting it.

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?