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

[Alper Yegin <[e-mail]>]

Hello Lingli,

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


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


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


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


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

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.



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

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.



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


OK.

Thanks.

Alper


>  
> Cheers,
>  
> Alper