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

[<[e-mail]>]

Hi Behcet, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[e-mail]] De la part de
> Behcet Sarikaya
> Envoyé : mercredi 1 juin 2016 20:38
> À : [e-mail]
> Objet : [multipathtcp] draft-boucadair-mptcp-plain-mode-07
> 
>  Hi all,
> 
> Recent mails in this thread came to my attention because I work on the
> hybrid access network issues and wish to convey my views on some of
> the issues discussed.
> 
> First of all, the claims that there is strong operator interest on
> this is over blown. Hybrid access is based on offloading some CPE
> traffic to 3G/LTE network, I don't think mobile operators are fond of
> such a thing.
> 

[Med] I confirm there is interest from operators. You can check, for example, http://www.netmanias.com/en/?m=view&id=reports&no=8532. 

> Also I strongly concur with Yoshi's point of CPE to convert UDP or TCP
> into MPTCP and requires
> Concentrators to convert back MPTCP into UDP or TCP is a complex
> process. 

[Med] FWIW, UDP/TCP conversion is not new. You can play with a Linux tool like http://linux.die.net/man/1/socat. Also, it is a feature implemented by SBCs (e.g., http://www.sip-dojo.com/why-brekeke-sip-server/tcp-udp-conversion).   

The crux of this is the problems arising from the use of
> MPTCP for tunneling, which is what this draft is advocating.
> 
> Here I recommend Joe Touch's Intarea draft
> https://tools.ietf.org/id/draft-ietf-intarea-tunnels-02.txt
> on IP Tunnels in the Internet Architecture. IETF developed many
> tunneling protocols which are surveyed in this draft but none of them
> are TCP/MPTCP based.

[Med] One of the currently deployed MPTCP schemes relies on SOCKS, which does not require any tunneling at all! The Plain Mode solves many of the issues raised by SOCKS. 

> I also question suitability of this work to the charter. There is this
> charter text:
> 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.
> 
> This draft has a middlebox called Concentrator but it is not trying to
> enable MPTCP hosts to communicate with TCP hosts,

[Med] Hmm, the draft also covers MPTCP-enabled hosts, e.g.,: 

   o  An MPTCP-enabled, multi-interfaced CPE or host that is directly
      ^^^^^^^^^^^^^^^^^                         ^^^^^^^^^^^^^^^^^^^^^^
      connected to one or multiple access networks is allocated
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
      addresses/prefixes via legacy mechanisms (e.g., DHCP) supported by
      the various available network attachments.

or

   This document focuses on the CPE-based model (i.e., the CPE embeds a
   MPTCP proxy that behaves on behalf of terminal devices), but plain
   transport mode can also apply to host-based models.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Both CPE and host-based models are in scope.