Subject: [multipathtcp] q about off-path proxy (explicit mode)

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 25 Mar 2017 06:08:21 -0700

Hello,
Now, I am trying to understand off-path (explicit mode) scenarios.
In explicit mode, we need to tell the final destination to the proxy
through MP_Convert Information Element. But, this requires mptcp
connections. In order to clarify which cases can use this mode, I have
drawn the following 7 cases.
I am wondering if we can support case 3) 4) 5) with explicit mode or not.
Also, supporting case 6), 7) seems to be a bit unclear.
It would be great if some folks could clarify this.

------------------------------------------------------------
-----------------

     C ... client,   S ... Server,  P ... Proxy,  MCIE ... MP_Convert
Information Element
   ====   ... mptcp connection
   ----   ... tcp connection

single proxy cases

1)   C ========== P -------- S         : C tells S's addr to P by MCIE
2)   C ========== P ======== S         : C tells S's addr to P by MCIE
3)   C ---------- P ======== S         : How C tell S's address to P?

double proxy cases

4)   C -------- P1 ======== P2 ------- S  : How C tell S's address to P1?
5)   C -------- P1 ======== P2 ======= S  : How C tell S's address to P1?
6)   C ======== P1 ======== P2 ------- S  : C tells S's addr to P1 by MCIE
and P1 forwards it to P2?
7)   C ======== P1 ======== P2 ======= S  : C tells S's addr to P1 by MCIE
and P1 forwards it to P2?

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 27 Mar 2017 14:15:42 +0200

Yoshifumi,

> I am wondering if we can support case 3) 4) 5) with explicit mode or
> not. Also, supporting case 6), 7) seems to be a bit unclear.
> -----------------------------------------------------------------------------
>
>

I think that you forgot case 0

  0)   C ---------- P -------- S

This is a classical SOCKS proxy, except that the SOCKS proxy requires 
additional rtts

> 3)   C ---------- P ======== S         : How C tell S's address to P?

Today, the thrid case is often a load balancer in front of a real 
server. In this case, the client is not aware of the existence of S and 
only knows P. If we want to support this scenario, we need to extend TCP 
itself.

> 5)   C -------- P1 ======== P2 ======= S  : How C tell S's address to P1?

Same as case 3 above. C could use the MCIE to add information about the 
final destination.

> 6)   C ======== P1 ======== P2 ------- S  : C tells S's addr to P1 by
> MCIE and P1 forwards it to P2?
> 7)   C ======== P1 ======== P2 ======= S  : C tells S's addr to P1 by
> MCIE and P1 forwards it to P2?

Here also, case 8 could be relevant in some scenarios

  8)   C ---------- P -------- S

This would create a generic explicit TCP proxy function, that would 
apply beyond MPTCP.

Olivier

---

From: <[email-masked]>
Date: Mon, 27 Mar 2017 15:06:27 +0000

Hi Yoshi,

Olivier already answered to many of your points. There are other communication scenarios not included in your list that we want to cover.

Below some additional comments.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de Yoshifumi Nishida
Envoyé : samedi 25 mars 2017 08:08
À : multipathtcp
Objet : [multipathtcp] q about off-path proxy (explicit mode)

Hello,
Now, I am trying to understand off-path (explicit mode) scenarios.
In explicit mode, we need to tell the final destination to the proxy through MP_Convert Information Element. But, this requires mptcp connections. In order to clarify which cases can use this mode, I have drawn the following 7 cases.
I am wondering if we can support case 3) 4) 5) with explicit mode or not. Also, supporting case 6), 7) seems to be a bit unclear.
It would be great if some folks could clarify this.

     C ... client,   S ... Server,  P ... Proxy,  MCIE ... MP_Convert Information Element
   ====   ... mptcp connection
   ----   ... tcp connection

single proxy cases

1)   C ========== P -------- S         : C tells S's addr to P by MCIE
2)   C ========== P ======== S         : C tells S's addr to P by MCIE
3)   C ---------- P ======== S         : How C tell S's address to P?
[Med] The communication between C and P relies on TCP. C does not need to supply any information to P for case 3. The client is not even aware about the presence of P in this case.

double proxy cases

4)   C -------- P1 ======== P2 ------- S  : How C tell S's address to P1?
[Med] S is the destination IP address of the packets sent from C to P1. There is no need for an object to supply that information.

5)   C -------- P1 ======== P2 ======= S  : How C tell S's address to P1?
[Med] S is the destination IP address of the packets sent from C to P1.

6)   C ======== P1 ======== P2 ------- S  : C tells S's addr to P1 by MCIE and P1 forwards it to P2?
[Med] No. S is the destination IP address of the packets sent from C to P1.  MCIE is not needed in the C-P1 leg.

7)   C ======== P1 ======== P2 ======= S  : C tells S's addr to P1 by MCIE and P1 forwards it to P2?
[Med] No. S is the destination IP address of the packets sent from C to P1.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 27 Mar 2017 11:20:58 -0700

Hi Olivier, Med,

Thanks for the response. I have been thinking that it would be better if we
can classify our use cases so that we can have clear vision for what to
solve. Things I may want to classify is:
   a) solutions requires changes in only MPTCP or in TCP general
   b) solutions requires proxies to be on-path or solutions that work with
off-path proxy.

We can think about the solutions for a) if we think it's necessary, but I
am thinking that the proper venue for the discussion might not be this WG.

I think the approach Med mentioned requires the proxy to be on-path, so I
would like to classify it as an on-path solution.
I had some hard time to comprehend the proxy drafts and I think one reason
for that is it somehow mixes up on-path and off-path cases. I start
thinking separating docs for on-path and off-path solutions might be
helpful.
--
Yoshi

On Mon, Mar 27, 2017 at 8:06 AM, <[email-masked]> wrote:

> Hi Yoshi,
>
>
>
> Olivier already answered to many of your points. There are other
> communication scenarios not included in your list that we want to cover.
>
>
>
> *De :* multipathtcp [mailto:[email-masked]] *De la part de*
> Yoshifumi Nishida
> *Envoyé :* samedi 25 mars 2017 08:08
> *À :* multipathtcp
> *Objet :* [multipathtcp] q about off-path proxy (explicit mode)
>
>
>
> Hello,
>
> [Med] The communication between C and P relies on TCP. C does not need to
> supply any information to P for case 3. The client is not even aware about
> the presence of P in this case.
>
>
>
> double proxy cases
>
>
>
> There is no need for an object to supply that information.
>
>
>

---

From: <[email-masked]>
Date: Mon, 27 Mar 2017 19:32:19 +0000

Re-,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : lundi 27 mars 2017 13:21
À : BOUCADAIR Mohamed IMT/OLN
Cc : Yoshifumi Nishida; multipathtcp
Objet : Re: [multipathtcp] q about off-path proxy (explicit mode)

Hi Olivier, Med,

Thanks for the response. I have been thinking that it would be better if we can classify our use cases so that we can have clear vision for what to solve. Things I may want to classify is:
   a) solutions requires changes in only MPTCP or in TCP general
   b) solutions requires proxies to be on-path or solutions that work with off-path proxy.

We can think about the solutions for a) if we think it's necessary, but I am thinking that the proper venue for the discussion might not be this WG.

I think the approach Med mentioned requires the proxy to be on-path, so I would like to classify it as an on-path solution.
[Med] I’m not sure to follow you here. What I described is aligned with the target dual proxy case (https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#section-4.2): the first proxy is embedded on a CPE. There is no technical problem there to intercept the traffic to be proxyied given that the CPE sees all the traffic.

I had some hard time to comprehend the proxy drafts and I think one reason for that is it somehow mixes up on-path and off-path cases. I start thinking separating docs for on-path and off-path solutions might be helpful.
[Med] There are a lot of commonalities between these two modes. The main difference is how to make involve the MCP into a connection.
--
Yoshi

On Mon, Mar 27, 2017 at 8:06 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshi,

Cheers,
Med

De : multipathtcp [mailto:[email-masked]<mailto:[email-masked]>] De la part de Yoshifumi Nishida
Envoyé : samedi 25 mars 2017 08:08
À : multipathtcp
Objet : [multipathtcp] q about off-path proxy (explicit mode)

Hello,

single proxy cases

double proxy cases

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 27 Mar 2017 14:18:15 -0700

Hi Med,

On Mon, Mar 27, 2017 at 12:32 PM, <[email-masked]> wrote:

> Re-,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yoshifumi Nishida [mailto:[email-masked]]
> *Envoyé :* lundi 27 mars 2017 13:21
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* Yoshifumi Nishida; multipathtcp
> *Objet :* Re: [multipathtcp] q about off-path proxy (explicit mode)
>
>
>
> Hi Olivier, Med,
>
>
>
> Thanks for the response. I have been thinking that it would be better if
> we can classify our use cases so that we can have clear vision for what to
> [Med] I’m not sure to follow you here. What I described is aligned with
> the target dual proxy case (https://tools.ietf.org/html/
> draft-nam-mptcp-deployment-considerations-01#section-4.2): the first
> proxy is embedded on a CPE. There is no technical problem there to
> intercept the traffic to be proxyied given that the CPE sees all the
> traffic.
>

Well, this classification might be a bit different from the way described
in the draft.
What I meant for off-path (explicit) case is the cases where the proxy is
not on the path between client and server. No more and no less.
So, the dest address of the packets from client should be proxy's address.
(Otherwise, there's no way for proxies to fetch the packets)

I have thought it may be simpler if we think in this way rather than
thinking about CPEs.

> [Med] There are a lot of commonalities between these two modes. The main
> difference is how to make involve the MCP into a connection.
>
>
This is just an idea. If we think we can proceed proxy ideas in the current
form, it's fine. But, I just would like to explore several possibilities.
--
Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 28 Mar 2017 10:21:53 +0200

Yoshifumi,
> we can classify our use cases so that we can have clear vision for what
> to solve. Things I may want to classify is:
> We can think about the solutions for a) if we think it's necessary, but
> I am thinking that the proper venue for the discussion might not be this
> WG.
>
> I think the approach Med mentioned requires the proxy to be on-path, so
> I would like to classify it as an on-path solution.
> I had some hard time to comprehend the proxy drafts and I think one
> reason for that is it somehow mixes up on-path and off-path cases. I
> start thinking separating docs for on-path and off-path solutions might
> be helpful.

We combined the drafts based on the suggestions from the Berlin meeting. 
There might be other ways to describe the solution. Based on the results 
of the discussion in Chicago, we can try to think about a series of 
drafts that might be easier to read because each draft would be focussed 
on a smaller subset

Let's discuss this on the list after the meeting since I will only 
attend remotely

Olivier

---

From: <[email-masked]>
Date: Tue, 28 Mar 2017 12:20:18 +0000

Hi Yoshi,

Please see inline.

Cheers,
Med

Envoyé : lundi 27 mars 2017 16:18

Hi Med,

On Mon, Mar 27, 2017 at 12:32 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]<mailto:[email-masked]>]

Hi Olivier, Med,

Well, this classification might be a bit different from the way described in the draft.
What I meant for off-path (explicit) case is the cases where the proxy is not on the path between client and server. No more and no less.
[Med] I see. As you can read in the plain mode draft, implicit/explicit thing is drawn from the perspective of the MCP located at the network provider side.

So, the dest address of the packets from client should be proxy's address. (Otherwise, there's no way for proxies to fetch the packets)
[Med] It shouldn’t because we don’t want to require any specific function at the client side for the dual proxy case. Network providers do not have any control on the hosts. The description text in the plain mode is clear about the src/dst addresses for this case:

   The Client sends a SYN segment addressed to the Server and it is
   intercepted by the upstream MCP which in turns initiates an MPTCP
   connection towards its downstream MCP that includes the MP_CONVERT
   Information Element described in Figure 4.  The destination address
   of the SYN segment is the IP address of the downstream MCP.  The
   MP_CONVERT Information Element included in the SYN contains the IP
   address and optionally the destination port of the Server; this
   information is extracted from the SYN message received over the
   upstream TCP connection.

I have thought it may be simpler if we think in this way rather than thinking about CPEs.
[Med] It is much simpler at this stage to focus on the target use case for the dual proxy deployment: MCP in the CPE + MCP at the network side.

This is just an idea. If we think we can proceed proxy ideas in the current form, it's fine. But, I just would like to explore several possibilities.
--
Yoshi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 28 Mar 2017 15:59:52 -0700

Hi Med,

On Tue, Mar 28, 2017 at 5:20 AM, <[email-masked]> wrote:

> *Envoyé :* lundi 27 mars 2017 16:18
> [Med] I see. As you can read in the plain mode draft, implicit/explicit
> thing is drawn from the perspective of the MCP located at the network
> provider side.
>

I think I understand the perspective.
I am thinking that if we don't combine explicit mode and off-path, it will
be less confusing (at least to me)
In my understanding, explicit mode can be used for off-path (probably for
single proxy case) and on-path (probably for 2 proxy case)
Implicit mode probably will be used for on-path case only.

--
Yoshi

---

From: <[email-masked]>
Date: Tue, 28 Mar 2017 23:09:02 +0000

Looking at the description
<< MPTCP is now seeing widespread deployment in networks to bond together two accesses, such as fixed and mobile broadband, by using an MPTCP-specific proxy or proxies. There are two scenarios. The first involves two proxies, one in the home gateway or Customer Premises Equipment and one in the network, both under the control of the operator. The other scenario involves an MPTCP-enabled smartphone, with LTE and WiFi, plus a proxy in the operator’s network>>

In the case with two proxies, the distinction is whether the proxy in the network is assumed to be on the default path or not (‘implicit’ vs ‘explicit’). In both cases it’s assumed that the home gateway is on the default path(!)

phil

From: multipathtcp [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: 28 March 2017 18:00
To: [email-masked]
Cc: multipathtcp <[email-masked]>
Subject: Re: [multipathtcp] q about off-path proxy (explicit mode)

Hi Med,

On Tue, Mar 28, 2017 at 5:20 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshi,

Please see inline.

Cheers,
Med

Hi Med,

Please see inline.

Cheers,
Med

Hi Olivier, Med,

I think I understand the perspective.
I am thinking that if we don't combine explicit mode and off-path, it will be less confusing (at least to me)
In my understanding, explicit mode can be used for off-path (probably for single proxy case) and on-path (probably for 2 proxy case)
Implicit mode probably will be used for on-path case only.

--
Yoshi