[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 ;-)? )
Will someone enlighten me on how deviated we are from the Reno TCP code?
I am under the impression that we have the W. Stevens RFC2581 implemented.
Is that true?
They even implemented this for NetBSD and DECUnix/Tru64:
http://www.psc.edu/networking/tcp.html#psc
Is this specified in the IPv6 specs? Does KAME do this?
If this has already been implemented, can someone e
And perhaps we can implement/import this...someday, like what
we did with schedular activations.
Relevant:
http://www.psc.edu/networking/rate-halving/
RFC2581
RFC2481
--
+------------------------------------------------------------------+
| [EMAIL PROTECTED] | [EMAIL PROTECTED] |
| http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. |
+------------------------------------------------------------------+
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
