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

From: Ramin Khalili <[email-masked]>
Date: Mon, 21 Oct 2013 11:46:12 +0200

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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 22 Oct 2013 21:53:33 -0700

Hi Ramin, Nicolas,

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.

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

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.

Thanks,
--
Yoshifumi

>
> 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.
> draft-khalili-mptcp-congestion-control-01
>>     I've read draft-khalili-mptcp-congestion-control-01 with great

---

From: KUHN Nicolas <[email-masked]>
Date: Wed, 23 Oct 2013 10:09:31 +0200

Hi all,

Please find my comments in your email, and let me know if I am wrong 
about my understanding of the draft and your questions.

Le 23/10/2013 06:53, Yoshifumi Nishida a écrit :
> 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.
>
>      -> 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.

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

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

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 23 Oct 2013 10:29:37 +0200

Hello,

On 23/10/13 - 10:09:31, KUHN Nicolas wrote:
> >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."
> 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.
> 
> >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!
> 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

> that ssthresh has been used (instead of minimum congestion window).
> Let me know if I am wrong.
> >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.
> >>
> >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.
> >>
> >>
> >>
> >>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Ramin Khalili <[email-masked]>
Date: Wed, 23 Oct 2013 16:00:37 +0200

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.

---

From: Ramin Khalili <[email-masked]>
Date: Wed, 23 Oct 2013 16:34:41 +0200

Nicolas,

OLIA uses the same slow start mechanism as TCP, it also uses the same 
mechanism as TCP to update ssthresh. The only difference is that with 
TCP, ssthresh cannot be smaller than 2MSS but with OLIA it can be 1 MSS.

Roughly saying, when a loss occurs TCP divides the cwnd by half, i.e. 
cwnd = cwnd_old /2, and set ssthresh = max (min_ssthresh, cwnd_old/2). 
cwnd_old is the value of cwnd right before observing the loss. For TCP, 
min_ssthresh is 2 MSS. OLIA uses exactly the same algorithm as TCP but 
with min_ssthresh = 1.

I must note that the mechanism that is used by TCP (and OLIA) to 
determine ssthresh is a bit more complex than what I explained above.

Cheers,
Ramin.

Am 23.10.2013 10:09, schrieb KUHN Nicolas:
>> 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: .
>>
> there is no slow start phase: the congestion window is always greater 
> than 1MSS!
>> 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).
>> >
>> main goal is to to avoid the overuse of a congested path whereas 
>> other paths are available.
>> >
>> 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.
>> >
>> >
>> >
>> >

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 24 Oct 2013 01:26:28 -0700

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.
>
> 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.
>
>>>>> On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn
>>>>>
>>>> <[email-masked]
>>>>
>>>>>>      interests and have the following comments. Please let me
>>>>>>
>>>>> know if I
>>>>
>>>>>      miss something.
>>>>>>
>>>>>>      max_w_paths are a bit ambiguous. Since they are "paths", it
>>>>>>
>>>>> seems
>>>>
>>>>>>      10MSS, 20MSS, 30MSS cwnd respectively, do we choose the
>>>>>>
>>>>> 20MSS path
>>>>
>>>>>>       More details can be found in [5], Section 4.1: Equations (3)
>>>>>
>>>> and (4)
>>>>
>>>>>       2: Do we really need to set the ssthresh to 1 MSS when
>>>>>>
>>>>> multiple
>>>>
>>>>>>      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
>>>>
>>>>>      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.
>>>>>
>>>>> If this is an important point for the logic, I would like to see
>>>>>
>>>> some
>>>>
>>>>> rationale in the draft.
>>>>>  ______________________________**_________________
>>> https://www.ietf.org/mailman/**listinfo/multipathtcp<https://www.ietf.org/mailman/listinfo/multipathtcp>
>>>
>> ______________________________**_________________
>> https://www.ietf.org/mailman/**listinfo/multipathtcp<https://www.ietf.org/mailman/listinfo/multipathtcp>
>>
>
>