Subject: [multipathtcp] new version of draft-khalili-mptcp-congestion-control

From: Ramin Khalili <[email-masked]>
Date: Tue, 22 Oct 2013 12:19:21 +0200

Folks,

We have updated our draft about the congestion control of MPTCP by 
applying comments and feedback we received from the members of mptcp WG:

http://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control

As a summary, in this draft we introduce "Opportunistic Linked-Increases 
Algorithm" (OLIA) for the congestion control of MPTCP. OLIA has been 
proposedin our CoNEXT 2012 paper. The extended version of this paper is 
published at IEEE/ACM ToN 2013.We show in these papers that the 
currentcongestion control of MPTCP suffers from important performance 
issues and that OLIA successfully addresses these problems and satisfies 
the design goal of MPTCP.

Recent studies over a wide range of scenarios (including wireless 
networks)show that MPTCP with OLIA always outperforms MPTCP with LIA and 
is very responsive to the changes in the environment (see IMC13 and 
CoNEXT13). These results all confirm that OLIA is an appropriate 
congestion control for MPTCP.

Unfortunately, I could not participate at IETF 88 in Vancouver but I 
would appreciate if there would be a short discussion during the mptcp 
WG meeting about how to proceed with this draft.

Best regards,

Ramin Khalili.

[CoNEXT12]: R. Khalili, N. Gast, M. Popovic, U. Upadhyay, J-Y. Le 
Boudec. "MPTCP is not Pareto-optimal: Performance issues and a possible 
solution", ACM CoNEXT 2012 (Best Paper)

http://conferences.sigcomm.org/co-next/2012/eproceedings/conext/p1.pdf

[ToN13]: R. Khalili, N. Gast, M. Popovic, J.-Y. Le Boudec. "MPTCP is not 
Pareto-optimal: Performance issues and a possible solution", IEEE/ACM 
Transaction on Networking, Vol. 21, Issue 5, October 2013.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6583272

[IMC13]: Y.-C. Chih, Y.-S. Lim, R. J. Gibbens, E. Nahum, R. Khalili, and 
D. Towsley, "A Measurement-based Study of MultiPath TCP Performance over 
Wireless Networks," long paper atACM IMC 2013.

http://conferences.sigcomm.org/imc/2013/papers/imc231-chenA.pdf

[CoNEXT13]: C. Paasch, R.Khalili, O. Bonaventure, "On the Benefits of 
Applying Experimental Design to Improve Multipath TCP", short paper at 
ACM CoNEXT 2013.

http://conferences.sigcomm.org/co-next/2013/program.html
(the camera ready would be available in few weeks)

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 22 Oct 2013 10:50:50 -0700

Hi Ramin,

OK. Let chairs discuss this.
In the meantime, I really appreciate if people express opinions on this.
(support, not support, let's wait a bit more, etc)
Please note that our current charter does not cover congestion control for
multipath transport protocols.
I think we will need to re-charter if we want to proceed this. Please let
us know if you have comments on this.

Thanks,
--
Yoshifumi

On Tue, Oct 22, 2013 at 3:19 AM, Ramin Khalili <
[email-masked]> wrote:

> proposed in our CoNEXT 2012 paper. The extended version of this paper is
> published at IEEE/ACM ToN 2013. We show in these papers that the currentcongestion control of MPTCP suffers from important performance issues and
> that OLIA successfully addresses these problems and satisfies the design
> goal of MPTCP.
>
> networks) show that MPTCP with OLIA always outperforms MPTCP with LIA and
> CoNEXT13). These results all confirm that OLIA is an appropriate congestion
> control for MPTCP.
>
> Unfortunately, I could not participate at IETF 88 in Vancouver but I would
> appreciate if there would be a short discussion during the mptcp WG meeting
> about how to proceed with this draft.
>
> Best regards,
> Ramin Khalili.
>
> [CoNEXT12]: R. Khalili, N. Gast, M. Popovic, U. Upadhyay, J-Y. Le Boudec.
> "MPTCP is not Pareto-optimal: Performance issues and a possible solution",
> ACM CoNEXT 2012 (Best Paper)
> Pareto-optimal: Performance issues and a possible solution", IEEE/ACM Transaction
> on Networking, Vol. 21, Issue 5, October 2013.
> Wireless Networks," long paper at ACM IMC 2013.
> [CoNEXT13]: C. Paasch, R. Khalili, O. Bonaventure, "On the Benefits of
> Applying Experimental Design to Improve Multipath TCP", short paper at ACM
> CoNEXT 2013.

---

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

Hi Yoshifumi,

During the IETF meeting in Berlin, I have discussed with Fred Baker, 
Olivier Bonaventure, and Philip Eardley about this draft. The general 
feedback was that congestion control is an important part of MPTCP and 
OLIA seems to be an appropriate solution, so it should be discussed in 
the group. The question was how to fit it into the agenda.

It would be really great if other folks can also express their opinion 
about how to proceed with this draft.

Best regards,
Ramin.

Am 22.10.2013 19:50, schrieb Yoshifumi Nishida:
> In the meantime, I really appreciate if people express opinions on 
> this. (support, not support, let's wait a bit more, etc)
> Please note that our current charter does not cover congestion control 
> for multipath transport protocols.
> I think we will need to re-charter if we want to proceed this. Please 
> let us know if you have comments on this.
>
> Thanks,
> --
> Yoshifumi
>
>
> On Tue, Oct 22, 2013 at 3:19 AM, Ramin Khalili 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Folks,
>
>     As a summary, in this draft we introduce "Opportunistic
>     Linked-Increases Algorithm" (OLIA) for the congestion control of
>     MPTCP. OLIA has been proposedin our CoNEXT 2012 paper. The
>     extended version of this paper is published at IEEE/ACM ToN
>     2013.We show in these papers that the currentcongestion control of
>     MPTCP suffers from important performance issues and that OLIA
>     successfully addresses these problems and satisfies the design
>     goal of MPTCP.
>
>     networks)show that MPTCP with OLIA always outperforms MPTCP with
>     LIA and is very responsive to the changes in the environment (see
>     IMC13 and CoNEXT13). These results all confirm that OLIA is an
>     appropriate congestion control for MPTCP.
>
>     Unfortunately, I could not participate at IETF 88 in Vancouver but
>     I would appreciate if there would be a short discussion during the
>     mptcp WG meeting about how to proceed with this draft.
>
>     Best regards,
>
>     Ramin Khalili.
>
>     Boudec. "MPTCP is not Pareto-optimal: Performance issues and a
>     possible solution", ACM CoNEXT 2012 (Best Paper)
>
>     [ToN13]: R. Khalili, N. Gast, M. Popovic, J.-Y. Le Boudec. "MPTCP
>     is not Pareto-optimal: Performance issues and a possible
>     solution", IEEE/ACM Transaction on Networking, Vol. 21, Issue 5,
>     October 2013.
>
>     [IMC13]: Y.-C. Chih, Y.-S. Lim, R. J. Gibbens, E. Nahum, R.
>     Khalili, and D. Towsley, "A Measurement-based Study of MultiPath
>     TCP Performance over Wireless Networks," long paper atACM IMC 2013.
>
>     [CoNEXT13]: C. Paasch, R.Khalili, O. Bonaventure, "On the Benefits
>     of Applying Experimental Design to Improve Multipath TCP", short
>     paper at ACM CoNEXT 2013.
>

---

From: Rui Paulo <[email-masked]>
Date: Mon, 28 Oct 2013 16:46:13 -0700

On 22 Oct 2013, at 10:50, Yoshifumi Nishida <[email-masked]> wrote:
> I think we will need to re-charter if we want to proceed this. Please let us know if you have comments on this.

Hmm, really? There is already a (apparently broken) MPTCP congestion control RFC. Why do we need to re-charter to improve on it?

Just curious.

--
Rui Paulo

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 28 Oct 2013 19:10:53 -0700

Hi Rui,

On Mon, Oct 28, 2013 at 4:46 PM, Rui Paulo <[email-masked]> wrote:

> Hmm, really? There is already a (apparently broken) MPTCP congestion
> control RFC. Why do we need to re-charter to improve on it?
>

Hmm.  I don't think I saw the info that the current MPTCP congestion
control is broken.
It would be good if you could list the pointer for it.
I've read the Ramin's draft (draft-khalili-mptcp-performance-issues), but I
think we will need to discuss how the scenarios in the draft are crucial.

BTW, I'm inclined to think your comment as showing support on the draft. Am
I wrong?
--
Yoshifumi

---

From: Ramin Khalili <[email-masked]>
Date: Tue, 29 Oct 2013 12:08:43 +0100

Yoshifumi,

Based on our results, we can argue that the current congestion control 
of MPTCP does not provide any better load-balancing/congestion-balancing 
than using Uncoupled NewReno (where regular TCP congestion control is 
used on the subflows). I could not say that it is completely broken but 
it does not do its job.

As an alternative exist that does the job, and as it is already part of 
the MPTCP implementation, I do not see any reason why we should not 
discuss about it.

Cheers,
Ramin.

Am 29.10.2013 03:10, schrieb Yoshifumi Nishida:
> Hi Rui,
>
> On Mon, Oct 28, 2013 at 4:46 PM, Rui Paulo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 22 Oct 2013, at 10:50, Yoshifumi Nishida
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > I think we will need to re-charter if we want to proceed this.
>     Please let us know if you have comments on this.
>
>     Hmm, really? There is already a (apparently broken) MPTCP
>     congestion control RFC. Why do we need to re-charter to improve on it?
>
>
> I've read the Ramin's draft (draft-khalili-mptcp-performance-issues), 
> but I think we will need to discuss how the scenarios in the draft are 
> crucial.
>
> BTW, I'm inclined to think your comment as showing support on the 
> draft. Am I wrong?
> --
> Yoshifumi
>
>
>
>
>
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Rui Paulo <[email-masked]>
Date: Tue, 29 Oct 2013 09:23:17 -0700

> On Oct 28, 2013, at 19:10, Yoshifumi Nishida <[email-masked]> wrote:
> 
> Hmm.  I don't think I saw the info that the current MPTCP congestion control is broken.
> I've read the Ramin's draft (draft-khalili-mptcp-performance-issues), but I think we will need to discuss how the scenarios in the draft are crucial.
> 
> BTW, I'm inclined to think your comment as showing support on the draft. Am I wrong?

I was merely questioning the need to re-charter given that RFC 6356 is a product of this WG. I haven't read Ramin's draft yet so I can't comment.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 29 Oct 2013 20:53:19 -0700

On Tue, Oct 29, 2013 at 9:23 AM, Rui Paulo <[email-masked]> wrote:

> I was merely questioning the need to re-charter given that RFC 6356 is a
> product of this WG. I haven't read Ramin's draft yet so I can't comment.
>

I see.
Just to be clear. Of course, we can have random discussions on RFC6356 or
Ramin's draft.
But, we cannot make consensus or publishing a document as an WG product if
it is not on the charter.
--
Yoshifumi

---

From: Rui Paulo <[email-masked]>
Date: Wed, 30 Oct 2013 10:08:18 -0700

On 29 Oct 2013, at 20:53, Yoshifumi Nishida <[email-masked]> wrote:
> Just to be clear. Of course, we can have random discussions on RFC6356 or Ramin's draft.
> But, we cannot make consensus or publishing a document as an WG product if it is not on the charter.

Are you saying that Ramin’s draft (which, as I understand it, is an improvement of RFC 6356) does not fall under the initial WG charter section c) ?

Specifically:

"c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control.”

I’m sure there’s something I’m missing, but I’m trying to understand why this WG can’t publish MPTCP congestion control documents without a new charter. What’s even more confusing to me is that we already published a congestion control algorithm with the initial charter.

If we indeed have to re-charter to work on MPTCP congestion control algorithms, I’d love to know what the WG chairs think about this.

Thanks,
--
Rui Paulo

---

From: <[email-masked]>
Date: Wed, 30 Oct 2013 18:04:44 +0000

Rui
Please see http://www.ietf.org/mail-archive/web/multipathtcp/current/msg02088.html

Best wishes
Phil

> -----Original Message-----
> From: Rui Paulo [mailto:[email-masked]]
> Sent: 30 October 2013 17:08
> To: Yoshifumi Nishida; Eardley,PL,Philip,TUB8 R
> Cc: multipathtcp
> Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-
> congestion-control
> 
> Are you saying that Ramin's draft (which, as I understand it, is an
> improvement of RFC 6356) does not fall under the initial WG charter
> section c) ?
> 
> Specifically:
> 
> "c. A coupled multipath-aware congestion control algorithm. This
> algorithm is the multipath equivalent of SACK/NewReno congestion
> control."
> 
> I'm sure there's something I'm missing, but I'm trying to understand
> why this WG can't publish MPTCP congestion control documents without a
> new charter. What's even more confusing to me is that we already
> published a congestion control algorithm with the initial charter.
> 
> If we indeed have to re-charter to work on MPTCP congestion control
> algorithms, I'd love to know what the WG chairs think about this.
> 
> Thanks,
> --
> Rui Paulo
> 
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 30 Oct 2013 20:50:35 -0700

Hi Rui,

On Wed, Oct 30, 2013 at 10:08 AM, Rui Paulo <[email-masked]> wrote:

> Are you saying that Ramin’s draft (which, as I understand it, is an
> improvement of RFC 6356) does not fall under the initial WG charter section
> c) ?

Well, the section is a part to describe the previous charter..
I think you won't see congestion control related words in the part to
describe new charter.

> I’m sure there’s something I’m missing, but I’m trying to understand why
> this WG can’t publish MPTCP congestion control documents without a new
> charter. What’s even more confusing to me is that we already published a
> congestion control algorithm with the initial charter.
>
> algorithms, I’d love to know what the WG chairs think about this.
>

Putting a topic in the charter means we will have to set milestone for it.
Otherwise, evaluating the progress might be difficult, which is not good
thing for the WG.
Hence, WG chairs sometimes omit a certain topics from the charter which
seems to be less attractive.

But, I also think re-chartering for adding a certain topic is fairly easy
for the WG as long as there is consensus. We can start the procedure if
that's the consensus.

Thanks,
--
Yoshifumi

---

From: Ramin Khalili <[email-masked]>
Date: Thu, 31 Oct 2013 15:04:54 +0100

Hi Yoshifumi,

What are the typical milestones for a topic like congestion control? I 
am asking as many practical milestones, such as implementation, 
debugging, integration into the UCLouvain'S MPTCP implementation, and 
performance evaluation (on many difference settings) are already done 
for our algorithm.

Cheers,
Ramin.

Am 31.10.2013 04:50, schrieb Yoshifumi Nishida:
> Hi Rui,
>
> On Wed, Oct 30, 2013 at 10:08 AM, Rui Paulo <[email-masked] 
>     On 29 Oct 2013, at 20:53, Yoshifumi Nishida
>     Are you saying that Ramin's draft (which, as I understand it, is
>     an improvement of RFC 6356) does not fall under the initial WG
>     charter section c) ?
>
>
>     I'm sure there's something I'm missing, but I'm trying to
>     understand why this WG can't publish MPTCP congestion control
>     documents without a new charter. What's even more confusing to me
>     is that we already published a congestion control algorithm with
>     the initial charter.
>
>     If we indeed have to re-charter to work on MPTCP congestion
>     control algorithms, I'd love to know what the WG chairs think
>     about this.
>
>
> Putting a topic in the charter means we will have to set milestone for 
> it. Otherwise, evaluating the progress might be difficult, which is 
> not good thing for the WG.
> Hence, WG chairs sometimes omit a certain topics from the charter 
> which seems to be less attractive.
>
> But, I also think re-chartering for adding a certain topic is fairly 
> easy for the WG as long as there is consensus. We can start the 
> procedure if that's the consensus.
>
> Thanks,
> --
> Yoshifumi
>
>
>
>
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 31 Oct 2013 20:45:49 -0700

Hi Ramin,

I'm not sure if these are typical topics, but I'm guessing it might be
analysis and evaluation for the current algorithm or new algorithm spec.
Anyway, it will be decided by the consensus.
--
Yoshifumi

On Thu, Oct 31, 2013 at 7:04 AM, Ramin Khalili <
[email-masked]> wrote:

>  Hi Yoshifumi,
>
> What are the typical milestones for a topic like congestion control? I am
> asking as many practical milestones, such as implementation, debugging,
> integration into the UCLouvain'S MPTCP implementation, and performance
> evaluation (on many difference settings) are already done for our algorithm.
>
> Cheers,
> Ramin.
>
> it. Otherwise, evaluating the progress might be difficult, which is not
> good thing for the WG.
> easy for the WG as long as there is consensus. We can start the procedure
> if that's the consensus.
>
>  Thanks,
> --
> Yoshifumi
>
>
>
>
>
> multipathtcp mailing [email-masked]://www.ietf.org/mailman/listinfo/multipathtcp
>
>
>