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

Hi,

In the paired MPTCP proxies mechanism, there is user's TCP session and there is also multipath TCP session. It is a TCP over TCP idea, correct? 
As for TCP over TCP, the following page explains why an internal meltdown effect would take place due to the interaction between two leveled retransmission mechanisms. 
http://sites.inka.de/bigred/devel/tcp-tcp.html
Do we have solid solutions for this issue nowadays?

Thanks,
Mingui

> -----Original Message-----
> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of
> philip.eardley@bt.com
> Sent: Wednesday, June 08, 2016 5:54 PM
> To: sarikaya@ieee.org; multipathtcp@ietf.org
> Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
> 
> I believe you're right that such work would be outside the charter.
> 
> We're hoping (if we get 2 sessions) in Berlin to have some discussion about
> potential re-chartering. In practice we haven't managed to get much work
> focussed specifically on meeting the current charter item on proxy (there was
> some individual drafts a while back) - but there seems to be quite a bit of
> industry work on proxies (beyond charter's single-ended proxy). So potential
> discussion topic
> 
> >From my perspective there seems to be some operator interest in hybrid. See
> for instance the discussions in banana bar-bofs we've had at last couple of ietfs -
> including description of the DT deployment. (note, not all hybrid solutions use
> mptcp)
> 
> Best wishes
> phil
> 
> -----Original Message-----
> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Behcet
> Sarikaya
> Sent: 01 June 2016 19:38
> To: multipathtcp@ietf.org
> Subject: [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.
> 
> 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