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

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 20 Apr 2010 19:47:15 +0900 (JST)

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]

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 20 Apr 2010 12:07:54 +0100

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:

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 21 Apr 2010 04:05:26 +0900 (JST)

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

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 20 Apr 2010 23:02:09 +0100

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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 21 Apr 2010 15:50:19 +0900 (JST)

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 )
   
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. 

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

---

From: Costin Raiciu <[email-masked]>
Date: Wed, 21 Apr 2010 10:21:36 +0100

Costin

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

>   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