Subject: [multipathtcp] q about on-path proxy

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 22 Mar 2017 02:03:53 -0700

Hello,

I am trying to understand on-path proxy scenarios.
(BTW, I'm referring draft-nam-mptcp-deployment-considerations-01
and draft-boucadair-mptcp-plain-mode-10)

In case of on-path proxy (implicit mode),the dest of the primary subflow
will be the receiver. It's not very clear to me how MCP intercepts the
packets in this subflow.
The MCP splits the connection between two nodes and send forged packets to
the sender?

Also, in the two proxy scenario, does the downstream MCP have to be
on-path?

Thanks,
--
Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 22 Mar 2017 10:35:07 +0100

Yoshifumi,
> will be the receiver. It's not very clear to me how MCP intercepts the

There are several techniques that can be deployed by operators to ensure 
that the transparent MCP is on-path for the initial subflow. All these 
techniques operate in the network layer or below and are thus 
transparent for TCP. Let me give an example based on source routing that 
does not match an actual deployment but would illustrate the main 
principle. With source routing, one can add inside the IP header a loose 
hop.

        +------- R4 ---- R5 --------+
C --- uMCP ---- R1 ---- R2 ------ dMCP ---- R6 --- R7 --- S

Consider a TCP connection created by client C towards server S. The uMCP 
is the first hop router for C. It intercepts the connection and 
transparently terminates it, acting as S. It then initiates a Multipath 
TCP connection towards S, acting as C. The packets for this connection 
are sent as IP packet that contain the IP address of the downstream MCP 
as a loose source routing hop. The dMCP removes the source routing 
option, transparently terminates the Multipath TCP connection and then 
initiates a connection towards S, acting as C.

Three connections exist to transfer data from C et S and vice-versa.

C<->uMCP  (source address C, destination address S)
uMCP<->dMCP (source address C, destination address S, using source 
routing to ensure that all downstream packets pass through dMCP, for 
upstream packets, source routing is usually not required because there 
is only one path to the uMCP that advertises C to R1 only )
dMCP<-> S (source address C, destination address S)

For the Multipath TCP connection between uMCP and dMCP, the second 
subflow is used without relying on source routing. The uMCP and the dMCP 
have addresses on the R4/R5 network and use the ADD_ADDR option to 
advertise those addresses and create the required subflows.

> The MCP splits the connection between two nodes and send forged packets
> to the sender?

Yes

> Also, in the two proxy scenario, does the downstream MCP have to be

If the downstream MCP is on path, then it does not have to include any 
NAT function which is beneficial from an operational viewpoint.

Olivier

---

From: <[email-masked]>
Date: Wed, 22 Mar 2017 09:40:31 +0000

Hi Yoshi,

Please see inline.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de Yoshifumi Nishida
Envoyé : mercredi 22 mars 2017 10:04
À : multipathtcp
Objet : [multipathtcp] q about on-path proxy

Hello,

I am trying to understand on-path proxy scenarios.
(BTW, I'm referring draft-nam-mptcp-deployment-considerations-01 and draft-boucadair-mptcp-plain-mode-10)

In case of on-path proxy (implicit mode),the dest of the primary subflow will be the receiver. It's not very clear to me how MCP intercepts the packets in this subflow.
[Med] In this mode, the MCP is placed on a default forwarding path. It will inspect TCP traffic it sees to determine the MPTCP one that needs to be proxied.

The draft says:

   Unlike the explicit mode, the implicit mode assumes that the MCP is
   located on a default forwarding path (primary path).  As such, the
   first subflow must always be placed over that primary path so that
   the MCP can intercept MPTCP flows.  Once intercepted, the MCP
   advertises its reachability information by means of MPTCP signals
   (MP_JOIN or ADD_ADDR).

The text does not specify which hook is used locally to inspect the traffic because this is implementation-specific.

The MCP splits the connection between two nodes and send forged packets to the sender?
[Med] Yes, the MCP splits the connection only if there is a MP_PREFER_PROXY signal received from the sender; forged packets are sent to the sender. draft-nam-mptcp-deployment-considerations also describes a deployment case where the MCP supports a configuration parameter to be removed from the connection if the destination is also MPTCP-capable. An example is shown in this figure:

   +----+                     +-----+                     +--+

   | H1 |                     | MCP |                     |RM|

   +----+                     +-----+                     +--+

   h1@h2@                       mcp@                       rm@

    | |                          |                          |

    | |src:h1             dst:rm@|src:h1             dst:rm@|

    | |=====SYN+MP_CAPABLE======>|====SYN+MP_CAPABLE=======>|

    | |<=====SYN/ACK+MP_CAPABLE==|<====SYN/ACK+MP_CAPABLE===|

    | |=====ACK+MP_CAPABLE======>|====ACK+MP_CAPABLE=======>|

    | | __________________________________________________  |

    | |/            Secondary subflow                      \|

    | |=====================SYN+MP_JOIN====================>|

    | |<===================SYN/ACK(MPJOIN)==================|

    | |=====================ACK(MP_JOIN)===================>|

    | |                       ...                           |

Also, in the two proxy scenario, does the downstream MCP have to be on-path?
[Med] Yes, the same considerations apply for both case (single proxy, dual proxy).

Thanks,
--
Yoshi

---

From: <[email-masked]>
Date: Wed, 22 Mar 2017 09:47:18 +0000

Hi Olivier, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[email-masked]] De la part de
> Olivier Bonaventure
> Envoyé : mercredi 22 mars 2017 10:35
> À : Yoshifumi Nishida; multipathtcp
> Objet : Re: [multipathtcp] q about on-path proxy
> 
> Yoshifumi,
> >

[Med] Perhaps I misunderstood your point but DNAT/SNAT are still needed for subsequent subflows even for the implicit case. Think about subflows that are placed with a destination address set to the one of the MCP and with a distinct source IP address than the one used to place the initial subflow.

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 22 Mar 2017 11:12:55 +0100

Med,

> [Med] Perhaps I misunderstood your point but DNAT/SNAT are still needed for subsequent subflows even for the implicit case. Think about subflows that are placed with a destination address set to th…

By no NAT, I mean that all the packets between the client and the server 
that the operator would observe on the R1-R2 path or the R6-R7 path have 
C/S as source/destination addresses. This means that the existing 
techniques that are used for logging, traffic control or monitoring that 
depends on addresses can be reused without any modification.

When the uMCP creates a subflow towards the dMCP, it uses other 
addresses than C and S, but these addresses are invisible to both the 
client and the final server.

Olivier

---

From: <[email-masked]>
Date: Wed, 22 Mar 2017 10:31:03 +0000

Re-,

Thank you for the clarification.

Please see inline.

Cheers,
Med

> De : Olivier Bonaventure [mailto:[email-masked]]
> Envoyé : mercredi 22 mars 2017 11:13
> À : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida; multipathtcp
> > [Med] Perhaps I misunderstood your point but DNAT/SNAT are still needed
> for subsequent subflows even for the implicit case. Think about subflows
> that are placed with a destination address set to the one of the MCP and
> with a distinct source IP address than the one used to place the initial
> subflow.
> 

[Med] For the R6-R7 leg, this is valid for all MCP deployments with source address/prefix preservation. 

> depends on addresses can be reused without any modification.

[Med] Agree, if these functions are located in the R1-R2 leg. Some adjustments may be needed (Legal Intercept, for example), but that is out of scope. 

> client and the final server.

[Med] Yes, this is the SNAT/DNAT I mentioned.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 22 Mar 2017 15:07:09 -0700

Hi Med, Olivier,

Thanks for the response. I think I got basic idea.  Now I have other
questions..
I feel on-path mode a bit more complex than off-path mode.

1:  I am thinking that when uMCP intercept the packet from C, we can send
MP_Convert Information Element to dMCP.
    (and dest will be dMCP instead of S)
    We don't need to use source routing and spoofing techniques on dMCP in
this approach, which looks simpler to me.

2: I am wondering how a sender will use MP_PREFER_SIGNAL.
    In my understanding, the possible use cases would be:
         a) A sender knows the receiver doesn't support MPTCP, but it still
wants to utilize MPTCP in some portions of path.
             In this case, it seems to me that we presume the existence of
MCP.
             If so, why we cannot use explicit mode (off-path mode) here?

         b) A sender not sure if the receiver supports MPTCP or not. But,
even if the receiver doesn't support MPTCP, it wants to use MPTCP in some
portions of path at least.
            In this case, uMCP will intercept packets and split the
connection regardless of whether the receiver supports MPTCP.
            The sender cannot know if the receiver supports MPTCP or not
because MCP works transparently.
            So, it can never learn about the receiver.
            If I think this way, it seems MP_PREFER_SIGNAL is not
beneficial when the receiver supports MPTCP.

--
Yoshi

On Wed, Mar 22, 2017 at 3:31 AM, <[email-masked]> wrote:
> [Med] Agree, if these functions are located in the R1-R2 leg. Some
adjustments may be needed (Legal Intercept, for example), but that is out
of scope.

---

From: <[email-masked]>
Date: Thu, 23 Mar 2017 07:34:21 +0000

Hi Yoshi, all,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : mercredi 22 mars 2017 23:07
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; multipathtcp
Objet : Re: [multipathtcp] q about on-path proxy

Hi Med, Olivier,

Thanks for the response. I think I got basic idea.  Now I have other questions..
I feel on-path mode a bit more complex than off-path mode.

1:  I am thinking that when uMCP intercept the packet from C, we can send MP_Convert Information Element to dMCP.
    (and dest will be dMCP instead of S)
    We don't need to use source routing and spoofing techniques on dMCP in this approach, which looks simpler to me.

2: I am wondering how a sender will use MP_PREFER_SIGNAL.
    In my understanding, the possible use cases would be:
         a) A sender knows the receiver doesn't support MPTCP, but it still wants to utilize MPTCP in some portions of path.
             In this case, it seems to me that we presume the existence of MCP.
[Med] The dual proxy case is the trivial case. Transforming a TCP connection into an MPTCP one assumes there is an on-path node that can handle the MTPCP connection appropriately. In order to distinguish native connections (e.g. MPTCP connections issued from a node located behind the uMCP) from proxied one, the MP_PREFER_PROXY signal is supplied to the dMCP as a trigger to “track” that connection.

             If so, why we cannot use explicit mode (off-path mode) here?
[Med] The explicit mode can be used, instead. There are deployment trade-offs that need to be considered. As an editor of the document, I’m trying to be neutral on this.

         b) A sender not sure if the receiver supports MPTCP or not. But, even if the receiver doesn't support MPTCP, it wants to use MPTCP in some portions of path at least.
            In this case, uMCP will intercept packets and split the connection regardless of whether the receiver supports MPTCP.
[Med] The uMCP behavior is policy-based. If it is instructed to intervene for native connections, it will do so. Otherwise, an MPTCP connection received from a host located in the LAN will be forwarded upstream without any modification (that is without any assistance from the MCP).

            The sender cannot know if the receiver supports MPTCP or not because MCP works transparently.
[Med] It can. An example of the single proxy case is provided in https://datatracker.ietf.org/doc/html/draft-nam-mptcp-deployment-considerations-01#section-5.6.1:

    ___________________
   / Host-based Model  \
   \___________________/

   +----+                     +-----+                     +--+
   | H1 |                     | MCP |                     |RM|
   +----+                     +-----+                     +--+
   h1@h2@                       mcp@                       rm@
    | |                          |                          |

      Figure 15: Sample Connection Establishment with MCP Withdrawal
                              (Implicit Mode)
            So, it can never learn about the receiver.

[Med] It can. See the theoretical example provided above.

            If I think this way, it seems MP_PREFER_SIGNAL is not beneficial when the receiver supports MPTCP.
[Med] Even if the receiver is MPTCP-capable, involving the MCP may be beneficial in some cases (discussed in draft-nam-*):

·         Some of the receiver’s network attachments may be subject to a volume quota: because the server does not have this visibility, a server sending the traffic aggressively on such interfaces will lead to exhaust the quota rapidly.

·         Communicating with IPv4-only receivers, but the sender is connected to an IPv6-only network.

--
Yoshi

On Wed, Mar 22, 2017 at 3:31 AM, <[email-masked]<mailto:[email-masked]>> wrote:
> > De : Olivier Bonaventure [mailto:[email-masked]<mailto:[email-masked]>]

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 23 Mar 2017 09:11:20 +0100

Yoshifumi,
> 1:  I am thinking that when uMCP intercept the packet from C, we can
> send MP_Convert Information Element to dMCP.
>     We don't need to use source routing and spoofing techniques on dMCP
> in this approach, which looks simpler to me.

There are three abstract ways to ensure that the packets from the uMCP 
reach the dMCP.

- influence the control plane (e.g. routing tables by using source 
specific routing) of the network between the uMCP and the dMCP to ensure 
that the packets reach the dMCP
- change all network packets (e.g. by using source routing)
- change the destination address of all flows initiated by the client

An advantage of the fist solution is that there is no per-packet 
overhead. A disadvantage of this solution is that it can be costly in a 
large network to implement and maintain this source specific routing.

An advantage of the second solution is that the IP addresses of the 
endpoints are preserved. A drawback of this solution is that there is a 
per packet overhead.

A drawback of the latter solution is that the network operator does not 
have visibility anymore on the traffic between the uMCP and the dMCP. 
All traffic appears as TCP connections to the dMCP. An advantage of this 
solution is that its overhead is minimised since only the SYN carries an 
additional TCP option.

There is no clear winner among these solutions and we should let the 
operators select the approach that better suits their deployment and 
operational concerns.

>          a) A sender knows the receiver doesn't support MPTCP, but it
> still wants to utilize MPTCP in some portions of path.
>          b) A sender not sure if the receiver supports MPTCP or not.
> But, even if the receiver doesn't support MPTCP, it wants to use MPTCP
> in some portions of path at least.

Currently, the main usage is the following in transparent mode

C --- uMCP ------ R1 ------ dMCP -------- R2 ------ S

The client wants to create a Multipath TCP connection towards S. A 
typical example is that C is an iPhone using the Siri application and S 
is Apple's server.

The uMCP and dMCP are useful when either the Client or the Server does 
not support Multipath TCP. If they both support Multipath TCP, it could 
be useful to allow the connection to pass through the uMCP and dMCP 
without terminating it. To achieve this in transparent mode, the dMCP 
must be able to distinguish between :

- a SYN containing an MP_CAPABLE option that was added by the uMCP and 
that must be terminated by the dMCP
- a SYN containing an MP_CAPABLE option that was inserted by the Client 
and should not be terminated by the dMCP

This is basically one bit of information. The MP_PREFER_PROXY option 
indicates that the MP_CAPABLE option was added by an upstream MCP and 
the connection should be terminated by a downstream MCP.

There are other use cases where the uMCP does not want the dMCP to 
terminate the Multipath TCP connections for policy reasons or because 
the uMCP knows that the server directly supports Multipath TCP.

I'm not a big fan of using an entire Multipath TCP option to carry one 
bit of information in the SYN. I would prefer to define a Proxy flag 
inside the MP_CAPABLE option as proposed several years ago on this list. 
This would be a clean solution with a very small overhead. We have spare 
bits in the MP_CAPABLE option.

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 23 Mar 2017 15:37:43 -0700

Hello Olivier, Med,

Thanks for providing detailed responses. I feel that things now got clearer
than before.
In my understanding, the benefits for on-path mode is MCP can stop
intercepting and splitting connection once it learns that both endpoints
support MPTCP.  if there're other benefits, please point out.

One thing which is not very clear to me yet is MP_PREFER_PROXY.
Med explained that there is a way to learn the endpoints support MPTCP. I
think MCPs can learn it through the method described in Figure 15, however
I'm not sure how the sender can learn it.

This makes me wonder why the sender needs to set MP_PREFER_PROXY.
Instead, I am thinking that using a certain option or flag that indicates
"MCP has intercepted this flow" may look more reasonable. This seems to be
more explicit signal to the downstream MCP.
Also, even when on-path MCP is not there, the sender might put
MP_PREFER_PROXY. This looks the waste of resource.

Thanks,
--
Yoshi

On Thu, Mar 23, 2017 at 1:11 AM, Olivier Bonaventure <
[email-masked]> wrote:

> An advantage of the fist solution is that there is no per-packet overhead.
> A disadvantage of this solution is that it can be costly in a large network
> to implement and maintain this source specific routing.
>
> endpoints are preserved. A drawback of this solution is that there is a per
> packet overhead.
>
> have visibility anymore on the traffic between the uMCP and the dMCP. All
> traffic appears as TCP connections to the dMCP. An advantage of this
> The client wants to create a Multipath TCP connection towards S. A typical
> example is that C is an iPhone using the Siri application and S is Apple's
> server.
>
> The uMCP and dMCP are useful when either the Client or the Server does not
> support Multipath TCP. If they both support Multipath TCP, it could be
> useful to allow the connection to pass through the uMCP and dMCP without
> terminating it. To achieve this in transparent mode, the dMCP must be able
> to distinguish between :
>
> indicates that the MP_CAPABLE option was added by an upstream MCP and the
> connection should be terminated by a downstream MCP.
>
> terminate the Multipath TCP connections for policy reasons or because the
> uMCP knows that the server directly supports Multipath TCP.
>
> I'm not a big fan of using an entire Multipath TCP option to carry one bit
> of information in the SYN. I would prefer to define a Proxy flag inside the
> MP_CAPABLE option as proposed several years ago on this list. This would be
> a clean solution with a very small overhead. We have spare bits in the
> MP_CAPABLE option.
>
>
>
> Olivier
>
>
>
>
>

---

From: <[email-masked]>
Date: Fri, 24 Mar 2017 06:41:52 +0000

Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : jeudi 23 mars 2017 23:38
À : [email-masked]; BOUCADAIR Mohamed IMT/OLN
Cc : multipathtcp
Objet : Re: [multipathtcp] q about on-path proxy

Hello Olivier, Med,

Thanks for providing detailed responses. I feel that things now got clearer than before.
In my understanding, the benefits for on-path mode is MCP can stop intercepting and splitting connection once it learns that both endpoints support MPTCP.  if there're other benefits, please point out.

One thing which is not very clear to me yet is MP_PREFER_PROXY.
Med explained that there is a way to learn the endpoints support MPTCP. I think MCPs can learn it through the method described in Figure 15, however I'm not sure how the sender can learn it.
[Med] An implementation example would look like the following :

·         A sends a SYN message with MP_CAPABLE+MP_PREFER_PROXY to B

·         This SYN is intercepted by an MCP which tracks the connection, that is: it removes the MP_PREFER_PROXY and add filters to intercept relevant incoming SYN/ACK. The SYN (MP_CAPABLE) is then forwarded to the next hop and so on, until it reaches B.

·         If the SYN/ACK received from B includes MP_CAPABLE, the MCP will forward it to A. A is now aware that B is MPTCP-capable and they can establish subsequent subflows directly. The MCP does not announce explicitly itself to A.

This makes me wonder why the sender needs to set MP_PREFER_PROXY.
[Med] The entity that sets the MP_PREFER_PROXY is likely to be an MCP. This is the typical dual-proxy case. This signal is set so that native MPTCP connections received from hosts of a LAN are distinguished from the connections the MCP transforms into MPTCP. An MCP located at the network side will intercept those connections that are proxied; not the ones that can be managed by endhosts.

This signal is motivated also by the requirements from MCP operators to control the usage of their MCP resources: only proxied MPTCP connections are assisted by an MCP.
The signal is also a guard against MCPs that will by default transform an MPTCP connection into a TCP connection. Allowing native connections to bypass that MCP is good to have.

Instead, I am thinking that using a certain option or flag that indicates "MCP has intercepted this flow" may look more reasonable. This seems to be more explicit signal to the downstream MCP.
[Med] Thank you for sharing your preference. I’m personally neutral on the structure of the MP_PREFER_PROXY signal. The most important point at this stage is to assess whether we need it or not.

Also, even when on-path MCP is not there, the sender might put MP_PREFER_PROXY. This looks the waste of resource.
[Med] This is a fair enough.

Thanks,
--
Yoshi

On Thu, Mar 23, 2017 at 1:11 AM, Olivier Bonaventure <[email-masked]<mailto:[email-masked]>> wrote:
Yoshifumi,

There are three abstract ways to ensure that the packets from the uMCP reach the dMCP.

- influence the control plane (e.g. routing tables by using source specific routing) of the network between the uMCP and the dMCP to ensure that the packets reach the dMCP
- change all network packets (e.g. by using source routing)
- change the destination address of all flows initiated by the client

An advantage of the fist solution is that there is no per-packet overhead. A disadvantage of this solution is that it can be costly in a large network to implement and maintain this source specific routing.

An advantage of the second solution is that the IP addresses of the endpoints are preserved. A drawback of this solution is that there is a per packet overhead.

A drawback of the latter solution is that the network operator does not have visibility anymore on the traffic between the uMCP and the dMCP. All traffic appears as TCP connections to the dMCP. An advantage of this solution is that its overhead is minimised since only the SYN carries an additional TCP option.

There is no clear winner among these solutions and we should let the operators select the approach that better suits their deployment and operational concerns.

             In this case, it seems to me that we presume the existence
of MCP.

The client wants to create a Multipath TCP connection towards S. A typical example is that C is an iPhone using the Siri application and S is Apple's server.

The uMCP and dMCP are useful when either the Client or the Server does not support Multipath TCP. If they both support Multipath TCP, it could be useful to allow the connection to pass through the uMCP and dMCP without terminating it. To achieve this in transparent mode, the dMCP must be able to distinguish between :

- a SYN containing an MP_CAPABLE option that was added by the uMCP and that must be terminated by the dMCP
- a SYN containing an MP_CAPABLE option that was inserted by the Client and should not be terminated by the dMCP

This is basically one bit of information. The MP_PREFER_PROXY option indicates that the MP_CAPABLE option was added by an upstream MCP and the connection should be terminated by a downstream MCP.

There are other use cases where the uMCP does not want the dMCP to terminate the Multipath TCP connections for policy reasons or because the uMCP knows that the server directly supports Multipath TCP.

I'm not a big fan of using an entire Multipath TCP option to carry one bit of information in the SYN. I would prefer to define a Proxy flag inside the MP_CAPABLE option as proposed several years ago on this list. This would be a clean solution with a very small overhead. We have spare bits in the MP_CAPABLE option.

Olivier

---

From: <[email-masked]>
Date: Fri, 24 Mar 2017 12:29:14 +0000

Following up on this.
I want to concentrate first **specifically** on the solution for this use case:

<<. The other scenario involves an MPTCP-enabled smartphone, with LTE and WiFi, plus a proxy in the operator’s network.>>

Looking first at the solution using MP_PREFER_PROXY on the SYN  ("implicit mode" solution)

I think the assumption is:
* the smartphone knows that the other end point is not MPTCP enabled, or prefers to use a proxy even if the other end point is MPTCP enabled.

I don’t like this assumption as it hinders end-to-end deployment of MPTCP.

Solution could be something on the lines you suggest below:
* the proxy tracks what end points are MPTCP enabled and which ones aren’t. I think this would run into scaling and DoS problems.
* or the smartphone tracks what end points are enabled and which ones aren’t; it needs to do this by which interface it tries to reach the other end point. Could be quite a lot of info to track

Perhaps it’s possible to devise a solution where the proxy adds a  HI_I_AM_A_PROXY onto the SYN_ACK (assuming the SYN_ACK goes through the proxy). Not sure what the next step would be. I guess one approach is to give up on the first connection and immediately send a new SYN with a PROXY_PLEASE_INSERT_YOURSELF. Seems to be getting cumbersome?

Do the currently deployed solutions for the smartphone scenario use MP_PREFER_PROXY, or do they use an “explicit mode” solution?

Thanks
phil

From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 24 March 2017 01:42
To: Yoshifumi Nishida <[email-masked]>; [email-masked]
Cc: multipathtcp <[email-masked]>
Subject: Re: [multipathtcp] q about on-path proxy

Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : jeudi 23 mars 2017 23:38
À : [email-masked]<mailto:[email-masked]>; BOUCADAIR Mohamed IMT/OLN
Cc : multipathtcp
Objet : Re: [multipathtcp] q about on-path proxy

Hello Olivier, Med,

Thanks,
--
Yoshi

Olivier

---

From: <[email-masked]>
Date: Fri, 24 Mar 2017 13:11:05 +0000

Forgot something, added in line

From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 24 March 2017 07:29
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [multipathtcp] q about on-path proxy

Following up on this.

Another assumption, I think is:
* connection is initiated from the smartphone
It would be nice if the solution also worked for connections initiated by the other end point (and definitely nothing bad must happen)

Thanks
phil

From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 24 March 2017 01:42
To: Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: multipathtcp <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] q about on-path proxy

Hi Yoshi,

Please see inline.

Cheers,
Med

Hello Olivier, Med,

Thanks,
--
Yoshi

Olivier

---

From: <[email-masked]>
Date: Fri, 24 Mar 2017 13:57:27 +0000

Hi Phil,

Please see inline.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]]
Envoyé : vendredi 24 mars 2017 14:11
À : [email-masked]; BOUCADAIR Mohamed IMT/OLN; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: [multipathtcp] q about on-path proxy

From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 24 March 2017 07:29
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [multipathtcp] q about on-path proxy

Following up on this.

<<. The other scenario involves an MPTCP-enabled smartphone, with LTE and WiFi, plus a proxy in the operator’s network.>>
[Med] IMHO, the implicit mode is more suitable for the dual-proxy case rather than the single proxy…but let’s discuss this one.

I don’t like this assumption as it hinders end-to-end deployment of MPTCP.
[Med] It doesn’t. The MCP can be removed from the path if the MP_CAPABLE is received from the RM.

Solution could be something on the lines you suggest below:
* the proxy tracks what end points are MPTCP enabled and which ones aren’t. I think this would run into scaling and DoS problems.
[Med] Scaling is not an issue here given that the implicit mode assumes that MCP inspects all TCP traffic. Tracking the 3WHS of the initial subflow and then get out from the connection if DST is MPTCP-capable is more optimal compared to systematically be inserted in all connections. Means to mitigate DoS problems are called out in the draft (rate-limit state creation, limit subflow creation, etc.).

* or the smartphone tracks what end points are enabled and which ones aren’t; it needs to do this by which interface it tries to reach the other end point. Could be quite a lot of info to track
[Med] A white list approach may be considered in early stages. That is always insert MP_PREFER_PROXY except for this list of servers.

Perhaps it’s possible to devise a solution where the proxy adds a  HI_I_AM_A_PROXY onto the SYN_ACK (assuming the SYN_ACK goes through the proxy). Not sure what the next step would be. I guess one approach is to give up on the first connection and immediately send a new SYN with a PROXY_PLEASE_INSERT_YOURSELF. Seems to be getting cumbersome?
[Med] This increases the delay of the connection establishment for non-obvious added value.

Another assumption, I think is:
* connection is initiated from the smartphone
It would be nice if the solution also worked for connections initiated by the other end point (and definitely nothing bad must happen)
[Med] For incoming connections (MCP-to-UE), there is no need to insert MP_PREFER_PROXY.

Do the currently deployed solutions for the smartphone scenario use MP_PREFER_PROXY, or do they use an “explicit mode” solution?
[Med] The deployments I’m aware of are using the explicit mode.

Thanks
phil

Hi Yoshi,

Please see inline.

Cheers,
Med

Hello Olivier, Med,

•         A sends a SYN message with MP_CAPABLE+MP_PREFER_PROXY to B

•         This SYN is intercepted by an MCP which tracks the connection, that is: it removes the MP_PREFER_PROXY and add filters to intercept relevant incoming SYN/ACK. The SYN (MP_CAPABLE) is then forwarded to the next hop and so on, until it reaches B.

•         If the SYN/ACK received from B includes MP_CAPABLE, the MCP will forward it to A. A is now aware that B is MPTCP-capable and they can establish subsequent subflows directly. The MCP does not announce explicitly itself to A.

Thanks,
--
Yoshi

Olivier

---

From: <[email-masked]>
Date: Fri, 24 Mar 2017 14:49:56 +0000

Thanks.
Several points here I don’t understand, but it seems this is not the preferred solution approach anyway.
So rather than following up the details, let me ask:
Does anyone want to pursue an “implict mode” solution to the single-ended proxy scenario?  Please shout if you do, otherwise I suggest we concentrate on an “explicit mode” solution for this scenario.
Thanks
phil

From: [email-masked] [mailto:[email-masked]]
Sent: 24 March 2017 08:57
To: Eardley,PL,Philip,TUB8 R <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [multipathtcp] q about on-path proxy

Hi Phil,

Please see inline.

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : vendredi 24 mars 2017 14:11
À : [email-masked]<mailto:[email-masked]>; BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: [multipathtcp] q about on-path proxy

Following up on this.

Thanks
phil

Hi Yoshi,

Please see inline.

Cheers,
Med

Hello Olivier, Med,

Thanks,
--
Yoshi

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 24 Mar 2017 11:07:02 -0700

Hi Med,

Thanks for the response.
Just one point..

On Thu, Mar 23, 2017 at 11:41 PM, <[email-masked]> wrote:

> Hi Yoshi,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yoshifumi Nishida [mailto:[email-masked]]
> *Envoyé :* jeudi 23 mars 2017 23:38
> *À :* [email-masked]; BOUCADAIR Mohamed IMT/OLN
> *Cc :* multipathtcp
> *Objet :* Re: [multipathtcp] q about on-path proxy
>
>
>
> Hello Olivier, Med,
>
>
>
> ·         This SYN is intercepted by an MCP which tracks the connection,
> that is: it removes the MP_PREFER_PROXY and add filters to intercept
> relevant incoming SYN/ACK. The SYN (MP_CAPABLE) is then forwarded to the
> next hop and so on, until it reaches B.
>
> ·         If the SYN/ACK received from B includes MP_CAPABLE, the MCP
> will forward it to A. A is now aware that B is MPTCP-capable and they can
> establish subsequent subflows directly. The MCP does not announce
> explicitly itself to A.
>

Hmm. I am not sure about this.
I understand A will receive MP_CAPABLE from B in this case. But, I think
even B doesn't support MPTCP, A will receive MP_CAPABLE from B which is
created by MCP (by spoofing). So, I think A cannot identify whether this is
from B or MCP.
--
Yoshi

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Sun, 26 Mar 2017 07:51:53 +0000

Implicit mode is getting deployed since you don’t need extensions to MPTCP but most people want explicit mode.

From: multipathtcp <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Friday, 24 March 2017 at 15:49
To: "mohamed. boucadair" <[email-masked]>, "[email-masked]" <[email-masked]>, Olivier Bonaventure <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [multipathtcp] q about on-path proxy

Thanks.

Hi Phil,

Please see inline.

Cheers,
Med

Following up on this.

Thanks
phil

Hi Yoshi,

Please see inline.

Cheers,
Med

Hello Olivier, Med,

Thanks,
--
Yoshi

Olivier