[multipathtcp] (re-)charter discussion (RE: draft-boucadair-mptcp-plain-mode-07)

Hi Phil, 

A proxy is always single-ended: that is, it transforms an MPTCP connection into an TCP connection, and vice versa. Does it really matter if the MPTCP peer is a CPE or  a host directly connected to an operator network?

IMHO, the key word in the charter is "helping MPTCP's incremental deployment" which is a goal of the plain mode specification.

I do agree that the UDP part of the discussion is not covered by the charter. 

Is there any chance to initiate the re-chartering discussion prior to the meeting?

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> philip.eardley@bt.com
> Envoyé : mercredi 8 juin 2016 11:54
> À : sarikaya@ieee.org; multipathtcp@ietf.org
> Objet : 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