Re: [multipathtcp] Comments on draft-deng-mptcp-proxy-00

[邓灵莉/Lingli Deng <[e-mail]>]

Hi Alper,

 

Thanks for your review and comments.

Plz see my reply inline.

 

Lingli

 

From: multipathtcp [mailto:[e-mail]] On Behalf Of Alper Yegin
Sent: Thursday, August 21, 2014 3:30 PM
To: [e-mail]
Subject: [multipathtcp] Comments on draft-deng-mptcp-proxy-00

 

Hello,

 

 

I read the deng-mptcp-proxy draft and here are my comments/questions.

 

 

   o Strip any MPTCP signal systematically when relaying TCP messages to

   a remote server: This mode assumes servers are not widely MPTCP-

   enabled. It has the advantage to not suffer from MPTCP fallback delay

   when the remote server is not MPTCP-enabled.

 

Would the proxy be terminating the TCP connection with the UE, or would it be relaying the TCP packets (with modifications)?  I had assumed the former, but the above statement points to the latter.

[邓灵莉/Lingli Deng] In this case, I believe the end-to-end connection is split by the proxy into MPTCP with the UE and TCP with the server. Maybe we can use another word instead of “relaying” to better clarify that. Thanks for pointing it out.

 

 

Off-path proxy and steering: How does the steering work? Is it based on proxy adding an IP address using MPTCP signaling?

[邓灵莉/Lingli Deng] There are many options I think. The one you mentioned is actually one of them.

 

 

 

   Note that by applying local breakout scheme, where the small cell

   doing IP-layer forwarding itself rather than relying on other 3GPP

   routing devices, it is expected that no extensions to existing 3GPP

   specs are needed for its integration with an MPTCP Proxy.

 

 

The WiFi AP could also use SAMOG and tunnel traffic to PGW, in which case there'd not be a need for MPTCP. I think this is what the text is referring to above.

[邓灵莉/Lingli Deng] Right.

 

So, is this about using MPTCP only when WiFi is using local breakout?

[邓灵莉/Lingli Deng] using MPTCP only when WiFi is *not* using local breakout.

 

 

   (b) Transparency: An on-path MPTCP Proxy supports negotiation with

   and acting towards the M-UE like a M-server on behalf of N-Server,

   while acting towards the N-Server like a N-UE on behalf of the M-UE.

 

 

Are the authors envisioning an explicit signaling (an extension to MPTCP), or is this done transparent to the UE (hence it becomes a matter of implementation on the proxy)?

[邓灵莉/Lingli Deng] We hoped that an on-path proxy is “invisible” to the UE, whenever possible. So there would be no explicit signaling to the UE for an on-path proxy.

 

   (d) Globally Routable Address: an off-path MPTCP Proxy that enables

   resource pooling from the same ISP's networks SHOULD expose a

   globally routable address to allow explicit steering of subsequent

   subflow traffic after they hit the public Internet.

 

We also need to consider the security issues stemming from introduction of the proxy, which acts as MitM.

End-to-end security solutions, e.g., TCPinc, would break -- unless we make this a non-transparent solution and design security accordingly.

[邓灵莉/Lingli Deng] Point taken. But for our use-case, we saw benefits for deployment and operation for transparent on-path proxies owned by the ISP.

 

 

   (e) Network Access Type Information: an MPTCP proxy SHOULD be able to

   make use of a reliable information sharing/reporting mechanism to

   acquire a subflow's Network Access Type information/update on a real-

   time basis.

 

 

Would this be handled out-of band with respect to MPTCP? 

[邓灵莉/Lingli Deng] I guess so.

Any specific protocols in mind?

[邓灵莉/Lingli Deng] As we are thinking about deploying the proxy onto the PGW, it is actually an internal information exchange between components. Right?

 

 

Cheers,

 

Alper