From owner-freebsd-net@FreeBSD.ORG Wed Mar 10 03:37:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C44F16A539; Wed, 10 Mar 2004 03:37:21 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCC7943D46; Wed, 10 Mar 2004 03:37:19 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i2ABbBd13557; Wed, 10 Mar 2004 12:37:12 +0100 (MET) Date: Wed, 10 Mar 2004 12:37:11 +0100 (CET) From: Harti Brandt To: Mike Silbersack In-Reply-To: <20040309160821.P705@odysseus.silby.com> Message-ID: <20040310123237.V61186@beagle.fokus.fraunhofer.de> References: <20040309214205.3EE2D5D07@ptavv.es.net> <20040309160821.P705@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Brad Knowles cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Kevin Oberman Subject: Re: Who wants SACK? (Re: was My planned work on networking stack) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2004 11:37:21 -0000 On Tue, 9 Mar 2004, Mike Silbersack wrote: MS> MS>On Tue, 9 Mar 2004, Kevin Oberman wrote: MS> MS>> Selective ACKnowledgment (SACK) allows acknowledgment of received MS>> packets in a TCP window so that only the missing/damaged packet needs to MS>> be re-transmitted. This is normally of little value on a LAN where ACKs MS>> arrive quickly and windows are smaller and no use on slow circuits. On MS>> fat pipes with latency and big windows it is a huge win as it allows you to MS>> recover much faster from a packet drop. If you don't have SACK, you need MS>> to re-transmit all of the packets in flight within the window while MS>> with SACK, you need only retransmit the dropped packet(s). If you have a MS>> 10 or 20 MB window, this is a big deal. MS> MS>That's not correct. Non-SACK TCP doesn't drop any additional packets vs MS>SACK. The difference is that SACK allows the transmitter to transmit the MS>packet which fills the "hole" and then immediately start transmitting new MS>data (or fill other holes.) Non-SACK senders have to wait to receive an MS>ACK after retransmitting the hole in order to find out if there are other MS>holes which must be filled or if new data can be transmitted. MS> MS>SACK itself really doesn't do much, it's all the new congestion control MS>schemes (FACK, Rate Halving, etc) that come shipped with most SACK MS>implementations that do the work and contain most of the complexity. For satellite pipes with drops that are not the result of congestion, but of transmission errors SACK helps. With congestion control only you get no throughput no matter what you do (I did some tests with a simulated 50MBit/sec GEO link with errors). But this is a rather limited application. harti