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

[<[e-mail]>]

Hi Behcet,

As one of the operators very interested in this, I don’t think it is over blown and the use case you describe might be the first one for a number of operators, but others are following. Fundamentally it is about resource pooling of access networking resources (of whatever technology transporting IP).

We are well-aware of the problems of a MPTCP-based solution (and draft-boucadair tries to solve some of them). However, we are not aware of any better standardized solution for multiple paths with heterogeneous characteristics of available and varying bandwidth, varying delays, and different packet handling characteristics. In case there is better ways of solving that problem let us know. 

The need for the unfortunate proxying/concentrators is a short term solution until MPTCP is more widespread implemented and deployed. 


Kind regards/Viele Grüsse

Marcus

——-
Marcus Brunner
Swisscom









Am 01.06.16, 20:37 schrieb "multipathtcp im Auftrag von Behcet Sarikaya" <[e-mail] im Auftrag von [e-mail]>:

> 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.
>
>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. 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.
>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, it is just tunneling
>the traffic. So there is no charter item that fits to this draft.
>I strongly suggest staying away from making MPTCP a tunneling protocol.
>
>Regards,
>
>Behcet
>
>_______________________________________________
>multipathtcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/multipathtcp