News for hackers. Stuff that matters.
Re:The Linux kernel MultiPath TCP project by jsaxton86 on Friday April 19, 2013 @01:31PM (#5577765)
What advantages does this have over existing link aggregation implementations?

Edit: one advantage I can think of is you don't have to ask your users to set up a bond0 interface, for example. Any other advantages?

Re:The Linux kernel MultiPath TCP project by mad_fab on Saturday April 20, 2013 @06:13AM (#5580946)
The main advantage is: the congestion control! With MPTCP you could deal with congestion at the transport level. Meaning, if you have three flow MPTCP will select the best (less RTT, space in the win, etc..) link to send datas, where the bonding is just balancing with a XOR or a round robin. This is definitely a big advantage, not only in datacenters but if you have a 3G and a WiFi connection. More about the congestion control: http://tools.ietf.org/html/draft-ietf-mptcp-congestion
Re:The Linux kernel MultiPath TCP project by trotsky on Friday April 19, 2013 @03:22PM (#5578258)
Current layer 2 link aggregation is effective for lots of connections with different source/destination pairs because the switches have limited resources and require simple schemes. It works fine for public servers and transit aggregation, but it's very bad at local aggregation to speed up limited connections like trying to bond multiple 1gig ports between san/nas and a server for example.
Re:The Linux kernel MultiPath TCP project by obo on Saturday April 20, 2013 @07:13AM (#5581031)
Exactly. With Multipath TCP, a single TCP connection can benefit from multiple interfaces, which is not the case with bonding techniques. See http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps for measurements showing Multipath TCP aggregating 6 10 Gbps interfaces.
Re:The Linux kernel MultiPath TCP project by songgao on Friday April 19, 2013 @03:05PM (#5578177)
I've never used link aggregation, but it seems that link aggregation would require routers/switches support. And it can be disabled. But this MPTCP assembles multi-path streams using normal TCP connections, which are enabled on all devices that works with Internet. I guess the advantage here is MPTCP is more practical.
Re:The Linux kernel MultiPath TCP project by smutticus on Friday April 19, 2013 @05:09PM (#5578725)
Link-aggregation(LAG) is typically only done with links of the same speeds. MPTCP instead seems to be focused specifically on links of differing speeds. LAGs are definied by such standards as IEEE 802.1ag and are typically done at layer 1.5. They are a link level protocol. MPTCP is a layer 4 protocol and so does not require the directly connected device to be aware of it.
Re:The Linux kernel MultiPath TCP project by dsr_ on Friday April 19, 2013 @02:23PM (#5577983)
It's not restricted to a single hop; it provides redundancy over completely different paths. As demonstrated, they used ethernet, wifi and a cell radio, then removed any two of them while keeping the packets flowing. That's pretty impressive.
Re:The Linux kernel MultiPath TCP project by jlgaddis on Friday April 19, 2013 @06:44PM (#5579053)
LAG/MLAG operates at a lower layer (datalink) than IP and TCP (transport).

Because of that, LAG/MLAG can support more than just MPTCP and, in fact, the two aren't mutually exclusive.