Re: Compound TCP

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Indeed; Compound TCP appears to try to find the best of both congestion
worlds, but doesn't explicitly negotiate options during connection SYN
time.

This does remind me than another TODO list that Dave and I have at some
point is to put support for vchan back into Mirage, so we can benchmark
the shared memory vs TCP interdomain throughput with Mirage applications.
We're definitely going to use more 'userland' CPU than the highly tuned
C Linux/FreeBSD stacks, so it'll be interesting to see the impact of this.

-anil

On 11 Jul 2012, at 19:15, Toby Moncaster wrote:

> Definitely no direct bearing on MPTCP but it is interesting as it shows ms is 
> prepared to put more complex stuff in their stack. And it is also relevant to 
> our polyversal tcp
> 
> 
> 
> On 11 Jul 2012, at 18:59, Balraj Singh <balrajsingh@xxxxxxxx> wrote:
> 
>> 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
>>> 
>>> 
>> 
>