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

In-line

On 02/06/16 10:17, "multipathtcp on behalf of Joe Touch" <multipathtcp-bounces@ietf.org on behalf of touch@isi.edu> wrote:

>
>
>On 6/2/2016 7:02 AM, Markus.Brunner3@swisscom.com wrote:
>> 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. 
>
>Why wouldn't an overlay that employs dynamic routing be easier?
>
>It wouldn't incur the delays of using reliable delivery with messages
>that don't preserve IP datagram boundaries and it's already supported
>with existing equipment. Further, it could use much more sophisticated
>path monitoring and choice.
>
>I.e., this is exactly what you'd get if you deploy something akin to
>LISP and basically ignore the label distribution problem (which you
>really don't have).
>
>Joe
WH> it doesn’t solve the use case where packets of a flow have to be split over multiple links and reordering + congestion control is required for these flows. If these requirements were not there you’re right that routing can be used.
>
>
>>
>> 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" <multipathtcp-bounces@ietf.org im Auftrag von sarikaya2012@gmail.com>:
>>
>>> 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
>>> multipathtcp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>_______________________________________________
>multipathtcp mailing list
>multipathtcp@ietf.org
>https://www.ietf.org/mailman/listinfo/multipathtcp