RE: Who wants SACK? (Re: was My planned work on networking stack)

From: Henderson, Thomas R <thomas.r.henderson_at_boeing.com>
Date: Thu, 11 Mar 2004 20:29:07 -0800
> -----Original Message-----
> From: Mike Silbersack [mailto:silby_at_silby.com]
> Sent: Tuesday, March 09, 2004 2:12 PM
> To: Kevin Oberman
> Cc: Brad Knowles; freebsd-current_at_freebsd.org; freebsd-net_at_freebsd.org
> Subject: Re: Who wants SACK? (Re: was My planned work on networking
> stack) 
> 
> 
> SACK itself really doesn't do much, it's all the new 
> congestion control
> schemes (FACK, Rate Halving, etc) that come shipped with most SACK
> implementations that do the work and contain most of the complexity.
> 

That's not quite true.  Basic SACK by itself can be very helpful, 
especially if NewReno is the non-SACK fallback, in long delay environments 
characterized by bursty losses (multiple packets in one window).  
With NewReno, you end up only recovering one packet per RTT, which 
can in some cases be much worse than just taking a timeout and 
starting over.  See below paper for some experimental traces 
of this:

http://citeseer.ist.psu.edu/henderson99transport.html

(not that I don't think that the more recent RFCs are an improvement
on basic SACK)

As for who/when to do this, I and perhaps others have been discouraged 
from taking a stab at a SACK patch in the past, because of a sentiment
that it should be undertaken as part of a bigger rewrite of TCP.  

Tom

p.s. Niels Provos ported our Berkeley BSDi-based SACK extension
to OpenBSD several years ago-- that might be something to look at
as a starting point.
Received on Thu Mar 11 2004 - 19:30:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:47 UTC