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

[Alper Yegin <[e-mail]>]

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.


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



   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.

So, is this about using MPTCP only when WiFi is 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)?

   (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.


   (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? Any specific protocols in mind?


Cheers,

Alper