From owner-freebsd-current@FreeBSD.ORG Tue Mar 9 14:12:09 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 EA90016A4E3 for ; Tue, 9 Mar 2004 14:12:09 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 6853E43D2F for ; Tue, 9 Mar 2004 14:12:09 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 96889 invoked from network); 9 Mar 2004 22:12:08 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 9 Mar 2004 22:12:08 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 9 Mar 2004 16:12:07 -0600 (CST) From: Mike Silbersack To: Kevin Oberman In-Reply-To: <20040309214205.3EE2D5D07@ptavv.es.net> Message-ID: <20040309160821.P705@odysseus.silby.com> References: <20040309214205.3EE2D5D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 10 Mar 2004 05:23:59 -0800 cc: freebsd-current@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Who wants SACK? (Re: was My planned work on networking stack) 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: Tue, 09 Mar 2004 22:12:10 -0000 On Tue, 9 Mar 2004, Kevin Oberman wrote: > Selective ACKnowledgment (SACK) allows acknowledgment of received > packets in a TCP window so that only the missing/damaged packet needs to > be re-transmitted. This is normally of little value on a LAN where ACKs > arrive quickly and windows are smaller and no use on slow circuits. On > fat pipes with latency and big windows it is a huge win as it allows you to > recover much faster from a packet drop. If you don't have SACK, you need > to re-transmit all of the packets in flight within the window while > with SACK, you need only retransmit the dropped packet(s). If you have a > 10 or 20 MB window, this is a big deal. That's not correct. Non-SACK TCP doesn't drop any additional packets vs SACK. The difference is that SACK allows the transmitter to transmit the packet which fills the "hole" and then immediately start transmitting new data (or fill other holes.) Non-SACK senders have to wait to receive an ACK after retransmitting the hole in order to find out if there are other holes which must be filled or if new data can be transmitted. 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. Mike "Silby" Silbersack