Re: [multipathtcp] MPTCP Proxy questions

[Jordan Melzer <[e-mail]>]

Dear Xinpeng,

Thank you for your comments, they are much appreciated.  To be clear, I did not write the slides I linked to on bonding two access networks – they were slides presented to the homenet group at IETF 90.  As one of their authors was from Huawei, you may have more insight into their use case than I do.  I have implemented a similar use case, one where a residential gateway uses WiFi (and specifically 802.11s) as an access mechanism in addition to DSL.  In both this use case and the homenets one, the end clients may have a single interface, with multiple interfaces becoming available at the residential gateway.  As you noted, a scenario in which the client has a single interface and is not MP-capable but is proxied by an MP-capable gateway is included in draft-deng-mptcp-proxy-00.

For these sorts of use cases, if we encounter a situation where the client is MP capable and the server is MP capable but both have a single interface, we would still want the residential gateway to do something to allow its two upstream connections to be used.  Similarly, we would want a client with a second, “off-net” interface to be able to use it.

Without off-net link:
+--------+     +-------+           +--------+
|        |     |       +------+    |        |
| client +-----+ proxy |      +----+ server |
|        |     |       +------+    |        |
+---+----+     +-------+           +--------+

With off-net link:
+--------+     +-------+           +--------+
|        |     |       +------+    |        |
| client +-----+ proxy |      +-+--+ server |
|        |     |       +------+ |  |        |
+---+----+     +-------+        |  +--------+
    |                           |
    +---------------------------+

The role of the “proxy” here is to allow its two upstream links to be used.  The criticism from the homenets slides about this being a network-layer problem may be somewhat valid, but the network layer doesn’t expose mid-network multipath topology to the transport layer and the network layer doesn’t solve this problem on its own.


Re the “off-net” proxy comments below, I was suggesting removing and adding addresses via MPTCP messages, rather than changing the address on packets.  The proxy can tell the client to add an address for it (I believe this can be done implicitly by sending a packet with one’s one address as the source) and remove the address for the server (an MPTCP option).  An MP-capable client will try out all of its interfaces against the proxy.  This is what I meant by leveraging the MITM to proxy all of the traffic.  As I have never actually tried this and missed whatever prior discussion there was at the design stage, I welcome comments on the list about whether or not this is a) correct and b) a feature.  I believe it to be both.  If this isn’t clear, I can try it again with a packet-flow diagram.

Similarly, I believe that in the two scenarios above where obth sides are MP-capable but unable, on their own, to leverage multiple paths mid-network, the proxy could add its own interfaces to both sides and pass traffic back and forth across it, effectively allowing for the multiple paths mid-network to be used.  Another option would be for the default client behaviour to be to test out multiple flows on the different network interfaces in order to probe out ECMP routes and kill them off if they don’t add value.  It’s a bit aggressive, but it’s an end-to-end solution.  Bittorrent clients used to be (and probably still are) much more aggressive than this.

Thoughts?

Jordan

From: Weixinpeng [mailto:[e-mail]]
Sent: August-05-14 11:19 PM
To: Jordan Melzer; [e-mail] Mailing List
Cc: Xiongchunshan (Sam); Zhulei (MBB Research); 邓灵莉/Lingli Deng
Subject: RE: MPTCP Proxy questions

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]<mailto:[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