> From: "Perry E. Metzger" <perry@piermont.com>

> Both sides must be SACK aware, unfortunately.
> 
> However, even just having my sups and rCVS work faster would be a big
> win. Heck, about 80% of my long range long duration transfers are over
> bad links with other NetBSD hosts. SACK would make a lot of that work
> far better for me. Also, once we have the feature, the FreeBSD people
> will put it in place and the Linux people won't let us show them up,
> so that will take care of a nice fraction of the world's web sites and
> such.

Perry, while I certainly hope SACK does this for you, I would
be reluctant to assume so.

SACK does not change the fundamental design premise of TCP that a
packet loss is due to congestion. It provides significantly better
behavior in the face of multiple-losses within a window, and will
essentially maintain fast recovery incases where reno and tahoe are
forced to slow-start.

It's not apparent to me that this will translate into your seeing
an improvement in cases where your losses are due to bad/lossy
links rather than due to congestion. I wouldn't be surprised if SACK
turned out to be a win in such cases, but I also wouldn't be surprised
if it made things worse.

In order to find out, I suggest you run some simulations with the LBL
network simulator and get back to us (check out ftp.ee.lbl.gov,
probably ns.tar.Z or somesuch).

SACK is nice, and is a good thing, and will increase the throughput
of TCPs in the face of purely congestion-related loss; what it
will do in the face of non-congestion-based loss is
not totally clear (at least to me).

--jhawk