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

[<[e-mail]>]

Hi Yoshi,

Yes, SOCKS5 supports UDP … but for signgle paths. Extensions are required so that packets from a given host/CPE sent over multiple paths (i.e., with distinct source IP addresses) are “glued” so that the same external IP address/port is used by the SOCKS server. Also, the SOCKS out-of-banding signaling will induce an extra delay for handling UDP flows. This is suboptimal.

Thank you.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[e-mail]]
Envoyé : vendredi 3 juin 2016 05:02
À : BOUCADAIR Mohamed IMT/OLN
Cc : Yoshifumi Nishida; Olivier Bonaventure; Olivier Bonaventure; MultiPath WG; [e-mail]
Objet : Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

Hi Med,

My question was if we can do the same or similar thing at the application level, like create a mapping between a TCP/UDP socket and a MPTCP socket. It doesn't have to be socks. Also, as socks5 supports UDP, the description might not be very precise.

Thanks,
--
Yoshi

On Mon, May 30, 2016 at 1:58 AM, <[e-mail]<mailto:[e-mail]>> wrote:
Re-,

Please see inline.

Cheers,
Med

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

Hi Olivier,

On Fri, May 27, 2016 at 12:38 AM, Olivier Bonaventure <[e-mail]<mailto:[e-mail]>> wrote:
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.


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.

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.
It would be good to have this sort of discussions in the draft.

[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