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

[<[e-mail]>]

Hi Yoshi,

Please see inline.

Cheers,
Med

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

Hi Med,

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

Please see inline.

Cheers,
Med

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

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.


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.

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