From owner-freebsd-current@FreeBSD.ORG Fri Jun 25 15:24:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFBF916A4CE; Fri, 25 Jun 2004 15:24:36 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB77843D46; Fri, 25 Jun 2004 15:24:36 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Fri, 25 Jun 2004 08:24:17 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 9691C5D09; Fri, 25 Jun 2004 08:24:16 -0700 (PDT) To: Robert Watson In-reply-to: Your message of "Fri, 25 Jun 2004 09:59:24 EDT." Date: Fri, 25 Jun 2004 08:24:16 -0700 From: "Kevin Oberman" Message-Id: <20040625152416.9691C5D09@ptavv.es.net> cc: liamfoy@sepulcrum.org cc: Paul Saab cc: current@freebsd.org cc: Daniel Lang Subject: Re: HEADS UP: SACK committed to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 15:24:37 -0000 > Date: Fri, 25 Jun 2004 09:59:24 -0400 (EDT) > From: Robert Watson > Sender: owner-freebsd-current@freebsd.org > > > On Fri, 25 Jun 2004, Daniel Lang wrote: > > > liamfoy@sepulcrum.org wrote on Fri, Jun 25, 2004 at 11:24:01AM +0200: > > [..] > > > > > I just commited the work done at Yahoo! to implement SACK in our tcp > > > > > stack. Please report any bugs or problems and we'll work on getting > > > > > them addressed. > > [..] > > > What is SACK anyone? > > [..] > > > > "Selective Acknowledgement", it allows a host/router to explicitly > > acknowledge TCP segments and retransmit them, such that if a segment > > gets lost, it can be retransmitted from the last hop instead of the > > connection endpoint, which would result in a much larger delay. > > Especially if you have wireless links, SACK can be a huge improvement. > > > > Please correct/elaborate, I'm not sure if I got that entirely right, > > except for the idea. ;-) > > Mostly right, except that it's only the end-hosts in the TCP connection. > Technically, one can be a router, but I'm guessing that's not the common > case. Basically, the original TCP said "retransmit everything" when it > realized a packet was dropped, and TCP SACK allows it to be more > selective, which conserves bandwidth, which has the effective of reducing > load, reducing latency, etc. The issue with wireless networks is questionable, too. SACK is needed for good throughput on fast links with relatively large latencies. It is valuable any time a large number of packets are launched before an ACK is received. Satellite links are a valid (if fairly uncommon) case where SACK is really valuable. More important in my case is when you have very high bandwidth streams over a geographically long distance. E.g. Los Angeles to Boston or across any ocean. Even if the line is running clean, a single dropped packet can really kill performance by dropping the stream into slow start. Even with fast recovery options, just the loss in retransmitting the large number of frames in transit can be a bit hit. Single streams of > 1 Gbps are not common on the commercial network, but in the research community where a physics experiment at Stanford can generate Terabytes of data that has to be sent to FermiLab and CERN, this is a very big issue. The lack of SACK in the FreeBSD stack has caused many to switch to Linux and FreeBSD is no longer the "standard" for high performance networking. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634