Date: Wed, 3 Jan 2001 12:32:23 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: "Michael C . Wu" <keichii@peorth.iteration.net> Cc: jlemon@FreeBSD.ORG, rwatson@FreeBSD.ORG, itojun@netbsd.org, hackers@FreeBSD.ORG Subject: Re: TCP Rate-Halving Message-ID: <20010103123223.I292@fw.wintelcom.net> In-Reply-To: <20010103010739.A68404@peorth.iteration.net>; from keichii@iteration.net on Wed, Jan 03, 2001 at 01:07:39AM -0600 References: <20010103010739.A68404@peorth.iteration.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Michael C . Wu <keichii@iteration.net> [010102 23:07] wrote: > [If need be, please add Cc: to -net] > > While doing my own research project, I came across this piece > of information. It seems like a "nobody-has-it-but-it-is-fast" thing. > > http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt > > It seeks to improve the Reno TCP implementation by the most > recommended trick in the book, redesigning the algorithm. > >From the above url: > "Hoe [Hoe95] suggested that during Fast Recovery the TCP > data sender space out retransmissions and new data on > alternate acknowledgements across the entire recovery RTT. > (Note that this eliminates the half RTT lull in sending > which occurs in Reno TCP.)" > > Do we already do this? I know that a re-write of our TCP code is > "imminent." This seeks to improve congested server TCP connections. > (Oh BTW, Isn't TCP the little thing that servers use ;-)? ) There's no re-write in progress, just a couple of us slaving away to make it mpsafe. As far as this feature, I'm pretty sure Jaynath was looking at implementing it. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010103123223.I292>