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

Just adding a few explanations to my previous email (which is a bit  
compressed).

> 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;
I mean, in the case when multipath cannot affect the loss rates at all.

> 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
This assumes link1 and link2 have the same capacity.

> 2. link3 / 2 in the second case.
>
> Hope this makes things clearer.
>
> Cheers,
> Costin
>
> <Picture 1.png>
>
>> 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
>>
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp