A 50 Gbps Connection With Multipath TCP 150
First time accepted submitter Olivier Bonaventure writes "The TCP protocol is closely coupled with the underlying IP protocol. Once a TCP connection has been established through one IP address, the other packets of the connection must be sent from this address. This makes mobility and load balancing difficult. Multipath TCP is a new extension that solves these old problems by decoupling TCP from the underlying IP. A Multipath TCP connection can send packets over several interfaces/addresses simultaneously while remaining backward compatible with existing TCP applications. Multipath TCP has several use cases, including smartphones that can use both WiFi and 3G, or servers that can pool multiple high-speed interfaces. Christoph Paasch, Gregory Detal and their colleagues who develop the implementation of Multipath TCP in the Linux kernel have achieved 50 Gbps for a single TCP connection [note: link has source code and technical details] by pooling together six 10 Gbps interfaces."
Re:Request For Comments (Score:5, Interesting)
What sort of security concerns are you thinking of?
An attacker who controls one of the paths can obviously modify, replace, delay or delete portions of the stream which are multiplexed onto that path. Such an attacker could probably perform a DoS that would shut down the entire stream (disclaimer: I haven't read the details). But of course ordinary TCP is subject to all the same attacks, if the attacker has control of the path that carries it. In many cases an attacker without control of the path can also execute DoS attacks against TCP (e.g. sending RSTs).
I'm not saying there aren't any new vulnerabilities exposed, but I'm not seeing where they would lie. TCP is not secure in any useful sense, so it's hard to see how MTCP could be worse.
Re:Standard DSL + custom host file = 50gbps connec (Score:2, Interesting)
or maybe we could just filter comments based on length or number of links. >1000 words or >20 links
Re:Uh, I get this with lacp (Score:4, Interesting)
Not unless they changed something recently. Read http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf [ieee802.org] LACP requires that any conversation goes over only a single link at a time. Out of order packets can do some rather nasty things to tcp connections and adding buffers to correct that does nasty things to voip / other latency sensitive bits. Sure linux boxes have some non standard modes that might work if you sitting one switch away but that's not conforming to the LACP spec. They also do not scale as they require keeping state of every session running through them. What networking gear are you using?
Re:API support (Score:5, Interesting)
Yep. And this is a godsend, in some ways: "multipath NFS" should soon be inexplicably easier to accomplish on a high scale. I will be able to put in a single redundant/HA host with 8 1GBps NICs and not have to worry about setting up multipath on each of the individual VM heads I run. This has the significant advantage of not being stuck with immobile "SAN storage" LUNs or, for that matter, "enterprise" hardware vendors which can't bring the reliability their hardware close to anything near what generic Intel or even bcm network cards can provide.
All the better if I've got unified storage at the backend with abstracted paths (eg. lustre, unionfs).
And from the looks of it, it's designed 'forward' - it's going to be MUCH easier to do HA TCP connectivity with this than it is with misc. service level TCP (eg. heartbeat), particularly when you're dealing with (mostly) centrally assigned IPv6 addresses. Awesome.
Granted, from the looks of it, we may have to wait for switch support first, too... I didn't read that carefully.