On Thu, Jan 06, 2005 at 02:48:36PM -0800, Jonathan Stone wrote:
[snippity]
> 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.

Ok, so I went and took a look at the FreeBSD-5 SACK code.
It had one issue (namedly that it traverses the list of SACK holes once
per each sack block), but apart from that it looks like it does the Right
Thing.

Patch: http://www.sigusr1.org/~kurahone/tcp-sack-netbsd-2.99.11-r2.diff.gz

Currently the code doen't actually do anything with the information it has
(as in, it'll build up a list of holes and scoreboard, but not use that for
retransmission), and it doesn't clear the SACK hole list when the slow
retransmit fires.   But that stuff is comming next.

Main difference from the FreeBSD code is that I jammed a loop so that it only
does one pass over the list of holes when it gets a new SACK block.

-- 
Kentaro A. Kurahone
SIGUSR1 Research and Development