Date: Tue, 03 Oct 2000 09:07:34 -0700 From: Julian Elischer <julian@elischer.org> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: net@FreeBSD.ORG Subject: Re: SACK in FreeBSD TCP. Message-ID: <39DA0446.CDBB9B56@elischer.org> References: <Pine.BSF.4.21.0010021106090.29826-100000@achilles.silby.com> <39D9F3AC.1C9A1F14@elischer.org> <200010031520.LAA40493@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman wrote:
>
> <<On Tue, 03 Oct 2000 07:56:44 -0700, Julian Elischer <julian@elischer.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39DA0446.CDBB9B56>