Re: [multipathtcp] towards a potential work item on two-ended proxy

On 02/08/16 08:33, "multipathtcp on behalf of mohamed.boucadair@orange.com" <multipathtcp-bounces@ietf.org on behalf of mohamed.boucadair@orange.com> wrote:

>Hi Phil,
>
>Please see inline.
>
>Cheers,
>Med
>
>> -----Message d'origine-----
>> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
>> philip.eardley@bt.com
>> Envoyé : lundi 1 août 2016 17:46
>> À : multipathtcp@ietf.org
>> Objet : Re: [multipathtcp] towards a potential work item on two-ended
>> proxy
>> 
>> Thanks.
>> So, for text for a potential work item, we could say something like "the
>> WG assumes that the HAG is not necessarily on the default routing path
>> between the end hosts".
>
>[Med] Yes, with some modifications to the wording: 
>* Actually, there are many "default" forwarding path*S*; a default forwarding path per network attachment. These default forwarding paths may be completely disjoint. 
>* I suggest to avoid using "HAG" term because it is tied to a specific use case while the proxy work is applicable to a variety of use cases. I prefer much more "MPTCP Concentrator" or "Network-Assisted MPTCP Proxy".  

WH> Indeed Network-assisted MPTCP proxy seems like a good terminology
>
>  This then leaves open whether we solve this
>> problem in the mptcp-based protocol (as per plain mode) or solve it in the
>> underlying layer (eg through a tunnel - transparent mode).
>> Do we assume that the other end of the mptcp segment is on the default
>> routing path?  I suppose this is the case for the CPE example we usually
>> have in mind - but since we want a general protocol, it would be good if
>> this end also need not be on the default end-to-end path.
>
>[Med] Another approach for this one is the charter to be silent about it, i.e., we don't assume nor preclude it.  
WH> agreed, we should have the charter focus on single ended MP-TCP and network assisted MP-TCP proxies e.g.
>     
>
>> 
>> It was also suggested to have a second (informational) document.
>> As a point of reference, our charter currently says (this is about one-
>> ended proxy): << 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.>>
>> So a potential work item may say something like:
>> The working group will detail the use cases /deployment scenarios, the
>> operational considerations and .... [anything else? Interaction with
>> endhost-to-endhost MPTCP?]
>
>[Med] I would add protocol extensions to differentiate native MPTCP connections from proxied ones.
WH> agreed
> 
>
>> 
>> Incidentally, it may be possible to use some of the text from draft-deng-
>> mptcp-mobile-network-proxy ?
>> 
>> I also note that draft-boucadair-mptcp-plain-mode has a very open-ended
>> ipr statement. Do you think it could be made more specific (at some
>> point)?
>
>[Med] FWIW, that IPR does not apply to the current version of the plain-mode draft since a step mentioned in the first claim of that patent deposit is not present in the draft.  
>
>> 
>> phil
>> 
>> 
>> -----Original Message-----
>> From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]
>> Sent: 27 July 2016 09:43
>> To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>;
>> multipathtcp@ietf.org
>> Subject: Re: [multipathtcp] towards a potential work item on two-ended
>> proxy
>> 
>> Phil,
>> 
>> > So far this discussion has made me a bit confused. Let me ask a
>> > specific
>> > question:-
>> >
>> > Why do we need both transparent and plain mode? If these are
>> > addressing different usage scenarios, please explain them (in a
>> > paragraph?)
>> 
>> The two modes address different deployment scenarios.
>> 
>> In the transparent mode, the HAG resides on the path to/from the client.
>> There are many ways in current networks to ensure that the HAG is on the
>> path of the clients that it serves. The transparent mode requires one
>> option to distinguish between end-to-end MPTCP connections (directly
>> established by the client using an MPTCP stack) and proxied connections.
>> During IETF96, the authors of plain-mode and transparent-mode agreed that
>> the transparent-mode draft would use an emply plain mode option to
>> indicate that a connection has been proxied.
>> 
>> In the plain-mode, the HAG does not need to be on the path to/from the
>> client. The plain-mode option is used to signal the original
>> source/destination address of the connection depending on the usage.
>> 
>> 
>> 
>> 
>> Olivier
>> 
>> _______________________________________________
>> 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