Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-congestion-control-01

From: ramin <[email-masked]>
Date: Thu, 24 Oct 2013 14:10:38 +0200

Sure, I will add a discussion part about this modification and will udate the new version.

Regards,
Ramin.

-------- Original message --------
From: Yoshifumi Nishida <[email-masked]> 
Date:  
To: Ramin Khalili <[email-masked]> 
Cc: Christoph Paasch <[email-masked]>,KUHN Nicolas <[email-masked]>,multipathtcp <[email-masked]>,Yoshifumi Nishida <[email-masked]> 
Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-congestion-control-01 
 
Hi Ramin, Christoph, Nicolas,

Thanks for the clarification.
I just thought OLIA uses low ssthresh at the beginning of the connection when I read the text, but now I think I understand.
I think I still need to understand how using 1 MSS for minimum ssthresh can affect the performance.
I'm hoping you will add some discussions on this point in the new version.

Thanks,
--
Yoshifumi 

On Wed, Oct 23, 2013 at 7:00 AM, Ramin Khalili <[email-masked]> wrote:
Hi Yoshifumi,

As Nicolas and Christoph said, the motivation behind this modification is to be less aggressive over a very lossy path. TCP new-reno uses ssthresh to decide if the user is in slow start or congestion avoidance phase (if cwnd =< ssthresh we are in slow start, o.w. congestion avoidance). Note that cwnd increases much faster during the slow start phase than congestion avoidance.

To have a good load balancing in the network, we should not use paths that have very bad performance. If we use minimum ssthresh of 2 MSS, cwnd would be almost always greater than 3MSS on a path even if the path is very lossy (because slow start is more aggressive than congestion avoidance). This results to a minimum traffic rate of 3MSS/RTT over a path which is very high.

By our modification, we allow the minimum traffic rate over a path be as small as 1MSS/RTT. Note that we do not change the minimum value of cwnd and similarly to TCP new-reno it is set to 1MSS. Also, this modification will not affect good paths (as for these paths, the probability that ssthresh become 1MSS is very small). Also, we apply this modification only if more than one path is available to the user, hence, it does not affect the performance of single path connections.

I would add some discussion in the draft about why and how this modification is applied. I am wondering if I can upload the new version after the modification?

Best regards,
Ramin.

Am 23.10.2013 10:29, schrieb Christoph Paasch:

Hello,

On 23/10/13 - 10:09:31, KUHN Nicolas wrote:
Le 23/10/2013 06:53, Yoshifumi Nishida a écrit :
Thanks for the reply. But, I think I am still a bit confused.
Maybe I overlook something...
I think I will need to think about Section 3 more carefully. It
would be great if you can point out what I'm missing.

1: "The algorithm only applies to the increase part of the
congestion avoidance phase."
     -> It seems to me that OLIA does nothing during slow start
phase, which is fine for me.

The algorithm behind OLIA congestion windows updates must be
introduced in congestion avoidance phase. And the slow start phase
should be the same as TCP. I agree with you on that point.

2: "We also use a similar slow start algorithm as in TCP, with the
modification that we set the ssthresh (slow start threshold) to be
1 MSS if multiple paths are established."
     -> It seems to me that OLIA supports slow-start like
algorithm. But, if you set ssthresh to be 1 MSS, I'm not sure how
you can activate it. Also, this sounds a bit contradictory to 1: .

Here comes the confusion. Setting ssthresh to be 1 MSS means that
there is no slow start phase: the congestion window is always
greater than 1MSS!
I guess there is a mistake in the current draft and I propose the
following changes:
1- precise that, as for common TCP, the ssthresh is initialized to
"infinity";
2- replace ssthresh hold in this section by "initial congestion
window" or "minimum congestion window".
the setting of ssthresh to 1 is done, when subsequent losses make the
ssthresh come down to 2. In regular TCP, if a loss happens and ssthresh
equals 2, it will not set it to 1, but leave it at 2.
However, with Ramin's proposal it will set it to 1, effectively allowing
a sending-rate of 1 packet per RTT.

The text probably needs to be changed to reflect this.

Cheers,
Christoph

3:  "In the case of a single path flow, we use the same minimum
ssthresh as in TCP (i.e. 2 MSS)."
    -> I am not very sure how the minimum ssthresh affects OLIA. I
guess it will be used only after loss.
As previously mentioned, I guess this confusion comes from the fact
that ssthresh has been used (instead of minimum congestion window).
Let me know if I am wrong.
If I am right, I think it is important to adapt the draft regarding
this issue.

Kind regards,

Nicolas

Thanks,
--
Yoshifumi

On Mon, Oct 21, 2013 at 2:46 AM, Ramin Khalili
<[email-masked]> wrote:
Dear Nicolas, Yoshifumi,

Thanks for your comments and points. We have apply them in our
draft and will submit the new version of our draft by this
afternoon (I will send a submission notice when the new version is
available).
With regards to the question about ssthresh, as Nicolas said,
the main goal is to to avoid the overuse of a congested path
whereas other paths are available.
With Christoph Paasch from UCLouvain, we have done a number of
experiments to study the effect of setting the minimum ssthresh to
1. We observed that it improves the load balancing in the network
but the gain is not very significant. Note that minimum ssthresh
for single path TCP would be still 2 MSS; hence, our modification
will not effect the single path TCP performance.
Cheers,

Ramin.

-------- Original Message --------
Subject:        Re: [multipathtcp] some comments on
draft-khalili-mptcp-congestion-control-01
Date:   Thu, 26 Sep 2013 00:32:42 -0700
From:   Yoshifumi Nishida <[email-masked]>
To:     Nicolas Kuhn <[email-masked]>
CC:     multipathtcp <[email-masked]>

Hi Nicolas,

Thanks for the response.

On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn
<[email-masked]
<mailto:[email-masked]>> wrote:

     Hello,

     Le 23/09/2013 08:00, Yoshifumi Nishida a écrit :
     Hello,
     I've read draft-khalili-mptcp-congestion-control-01 with great
     interests and have the following comments. Please let me
know if I
     miss something.

     1: It seems to me that how to determine collective_paths and
     max_w_paths are a bit ambiguous. Since they are "paths", it
seems
     that they are expected to be more than 1.
     However, I'm not very sure about the logic to choose them. For
     example, if 3 paths have
     10MSS, 20MSS, 30MSS cwnd respectively, do we choose the
20MSS path
     as one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case?

     More details can be found in [5], Section 4.1: Equations (3)
and (4)
     should be included in the draft.

OK. Thanks for the info.

     2: Do we really need to set the ssthresh to 1 MSS when
multiple
     paths are used? RFC6356 doesn't have this kind of logic. I'm
     wondering why this is required. Also, in case of single
path, the
     draft requires to set the ssthresh to 2 MSS, but I'm not
very sure
     about the rationale behind this.

     This may be required to avoid the overuse of a congested path
     whereas other paths are available. If there are many paths,
there is
     no use in spoiling media resources with ssthresh set to 2
MSS. I
     guess this parameter is set to 1 MSS to properly only
analyze the
     traffic around.

     The authors may have more explanations than I do.

I personally think setting small ssthresh is not very necessarily,
especially for single path case.
If this is an important point for the logic, I would like to see
some
rationale in the draft.
I hope authors will address this in new version.

Thanks,
--
Yoshifumi

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