Re: [multipathtcp] potential MPTCP proxy charter item

[Alan Ford <[e-mail]>]

Hi Med,

Inline...


>> -----Message d'origine-----
>> De : multipathtcp [mailto:[e-mail]] De la part de
>> Christoph Paasch
>> Envoyé : lundi 7 novembre 2016 17:24
>> À : Olivier Bonaventure
>> Cc : [e-mail]
>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
>> 
>> Hello,
>> 
>> On 07/11/16 - 08:56:07, Olivier Bonaventure wrote:
>>> 
>>> The problem is more complex than this because the connecitivity on the
>> CPE
>>> is not the same as connectivity on the endhost. Consider the following
>>> scenario :
>>> 
>>> laptop <-----------+
>>>                   |
>>> smartphone <----> cpe <-------> mcp <------> server
>>>    +              +
>>> cellular1     cellular2
>>> 
>>> The MCP resides on the DSL path between the CPE and the server.
>>> 
>>> The laptop is connected over WiFi and the CPE converts the TCP
>> connection
>>> onto an MPTCP connection to bond DSL and cellular2.
>>> 
>>> The smartphone is connected over wifi to the cpe which is connected over
>> DSL
>>> to the server via the MCP. When the smartphone uses MPTCP, it wants to
>> use
>>> WiFi and cellular1. It could start over WiFi and then moves and want to
>>> switch to cellular1. The MCP has no idea of cellular1 and cannot
>> terminate
>>> an MPTCP connection created by the smartphone.
>> 
>> I'm not sure, why Alan's suggestion to only proxy based on the SYN/ACK
>> doesn't work here.
>> 
>> There are two scenarios here:
>> 
>> 1. server supports MPTCP: Then, everything is fine. CPE and MCP will stay
>>   out of the business and native MPTCP will be done from smartphone to
>>   server.
> 
> [Med] Existing network-assisted MPCP documents already cover this case. Native MPTCP connections will be established by that smartphone without even being intercepted by an MCP. The MCP has not to inspect the SYN/ACK. The problem is more on the laptop side. 

But inspecting the SYN/ACK would allow the MCP to provide Multipath capabilities when the smartphone is MPTCP capable but the server is not. However, that’s a side-effect...

> 
> Let's consider a TCP connection from that laptop. This TCP connections is relayed to MPTCP via the fixed line, and the intercepted by the MCP. If the MCP withdraws itself because it receives an MP_CAPBLE in the SYN/ACK from the ultimate server, the secondary subflow (via cellular2) may not be established because only private IPv4 addresses may be assigned in that leg (e.g., dedicated APN is used). In this case, the withdrawal of the MCP will lead to more failures. 

Sorry I don’t follow that scenario. If cellular2 tried to join, it would talk direct to the far end, and not to the MCP,  if the MCP was not in the path… Right? So what’s the problem?

If the MCP remained in the path, then what would be different for this scenario to make it work?

> 
> This is exactly why I'm advocating for a configurable parameter. 
> 
>> 2. server does not support MPTCP: In that case the MCP will announce its
>>   public IP to the smartphone and this one can then create an MPTCP-
>> subflow
>>   via cellular1.

These two scenarios make sense to me (at the moment), I am confused as to why this would not work?

Regards,
Alan