Re: [multipathtcp] High-level design decisions /architecture

[Costin Raiciu <[e-mail]>]

I don't understand what you mean by subflows fighting each other.

look at the examples in the picture attached .

Say for simplicity that the RTT of the multipath subflows is the same  
in both cases, and say link 1, link 2 and link 3 have the same loss  
rate p (i.e. disregard flows B,C and E).

The controller will give the **same** throughput to the multipath  
connection in the two cases, i.e. what a TCP would get if it saw loss  
rate p.

In this case, there is no throughput benefit for using multipath;  
multipath increases throughput when it can affect the loss rates. In  
the same picture, if the flows B,C and E have the same throughput as  
the multipath subflows, the connection will get:
1. (link1 + link2)/3 in the first case
2. link3 / 2 in the second case.

Hope this makes things clearer.

Cheers,
Costin

> Costin Raiciu wrote:
>> Hi Joe,
>>
>> The proposed congestion controller gives the aggregate multipath
>> connection the throughput a TCP would get on the best (fastest) of  
>> the
>> paths available (to the multipath connection). It does so only by
>> looking at loss rates and rtts on the different paths. It does not  
>> need
>> to know whether there is a shared bottleneck or not.
>
> If it doesn't, then you will create the potential for a single  
> multipath
> group to fight with itself, which seems less than productive.
>
> Joe
>