Subject: Re: [multipathtcp] potential MPTCP proxy charter item

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Mon, 17 Oct 2016 21:22:03 +0000

Sorry for the late reply, but more in-line

From: multipathtcp <[email-masked]> on behalf of "mohamed. boucadair" <[email-masked]>
Date: Friday, 7 October 2016 at 09:08
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item

Hi Phil,

Please see inline.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 8 août 2016 11:50
À : [email-masked]
Objet : [multipathtcp] potential MPTCP proxy charter item

I had thought a potential charter item could be something on the lines of:

<Experimental Extensions to the MPTCP protocol to enable an MPTCP-aware middlebox to act as an MPTCP proxy for an end host, which runs TCP. One or both end hosts may be MPTCP-unaware, and the MPTCP proxy(s) is (are) not necessarily on the default routing path(s). The working group will also detail, in an Informational document, the use cases /deployment scenarios and the operational considerations.>

[Med] I would like to see the charter includes the following; “The working group will also edit Network-Assisted Multipath provisioning documents. In particular, the WG will specify DHCP options and RADIUS attributes for MPTCP.”

WH> I am fine with this, but why do we state experimental extensions? Why is this not main stream?
However, if I get the discussion right, this is not quite right.
* assume a controlled environment (to avoid a problem where the message reaches the ‘wrong’ proxy) (IETF usually prefers generally applicable protocols)
* assume some (?additional) ‘header swapping’ protocol and a new signalling protocol (not an mptcp extension – so probably in INTAREA WG’s remit)
[Med] IMHO, it is not odd to document in the mptcp wg how a Network-Assisted MPTCP solution can also be applicable to other protocols (UDP in particular). This work can be done jointly/closely with other WGs. The important point is whether there is enough interest from the mptpcp WG members to work on this.
WH> indeed is to specify the means in MPTCP WG and other WG can be consulted to review the work. If you split it out it becomes less efficient from a protocol perspective.
If the above is roughly right, then I think some extra work is needed before we can get a clear charter item. Can some of the work that isn’t mptcp extensions be cleanly separated out? Can you be clear what deployment assumptions are being made (and preferably reduce them, so there is wider applicability). Personally I’d also find it very helpful if the plain/transparent ‘merged’ draft could try and follow the guidance about protocol models in RFC4101 (personally I found the plain mode doc difficult to understand).

Thanks
phil

---

From: <[email-masked]>
Date: Tue, 18 Oct 2016 05:52:37 +0000

Hi Wim,

Yes, this can be main stream.

Cheers,
Med

De : Henderickx, Wim (Nokia - BE) [mailto:[email-masked]]
Envoyé : lundi 17 octobre 2016 23:22
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; [email-masked]
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

From: multipathtcp <[email-masked]<mailto:[email-masked]>> on behalf of "mohamed. boucadair" <[email-masked]<mailto:[email-masked]>>
Date: Friday, 7 October 2016 at 09:08
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item

Hi Phil,

Please see inline.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : lundi 8 août 2016 11:50
À : [email-masked]<mailto:[email-masked]>
Objet : [multipathtcp] potential MPTCP proxy charter item

Thanks
phil

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 18 Oct 2016 17:46:16 +0200

Hi Med, hi all,

there are two cases to distinguish here:

1) you have one or two MPTCP proxies that terminate the TCP connection and open a new MPTCP connection

2) you tunnel other traffic over MPTCP

Case two is using TCP as a tunneling mechanism. This is discussed in several working groups for different purposes and is not very straight-forward in a lot of cases. Such an approach definitely needs coordination and transport as well as tunnel expertise.

Which case are you talking about? While Phil’s proposal sounded rather like case 1, your proposal sounds very much like case 2.

Mirja

> Am 18.10.2016 um 07:52 schrieb [email-masked]:
> 
> Hi Wim,
>  
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Wed, 19 Oct 2016 04:05:16 +0000

Case 1 is a mandatory 
I would like to see case 2 as well, but I agree on coordination

On 18/10/2016, 17:46, "Mirja Kühlewind" <[email-masked]> wrote:

    Hi Med, hi all,

    

    
    Mirja

---

From: <[email-masked]>
Date: Wed, 19 Oct 2016 05:28:02 +0000

Hi Mirja, 

I'm for these two cases to be included:
* Case 1 is the mandatory piece to have.
* Case 2 solves the problem for no TCP traffic while leveraging on the same extensions that are used for case 1.  

I do fully agree that case 2 requires inter-area/WG coordination. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kühlewind [mailto:[email-masked]]
> Envoyé : mardi 18 octobre 2016 17:46
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Henderickx, Wim (Nokia - BE); [email-masked];
> [email-masked]
> Case two is using TCP as a tunneling mechanism. This is discussed in
> several working groups for different purposes and is not very straight-
> forward in a lot of cases. Such an approach definitely needs coordination
> and transport as well as tunnel expertise.
> 
> Which case are you talking about? While Phil’s proposal sounded rather
> like case 1, your proposal sounds very much like case 2.
> 
> Mirja
> 
> 
> > From: multipathtcp <[email-masked]> on behalf of
> "mohamed. boucadair" <[email-masked]>
> > To: "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> > <Experimental Extensions to the MPTCP protocol to enable an MPTCP-aware
> middlebox to act as an MPTCP proxy for an end host, which runs TCP. One or
> both end hosts may be MPTCP-unaware, and the MPTCP proxy(s) is (are) not
> necessarily on the default routing path(s). The working group will also
> detail, in an Informational document, the use cases /deployment scenarios
> and the operational considerations.>
> >
> > [Med] I would like to see the charter includes the following; “The
> working group will also edit Network-Assisted Multipath provisioning
> documents. In particular, the WG will specify DHCP options and RADIUS
> attributes for MPTCP.”
> >
> >
> > * assume a controlled environment (to avoid a problem where the message
> reaches the ‘wrong’ proxy) (IETF usually prefers generally applicable
> protocols)
> > * assume some (?additional) ‘header swapping’ protocol and a new
> signalling protocol (not an mptcp extension – so probably in INTAREA WG’s
> remit)
> > [Med] IMHO, it is not odd to document in the mptcp wg how a Network-
> Assisted MPTCP solution can also be applicable to other protocols (UDP in
> particular). This work can be done jointly/closely with other WGs. The
> important point is whether there is enough interest from the mptpcp WG
> members to work on this.
> > WH> indeed is to specify the means in MPTCP WG and other WG can be
> consulted to review the work. If you split it out it becomes less
> efficient from a protocol perspective.
> > If the above is roughly right, then I think some extra work is needed
> before we can get a clear charter item. Can some of the work that isn’t
> mptcp extensions be cleanly separated out? Can you be clear what
> deployment assumptions are being made (and preferably reduce them, so
> there is wider applicability). Personally I’d also find it very helpful if
> the plain/transparent ‘merged’ draft could try and follow the guidance
> about protocol models in RFC4101 (personally I found the plain mode doc
> difficult to understand).
> >
> > Thanks
> > phil
> >
> >
> >

---

From: Alan Ford <[email-masked]>
Date: Wed, 19 Oct 2016 10:45:55 +0100

Do you guys expect any impact on the base protocol from this work?

Regards,
Alan

> On 19 Oct 2016, at 06:28, [email-masked] wrote:
> 
> Hi Mirja, 
>

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Wed, 19 Oct 2016 15:17:33 +0000

I don’t expect changes to the base spec. AT least not with the current view of the solution/implementations.

On 19/10/2016, 11:45, "multipathtcp on behalf of Alan Ford" <[email-masked] on behalf of [email-masked]> wrote:

    Regards,
    Alan

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 19 Oct 2016 21:42:18 +0200

Mirja,
> 1) you have one or two MPTCP proxies that terminate the TCP connection and open a new MPTCP connection

There is a very clear demand for this type of solution and there are 
various implementations that are available or are being developped. 
Several deployments exist and there is a large demand for this type of 
services. It would be silly for the IETF to ignore this use case after 
having spent years to specify the Multipath TCP protocol.

Olivier

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 19 Oct 2016 22:36:24 +0200

Hi Olivier,

I think both cases are valid and interesting for the IETF. The questions is where to address them. As I said case 1 could be in scope for MPTCP or actually is probably already with the current charter. 

The other question however is, what does the IETF need to do here. I believe most of this use case can just be done right now without any further actions of the IETF.

I know there is a proposal for an MPTCP extension to support this use case. I would recommend to separate this out from the operational consideration because specifying the extension is clearly in scope for the working group.

My 2c.
Mirja

> Am 19.10.2016 um 21:42 schrieb Olivier Bonaventure <[email-masked]>:
> 
> Mirja,
>> 
> There is a very clear demand for this type of solution and there are various implementations that are available or are being developped. Several deployments exist and there is a large demand for this type of services. It would be silly for the IETF to ignore this use case after having spent years to specify the Multipath TCP protocol.
> 
> 
> 
> Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 19 Oct 2016 13:56:59 -0700

Hello,

On Wed, Oct 19, 2016 at 12:42 PM, Olivier Bonaventure
<[email-masked]> wrote:
> There is a very clear demand for this type of solution and there are various
> implementations that are available or are being developped. Several
> deployments exist and there is a large demand for this type of services. It
> would be silly for the IETF to ignore this use case after having spent years
> to specify the Multipath TCP protocol.

I also think we should not ignore the use case.
But, I am somehow thinking that we might want to clarify the
terminologies a bit more so that we can have more clear focus.

I might be wrong, but these words give me the following impressions.

1: Protocol X proxy:
    It speaks protocol X on behalf of communicating endpoints .
    From one end's point of view, it looks as if the other end speaks
protocol X.

2: Tunneling over protocol X
     Protocol X carries other protocol Y packets (by using
encapsulation)  All info in protocol Y (headers, etc) will be
preserved.

3:  Protocol X-Y / Protocol Y-X gateway
     Convert protocol X into protocol Y, or convert protocol Y into
protocol X for protocol connectivity/compatibility, etc.
     Some info in the original protocol might be lost due to the conversion.

If I follow these impressions, it seems that some proposals are close
to 3. (again, I might be wrong)
I might want to check if we want to clarify this point in the charter
or leave it ambiguous.
I am just wondering if we might need to clarify the terminology or
adding some texts to avoid miscommunications.

Thanks,
--
Yoshi

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Thu, 20 Oct 2016 04:01:06 +0000

Alan, one thing that came to mind to support long TCP option for plain-mode/TFO something might be required in the base draft.
For Ipv6 we need more space and if we design it well we can use it for TCP-AO, etc etc

Besides this we are good afais 

On 19/10/2016, 17:17, "Henderickx, Wim (Nokia - BE)" <[email-masked]> wrote:

    
        
        Regards,
        Alan

---

From: <[email-masked]>
Date: Thu, 20 Oct 2016 05:56:46 +0000

Hi Alan, 

There is a modification that we expect from the base MPTCP. It is basically associating a meaning with a flag in the MP_CAPABLE option.

Cheers,
Med

> De : Alan Ford [mailto:[email-masked]]
> Envoyé : mercredi 19 octobre 2016 11:46
> Cc : Mirja Kühlewind; [email-masked]
> > * Case 2 solves the problem for no TCP traffic while leveraging on the
> same extensions that are used for case 1.
> >
> >> 1) you have one or two MPTCP proxies that terminate the TCP connection
> and
> >> open a new MPTCP connection
> >>

---

From: <[email-masked]>
Date: Thu, 20 Oct 2016 05:58:58 +0000

Hi Mirja, 

Please see inline.

Cheers,
Med

> Envoyé : mercredi 19 octobre 2016 22:36
> À : [email-masked]
> Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> I think both cases are valid and interesting for the IETF. The questions
> is where to address them. As I said case 1 could be in scope for MPTCP or
> actually is probably already with the current charter.
> 
> The other question however is, what does the IETF need to do here. I
> believe most of this use case can just be done right now without any
> further actions of the IETF.

[Med] Yes, there are some implementations and even deployments. The feedback from some of these deployments is that, for example, they are suffering from long setup delays of MPTCP connections vs. TCP. For non-TCP solutions, most of deployments require that the same vendor provide both the CPE and the concentrator located in the network side! ... 

Because existing solutions are not optimized and suffer from interoperability issues, there is a need for IETF protocol extensions.   

> 
> I know there is a proposal for an MPTCP extension to support this use
> case. I would recommend to separate this out from the operational
> consideration because specifying the extension is clearly in scope for the
> working group.

[Med] I agree that this should be separated. My take on this is that we need this set of documents: 

* MPTCP extension: Specify the MPTCP option and its usage
* An Informational document on use cases/deployment scenarios and the operational considerations
* MPTCP provisioning DHCP/RADIUS documents. 

> and open a new MPTCP connection
> >

---

From: <[email-masked]>
Date: Thu, 20 Oct 2016 06:14:50 +0000

Hi Yoshi, 

The discussion I had with many operators is that they would like to see both TCP and UDP addressed with the ** same solution**. This is why we came up with the proposal to leverage MPTCP for other protocols (UDP, mainly).

>     From one end's point of view, it looks as if the other end speaks

And

> protocol X for protocol connectivity/compatibility, etc.

I know Olivier/Stefano have a better name to denote both these cases. 

Cheers,
Med

> De : Yoshifumi Nishida [mailto:[email-masked]]
> Envoyé : mercredi 19 octobre 2016 22:57
> Cc : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; [email-masked]
> various

---

From: <[email-masked]>
Date: Thu, 20 Oct 2016 06:50:24 +0000

WG,

Let me second Med's recent replies to Yoshi, Mirja and Alan. 

I too believe the mptcp WG is the right placeholder to work on an MPTCP extension that can accommodate use cases which are currently being investigated, marketed and - yes - deployed (for some of them, with their procession of already-documented drawbacks (TCP-only communications) and flaws, like QoS-affecting signaling delays) by some operators.

These use cases mainly fall under the so-called hybrid access service offering umbrella, so that end-users can take advantage of various access network technologies for the sake of optimized resource usage, among other incentives.

I also believe MPTCP is the right solution to address such use cases. As I already mentioned a while ago, working on an extension that can facilitate the establishment of MPTCP connections in a network-assisted fashion as we call it in the current Plain Transport Mode option draft will not hinder MPTCP massive adoption but rather encourage it.

I also know there are already prototype implementations of such extension that are currently being tested.

I therefore support the adoption of the MPTCP proxy charter item by the mptcp WG, as this work addresses very concrete and short term use cases that have been publicized by several operators. 

And I think that this WG should start working asap on the set of deliverables mentioned by Med in his recent response to Mirja: MPTCP extension specification, deployment scenarios and operational considerations and DHCP/RADIUS-based provisioning means.

Cheers,

Christian.

-----Message d'origine-----
De : multipathtcp [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 20 octobre 2016 08:15
À : Yoshifumi Nishida; [email-masked]
Cc : [email-masked]
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Yoshi, 

And

Cheers,
Med

> De : Yoshifumi Nishida [mailto:[email-masked]] Envoyé : 
> mercredi 19 octobre 2016 22:57 À : [email-masked] Cc 
> : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; [email-masked] 
> > would be silly for the IETF to ignore this use case after having 
> > spent
> years
> to 3. (again, I might be wrong) I might want to check if we want to 
> clarify this point in the charter or leave it ambiguous.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Skog <[email-masked]>
Date: Thu, 20 Oct 2016 07:01:35 +0000

Hi all!
We have seen solid interest from several operators on Hybrid Access solutions based on MPTCP as the base technology.
In the light of increased UDP traffic we also see demand for the same type of solution also catering for UDP.
Therefore, I believe the MPTCP WG should continue the work around the "plain mode" to have a solution for UDP and update the charter (if it is needed for the continuation).

Cheers,
/Robert

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: den 20 oktober 2016 08:15
To: Yoshifumi Nishida <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [multipathtcp] potential MPTCP proxy charter item

Hi Yoshi, 

And

Cheers,
Med

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 25 Oct 2016 14:06:47 +0200

Hi all, hi Christian,

see below.

> Am 20.10.2016 um 08:50 schrieb [email-masked]:
> 
> WG,
> 

I agree that these use case are interesting and work is needed here. See further below.

> 
> I also believe MPTCP is the right solution to address such use cases.

As I mention previously there are two very different deployment scenarios: a connection-terminating MPTCP proxy or a MPTCP tunnel solution. In general using TCP as a tunneling technology is challenging and has a broader scope than just MPTCP.

> As I already mentioned a while ago, working on an extension that can facilitate the establishment of MPTCP connections in a network-assisted fashion as we call it in the current Plain Transport Mode option draft will not hinder MPTCP massive adoption but rather encourage it.
> 

An MPTCP extension specification is clearly in scope for MPTCP and can be done right now without a charter change. 

I’m not sure if deployment scenarios need to be documented (in an RFC). As you said above there are already prototype and some real deployments as well. Not sure why we need additional documentation here.

Operational consideration might or might not below in the MPTCP working group. However, there is the BANANA BoF in Seoul that will discuss hybrid-access services (and different approach to provide this service). Depending where this effort goes that might be a better home or some wg in intarea.

DHCP/RADIUS extension go into the DHC working group. They are charter to specify these kind of extensions and you can start this work there immediately.

I’m not saying we shouldn’t do this work; I’m just saying that MPTCP might not be the right group for all parts of this work. This is my recommendation as transport AD but I’m sure a rechartering discussion in the IESG would provide similar feedback.

Mirja

---

From: <[email-masked]>
Date: Wed, 26 Oct 2016 08:12:30 +0000

Hi,
I remember in Berlin discussion about a new /merged version of Med and Olivier's drafts - with a nice description of the protocol model to make it easier to understand (both the high-level approach, and the assumptions - especially as these are different to those of RFC6824). I think this would make it easier to write text for a new charter item. (at least my attempt to write a new charter item a while back was inaccurate /inadequate).  Is this possible please?
I agree we want this work to happen - it's great to see MPTCP being widely used and we want standardisation.

Best wishes
Phil. 

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of Mirja Kühlewind
Sent: 25 October 2016 13:07
To: [email-masked]
Cc: [email-masked]
Subject: Re: [multipathtcp] potential MPTCP proxy charter item

Hi all, hi Christian,

see below.

Mirja

> De : multipathtcp [mailto:[email-masked]] De la part de 
> [email-masked] Envoyé : jeudi 20 octobre 2016 08:15 À : 
> Yoshifumi Nishida; [email-masked] Cc : 
> [email-masked] Objet : Re: [multipathtcp] potential MPTCP proxy 
> charter item
> 
> Hi Yoshi,
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: <[email-masked]>
Date: Fri, 28 Oct 2016 06:44:53 +0000

Hi Phil, 

I remember, as well :-)

The drafts were completely rewritten to take into considerations the comments and also to help the chartering effort. Here is the set of the Network-Assisted MPTCP documents:

* An MPTCP Option for Network-Assisted MPTCP: https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09 
* Network-Assisted MPTCP: Use Cases, Deployment Scenarios and Operational Considerations: https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-00 
* DHCP Options for Network-Assisted Multipath TCP: https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-06 
* RADIUS Extensions for Network-Assisted Multipath TCP: https://tools.ietf.org/html/draft-boucadair-mptcp-radius-03 

Questions, comments and suggestions are more than welcome!

Cheers,
Med

> [email-masked]
> Envoyé : mercredi 26 octobre 2016 10:13
> À : [email-masked]; JACQUENET Christian IMT/OLN
> I remember in Berlin discussion about a new /merged version of Med and
> Olivier's drafts - with a nice description of the protocol model to make
> it easier to understand (both the high-level approach, and the assumptions
> - especially as these are different to those of RFC6824). I think this
> would make it easier to write text for a new charter item. (at least my
> attempt to write a new charter item a while back was inaccurate
> /inadequate).  Is this possible please?
> > I too believe the mptcp WG is the right placeholder to work on an MPTCP
> extension that can accommodate use cases which are currently being
> investigated, marketed and - yes - deployed (for some of them, with their
> procession of already-documented drawbacks (TCP-only communications) and
> flaws, like QoS-affecting signaling delays) by some operators.
> >
> > These use cases mainly fall under the so-called hybrid access service
> offering umbrella, so that end-users can take advantage of various access
> network technologies for the sake of optimized resource usage, among other
> incentives.
> 
> As I mention previously there are two very different deployment scenarios:
> a connection-terminating MPTCP proxy or a MPTCP tunnel solution. In
> general using TCP as a tunneling technology is challenging and has a
> broader scope than just MPTCP.
> 
> 
> > As I already mentioned a while ago, working on an extension that can
> facilitate the establishment of MPTCP connections in a network-assisted
> fashion as we call it in the current Plain Transport Mode option draft
> will not hinder MPTCP massive adoption but rather encourage it.
> >
> > I also know there are already prototype implementations of such
> extension that are currently being tested.
> >
> > I therefore support the adoption of the MPTCP proxy charter item by the
> mptcp WG, as this work addresses very concrete and short term use cases
> that have been publicized by several operators.
> >
> > And I think that this WG should start working asap on the set of
> deliverables mentioned by Med in his recent response to Mirja: MPTCP
> extension specification, deployment scenarios and operational
> considerations and DHCP/RADIUS-based provisioning means.
> 
> I’m not sure if deployment scenarios need to be documented (in an RFC). As
> you said above there are already prototype and some real deployments as
> well. Not sure why we need additional documentation here.
> 
> Operational consideration might or might not below in the MPTCP working
> group. However, there is the BANANA BoF in Seoul that will discuss hybrid-
> access services (and different approach to provide this service).
> Depending where this effort goes that might be a better home or some wg in
> intarea.
> 
> DHCP/RADIUS extension go into the DHC working group. They are charter to
> specify these kind of extensions and you can start this work there
> immediately.
> 
> I’m not saying we shouldn’t do this work; I’m just saying that MPTCP might
> not be the right group for all parts of this work. This is my
> recommendation as transport AD but I’m sure a rechartering discussion in
> the IESG would provide similar feedback.
> 
> Mirja
> 
> 
> 
> >
> > Cheers,
> >
> > Christian.
> >
> > The discussion I had with many operators is that they would like to see
> both TCP and UDP addressed with the ** same solution**. This is why we
> came up with the proposal to leverage MPTCP for other protocols (UDP,
> mainly).
> >
> >>> deployments exist and there is a large demand for this type of
> services.
> >> It
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que
> les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
> >
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.

---

From: Alan Ford <[email-masked]>
Date: Sat, 29 Oct 2016 11:01:46 +0100

Hi Med,

Thank you for updating these drafts, I have been awaiting these with great interest!

Re draft-nam-mptcp-deployment-considerations-00:
- The three use cases in S3 make sense
- But in S4, the two deployment scenarios, focuses purely on Scenarios 1 & 3, not 2

In S5.2.1, the usage model is that data is explicitly targeted to the MCP.
in S5.2.2, implicit, it only works for Scenario 1 of S4. By the diagrams, it needs to now that a destination is not MPTCP capable - how does it have this knowledge? Should it actually be intercepting the SYN/ACK from RM and making adjustments there?

This continues in the 5.2.2.1 discussion - what is the purpose of MP_CONVERT in the implicit mode? Is it just to say “if there’s an MCP on this path, I would like it“? This seems different from the use of it as described in the plain mode draft (where it appears to be used for explicit mode by signalling the target IP address). You talk about differentiating between “native” and “proxied” MPTCP connections, but how would the initiator know this in implicit mode?

I think this is a valuable document which explains how proxies can be used to extend the benefits of MPTCP to connections where one or both end hosts are not MPTCP-capable. It think this fits with the proxy charter item today.

Re draft-boucadair-mptcp-plain-mode-09

S3.1 - two issues:

1) How does the client know the server does not support MPTCP and thus should be going through the proxy? Or does everything go through the proxy?
(This is similar to the question in implicit mode of how does the MCP know the server does not support MPTCP?)

2) Why make MP_CONVERT appear to be be part of MPTCP, when it’s not? In S4 you talk about it being included in the SYN payload - therefore it’s part of the TCP payload. This is fine and aligns with what I’ve been saying since IETF95 - the proposed protocol is not MPTCP-specific, and is simply signalling the target at the start of the TCP payload. This does not need to be a MPTCP option to make this happen.

To be clear - again - I have no issue with this work being done in MPTCP WG, it is “how to use proxies to increase deployment of MPTCP”. But this particular document is not MPTCP-specific; whether it is published here or elsewhere I don’t care, but it really shouldn’t’ be written as if it’s extending the MPTCP spec when there is no reason for it to be.

Finally, you earlier mentioned the possible effect on the base spec regarding a flag, but I see no mention of it in these docs.

Regards,
Alan

> On 28 Oct 2016, at 07:44, [email-masked] wrote:
> 
> Hi Phil, 
> 
> I remember, as well :-)
>