Subject: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-plain-mode-03.txt

From: <[email-masked]>
Date: Thu, 5 Nov 2015 13:45:41 +0000

Dear all,

This is an update to a proposal that intends to avoid requiring an extra encapsulating scheme between a CPE and an MPTCP Concentrator located in the provider's network. 

The document suggests also relaying UDP packets into TCP-formatted packets in the CPE-Concentrator leg. Some features may be disabled/enabled at the CPE/Concentrator when processing UDP packets.

The main motivation is to ease integrating an MPTCP Concentrator into an operational network without requiring updating intermediate service functions to support another yet encapsulation scheme.

Comments are more than welcome. 

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : jeudi 5 novembre 2015 14:33
> À : [email-masked]
> Objet : I-D Action: draft-boucadair-mptcp-plain-mode-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : An MPTCP Option for Network-Assisted MPTCP
> Deployments: Plain Transport Mode
>         Authors         : Mohamed Boucadair
>                           Christian Jacquenet
>                           Denis Behaghel
>                           Stefano Secci
> 	Filename        : draft-boucadair-mptcp-plain-mode-03.txt
> 	Pages           : 14
> 	Date            : 2015-11-05
> 
> Abstract:
>    One of the promising deployment scenarios for Multipath TCP (MPTCP)
>    is to enable a Customer Premises Equipment (CPE) that is connected to
>    multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its
>    network attachments.  Because of the lack of 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 Concentrator.  This document focuses on a deployment scheme
>    where the identity of the MPTCP Concentrator(s) is explicitly
>    configured on connected hosts.
> 
>    This document specifies an MPTCP option that is used to avoid an
>    encapsulation scheme between the CPE and the MPTCP Concentrator.
>    Also, this document specifies how UDP traffic can be distributed
>    among available paths without requiring any encapsulation scheme.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-boucadair-mptcp-plain-mode-03
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 12 Nov 2015 14:37:10 +0100

Med,
> This is an update to a proposal that intends to avoid requiring an extra encapsulating scheme between a CPE and an MPTCP Concentrator located in the provider's network.

This is an extension of the solution proposed earlier in
http://inl.info.ucl.ac.be/publications/multipath-middlebox

Do you have any implementation results that demonstrate the feasibility 
of the proposed approach ?

> The document suggests also relaying UDP packets into TCP-formatted packets in the CPE-Concentrator leg. Some features may be disabled/enabled at the CPE/Concentrator when processing UDP packets.

I'm not sure I understand why you want to map UDP packets into 
TCP-formatted packets. What is the benefit of having a 20 bytes header 
in front of UDP packets (maybe less if you apply a solution like
https://tools.ietf.org/html/draft-denis-udp-transport-00) ?

Do you plan to send SYN/SYN+ACK before the first packet of a flow and 
FIN/RST after ?

Olivier

---

From: <[email-masked]>
Date: Thu, 12 Nov 2015 14:03:21 +0000

Hi Olivier, 

Thank you for the feedback. 

Please see inline.

Cheers,
Med

> De : Olivier Bonaventure [mailto:[email-masked]]
> Envoyé : jeudi 12 novembre 2015 14:37
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Cc : Denis Behaghel ([email-masked])
> ([email-masked])
> Objet : Re: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-plain-
> mode-03.txt
> 
> Med,
> >
> > This is an update to a proposal that intends to avoid requiring an extra
> encapsulating scheme between a CPE and an MPTCP Concentrator located in
> the provider's network.
> 

[Med] Thank you for sharing the pointer. I will look at that document. 

> of the proposed approach ?

[Med] We are planning to have one or two implementations that follow this specification. We will share the results once available. 

> 
> > The document suggests also relaying UDP packets into TCP-formatted
> packets in the CPE-Concentrator leg. Some features may be disabled/enabled
> at the CPE/Concentrator when processing UDP packets.
> 
> TCP-formatted packets.

[Med] The benefit is to reuse at maximum the same functional blocks for handling both TCP and UDP traffic. Some specific TCP features may be enabled/disabled when handling the UDP traffic; this is deployment-specific. If tunneling is enabled for UDP, then there is no point to avoid it for TCP.

 What is the benefit of having a 20 bytes header
> https://tools.ietf.org/html/draft-denis-udp-transport-00) ?

[Med] I'm not aware of that draft. Will look at it.

> Do you plan to send SYN/SYN+ACK before the first packet of a flow and

[Med] No. The plan is to maintain the sessions used to transport udp packets open so that there is 0-RTT for relaying UDP packets.

---

From: Christoph Paasch <[email-masked]>
Date: Sun, 15 Nov 2015 18:23:10 -0800

Hello Mohamed,

I tried to understand the draft, but it's not yet clear to me how the
proxying would work.

Am I right that the draft is proposing a scheme where the Proxies (CPE and
concentrator) are not terminating the TCP-connections?
If that's the case, I am wondering how the TCP sequence numbers are being
handled end-to-end (from the client's device to the server).

Further, it seems to me that the assumption is that MPTCP guarantees the
message-boundaries, because the Plain Mode MPTCP option is put on a
per-segment basis. However, MPTCP cannot guarantee that those message
boundaries are respected.
In my opinion, Plain Mode MPTCP's option belongs into the payload. So,
basically, this would be multistreaming (e.g., HTTP/2-style) on top of a
reliable transport like MPTCP.

Cheers,
Christoph

On 05/11/15 - 13:45:41, [email-masked] wrote:
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 16 Nov 2015 11:15:21 +0000

Christoph, my 2 cents:
- The proposal terminates the sequence numbers and provides a true proxy and hence rewrites the sequence numbers at the proxy points.
- I am not sure what you mean with the message boundaries. Can you clarify?

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 16 Nov 2015 14:09:08 +0100

Med,
> This is an update to a proposal that intends to avoid requiring an extra encapsulating scheme between a CPE and an MPTCP Concentrator located in the provider's network.

I'm not sure I fully understand your proposal. Can I summarize it in 
saying that you place the plain mode MPTCP option in all segments that 
are exchanged and that this option is used to allow the CPE and the 
concentrator to rewrite the IP addresses of the MPTCP segments that they 
receive ?

This looks strange to me because it creates some overhead in each 
segment and also requires the utilisation of EDO which is not yet widely 
implemented. Note you might have problems to use EDO and support any 
middlebox that would already exist in the network as mentioned in 
section 4.1
"The use of a plain transport mode does not require the upgrade of any
    intermediate function (security, TCP optimizer, etc.) that may be
    located on-path."

I would start to analyse first what can be done when there are no 
middleboxes, because if you want to support them, they will mess with 
almost everything.

Olivier

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 17 Nov 2015 00:16:35 -0800

> - The proposal terminates the sequence numbers and provides a true proxy and hence rewrites the sequence numbers at the proxy points.

Ok, I see. Thanks for clarifying.

>From Mohamed's document I understand that he wants to tunnel multiple TCP
streams on top of a single MPTCP connection.
This means, that different TCP connections with different destinations will
be sent on the same MPTCP-connection. Thus, each of those segments will have
a different MPTCP Plain Mode option, which implies that these segments
cannot get split/coalesced as otherwise data will be delivered to the wrong
destination behind the concentrator. And it also implies that MPTCP will
take into account to which TCP-connection data in the send-buffer belongs
to, thus it effectively has to guarantee the message boundaries by the
application that is writing into its send-buffer.

I do not think that this is the right approach. If we want to tunnel
multiple TCP streams on top of a single MPTCP-connection, the demultiplexing
should either be backed into the payload (aka, HTTP/2-style), or be part of
MPTCP's DSS-mapping (as the DSS mapping guarantees the boundaries of its
mapping). The former is easy to achieve, while the latter could be done by
adding a "stream-identifier" into the DSS-option.

The advantage of this is that the transport (MPTCP in this case) is free to
choose to schedule traffic in the most efficient way, without having to take
into account message-boundaries and be limited by the constraint that this
imposes.

Christoph

---

From: <[email-masked]>
Date: Tue, 17 Nov 2015 08:55:10 +0000

Hi Christoph,

Please see inline. 

Cheers,
Med

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : mardi 17 novembre 2015 09:17
> À : Henderickx, Wim (Wim)
> Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked]; Denis Behaghel
> ([email-masked]) ([email-masked])
> > - The proposal terminates the sequence numbers and provides a true proxy
> and hence rewrites the sequence numbers at the proxy points.
> 

[Med] No, sorry if this was not clear in the draft but we are not proposing that way for transforming TCP connections into MPTCP connections. Typically, there will be as many MPTCP connections as TCP connections that are "elected" to be distributed among multiple paths. 

> > On 15/11/15 18:23, "multipathtcp on behalf of Christoph Paasch"
> <[email-masked] on behalf of [email-masked]> wrote:
> >
> > >Hello Mohamed,
> > >
> > >
> > >> This is an update to a proposal that intends to avoid requiring an
> extra encapsulating scheme between a CPE and an MPTCP Concentrator located
> in the provider's network.
> > >>
> > >> The main motivation is to ease integrating an MPTCP Concentrator into
> an operational network without requiring updating intermediate service
> functions to support another yet encapsulation scheme.
> > >>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 17 Nov 2015 13:37:06 +0000

Christoph, as already clarified by med the idea is not to bundle multiple tcp stream in a single MP-TCP connection.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 17 Nov 2015 10:49:16 -0800

Hello Med,

> [Med] No, sorry if this was not clear in the draft but we are not proposing that way for transforming TCP connections into MPTCP connections. Typically, there will be as many MPTCP connections as T…

so, in this case the MPTCP Plain Mode option would be set on which segment?
Why not simply doing a SOCKS-proxy?

I don't think there is a need for a new MPTCP subtype here.

Christoph

---

From: <[email-masked]>
Date: Wed, 18 Nov 2015 06:54:20 +0000

Hi Christoph, 

Please see inline. 

Cheers,
Med

> Envoyé : mardi 17 novembre 2015 19:49
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Henderickx, Wim (Wim); [email-masked]; Denis Behaghel
> > [Med] No, sorry if this was not clear in the draft but we are not
> proposing that way for transforming TCP connections into MPTCP
> connections. Typically, there will be as many MPTCP connections as TCP
> connections that are "elected" to be distributed among multiple paths.
> 

[Med] SOCKS and other encapsulation modes cane be used, indeed. But the integration of an encapsulation-based solution may not be as that "simple" as you seem to suggest in your answer. Please keep in mind there are advanced service functions that are enabled in the network side and if you want to reuse those functions for the aggregated traffic, you may end up requiring to update those intermediate service functions. So, integration tasks may not be that simple. The same observation applies for updating CPE software platforms. 

We touched about this point briefly in the document:

   The use of a plain transport mode does not require the upgrade of any
   intermediate function (security, TCP optimizer, etc.) that may be
   located on-path.  Thus, the introduction of MPTCP concentrators in
   operational networks to operate plain mode does not add any extra
   complexity as far as the operation of possible intermediate functions
   is concerned.

The situation is not black or white. Some operators will be happy with an encapsulation mode (SOCKS, GRE, MIP) while others may prefer the native plain transport mode (this proposal). 

> I don't think there is a need for a new MPTCP subtype here.

[Med] Fully agree. We don't need an option if SOCKS is used. 

> > > be sent on the same MPTCP-connection. Thus, each of those segments
> will
> > > have
> > > should either be backed into the payload (aka, HTTP/2-style), or be
> part
> > > of
> > > The advantage of this is that the transport (MPTCP in this case) is
> free
> > > to
> > > choose to schedule traffic in the most efficient way, without having
> to
> > > take
> > > > >Am I right that the draft is proposing a scheme where the Proxies
> (CPE
> > > and
> > > > >Further, it seems to me that the assumption is that MPTCP
> guarantees
> > > the
> > > > >basically, this would be multistreaming (e.g., HTTP/2-style) on top
> of
> > > a
> > > > >> > De : I-D-Announce [mailto:[email-masked]] De la
> part
> > > de
> > > > >> > [email-masked]
> > > > >> >    multiple networks (e.g., DSL, LTE, WLAN) to optimize the
> usage
> > > of its
> > > > >> >    network attachments.  Because of the lack of MPTCP support
> at
> > > the
> > > > >> >    model that relies upon the activation of a dedicated
> function
> > > called
> > > > >> > https://www.ietf.org/rfcdiff?url2=draft-boucadair-mptcp-plain-
> mode-
> > > 03
> > > > >> >
> > > > >> >

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 23 Nov 2015 08:48:45 +0100

Hello Med,

> The situation is not black or white. Some operators will be happy with an encapsulation mode (SOCKS, GRE, MIP) while others may prefer the native plain transport mode (this proposal). 

I think, the document would benefit of giving a more precise example of how
the Plain Mode option will be used. E.g., on which segment should the plain
mode option be placed (from what I see, it only is really needed on
SYN-segments). The document in its current form does not really help in
understanding this - Figure 3 seems to treat MPTCP more like a datagram
service than a connected byte-stream service. I think much of the confusion
comes from there.
Maybe you can give an example on how Plain Mode will be used (taking into
account the 3-way handshake of MPTCP and the available TCP option-space)?

Further, more information on what exactly would go wrong with alternative
solutions of providing the IP-addresses in the payload. Especially, because
TCP optimizers, intrusion detection systems,... anyways will have issues when
faced with an MPTCP-flow. Thus, I'm not sure in what way a SOCKS-like
approach (or which ever way of putting the IP-address in the payload) will be
an additional issue as MPTCP is already a "problem" for those devices.

Cheers,
Christoph