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

[<[e-mail]>]

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

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

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

phil


-----Original Message-----
From: Olivier Bonaventure [mailto:[e-mail]] 
Sent: 27 July 2016 09:43
To: Eardley,PL,Philip,TUB8 R <[e-mail]>; [e-mail]
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