On Fri, Jan 04, 2008 at 04:37:54PM +0000, Will Morton wrote: > > I have built the protocol based on TCP Vegas, but after reading those > references I clearly need to update it to use SACK and to ack-clock > except on rto, as you mention. My implementation of the protocol is > seemingly coming to resemble a microcosm of TCP development. :o) > > One further question, which RFCs 2018/2581 don't seem to address; do > modern TCPs still use a Vegas-like system for detecting congestion in > advance of packet loss, i.e. by measuring difference between expected > and actual throughput and adjusting the window accordingly? If not, > what other mechanism[s] do they use?
A couple years ago the IETF's TCP Maintenance and Minor Extensions working group put together an RFC that lists and describes most of the TCP RFCs that have been written and what their current implementation and recommendation status is: http://www.ietf.org/rfc/rfc4614.txt You might find that helpful. Note that Vegas is not among the recommended behaviors, and not written up in an RFC. *Standardized* modern TCP congestion control does not include any delay-based component. Vista's CTCP does have a delay-based component and Linux includes some algorithms with delay-based components, but these are all experimental, and not even passed through the IETF TCPM group yet. See: http://www.ietf.org/internet-drafts/draft-sridharan-tcpm-ctcp-01.txt http://www.ietf.org/internet-drafts/draft-rhee-tcpm-cubic-00.txt for example specifications of "modern" *experimental* TCP congestion controllers that have delay-based components that detect and react to changes in RTT as congestion signals. _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
