Subject: [multipathtcp] Fwd: q about draft-raiciu-mptcp-congestion-01

From: Costin Raiciu <[email-masked]>
Date: Wed, 30 Mar 2011 09:09:33 -0400

Hi Roch,

There was an email discussion on the list a while ago related to your question (the email echange is included below). Does this make things clearer?
Costin

Begin forwarded message:

> From: Yoshifumi Nishida <[email-masked]>
> Date: 22 April 2010 06:17:33 EDT
> To: [email-masked]
> Subject: Re: [multipathtcp] q about draft-raiciu-mptcp-congestion-01
> 
> 
> Hello Costin,
> 
> I really appreciate your patience. Now, I think I understand your point clearly. Thank you so much!
> I'll think about this a little bit more during the weekend.
> 
> Thanks,
> --
> Yoshifumi Nishida
> [email-masked]
> 
> 
> 
> From: Costin Raiciu <[email-masked]>
> Subject: Re: [multipathtcp] q about draft-raiciu-mptcp-congestion-01
> Date: Wed, 21 Apr 2010 10:21:36 +0100
> Message-ID: <[email-masked]>
> 
>> 
>> Costin
>> 
>> On 21 Apr 2010, at 07:50, Yoshifumi Nishida wrote:
>> 
>>> 
>>> Hi Costin, Thanks for your reply.
>>> 
>>> I still have 2 questions on this.. Please point out if I misunderstand something.
>>> 
>>> 1: Let's say, we have two disjoint 100Mbps links and we have already one TCP 
>>>  connection on each link.
>>>  Here, we start MPTCP to use both links. In this case, Normal TCP will get 
>>>  80Mbps and each subflow of MPTCP will get 20Mbps on each link. Hence, MPTCP 
>>>  will get 40Mbps as total.
>>> 
>>>  But, this does not satisfy the Goal 1 ( A multipath flow should perform at least 
>>>  as well as a single path flow would on the best of the paths available to it )
>> 
>> No. Multipath will equalize loss rates on the two links above. Say the loss rate is p on both links.
>> The TCPs will get an avg window of sqrt(2/p).
>> One multipath flow will get an avg window of sqrt(a/p) (because it is growing with a/2 packets per RTT). The aggregate multipath window is 2*sqrt(a/p) = sqrt(4*a/p). When a=0.5, this becomes sqrt(2/p) which is the same as single path TCP.
>> 
>>> 
>>> 2: From my point of view, the performance of subflow still looks 1/4 of the 
>>>  performance of normal TCP that goes through the same link. 
>>>  Because the coupled congestion control only affects the increase of cwnd. I can't see
>>>  any other differences from noraml TCP connections. If we run 2 subflows on the link 
>>>  with 0.5% PLR, I think both subflows will see 0.5% loss. 
>> The key difference is the way the window is reduced. If you have a single TCP flow sending w packets per RTT, and packet loss rate is p, it will drop the window to w/2 on average every 1/(pw) RTTs (this assumes the window is constant in the interval - for simplicity of argument). If you have a multipath flow sending w packets per RTT in aggregate, at the same packet loss rate p it will get a drop every 1/(wp) RTTs; however this drop will be only on one of the two subflows, which will reduce its window to half. The aggregate window has now dropped from w to 3w/4. This is less aggressive than TCP. Hence, we need to increase less aggressively too.
>> 
>> Cheers,
>> Costin
>> 
>>> 
>>> Thanks,
>>> --
>>> Yoshifumi Nishida
>>> [email-masked]
>>> 
>>> From: Costin Raiciu <[email-masked]>
>>> Subject: Re: [multipathtcp] q about draft-raiciu-mptcp-congestion-01
>>> Date: Tue, 20 Apr 2010 23:02:09 +0100
>>> Message-ID: <[email-masked]>
>>> 
>>>> Hi Yoshifumi.
>>>> 
>>>> Let's assume both subflows go through a common bottleneck and have the same rtt. 
>>>> You are right, the aggregate increase of the two multipath subflows would be 0.5 segments per rtt which is half of a single TCP flow. However, on a drop on any subflow, the total rate is decreased by 1/4 because the subflow that takes the drop halves its rate. In aggregate this decrease is less aggresive than TCPs. The slower increase + less aggressive decrease of multipath even out, and the resulting rate is that of the single path tcp.
>>>> 
>>>> Cheers,
>>>> Costin
>>>> 
>>>> On 20 Apr 2010, at 20:05, Yoshifumi Nishida wrote:
>>>> 
>>>>> 
>>>>> Hi Costin, Thanks for the response.
>>>>> 
>>>>> Sorry, I guess I am still confused.. Please let me explain.
>>>>> 
>>>>> According to the draft, "subflow i will increase by alpha * cwnd_i / tot_cwnd segments per RTT."
>>>>> 
>>>>> Now, if we have two identical links, alpha will be 0.5 as you mentioned.
>>>>> This means, each subflow will increase by 0.25 segments per RTT, 
>>>>> which will be likely 4 times slower than normal TCP. 
>>>>> 
>>>>> I think each subflow can increase by 0.5 segments per RTT in this case.
>>>>> 
>>>>> Thanks,
>>>>> --
>>>>> Yoshifumi Nishida
>>>>> [email-masked]
>>>>> 
>>>>> 
>>>>> From: Costin Raiciu <[email-masked]>
>>>>> Subject: Re: [multipathtcp] q about draft-raiciu-mptcp-congestion-01
>>>>> Date: Tue, 20 Apr 2010 12:07:54 +0100
>>>>> Message-ID: <[email-masked]>
>>>>> 
>>>>>> Hi Yoshifumi.
>>>>>> 
>>>>>> Alpha does not control resource pooling, It just adjusts the total rate of the multipath flow to match that of a single path flow on the best path. Your calculations are right, alpha should be 0.5 in that case.
>>>>>> 
>>>>>> Resource pooling is "embedded" is the linkage: each subflow r will grow with alpha * cwnd_r / total_cwnd per RTT. This means that flows with lower loss rate (i.e. higher window) will get most of the increase.
>>>>>> 
>>>>>> We have studied a family of algorithms parameterized by phi  (phi in [0,2]), where changing phi changes the degree of resource pooling. In that family, the algorithm  with phi=1 is the algorithm in this draft. It gets reasonable resource pooling, and does not overreact to congestion signals from one path; this makes it more robust when congestion levels vary, as in the internet today. That study is in a paper under submission; if you want I can send you the paper offline.
>>>>>> 
>>>>>> Cheers,
>>>>>> Costin
>>>>>> 
>>>>>> On 20 Apr 2010, at 11:47, Yoshifumi Nishida wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Hello, Please correct me if I'm wrong.. 
>>>>>>> I have one question in the caluclation of alpha in draft-raiciu-mptcp-congestion-01
>>>>>>> 
>>>>>>> If I understand correctly, I think the alpha=1 is the best value for ideal 
>>>>>>> resource pooling scenario.  
>>>>>>> 
>>>>>>> Now, let's say we have two links which have the same value for rtt_i, mss_i  
>>>>>>> and cwnd_i. Then, total_cwnd will be 2 * cwnd_i. 
>>>>>>> In this case, alpha will be calcurated by the following equation: 
>>>>>>> 
>>>>>>>                                                 2 
>>>>>>>                                   cwnd_i * mss_i 
>>>>>>>                                  --------------- 
>>>>>>>                                            2 
>>>>>>>                                      rtt_i 
>>>>>>>          alpha = 2 * cwnd_i  * ------------------------- 
>>>>>>>                               /   2*  cwnd_i * mss_i \ 2 
>>>>>>>                               |  ----------------    | 
>>>>>>>                               \         rtt_i        / 
>>>>>>> 
>>>>>>> Then, it will be 1/2. 
>>>>>>> Where did I make mistake? 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> -- 
>>>>>>> Yoshifumi Nishida
>>>>>>> [email-masked]
>>>>>>> _______________________________________________
>>>>>>> multipathtcp mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>>>>>> 
>>>> 
>>