Subject: [multipathtcp] is it necessary to calculate tot_cwnd in coupled congestion control algorithm ?

From: Ming Li <[email-masked]>
Date: Thu, 12 Apr 2012 09:20:15 +0300

Hei,

According to the formulas (1) and (2) given by " 
draft-ietf-mptcp-congestion-07 
<http://tools.ietf.org/html/draft-ietf-mptcp-congestion-07.txt>", when 
we put (2) into (1), the value of tot_cwnd is on both of the element and 
the denominator and element. Thus, we do not necessarily to calculate 
the tot_cwnd because it can be removed on the element and denominator. 
But the paper seems spend some effort to explain how to get the 
toto_cwnd value in kernel. I do not know why ? Could someone give some 
comments ?

Thank you very much!

Br,
Ming

---

From: Costin Raiciu <[email-masked]>
Date: Thu, 12 Apr 2012 12:09:35 +0300

Hi,

That's a good optimization that we have missed. tot_cwnd cancels out when you compute the actual increase, so it's not needed after all. You can just compute alpha/tot_cwnd and use it on every ack, thus removing the need
to compute tot_cwnd. The code thus becomes simpler.

Thanks,
Costin

On 12 Apr 2012, at 09:20, Ming Li wrote:

> Hei, 
> 
> According to the formulas (1) and (2) given by " draft-ietf-mptcp-congestion-07", when we put (2) into (1), the value of tot_cwnd is on both of the element and the denominator and element. Thus, we do not necessarily to calculate the tot_cwnd because it can be removed on the element and denominator. But the paper seems spend some effort to explain how to get the toto_cwnd value in kernel. I do not know why ? Could someone give some comments ?
> 
> Thank you very much!
> 
> Br,
> Ming
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Ming Li <[email-masked]>
Date: Thu, 12 Apr 2012 13:21:48 +0300

hei,

Thank you for your reply.

Now the problem is that: I used the correct formula but the result is 
not as the same as the that of the real implementation given by figure 7 
in the paper of "MultiPath TCP - From Theory to Practice".

It shows that in ns3 simulated mptcp, the coupled congestion control 
scheme is too conservative. When the packet loss rate of the lossy link 
is 1%, the throughput of the lossy link decreases much more 
dramatically. I attached my test result and the corresponding test 
result from that paper in the attachment.

Br,
Ming

---

From: Costin Raiciu <[email-masked]>
Date: Thu, 12 Apr 2012 16:33:42 +0300

Hi,

The difference in outcome is very big, as you say. I doubt the difference is due to a problem of the implementation - the formula is correct just less efficient. 

To compare properly you have to make sure you use the exact same setup. same buffer sizes, same RTT. Have you done that? 

Christoph of UCL-BE can give you details about the setup if it is not described in the paper already.
Costin

On 12 Apr 2012, at 13:21, Ming Li wrote:

> Now the problem is that: I used the correct formula but the result is not as the same as the that of the real implementation given by figure 7 in the paper of "MultiPath TCP - From Theory to Practice".
> 
> It shows that in ns3 simulated mptcp, the coupled congestion control scheme is too conservative. When the packet loss rate of the lossy link is 1%, the throughput of the lossy link decreases much more dramatically. I attached my test result and the corresponding test result from that paper in the attachment.
> 
> Br,
> Ming
> 
> 
> <mptcp-MPTCPCOUPLE-without-background-traffic.pdf><mptcp real implementation.png><2011 - MultiPath TCP - From Theory to Practice.pdf>