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

[<[e-mail]>]

Matt, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
> [mailto:[e-mail]]
> Envoyé : jeudi 20 avril 2017 16:33
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [e-mail]; [e-mail]
> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
> 
> 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/1VQyZgcg3aHoB0VVeCBYlc6cTVD6a0ZrwXFtw6E
> vNw6s/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?

[Med] A proposal we have to make use of path diversity corresponds to Case 6 of slide 16 (https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf). To do so, the CPE needs to be provided with a policy so that this connection is eligible to network-assisted MPTCP. These policies are discussed in https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2.1. 

In addition to that policy, we have a configurable parameter to instruct the proxy to be removed from the path (see Section 5.6.1 of that draft)

==
   Whether an MCP must be maintained in the processing of an MPTCP
   connection that involve MPTCP-capable clients and server is a
   configurable parameter.
==

Note that blindly withdrawing a proxy when both the client and server are MPTCP-capable may lead to some issues: 

==
   1.  The use of private IPv4 addresses in some access networks.
       Typically, additional subflows can not be added to the MPTCP
       connection without the help of an MCP.

   2.  The assignment of IPv6 prefix only by some networks.  If the
       server is IPv4-only, subflows that are placed over IPv6 cannot be
       added to an MPTCP connection towards that server.

   3.  Some of the access networks are subject to subscription with
       volume quota.
==

 In other words,
> how could the cell phone discover it should start a second subflow over
> WiFi?

[Med] This is a general MPTCP problem: triggers to add new subflows to an MPTCP connection. We don't require a modification to that behavior. If appropriate policies are configured on the CPE (LAN), subflows will be created over existing multiple paths. Doing so allows for rich path diversity.   

> 
> Maybe there is an MPTCP-based solution.

[Med] Another proposal would be to use a means to create state for incoming connections for each CPE WAN interfaces (PCP (RFC6887)) + discover the external IP addresses allocated to the CPE, and then advertise these addresses/ports to the remote MPTCP endpoint. The remote MPTCP will create subflow using these addresses. The extension in https://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-02 can be used to encourage the remote endpoint to create incoming subflows.


 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.

[Med] I agree. 

> 
> 
> Thanks,
> Matt