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

From: Alper Yegin <[email-masked]>
Date: Thu, 21 Aug 2014 10:29:49 +0300

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

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Fri, 22 Aug 2014 10:03:02 +0800

Hi Alper,

Thanks for your review and comments.

Plz see my reply inline.

Lingli

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

Hello,

 

[邓灵莉/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.

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

 

[邓灵莉/Lingli Deng] Right.

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

 

[邓灵莉/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.

[邓灵莉/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.

   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

---

From: Alper Yegin <[email-masked]>
Date: Fri, 22 Aug 2014 11:07:12 +0300

Hello Lingli,

> [邓灵莉/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 bett…

In that case, this does not qualify as  "TCP proxy" as TCP does not terminate on the proxy.
But it qualifies as "MPTCP proxy" as MPTCP bits do terminate on that middle node.
Just making an observation...

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

For that particular solution, the initial sub-flow is assumed to go thru on-path proxy. Otherwise the proxy cannot catch the connection to steer. 
(I know your draft is not about solutions, nevertheless discussion from you or other folks on solution aspect is welcome as well.)

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

It could be useful to elaborate the text in the draft. Even if SAMOG is not mentioned, at least describing its affect at a high-level would help the readers understand what "relying on other 3GPP routing devices" mean.

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

I have a different understanding, possibly due to a terminology issue.

If WiFi traffic is back hauled to the PGW using SAMOG, then that does not qualify as "local breakout". And that's when we don't need MPTCP.

When WiFi traffic is offloaded to Internet (no backhauling to the core network), then that's "local breakout" and that's where MPTCP comes into the picture.

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

OK.

Thanks.

Alper