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

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".  

  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.       

> 
> 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. 

> 
> 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