Wow, I didn't think this could be done this transparently. This has the potential to be huge, if it's adopted. Crossing my fingers.
Specifically, I can't wait till I can actually use my phone as I'm walking away from a Wi-Fi hotspot (which is very common).
Edit: As noted in another comment, Apple apparently adopted MPTCP for Siri in iOS7! http://support.apple.com/kb/HT5977 Now we just have to wait for every server on the internet to support it. :-/
Well, I'm not sure if I mis-configured something, but I was not able to trigger MPTCP traffic from iOS 7. I was using a MPTCP enabled Linux box, serving video files over HTTP. But all I saw from iOS was traditional single-path TCP. If my tests were conducted correctly, Apple might have disabled MPTCP for third-party services.
I was actually working on server-client software in Go to allow multihoming IP connections.[0] The original use case was to load-balance packets across wi-fi + 3G or other connections. It's not quite user-friendly yet, but with a little work it could use new connections as they come up (maybe poll ifconfig?).
You'd of course need to install the software on your outside server that will forward packets for you, but a DO droplet would be great for that. It'd also work for the case where your router is your server and you shift between wired and wireless.
Offtopic warning: the following has nothing to do with MPTCP.
I was wondering why SCTP [1] never took off. It sounds like a shoe-in for HTTP and other web-based protocols. All the application level protocols that must come up with a mechanism for communicating the length of the payload... Why not have that built into the transport protocol? Of course you do have streaming to deal with, but streaming can still be solved with SCTP same as what we do now in HTTP: say this is a stream, so the client keeps reading.
Then I saw it: NAT. Fucking NAT strikes again. Once IPv6 takes over [2], I hope to never speak those three letters in that sequence again.
An interesting feature here is that in theory you could have a host with two 20M connections and a host with a 10M connection and a 30M connection and by using more than two subflows they could communicate at 40M.
I wonder if they've considered what happens with this for hosts that are very multihomed. If you have two hosts that each have 25 addresses, do you actually want 625 subflows? Or do you want to countenance the possibility that only one address on each host is fast and you didn't create a subflow between them because you didn't try every possibility?
I'm using it to bond two 4G interfaces (Verizon + Clearwire) on the train at this very moment. Need to remember to bring a USB wifi adapter next time so I can add the Amtrak wifi to the mix!
No SigmaVPN, because it's lacking support for a major platform out there.
Maybe tinc-vpn would be an option though.
No bonding on Android, since there's No App For That (at least I know of none?). Doing that in a terminal, on a phone, is really the last thing I'd like to play with.
How does one set bonding for SigmaVPN? Is it as simple as creating multiple tun devices and then bonding them together with ifenslave? Or is it more involved then that?
> The measurements revealed that protocol designers can no longer assume that the Internet is transparent when designing a TCP extension; and no TCP extension can assume that a single field of the TCP header will reach the destination without any modification.
The Net Neutrality situation is worse than I thought.
We were really surprised by what we found - especially just how prevalent middleboxes that are aware of and modify TCP packets actually are. The results are a couple of years old now, so things have probably got even worse. But that's mostly separate from the network neutrality debate. You don't need to modify packets to shape them - our methodology would not have revealed shaping.
Could this be applied within a NATed network without cooperation of the server outside the NAT? That way you could at least move your laptop back and forth between wired and wireless connections inside the office or home without breaking all your sessions.
Yes! The design of MPTCP specifically takes that into considerations since most of hosts are behind a NAT. It basically initiates may normal TCP connections as subflows. All the middle-boxes would see normal TCP connections while the two MPTCP-aware endpoints split/aggregate traffic using multiple subflows.
Sometimes I regret all the time and effort I put into network protocols. Particularly when I look at some new advance and it just makes me sad.
Sure, you could design some new protocol. Except that it could never actually work in practice---the infrastructure will see to that. Instead, it's better to treat a TCP connection with a fixed port of 80 (or 443, if you're so inclined) as precious and slather on some more bandaids until it stops not working at all.
Multipath TCP becomes really useful when coupled with source-sensitive routing. Some on-going work on this topic (based on the Babel routing protocol for mesh networks):
For the server side, why not just use SCTP which not only has multi-homing, but also reliable datagram messaging? Are there issues using it intra-datacenter?
> "Multihoming is becoming the norm instead of the exception"
Well - at least Multipath TCP spared us from solving that use-case with generalized BPG usage on mobile devices. Too bad, it could have been fun - in a way...
You likely don't understand "BGP" at a fundamental level. Considering you need a well known and agreed peering agreement - BGP is not designed for use on end-points in any dynamic peering fashion. It is an external "routing" protocol. Hosts leverage "routed" protocols (e.g. IP). But, say, in our fantasy world your iPhone could take a full Internet routing table (it can't). BGP is not designed to deal with very long prefixes (/32 host routes) and in fact most peering agreements will flat out block prefixes longer than a /24 based on policy.
BGP on mobile devices would never have been fun and never worked. If each mobile host that came online required BGP around the world to update it's FIB we'd be in a world of hurt (partially because you can't aggregate host routes as you don't know where they're originating transit from). The more routes you add to BGP the worse BGP becomes from a maintainability perspective.
TL;DR
Don't mention BGP on mobile devices as fun to any network engineer unless you're using the reference as a bad joke.
[+] [-] nardi|12 years ago|reply
Specifically, I can't wait till I can actually use my phone as I'm walking away from a Wi-Fi hotspot (which is very common).
Edit: As noted in another comment, Apple apparently adopted MPTCP for Siri in iOS7! http://support.apple.com/kb/HT5977 Now we just have to wait for every server on the internet to support it. :-/
[+] [-] songgao|12 years ago|reply
[+] [-] erjiang|12 years ago|reply
You'd of course need to install the software on your outside server that will forward packets for you, but a DO droplet would be great for that. It'd also work for the case where your router is your server and you shift between wired and wireless.
[0] https://github.com/erjiang/tuntuntun
[+] [-] IgorPartola|12 years ago|reply
I was wondering why SCTP [1] never took off. It sounds like a shoe-in for HTTP and other web-based protocols. All the application level protocols that must come up with a mechanism for communicating the length of the payload... Why not have that built into the transport protocol? Of course you do have streaming to deal with, but streaming can still be solved with SCTP same as what we do now in HTTP: say this is a stream, so the client keeps reading.
Then I saw it: NAT. Fucking NAT strikes again. Once IPv6 takes over [2], I hope to never speak those three letters in that sequence again.
[1] http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...
[2] https://www.google.com/intl/en/ipv6/statistics.html
[+] [-] pinhead|12 years ago|reply
https://www.usenix.org/conference/nsdi11/design-implementati...
https://www.usenix.org/conference/nsdi12/technical-sessions/...
Others: http://multipath-tcp.org/pmwiki.php/Researchers/References
[+] [-] AnthonyMouse|12 years ago|reply
I wonder if they've considered what happens with this for hosts that are very multihomed. If you have two hosts that each have 25 addresses, do you actually want 625 subflows? Or do you want to countenance the possibility that only one address on each host is fast and you didn't create a subflow between them because you didn't try every possibility?
[+] [-] sergiosgc|12 years ago|reply
[+] [-] ClashTheBunny|12 years ago|reply
[0] http://frozenriver.net/SigmaVPN
[+] [-] seatonist|12 years ago|reply
I'm using it to bond two 4G interfaces (Verizon + Clearwire) on the train at this very moment. Need to remember to bring a USB wifi adapter next time so I can add the Amtrak wifi to the mix!
edit: No linux support though. :/
[+] [-] darklajid|12 years ago|reply
Maybe tinc-vpn would be an option though.
No bonding on Android, since there's No App For That (at least I know of none?). Doing that in a terminal, on a phone, is really the last thing I'd like to play with.
Or did I misunderstand your second suggestion?
[+] [-] jhgg|12 years ago|reply
[+] [-] sp332|12 years ago|reply
[+] [-] liotier|12 years ago|reply
iOS7, released on September 18, 2013 is the first large scale commercial deployment of Multipath TCP - http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013...
[+] [-] loup-vaillant|12 years ago|reply
The Net Neutrality situation is worse than I thought.
[+] [-] mhandley|12 years ago|reply
[+] [-] Scramblejams|12 years ago|reply
[+] [-] songgao|12 years ago|reply
[0] http://tools.ietf.org/html/rfc6824#page-51
[+] [-] mcguire|12 years ago|reply
Sure, you could design some new protocol. Except that it could never actually work in practice---the infrastructure will see to that. Instead, it's better to treat a TCP connection with a fixed port of 80 (or 443, if you're so inclined) as precious and slather on some more bandaids until it stops not working at all.
[+] [-] kerneis|12 years ago|reply
http://www.pps.univ-paris-diderot.fr/~boutier/source-specifi...
[+] [-] vbit|12 years ago|reply
[+] [-] lucian1900|12 years ago|reply
TCP multihoming would work for most protocols/apps out there.
[+] [-] liotier|12 years ago|reply
Well - at least Multipath TCP spared us from solving that use-case with generalized BPG usage on mobile devices. Too bad, it could have been fun - in a way...
[+] [-] windexh8er|12 years ago|reply
BGP on mobile devices would never have been fun and never worked. If each mobile host that came online required BGP around the world to update it's FIB we'd be in a world of hurt (partially because you can't aggregate host routes as you don't know where they're originating transit from). The more routes you add to BGP the worse BGP becomes from a maintainability perspective.
TL;DR Don't mention BGP on mobile devices as fun to any network engineer unless you're using the reference as a bad joke.
[+] [-] worklogin|12 years ago|reply
[+] [-] jbb555|12 years ago|reply