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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[e-mail]]
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, <[e-mail]<mailto:[e-mail]>> 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.

Below some additional comments.

Cheers,
Med

De : multipathtcp [mailto:[e-mail]<mailto:[e-mail]>] 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.