Re: [multipathtcp] Consensus call on potential MPTCP proxy work

["Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <[e-mail]>]

Hi Med,

Thanks for the response.

> On Apr 20, 2017, at 1:32 AM, [e-mail] wrote:
> 
> What I meant by "native MPTCP connections" is that the CPE won't proxy a SYN that contains MP_CPABALE received from an MPTCP-capable client. That is, the CPE won't modify the destination IP address to the one of the network-located proxy. That SYN+MP_CPABALE will be received and handled directly by the remote server.   

I thought this was the case. 

Part of this proposal that I do not support is that network assistance requires connection hijacking. There is no plan to have the network assist 2 MPTCP hosts that want end-to-end connectivity.

Here is a network diagram I drew up:
https://docs.google.com/drawings/d/1VQyZgcg3aHoB0VVeCBYlc6cTVD6a0ZrwXFtw6EvNw6s/edit?usp=sharing

What I would like to see is a solution that supports the following:

The cell phone and server have on ongoing connection over Path 3. Now this phone wants to add a subflow using the WiFi interface. How could the network assist this connection to enable the use of both Path 1 and Path 2 rather than (Path 1 xor Path 2) in an end-to-end manner? In other words, how could the cell phone discover it should start a second subflow over WiFi?

Maybe there is an MPTCP-based solution. Maybe there is an out of band solution. I have not fleshed anything out at the moment, but I think network assistance in a more general sense is a useful topic to dwell on.


Thanks,
Matt