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

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 22 Sep 2013 23:00:49 -0700

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?

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.

3: It looks that w_p and rtt_p in equation (1) are not defined.

Editorial comment:
Reference 7 is not cited in the draft.

Thanks,
--
Yoshifumi

---

From: Nicolas Kuhn <[email-masked]>
Date: Mon, 23 Sep 2013 09:01:29 +0200

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.

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

> 3: It looks that w_p and rtt_p in equation (1) are not defined.
It should be: SUM_{p \in paths}(w_p;rtt_p) - according to [5].

Regards,

Nicolas KUHN

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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 26 Sep 2013 00:32:42 -0700

Hi Nicolas,

Thanks for the response.

> should be included in the draft.

OK. Thanks for the info.

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

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