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

On 31/07/16 23:02, "multipathtcp on behalf of Rao Shoaib" <multipathtcp-bounces@ietf.org on behalf of rao.shoaib@oracle.com> wrote:

>
>
>On 07/27/2016 01:43 AM, Olivier Bonaventure wrote:
>> 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.
>Why is it necessary to know that the connection has been proxied ?

WH> Otherwise the concentrator will perform the proxy function although the destination is the application server.
So assume an E2E MPTCP flow. The UE initiates it and the element with the network assisted MPTCP proxy (Concentrator) receives it. The concentrator should not proxy this flow. It should only act upon MPTCP flow that should be proxied in network assisted mode. This is the reason we need an indication about this
>>
>> 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.
>Since we seem to be only considering TCP, will the protocol field be 
>removed from the draft ?

WH> this is to be discussed 
>
>Shoaib
>>
>>
>>
>>
>> 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