[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
>
>



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.