Slashdot Mirror

Are there legitimate reasons for one device to have multiple public IPs simultaneously?

Yes, it's called being multihomed. Also MP-TCP/IPMP.

Linux and Apple iOS support it for starters, and it can greatly improve network performance.

There are also firewall devices which will balance traffic sourced across WANs.

Or may use a public IP address NAT pool, where different TCP connections from the same end host will be sourced from different public IPs, because they're different connection ID numbers.

There's a lot of multipath-related work being done right now, at the IETF, within OpenWRT, and independently.

We've been working on providing multiple routes automatically (disclaimer -- I'm a co-author). As to actually making use of the multiple routes, the solution that currently works best is MP-TCP, a set of kernel patches that allows TCP to use multiple routes simultaneously, with no modification to applications. Other solutions are SHIM6, which works below the transport layer, and Multipath Mosh, which works at the application layer.

I'm pretty confident we'll be able to have most of this stuff enabled by default in mainstream Linux distributions by the end of the year.

http://www.multipath-tcp.org/

of course, this requires the other end to support it, which it probably doesn't.

I've also considered selling "multipath vpn" service... the idea being that people with two DSL providers (and one dsl and one cable) provider would setup their gateway (or use a linux box that I sell them and manage) to send all packets out VPNs on both connections, to my own vpn endpoint in a datacenter. The idea being that then my server on the other end of that connection would take the first packet and send it on to it's destination. Assuming that my datacenter has a good connection, you would suffer less packet loss, and less latency.

My solution here would solve the problem if the problem is latency/loss on your last mile connection. It would not help at all if the problem was further along the connection, while multipath-tcp would

It is open source itself. troll.

http://multipath-tcp.org/pmwiki.php/Users/DoItYourself

Sorry to rain on your parade, but multipath TCP already does this...

So do MTCP developers see solutions for any of these problems on the horizon?

I'm in no way affiliated or knowledgeable in MPTCP - so I may be wrong - but from what I got from their presentation, MCTCP is not actually designed with the NFS-like usecase in mind (even if it may be used for such), but with the more "common" usecase of a mobile device able to use either/both cellular and WiFI networking.

The second thing that I saw as peculiar: it is not even supported by a network protocol (like IP is supporting TCP/UDP/SCTP/etc), but is supported by TCP. While it will have to deal somehow with re-assembling back a stream from packets streams over different paths, in itself it will be as prone to HOL as the bunch of underlying individual TCP streams which support those different paths.
That is, assuming the head-of-line is send on one path and that path involves a HOL-blocking, then it doesn't matter if the other paths have lower latencies, the entire original stream will be HOL-blocked

For those wanting to try, their install howto. Seems supported on:
1. Linux - either debian binaries or compiling from source. Both kernel module and UserSpace ways.
2. Virtualized Linuxes - their example is provided for Amazon EC2
3. Mac OSX - but, obviously, not on iPhone (I estimate slim chances for this to happen in the near future - it's a technology disruptive for the mobile providers income, as it makes the multi-pathing over cell/WiFi hot-spots transparent to end user)
4. Android (Opinion: see? This is one of the reasons relying on "walled gardens" is bad: you have to wait for the mercy of the garden lord to benefit from something).

Sort of: if both WiFi and cell channels are available (think: wandering in a shopping mall with public hotspots), one's Android mobile will use both of them in the same time to manage one's plot in Farmville (or to download the MP3's using that magnet from the PirateBay, or placing whatever buy/sell orders on stock exchange); if one walks out of WiFi spot coverage, the mobile will use only what's available - the cell connection.

Why I used android in my example? Well, it's a Linux kernel, the first implementation is already available. Besides, that should be great news for Google: their "goggles" will be able to transmit what you see much faster and reliable. What I understand from the MCTCP guys' presentation makes me believe MPTCP is able to cope with the use and drop from use of multiple dynamically IP addresses (are assigned to the many network devices one's mobile has): thus stepping from one hot-spot to another will not impede Google's capability to receive the data from your (their?) glasses.