Re: [multipathtcp] MPTCP Proxy questions

[Weixinpeng <[e-mail]>]

Hi Jordan,
Thanks for your questions.
Please see my comments inline. Thanks!

BR,
Xinpeng
From: multipathtcp [mailto:[e-mail]] On Behalf Of Jordan Melzer
Sent: Friday, August 01, 2014 9:38 AM
To: [e-mail] Mailing List
Subject: [multipathtcp] MPTCP Proxy questions

Hi everyone,

I recently implemented a simple “on-path” MPTCP “proxy” by running TCP MITM software (Mallory) on a machine with an MPTCP enabled kernel (UC Louvain).  It is not a sophisticated proxy – though Mallory’s plugin architecture could allow it to be – but having something running as a proxy raises a number of questions for me, and these may be of general interest.

The application I used it for is similar to the “hybrid access network” model recently presented within homenet: https://tools.ietf.org/agenda/90/slides/slides-90-homenet-2.pdf

While the homenet model sees LTE being used to augment DSL speeds, in my prototype multiple WiFi networks from neighbouring home gateways can be used to improve access rates at the home gateway.  The GRE-based solution suggested within homenet could only work with a single connection of unknown rate.  I used an on-path MPTCP proxy at the residential gateway, which is viable for aggregating any number of connections of unknown rate.  MPTCP was dismissed within the homenet proposal for being at the wrong layer.  I would welcome comments on that.  Another approach, one used by a system called Binder out of the University of Edinburgh (http://www.cs.stir.ac.uk/~mmf/res/pubs/lcdnet13.pdf) used an OpenVPN tunnel to ensure that all traffic was over MPTCP within the ISP network.  In this model and in the homenet one, there must be a tunnel termination point at the ISP.
[Wei] As my understanding, the purpose of work you are doing in homenet model is to use different network access service at home to simultaneously to provide a faster and reliable access rate for users?
For the following reasons listed in your slides that MPTCP is not suitable for your homenet:
– Application layer [Wei] It is more suitable to see MPTCP as a transport layer service not application layer.
 – Multihomed hosts rather than multihoming RG  [Wei] I think the MPTCP proxy mechanism could be suitable for multihoming RG scenario, the architecture have been mentioned in  draft-deng-mptcp-proxy-00, and we will discuss this latter version of draft-wei-mptcp-proxy-mechanism
 – Lack the mechanism on packet-based traffic [Wei]In MPTCP, packet distribution on different interfaces in decided by MPTCP itself.
   – TCP application only [Wei]Right.

In a proxy model, should MPTCP see wide deployment on the Internet, an ISP-side MPTCP proxy becomes superfluous.  What should happen when both sides are MPTCP enabled is a good question – how should the multiple paths available from the residential gateway onwards be signalled?
[Wei] Do you mean both end host are MPTCP capable? If that case, the proxy will not act as a proxy and have nothing to do with the traffic. Could you explain this in more detail? :“how should the multiple paths available from the residential gateway onwards be signalled?”


Re draft-wei-mptcp-proxy-mechanism-00.txt, the new feature suggested in the draft is a mechanism to indicate the presence of an “off-path” proxy and provide an IP address for it.  As it appears to be possible to leverage the MITM on the primary connection to address the off-path case by simply hijacking the connection through removing the original destination address and adding the proxy address, it would be helpful for the draft to directly address what makes the new mechanism suggested preferable to the mechanism that is already available.  Is an explicitly signalled proxy valuable for the kind of use case above, where multiple paths are available starting deeper in the network?
[Wei]  In off-path model，we assume that there is a proxy located in the path of initial sub-flow from MPTCP host, the reason why by simply hijacking the connection and replacing original destination address with proxy address is not enough is that if proxy’s address is not explicitly signaled to MPTCP host, for the subsequent sub-flows their destination address will be also TCP host’s address, and  these sub-flows are not assured to pass through the proxy that the initial sub-flow passed. Off-path model would be especially useful in case MPTCP host uses service from different network operators simultaneously.

I will have some comments on the larger proxy use cases draft later.  Despite having implemented what we are calling a proxy and having worked on a system that requires one, I am somewhat ambivalent about gateways that assist the user without the user’s consent, and am somewhat hesitant to even call them proxies – in other contexts a proxy is usually designated by a user
[Wei] There are different kinds of proxies which are transparent or non-transparent to end user, and I think we should only see the proxy with user’s consent as just one of them.
.  I don’t have a proposal yet on how to make proxying more consensual or to do useful things in situations where MPTCP is enabled but could work more effectively if the network provided more information about itself.  I would welcome either thoughts on those concerns or specific solutions.  Hopefully I’ll have some to suggest in the coming days.
Regards,
Jordan

Jordan Melzer
TELUS Communications