From owner-freebsd-net Tue Oct 3 9: 8:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 1F04A37B66C for ; Tue, 3 Oct 2000 09:08:21 -0700 (PDT) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id AAA15711; Wed, 4 Oct 2000 00:08:03 +0800 Received: from elischer.org (reggae-34-48.nv.iinet.net.au [203.59.167.48]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id AAA14328; Wed, 4 Oct 2000 00:08:01 +0800 Message-ID: <39DA0446.CDBB9B56@elischer.org> Date: Tue, 03 Oct 2000 09:07:34 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: SACK in FreeBSD TCP. References: <39D9F3AC.1C9A1F14@elischer.org> <200010031520.LAA40493@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > > < said: > > > What I think would be really cool would be a Vegas/new-reno/SACK > > implementation! > > I'm not aware of anyone other than Larry Peterson who thinks that > Vegas was correct, never mind a good idea to implement. In the past I had something to do with some systems that used "vegas-like" logic to try reduce losses. They worked quite well in low to medium loads and were neutral (as compared to dumber systems) in heavy congestion (where packet loss is unavaoidable). Certainly reno/tahoe are "criminally negligent" when it comes to losing packets that didn't need to be lost. New-reno, from looking at it might be a little better. Unfortunatly the logic used for Vegas is susceptible to network topology and load flucuations, but I found in practice that they work 'enough' to make them useful. The systems we used would reset themselves back to default "dumb" behaviour if it looked as if the network was too unstable to try use vegas-like "prediction". In particular when competing with many streams of beligerent stacks (e.g. tahoe/reno) the ability to measure the aproach of an impending packet loss was less sure, and the loss of a packet might not be avoided by backing off anyway as the load is probably coming from somewhere else. We found however that even in this case it rarely performed WORSE than the dumb stack. I think that addition of SACK would aid greatly in cases of heavy load/loss and Vegas would assist in light to medium loads. In each case the change doesn't negatively (in our experience) the behaviour in the case where it is not useful. > > -GAWollman -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message