[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Compound TCP
It looks like Compound TCP is an improvement to TCP Vegas. Essentially, TCP Vegas measures RTT precisely to detect when buffering starts. It then uses a couple of magic numbers to set how much buffering to maintain in the network. By playing with the magic numbers it can be made more or less aggressive compared to TCP Reno (the reference). FastTCP is a variant in which the window is adjusted in a cleverer manner so that it reaches it's steady state more quickly. It looks like Compound TCP uses both TCP Vegas style RTT based window adjustment for the bottom part of the window and TCP Reno style AIMD with pkt loss based window adjustment for the top part of the window. I can see how this can give the big benefits of TCP Vegas (I like TCP Vegas) and at the same time be able to deal well with pkt loss and be fair with other TCP Renos. So compound here I think is in the sense of both Vegas and Reno in the same TCP flow, but I don't think it has much bearing on multipath TCP, though I could be misunderstanding somethign obvious. Balraj On Wed, Jul 11, 2012 at 4:55 PM, Toby Moncaster <toby.moncaster@xxxxxxxxxxxx> wrote: > Hi All, > > not sure if anyone else has come across Microsoft's Compound TCP (which I > believe now ships as standard with Windows). It uses a combination of > delay-based and loss-based congestion controllers and is designed to work in > high-speed, long-distance networks without adversely affecting the > performance on slower or more congested networks. > > http://research.microsoft.com/en-us/projects/ctcp/ > > http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 > > http://en.wikipedia.org/wiki/Compound_TCP > > Toby > >
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |