Re: [multipathtcp] potential MPTCP proxy charter item

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Alan Ford [mailto:[e-mail]]
> Envoyé : mercredi 9 novembre 2016 09:04
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Mirja Kühlewind; [e-mail];
> [e-mail]
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi Med,
> 
> Thanks for providing some scenarios. Comments inline…
> 
> > On 9 Nov 2016, at 06:41, [e-mail] wrote:
> >
> > Hi Alan,
> >
> > Below some examples to illustrate the problem I'm talking about.
> >
> > (1) Private IPv4 addresses or RFC6598 Shared Address space
> >
> > Let's consider this configuration (reusing the same topology in this
> thread):
> >
> > laptop <-----------+
> >                   | (Public IPv4@)
> > smartphone <----> cpe <----FIXED------> mcp <------> server
> >     +             +
> >  cellular1     cellular2
> >                (Private IPv4)
> >
> > In this example, the multipath CPEs gets a public IPv4 address from the
> fixed network and a private IPv4 address (or an address from RFC6598
> range) from the mobile network (cellular2).
> >
> > Consider the server is MPTCP-capable.
> >
> > The first subflow can be placed using the fixed line. Fine.
> > The MCP will remove itself from the connection because the server is
> MPTCP-capable. Cool!
> > The second subflow that will use cellaulr2 cannot be established because
> of a basic forwarding problem: packets sourced with private IPv4 addresses
> cannot be forwarded over the public Internet.
> 
> Presumably cellular2 goes through a NAT in order to talk to anything in
> the public Internet. So it can be addressed to the server, and work like
> any other MPTCP subflow behind a NAT would work today.

[Med] You are assuming that the same Internet APN will be used for the hybrid access. This is not a valid assumption. Some deployment are considering dedicated APN for this service to avoid additional public IPv4 address are assigned to this service and also to avoid overload the service function at the Gi interface with traffic that will be routed to the backbone of the same provider.

> 
> What am I missing? Why is this any different to today with a MPTCP end
> host with private IP addresses?

[Med] The difference is that there is no NAT in the path before the MCP. The MCP has the role to use the IP address assigned by the fixed line when forwarding the secondary subflow. 

> 
> The smartphone does not have knowledge of cellular2, presumably… So the
> CPE would have to do something funky with the traffic to split it over
> fixed and cellular2

[Med] This is a proxy function (MCP) in the CPE! I didn't focused on that part of the flow because there are other problems there. If the CPE does not embed an MCP, an MPTCP capable host (laptop of smartphone) may not be able to aggregate the resources of multiple access links. Going native will lead to less QoE compared to involving the MCP located in the CPE. 

 - but it could still establish the subflow towards the
> server on cellular2, without any knowledge of the smartphone or the
> network.
> 
> >
> > (2) IPv6-only access network
> >
> > Lets' consider this configuration:
> >
> > laptop <-----------+
> >                   | (Public IPv4@
> > smartphone <----> cpe <----FIXED------> mcp <------> server
> >     +              +                                IPv4-only
> >  cellular1     cellular2
> >                (IPv6-only prefix)
> >
> > In this example, the multipath CPEs gets a public IPv4 address from the
> fixed network and an IPv6 prefix from the mobile network (cellular2).
> >
> > Consider the server is MPTCP-capable, but IPv4-only.
> >
> > The first subflow can be placed using the fixed line. Fine.
> > The MCP will remove itself from the connection because the server is
> MPTCP-capable. Cool!
> > The second subflow that will use cellaulr2 cannot be added because the
> remote server does not support IPv6.
> >
> 
> So in this case, if the MCP was on-path, it could be dual-stack and could
> add its IPv6 address to the subflows.

[Med] Yes. 

> 
> If the MCP knew the connection was being proxied, would this help? Since
> as you’ve already defined, the MCP <—> server path would then be TCP. If
> the MCP stayed on-path, you could do multi path towards the MCP but then
> lose MPTCP capabilities to the server.

[Med] The MCP can do the following:
* It removes itself from the connection, then the connection will be e2e MPTCP... but only one access network will be used at the client side.
* The MCP may decide the stay in the connection to glue two adjacent MPTCP connections. Doing so, we benefit from both MPTCP capabilities at the client and servier side. 

The exact behavior should IMHO be configurable. 

> 
> Or alternatively, the MCP could always stay on-path but only add IPv6
> addresses if it somehow had knowledge that was required based on the
> source or destination address. Does it need to know by a flag? Would there
> actually be any harm by maintaining itself on the path anyway?

[Med] I don't see a harm in doing so (see above), but those who want to have an e2e MPTCP connection may see something bad in that design. I though they wanted to completely remove the MCP from the path when both the client and server are MPTCP-capable. 

 It’s not
> like it’s doing anything other than packet forwarding on the initial
> subflow, and just adds its IPv6 addresses to the initial exchanges in case

[Med] It needs to terminate the MPTCP connections, mange them, etc. This is exactly the MCP job. 

> it would be useful - and if it receives traffic to the relevant
> address/port, it can start forwarding it to the far end too (possibly over
> a second IPv4 subflow). Again, no need or any explicit signalling to make
> this work.

[Med] We are not discussing about any explicit signaling her, Alan. We are discussing the implications on removing the MCP from the path based on SYN/ACK that will carry an MP_CAPABLE option!

> 
> > I can share other examples where problems arise when the proxy is
> blindly removed from the connection based on the presence of MP_CAPABLE in
> SYN/ACK.
> 
> If it would help to clarify, please do! Since I don’t see a problem in
> (1), and whilst I can see a potential problem in (2) above, I am not sure
> how you are resolving it. Any other examples very welcome!

[Med] Happily. You can consider a homenet architecture https://tools.ietf.org/html/rfc7368 where MPTCP-capable hosts may not be aware of the presence of multiple paths (see this simple topology).  The use of a proxy will to deterministically make use of the path diversity.

           +-------+-------+    +-------+-------+          \
           |   Service     |    |   Service     |           \
           |  Provider A   |    |  Provider B   |            | Service
           |    Router     |    |    Router     |            | Provider
           +-------+-------+    +------+--------+            | Network
                   |                   |                     /
                   |     Customer      |                    /
                   |     Internet      |                   /
                   |    Connections    |
                 +-----------+-----------+                 \
                 |                       |                  \
                 |     Customer Edge     |                   \
                 |        Router         |                   /
                 +-----------+-----------+                  /
                             |                             /
                             |                            | End-User
     ---+------------+-------+--------+-------------+---  | Network(s)
        |            |                |             |      \
   +----+-----+ +----+-----+     +----+-----+ +-----+----+  \
   |IP   Host | |IP   Host |     | IP   Host| |IP   Host |  /
   |   H1     | |   H2     |     |    H3    | |   H4     | /
   +----------+ +----------+     +----------+ +----------+

Things may be complicated for the enterprise case: 


           +-------+-------+    +-------+-------+          \
           |   Service     |    |   Service     |           \
           |  Provider A   |    |  Provider B   |            | Service
           |    Router     |    |    Router     |            | Provider
           +-------+-------+    +------+--------+            | Network
                   |                   |                     /
                   |     Customer      |                    /
                   |     Internet      |                   /
                   |    Connections    |
                 +-----------+-----------+                 \
                 |                       |                  \
                 |     Customer Edge     |                   \
                 |        Router         |                   /
                 +-----------+-----------+                  /
          Network A        | |   |      Network B(E)         |
    ----+-------------+----+ |   +---+-------------+------+  |
        |             |      |       |             |      |  |
   +----+-----+ +-----+----+ |  +----+-----+ +-----+----+ |  |
   |IP   Host | |IP   Host | |  |  IP  Host| |IP   Host | |  |
   |    H1    | |    H2    | |  |    H3    | |    H4    | |  |
   +----------+ +----------+ |  +----------+ +----------+ |  |
                             |        |             |     |  |
                      Link F |     ---+------+------+-----+  |
                             |               | Network E(B)  |
                      +------+--------+      |               | End-User
                      |     IP        |      |               | Networks
                      |   Interior    +------+               |
                      |    Router     |                      |
                      +---+-------+-+-+                      |
          Network C       |       |   Network D              |
    ----+-------------+---+       +---+-------------+---     |
        |             |               |             |        |
   +----+-----+ +-----+----+     +----+-----+ +-----+----+   |
   |IP   Host | |IP   Host |     | IP   Host| |IP   Host |   |
   |   H5     | |   H6     |     |    H7    | |    H8    |   /
   +----------+ +----------+     +----------+ +----------+  /

Of course, we can propose solutions without involving an MCP but this will require major changes to how forwarding is achieved, further it make some assumptions about the internal addressing scheme.

> 
> Best regards,
> Alan
> 
> 
>