Subject: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

From: <[email-masked]>
Date: Fri, 20 May 2016 05:46:51 +0000

Dear all, 

An updated version of the specification is available online: https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/?include_text=1. This version takes into account comments that were received during the IETF meeting and other bilateral meetings.

The authors do think that this effort is within the scope of this WG, especially this part of the charter: 

"Finally, the working group will explore whether an MPTCP-aware
middlebox would be useful, where at least one end host is MPTCP-enabled.
For example, potentially helping MPTCP's incremental deployment by
allowing only one end host to be MPTCP-enabled and the middlebox acts as
an MPTCP proxy for the other end host, which runs TCP; and potentially
helping some mobility scenarios, where the middlebox acts as an anchor
between two MPTCP-enabled hosts. The working group will detail what real
problems an MPTCP-enabled middlebox might solve, how it would impact the
Multipath TCP architecture (RFC6182), what proxy approach might be
justified as compared against alternative solutions to the problems, and
the likely feasibility of solving the technical and security issues."

We would like to formally ask the WG to consider adoption of this draft.

Comments, suggestions, and questions are more than welcome.

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : jeudi 19 mai 2016 17:45
> À : [email-masked]
> Objet : I-D Action: draft-boucadair-mptcp-plain-mode-07.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
>                           Wim Henderickx
>                           Robert Skog
>                           Olivier Bonaventure
>                           Suresh Vinapamula
>                           SungHoon Seo
> 	Filename        : draft-boucadair-mptcp-plain-mode-07.txt
> 	Pages           : 31
> 	Date            : 2016-05-19
> 
> 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 the
>    encapsulation of packets and out-of-band signaling between the CPE
>    and the MPTCP concentrator.  Also, this document specifies how UDP
>    traffic, in particular, can be distributed among available paths by
>    leveraging MPTCP capabilities.
> 
> 
> 
> 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-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-boucadair-mptcp-plain-mode-07
> 
> 
> 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: Yoshifumi Nishida <[email-masked]>
Date: Wed, 25 May 2016 00:27:14 -0700

Hi Med,

I might want to see more feedback before the adoption call.
I've read the draft, but I think I still have some unclear points in the
draft.

I particularly would like to understand the following points as starting
point. Please let me know if I miss something.

1: This method requires CPEs to convert UDP or TCP into MPTCP and requires
Concentrators to convert back MPTCP into UDP or TCP. This could be rather
complex process than other approach such as GRE. So, what's the benefits to
utilize MPTCP here? I think the draft should describe some useful scenarios
to use MPTCP.

2: Including data in SYN is allowed in RFC793, but I'm not very sure how
many implementations actually accept it. I think the draft should discuss
this point. Also, what will happen if PM option is included in the payload,
but it is removed by the middleboxes?

Thanks,
--
Yoshi

On Thu, May 19, 2016 at 10:46 PM, <[email-masked]> wrote:

> Dear all,
>
> An updated version of the specification is available online:
> https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/?include_text=1.
> This version takes into account comments that were received during the IETF
> meeting and other bilateral meetings.
>
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 25 May 2016 09:50:47 +0200

Yoshifumi,
> 1: This method requires CPEs to convert UDP or TCP into MPTCP and
> requires Concentrators to convert back MPTCP into UDP or TCP. This could
> be rather complex process than other approach such as GRE. So, what's
> the benefits to utilize MPTCP here? I think the draft should describe
> some useful scenarios to use MPTCP.

There is already operational experience with this type of solution and 
it turns out that using MPTCP to support TCP traffic in hybrid access 
networks is a much better approach than using a tunneling technique like 
GRE. In an hybrid access network such as DSL+LTE, there are two types of 
problems that need to be tackled :

1. How to hide the different addresses used on the DSL and LTE networks
2. How to achieve efficient load balancing over networks having 
different characteristics (delay, bandwidth, packet losses) that change 
dynamically

GRE solves the first problem in a clean manner. However, it causes two 
issues when you consider the second problem :

a. Since paths have different delays, doing per packet load balancing 
creates massive reording that results in bad TCP performance
b. Since the two underlying paths are hidden by encapsulation, TCP's 
congestion control scheme cannot probe the different paths and adjust 
ths congestion window correctl. This results in bad TCP performance as well.

An MPTCP-based solution solves these problems in a clean manner since 
MPTCP sees the different paths and can use them efficiently.

You can find some additional information in the Tessares whitepaper 
published last year

http://www.tessares.net/white-papers/

There is already operational experience with this type of MPTCP-based 
solutions and if you think that this would be useful, we could organise 
a presentation at the next IETF meeting on this experience

> many implementations actually accept it.

Well, the deployment of TFO shows that this is possible.

> I think the draft should
> discuss this point. Also, what will happen if PM option is included in
> the payload, but it is removed by the middleboxes?

The assumption is that this solution will be deployed in controlled 
environments and only used between the CPE and the Concentrator. Since 
the operator controls the two networks that are bound together, he can 
verify that there are no middleboxes that drop the PM option.

Olivier

---

From: Rao Shoaib <[email-masked]>
Date: Wed, 25 May 2016 10:51:36 -0700

> verify that there are no middleboxes that drop the PM option.
I am extremely interested in encapsulating UDP in MPTCP but this 
solution is very specific and hence why should it even be standardized ?
The proposed solution does not deal with segmentation and message 
boundaries at all.

We have developed a similar solution in which we pass the original 
IP/UDP header to the MPTCP receiver[1]. The Reciever waits for the 
complete length of the message to be received and recreates the complete 
IP/UDP message before passing it up to IP/UDP for processing. MPTCP 
guarantees  in order delivery so a large message can be distributed over 
multiple connections and reconstructed on the receiver without having to 
worry about duplicate segments.

Also the concentrator stuff is deployment specific and should added as 
an application header.

What needed is a standard way (new option) to signal the other end that 
the current message needs special handling and that's it. How such a 
message is handled can be implementation specific.

Rao.

[1] We have not looked at all the implication of doing this but for our 
use case it is fine. Comment welcome.

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 25 May 2016 21:07:08 +0200

Rao,
> solution is very specific and hence why should it even be standardized ?

There is a clear demand from operators for a solution to this problem in 
hybrid access networks.

> The proposed solution does not deal with segmentation and message

This is covered with the length field. Basically, UDP is transported as 
follows :

client --- cpe --------- concentrator ----- server

client sends UDP <src,dest,sp,dp,len,payload>

CPE places data inside MPTCP segment containing len,payload

Concentrator uses len to extract UDP payload from bytestream and then 
reconstructs the entire UDP segment that can be sent to the server

The assumption here is that there is a one-to-one mapping between a UDP 
flow and one MPTCP connection.

> worry about duplicate segments.

This is similar to the approach proposed in the PM draft, except that in 
the PM draft the information about the UDP flow is sent in the SYN for 
the entire MPTCP connection and not attached to each data as when you 
place the entire IP packet in the bytestream
> Also the concentrator stuff is deployment specific and should added as

What do you mean by concentrator stuff ?

> message is handled can be implementation specific.

In hybrid access networks, MPTCP_based bonding for UDP is mainly useful 
for large flows. In this case, creating an MPTCP connection per flow 
implies that you do not need to reproduce the IP and UDP headers in the 
MPTCP connection

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 25 May 2016 23:31:26 -0700

Hi Olivier,

On Wed, May 25, 2016 at 12:50 AM, Olivier Bonaventure <
[email-masked]> wrote:

> There is already operational experience with this type of solution and it
> turns out that using MPTCP to support TCP traffic in hybrid access networks
> is a much better approach than using a tunneling technique like GRE. In an
> hybrid access network such as DSL+LTE, there are two types of problems that
> need to be tackled :
>
> 2. How to achieve efficient load balancing over networks having different
> characteristics (delay, bandwidth, packet losses) that change dynamically
>
> congestion control scheme cannot probe the different paths and adjust ths
> congestion window correctl. This results in bad TCP performance as well.
>
> solutions and if you think that this would be useful, we could organise a
> presentation at the next IETF meeting on this experience

I think I understand general idea.
But, as far as I read the draft, I got an impression that a UDP or a TCP
flow will be mapped to a single subflow of a mptcp session.
There is no description about using multiple subflows for a single TCP/UDP
flow, or updating subflow mappings in the middle of a session.
I think the draft should mention these cases.

> environments and only used between the CPE and the Concentrator. Since the
> operator controls the two networks that are bound together, he can verify
> that there are no middleboxes that drop the PM option.

Hmm. then, I think these presumptions should be listed in the draft.
But, one concern is the proposal will be too specific to standardize if
there're too much presumptions...

Thanks,
--
Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 26 May 2016 17:35:54 +0200

Yoshifumi,

>
>     There is already operational experience with this type of
>     MPTCP-based solutions and if you think that this would be useful, we
>     could organise a presentation at the next IETF meeting on this
>     experience
>
>

No, since the PM option is carried in the SYN of the initial subflow, a 
TCP flow will be mapped onto an MPTCP connection (and thus will be able 
to use any of its subflows)

> There is no description about using multiple subflows for a single
> TCP/UDP flow, or updating subflow mappings in the middle of a session.

Since the mapping is between a TCP connection (UDP flow) and an MPTCP 
connection, it applies for all the subflows of the MPTCP connection 
automatically. I'm not in favor of changing the mapping during the 
lifetime of an MPTCP connection, it leads to implementation complexity 
that are not worth the effort given that we can establish another MPTCP 
connection bound to another flow.

>     environments and only used between the CPE and the Concentrator.
>     Since the operator controls the two networks that are bound
>     together, he can verify that there are no middleboxes that drop the
>     PM option.
>
>

We can add a section on middlebox interference and discuss how the 
proposal would work when there is a middlebox even if the most likely 
deployment is an environment without middleboxes that interfere with 
TCP. Having NAT on any of the paths does not create any problem. The 
problematic middleboxes are, as always with MPTCP, those that :
- remove some TCP options
- remove data from the SYN payload

Olivier

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 27 May 2016 00:30:28 -0700

Hi Olivier,

On Thu, May 26, 2016 at 8:35 AM, Olivier Bonaventure <
[email-masked]> wrote:

> TCP flow will be mapped onto an MPTCP connection (and thus will be able to
> use any of its subflows)

> automatically. I'm not in favor of changing the mapping during the lifetime
> of an MPTCP connection, it leads to implementation complexity that are not
> worth the effort given that we can establish another MPTCP connection bound
> to another flow.
>

I see. Sorry. I might be confused by the name of Concentrator..

Then, my another question is if we can do the same thing with application
level.
I am wondering if we can write an application gateway for CPE and
Concentrator to send mapping information just like PM option, (and do some
segmentation tasks as well) so that we can mitigate middlebox interventions.

        2: Including data in SYN is allowed in RFC793, but I'm not very
>>         sure how
> deployment is an environment without middleboxes that interfere with TCP.
> Having NAT on any of the paths does not create any problem. The problematic
> middleboxes are, as always with MPTCP, those that :

Sounds good to me.
Thanks,
--
Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 27 May 2016 09:38:07 +0200

Yoshifumi,

>
>
>     Since the mapping is between a TCP connection (UDP flow) and an
>     MPTCP connection, it applies for all the subflows of the MPTCP
>     connection automatically. I'm not in favor of changing the mapping
>     during the lifetime of an MPTCP connection, it leads to
>     implementation complexity that are not worth the effort given that
>     we can establish another MPTCP connection bound to another flow.
>
>
> Then, my another question is if we can do the same thing with
> application level.
> Concentrator to send mapping information just like PM option, (and do
> some segmentation tasks as well) so that we can mitigate middlebox
> interventions.

The closest solution in the application level is SOCKS. This is what KT 
is doing in Korea and what OVH is deploying for their OverTheBox 
solution. Both do this on top of MPTCP.

Olivier

--

---

From: <[email-masked]>
Date: Fri, 27 May 2016 07:50:53 +0000

Hi,

You probably already mention it, but another way is to run MPTCP on top of IP tunnels between CPE and concentrator (I'm not advocating for tunnels, just pointing alternative :-)). 

Pierrick

> De : multipathtcp [mailto:[email-masked]] De la part de Olivier
> Bonaventure
> Envoyé : vendredi 27 mai 2016 09:38
> À : Yoshifumi Nishida
> Cc : MultiPath WG; [email-masked]
> Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
> 
> Yoshifumi,
> 
> >
> >
> The closest solution in the application level is SOCKS. This is what KT is doing in
> Korea and what OVH is deploying for their OverTheBox solution. Both do this on
> top of MPTCP.
> 
> 
> Olivier
> 
> --
> 
> This email and any files transmitted with it are confidential and intended solely for
> the use of the individual or entity to whom they are addressed.
> individual named. If you are not the named addressee you should not disseminate,
> distribute or copy this e-mail. Please notify the sender immediately by e-mail if you
> have received this e-mail by mistake and delete this e-mail from your system. If
> you are not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this information is
> strictly prohibited.
> 

_________________________________________________________________________________________________________________________

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: Yoshifumi Nishida <[email-masked]>
Date: Fri, 27 May 2016 17:08:58 -0700

Hi Olivier,

On Fri, May 27, 2016 at 12:38 AM, Olivier Bonaventure <
[email-masked]> wrote:

> The closest solution in the application level is SOCKS. This is what KT is
> doing in Korea and what OVH is deploying for their OverTheBox solution.
> Both do this on top of MPTCP.

I might want to understand pros and cons for the proposal and others.
It would be good to have this sort of discussions in the draft.

Thanks,
--
Yoshi

---

From: Rao Shoaib <[email-masked]>
Date: Sat, 28 May 2016 01:55:41 -0700

On 05/25/2016 12:07 PM, Olivier Bonaventure wrote:
> There is a clear demand from operators for a solution to this problem 
> in hybrid access networks.

OK but this solution is very specific to the mobile network. We would 
prefer a generic encapsulation solution which has no address mapping. 
Maybe the address mapping part should be made optional based on a flag ?

> This is covered with the length field. Basically, UDP is transported 
> as follows :
Yes it does, sorry I missed that.
>
> The assumption here is that there is a one-to-one mapping between a 
> UDP flow and one MPTCP connection.
I am not sure that is a good thing, we would prefer that it be used to 
send any protocol packet destined for the host.
Not including encapsulated protocol's header works for UDP but wont for 
other protocols.

> What do you mean by concentrator stuff ?
Address mapping stuff -- Use of D bit.
> In hybrid access networks, MPTCP_based bonding for UDP is mainly 
> useful for large flows. In this case, creating an MPTCP connection per 
> flow implies that you do not need to reproduce the IP and UDP headers 
> in the MPTCP connection
>
For our use case (Host Environment) preserving ports and reducing number 
of connections is more important. Including protocol message header 
allows use of the same connection for encapsulating any protocol and any 
port. Also note that size of UDP header is only 8 bytes and we can omit 
checksum and reduce it to 6 bytes which is a very small fraction for 
even a 1K message size.

After re-reading the draft I think the proposal for encapsulation is 
pretty good, only minor details need to be cleared up.

Shoaib

---

From: <[email-masked]>
Date: Mon, 30 May 2016 08:48:51 +0000

Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : jeudi 26 mai 2016 08:31
À : Olivier Bonaventure
Cc : Yoshifumi Nishida; BOUCADAIR Mohamed IMT/OLN; MultiPath WG; [email-masked]
Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

Hi Olivier,

On Wed, May 25, 2016 at 12:50 AM, Olivier Bonaventure <[email-masked]<mailto:[email-masked]>> wrote:
Yoshifumi,

There is already operational experience with this type of solution and it turns out that using MPTCP to support TCP traffic in hybrid access networks is a much better approach than using a tunneling technique like GRE. In an hybrid access network such as DSL+LTE, there are two types of problems that need to be tackled :

1. How to hide the different addresses used on the DSL and LTE networks
2. How to achieve efficient load balancing over networks having different characteristics (delay, bandwidth, packet losses) that change dynamically

GRE solves the first problem in a clean manner. However, it causes two issues when you consider the second problem :

a. Since paths have different delays, doing per packet load balancing creates massive reording that results in bad TCP performance
b. Since the two underlying paths are hidden by encapsulation, TCP's congestion control scheme cannot probe the different paths and adjust ths congestion window correctl. This results in bad TCP performance as well.

An MPTCP-based solution solves these problems in a clean manner since MPTCP sees the different paths and can use them efficiently.

You can find some additional information in the Tessares whitepaper published last year

There is already operational experience with this type of MPTCP-based solutions and if you think that this would be useful, we could organise a presentation at the next IETF meeting on this experience

I think I understand general idea.
But, as far as I read the draft, I got an impression that a UDP or a TCP flow will be mapped to a single subflow of a mptcp session.

[Med] The draft says the following:

Section 5.1:

The data carried in UDP datagrams belonging to

   a given UDP flow are therefore transported in an MPTCP connection.

   The management of MPTCP connections that are triggered by UDP

   datagrams follows the guidelines documented in [RFC6824<https://tools.ietf.org/html/rfc6824>].

Section 5.2:

   A flow example is shown in Figure 5 to illustrate how TCP packets are
   generated to relay UDP datagrams using several subflows.  Non-SYN
   messages that belong to a given subflow do not include any PM option.
   Also, this example shows how subsequent UDP datagrams of this flow
   are transported over the existing subflow or how a new subflow is
   created.  In this example, the SYN segment issued to add a new
   subflow also includes data received in a UDP datagram.

and

   Figure 6 shows an example of UDP datagrams that are transported over

   MPTCP subflows.  Unlike the previous example, additional subflows to

   transport UDP datagrams of the same flow are established in advance

   between the CPE and the concentrator.

Do you think additional text is needed to make it clear? Thank you.

There is no description about using multiple subflows for a single TCP/UDP flow, or updating subflow mappings in the middle of a session.

[Med] Please refer to Figures 5 & 6.

The assumption is that this solution will be deployed in controlled environments and only used between the CPE and the Concentrator. Since the operator controls the two networks that are bound together, he can verify that there are no middleboxes that drop the PM option.

[Med] These assumptions are already called out in the draft, e.g.,

Section 1:

Also, it assumes the various

   network attachments provided to an MPTCP-enabled CPE are managed by

   the same administrative entity.

Section 4.2:

Given

      that this option is designed to be used in a controlled

      environment, this specification recommends to always place the PM

      options inside the payload of a SYN segment.

Do you think additional text is still required?

---

From: <[email-masked]>
Date: Mon, 30 May 2016 08:58:58 +0000

Re-,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : samedi 28 mai 2016 02:09
À : Olivier Bonaventure
Cc : Yoshifumi Nishida; Olivier Bonaventure; BOUCADAIR Mohamed IMT/OLN; MultiPath WG; [email-masked]
Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

Hi Olivier,

On Fri, May 27, 2016 at 12:38 AM, Olivier Bonaventure <[email-masked]<mailto:[email-masked]>> wrote:
Yoshifumi,

The closest solution in the application level is SOCKS. This is what KT is doing in Korea and what OVH is deploying for their OverTheBox solution. Both do this on top of MPTCP.

I might want to understand pros and cons for the proposal

[Med] Below is provided an excerpt from the draft:

   o  No encapsulation required (no tunnels, whatsoever).

   o  No out-of-band signaling for each MPTCP subflow required.

   o  Carries any protocol (incl.  UDP) for the benefit of massive MPTCP

      adoption (Section 5<https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-07#section-5>).

   o  Accommodates various deployment contexts (Section 6<https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-07#section-6>).

Which can be interpreted as follows:

·         No chatty: the solution does not overload the concentrator with out-of-banding signaling messages.

·         No extra delay to establish MPTCP connections.

·         Supports UDP

·         Allows to share the same external IP address among various subscribers (deployments suffering from IPv4 address depletion)

·         Allows to assign a single IP address for connections that belong to the same subscriber (deployments with no pressure on IPv4 address usage)

·         Allows to preserve the source IPv6 address

·         …

The draft acknowledges the overhead for UDP.

and others.

[Med] We already have some text in the draft about the cons of using, e.g., SOCKS:

   Current operational MPTCP deployments by network operators are
   focused on the forwarding of TCP traffic.  In addition, the design of
   such deployments sometimes assumes the use of extra signalling
   provided by SOCKS [RFC1928<https://tools.ietf.org/html/rfc1928>], at the cost of additional management
   complexity and possible service degradation (e.g., up to 8 SOCKS
   messages may need to be exchanged between two MPTCP proxies before an
   MPTCP connection is established, thereby yielding several tens of
   milliseconds of extra delay before the connection is established).
Further, a SOCKS-based solution does not allow to support natively UDP bonding.

Thanks,
--
Yoshi

---

From: <[email-masked]>
Date: Mon, 30 May 2016 09:22:58 +0000

Hi Shoaib, 

Please see inline.

Cheers,
Med

> De : multipathtcp [mailto:[email-masked]] De la part de Rao
> Shoaib
> Envoyé : samedi 28 mai 2016 10:56
> À : [email-masked]; [email-masked]
> OK but this solution is very specific to the mobile network.

[Med] The solution is not specific to the mobile network, but targets all network providers who want to allow their customers to make use of all available network attachments (e.g., fixed, WLAN, cellular, etc.)

 We would
> prefer a generic encapsulation solution which has no address mapping.

[Med] It seems that you want to cover the case of an MPTCP-enabled host communicating an MPTCP-enabled server exchanging any protocol data inside an MPTCP connection? Can you please confirm/infirm?

> Maybe the address mapping part should be made optional based on a flag ?

[Med] The technical details can be worked out once we understand your deployment case.

[snip]
> pretty good, only minor details need to be cleared up.

[Med] Thank you. We are more than open to discuss those details.