Subject: [multipathtcp] TR: New Version Notification for draft-boucadair-mptcp-plain-mode-10.txt

From: <[email-masked]>
Date: Fri, 10 Mar 2017 08:43:26 +0000

Dear all, 

A new version of the draft is available online. This version integrates the comments that were raised on the mailing list. 
We had many off-line discussions with Alan, this version is the outcome of those discussion. The main changes are:

* MP_CONVERT object does not consume anymore the MPTCP option codepoints space.
* A new MPTCP option (MP_PREFER_PROXY) is defined to demux native connections vs proxied one when the implicit mode is in use.
* MCPs are now able to detect if remote MCPs do not support MP_CONVERT
* Only TCP is covered
* Interference with TFO are discussed 

Comments, questions, and suggestions are always welcome.

Cheers,
Med

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> Envoyé : vendredi 10 mars 2017 08:52
> À : Wim Henderickx; Luis M. Contreras; [email-masked]; Wouter
> Cloetens; Suresh Vinapamula; Denis Behaghel; BOUCADAIR Mohamed IMT/OLN;
> Suresh Vinapamula; Robert Skog; Luis Contreras; JACQUENET Christian
> IMT/OLN; Bart Peirens; Ullrich Meyer; Denis Behaghel; Olivier Bonaventure;
> SungHoon Seo; Stefano Secci
> Objet : New Version Notification for draft-boucadair-mptcp-plain-mode-
> 10.txt
> 
> 
> A new version of I-D, draft-boucadair-mptcp-plain-mode-10.txt
> has been successfully submitted by Mohamed Boucadair and posted to the
> IETF repository.
> 
> Name:		draft-boucadair-mptcp-plain-mode
> Revision:	10
> Title:		Extensions for Network-Assisted MPTCP Deployment Models
> Document date:	2017-03-09
> Group:		Individual Submission
> Pages:		25
> URL:            https://www.ietf.org/internet-drafts/draft-boucadair-
> mptcp-plain-mode-10.txt
> Status:         https://datatracker.ietf.org/doc/draft-boucadair-mptcp-
> plain-mode/
> Htmlized:       https://tools.ietf.org/html/draft-boucadair-mptcp-plain-
> mode-10
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-boucadair-mptcp-
> plain-mode-10
> 
> Abstract:
>    Because of the lack of Multipath TCP (MPTCP) support at the server
>    side, some service providers now consider a network-assisted model
>    that relies upon the activation of a dedicated function called MPTCP
>    Conversion Point (MCP).  Network-Assisted MPTCP deployment models are
>    designed to facilitate the adoption of MPTCP for the establishment of
>    multi-path communications without making any assumption about the
>    support of MPTCP by the communicating peers.  MCPs located in the
>    network are responsible for establishing multi-path communications on
>    behalf of endpoints, thereby taking advantage of MPTCP capabilities
>    to achieve different goals that include (but are not limited to)
>    optimization of resource usage (e.g., bandwidth aggregation), of
>    resiliency (e.g., primary/backup communication paths), and traffic
>    offload management.
> 
>    This document specifies extensions for Network-Assisted MPTCP
>    deployment models.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Alan Ford <[email-masked]>
Date: Thu, 23 Mar 2017 23:40:11 +0000

Hi Med, all,

Thanks for this, and I’m sorry it’s taken a couple of weeks to respond. This document is certainly clearer to follow than previous versions and it’s clearer where you’re going with this now. You have two different ways of implementing MPTCP proxying which work in different deployment scenarios.

My main concern remains the need for this MP_PREFER_PROXY option.

The use case as I see it is for the CPE acting as an MCP to insert this into the flow in order to signal for the other MCP to pick up the flow and proxy it. But I still find myself asking why?

Why is this solution uniquely better than either:

- Explicitly address the MCP using MP_CONVERT; or
- Just insert MCP into everything which doesn’t support MPTCP anyway

This would potentially require DHCP to deliver the MCP address for point 1, and potential policy configuration as to what to proxy and what not to for point 2, but are these significant issues? What sort of policy would a client be able to apply which a proxy would not be able to? And are there any scenarios why the MP_PREFER_PROXY bit is the only way of achieving what you want?

Given this option is now a separate option and not a bit in the MP_CAPABLE handshake I am less concerned about its impact on the base protocol spec, since this can be kept entirely separate, but I am still puzzled as to the actual real-world requirements of this rather than the other two options.

As a side issue, and not to derail this conversation, I’d rather the term “MP_CONVERT" didn’t look quite so much like an MPTCP option when it wasn’t.

Regards,
Alan

> On 10 Mar 2017, at 08:43, [email-masked] wrote:
> 
> Dear all, 
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Fri, 24 Mar 2017 07:02:32 +0000

Hi Alan,

Please see inline.

Cheers,
Med

De : Alan Ford [mailto:[email-masked]]
Envoyé : vendredi 24 mars 2017 00:40
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : Re: [multipathtcp] New Version Notification for draft-boucadair-mptcp-plain-mode-10.txt

Hi Med, all,

The use case as I see it is for the CPE acting as an MCP to insert this into the flow in order to signal for the other MCP to pick up the flow and proxy it.
[Med] Yes.

But I still find myself asking why?
[Med] Fair question.

- Explicitly address the MCP using MP_CONVERT;
[Med] The implicit mode is something that can be easily implemented compared to the explicit mode even if it comes with its constraints (e.g., location of the MCP, ..). Our approach here is not mandate the deployment scheme and let operators to make their choice.

 or
- Just insert MCP into everything which doesn’t support MPTCP anyway
[Med] The problem with the second one is that MCP resources usage won’t be optimized: an operator would like to dedicate these resources to the connections it proxies. Further, because “everything doesn’t support MPTCP anyway” there will be MCPs that will strip by default MP_CAPABLE. So, having the MP_PREFER_PROXY signal will help MPTCP connections issued from endhosts to bypass this MCP.

Regards,
Alan

On 10 Mar 2017, at 08:43, [email-masked]<mailto:[email-masked]> wrote:

Dear all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : vendredi 10 mars 2017 08:52
À : Wim Henderickx; Luis M. Contreras; [email-masked]<mailto:[email-masked]>; Wouter

Abstract:

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

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

---

From: Alan Ford <[email-masked]>
Date: Fri, 24 Mar 2017 12:16:55 +0000

Hi Med,

Thanks for the reply. I remain confused however with this:

What connections do you envisage not getting a MP_PREFER_PROXY signal on them?

Regards,
Alan

> On 24 Mar 2017, at 07:02, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Alan,
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> De : Alan Ford [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc : [email-masked] <mailto:[email-masked]>
> On 10 Mar 2017, at 08:43, [email-masked] <mailto:[email-masked]> wrote:
>  
> Dear all, 
> 
> De : [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>]
> À : Wim Henderickx; Luis M. Contreras; [email-masked] <mailto:[email-masked]>; Wouter
> URL:            https://www.ietf.org/internet-drafts/draft-boucadair- <https://www.ietf.org/internet-drafts/draft-boucadair->
> mptcp-plain-mode-10.txt
> Status:         https://datatracker.ietf.org/doc/draft-boucadair-mptcp- <https://datatracker.ietf.org/doc/draft-boucadair-mptcp->
> plain-mode/
> Htmlized:       https://tools.ietf.org/html/draft-boucadair-mptcp-plain- <https://tools.ietf.org/html/draft-boucadair-mptcp-plain->
> mode-10
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-boucadair-mptcp- <https://www.ietf.org/rfcdiff?url2=draft-boucadair-mptcp->
> plain-mode-10
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/multipathtcp <https://www.ietf.org/mailman/listinfo/multipathtcp>
>

---

From: <[email-masked]>
Date: Fri, 24 Mar 2017 12:37:23 +0000

Re-,

Please see inline.

Cheers,
Med

Envoyé : vendredi 24 mars 2017 13:17

Hi Med,

What connections do you envisage not getting a MP_PREFER_PROXY signal on them?
[Med] MPTCP connections issued from a host in the LAN. A default policy configured to a CPE would be that these connections need to bypass the network-assisted MPTCP service.

Regards,
Alan

On 24 Mar 2017, at 07:02, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alan,

Please see inline.

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>

Hi Med, all,

 or

Regards,
Alan

Dear all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : vendredi 10 mars 2017 08:52
À : Wim Henderickx; Luis M. Contreras; [email-masked]<mailto:[email-masked]>; Wouter

Abstract:

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

---

From: Alan Ford <[email-masked]>
Date: Fri, 24 Mar 2017 23:44:27 +0000

Hi Med,

> [Med] MPTCP connections issued from a host in the LAN. A default policy configured to a CPE would be that these connections need to bypass the network-assisted MPTCP service. 

Could you please expand on this? Which connections would get network-assisted MPTCP and which would not? Why treat some different from others?

Regards,
Alan

> On 24 Mar 2017, at 12:37, [email-masked] wrote:
> 
> Re-,
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> On 24 Mar 2017, at 07:02, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Alan,
>  
> Please see inline.
>  
> Cheers,
> Med
>

---

From: <[email-masked]>
Date: Mon, 27 Mar 2017 12:46:34 +0000

Hi Alan,

Please see inline.

Cheers,
Med

Envoyé : vendredi 24 mars 2017 18:44

Hi Med,

Could you please expand on this? Which connections would get network-assisted MPTCP and which would not? Why treat some different from others?
[Med] This is policy-based (Section 5.6.3 of draft-nam-mptcp-deployment-considerations). Policies to determine connections that are eligible to the network-assisted MPTCP can be provided by the network provider, configured locally on the CPE by a user, etc. It is perfectly fine for a network provider to provision a default policy to let pass all MPTCP connections received from the LAN side without any help form an MCP. Other policies can be provisioned to MCPs.

Regards,
Alan

On 24 Mar 2017, at 12:37, [email-masked]<mailto:[email-masked]> wrote:

Re-,

Please see inline.

Cheers,
Med

Hi Med,

Regards,
Alan

Hi Alan,

Please see inline.

Cheers,
Med

Hi Med, all,

 or

Regards,
Alan

Dear all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : vendredi 10 mars 2017 08:52
À : Wim Henderickx; Luis M. Contreras; [email-masked]<mailto:[email-masked]>; Wouter

Abstract:

The IETF Secretariat

---

From: Alan Ford <[email-masked]>
Date: Mon, 27 Mar 2017 21:48:41 +0100

Hi Med,

Right, so:

1) if you had policy at the sending MCP (CPE) it would need explicit mode.

2) If you had policy at the receiving MCP it could be done with implicit mode.

So the case where this is useful is if you have policy at the sending MCP but need to be using implicit mode. Is that right? Why would such a use case exist which could not be solved with either of the other two solutions above?

Regards,
Alan

> On 27 Mar 2017, at 13:46, [email-masked] wrote:
> 
> Hi Alan,
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> On 24 Mar 2017, at 12:37, [email-masked] <mailto:[email-masked]> wrote:
>  
> Re-,
>  
> Please see inline.
>  
> Cheers,
> Med
>

---

From: <[email-masked]>
Date: Tue, 28 Mar 2017 12:09:37 +0000

Hi Alan,

Please see inline.

Cheers,
Med

Envoyé : lundi 27 mars 2017 15:49

Hi Med,

Right, so:

1) if you had policy at the sending MCP (CPE) it would need explicit mode.
Med: Not necessarily. Policies to elect flows can be provisioned on the CPE for both explicit/implicit modes. Traffic selection and traffic distribution logic is a common building block, if you will, for all modes. Please refer to the nam-deployment draft.

2) If you had policy at the receiving MCP it could be done with implicit mode.
[Med] I’m not sure to get this one. Do you mean policies for incoming connections?

Regards,
Alan

On 27 Mar 2017, at 13:46, [email-masked]<mailto:[email-masked]> wrote:

Hi Alan,

Please see inline.

Cheers,
Med

Hi Med,

Regards,
Alan

Re-,

Please see inline.

Cheers,
Med

Hi Med,

Regards,
Alan

Hi Alan,

Please see inline.

Cheers,
Med

Hi Med, all,

 or

Regards,
Alan

Dear all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : vendredi 10 mars 2017 08:52
À : Wim Henderickx; Luis M. Contreras; [email-masked]<mailto:[email-masked]>; Wouter

Abstract:

The IETF Secretariat

---

From: Alan Ford <[email-masked]>
Date: Tue, 28 Mar 2017 13:32:32 +0100

Hi Med,

I’m trying to determine what problem is trying to be solved here. I may have badly expressed my statements before, so I’ll rephrase:

1) If you wanted policy on the sending MCP, explicit mode would allow this
2) If you wanted policy at the receiving MCP, implicit mode would allow this

Additionally, the MP_PREFER_PROXY option allows policy at the sending MCP in implicit mode.

What I’m trying to get at is whether there are any actual deployment situations where this model is necessary?

Regards,
Alan

> On 28 Mar 2017, at 13:09, [email-masked] wrote:
> 
> Hi Alan,
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> On 27 Mar 2017, at 13:46, [email-masked] <mailto:[email-masked]> wrote:
>  
> Hi Alan,
>  
> Please see inline.
>  
> Cheers,
> Med
>