9 ms·

The Linux kernel MultiPath TCP project

124 points by TallGuyShort 14y ago

deleted 14y ago
[deleted]
mmastrac 14y ago
Since the site is having trouble: MultiPath TCP (MPTCP) is an effort towards enabling the simultaneous use of several IP-addresses/interfaces by a modification of TCP that presents a regular TCP interface to applications, while in fact spreading data across several subflows. Benefits of this include better resource utilization, better throughput and smoother reaction to failures. Slides - explaining MultiPath TCP - are available in .pdf and .pptx format. You can also have a look at our Google Techtalk about MPTCP. The IP Networking Lab is implementing MPTCP in the Linux Kernel and hosting it on this website for users, testers and developers. For questions, feedback,... please contact us at the mptcp-dev Mailing-List http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://www.youtube.com/watch?feature=player_embedded&v=VWN0ctPi5cw http://www.youtube.com/watch?feature=player_embedded&v=V...
- diroussel 14y ago
  Maybe the site should be using MultiPath TCP?
  - cpaasch 14y ago
    It is using MPTCP. We are just having right now an extremly high visitor-count. The server is only running on a tiny XEN-VM and thus it becomes overloaded.
- newman314 14y ago
  Has MPTCP been tested with CoDel?
  - obo 14y ago
    If you use Multipath TCP with a single interface through a router, it will behave like regular TCP (doing NewReno congestion control scheme)
Zash 14y ago
Whatever happened with SCTP?
- easytiger 14y ago
  I've never seen it mentioned outside the Stevens book and that it was supported in java 7
- peterwwillis 14y ago
  It's pretty slow and relegated to telcos and people who need HA multihoming.
  - jallmann 14y ago
    Is this slowness intrinsic to SCTP, or a matter of implementation?
    - Nrsolis 14y ago
      It's always a matter of implementation. SCTP is the solution to the problem that Multipath TCP is trying to solve. The biggest challenge is the penetration of TCP libraries vs. SCTP libraries.
      - peterwwillis 14y ago
        ...and that SCTP has higher overhead/complexity. But 'slowness' is an imprecise term. Some applications will perform much faster over TCP because the link is short, reliable, and the application only needs to stream data in-line. Heck, even with network loss you can see gains in TCP vs SCTP. Some applications will be faster with SCTP because of either the nature of how the application handles network data, or the properties of the network they're traveling over. But speed was never a design consideration of SCTP. If you want speed, use UDP. If you want something that's fast and "just works", use TCP, or this multipath TCP thing. If you want something designed to pass multiple independent unidirectional data messages across a single "connection" that can span multiple network paths and never miss a beat, use SCTP.
profquail 14y ago
There's also a Multipath TCP patch for FreeBSD 10-CURRENT: http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html Slides with more info: https://www.ietf.org/proceedings/84/slides/slides-84-mptcp-2 https://www.ietf.org/proceedings/84/slides/slides-84-mptcp-2
songgao 14y ago
Multi-path TCP is not only about throughput, but also about providing redundancy to improve stability. And to me, redundant stream is more attractive. It happens a lot when I am with my iPhone at boundary of a Wi-Fi network coverage, the network is very unstable with oscillations between Wi-Fi and 4G. The phone stays in the status with connected Wi-Fi but it's actually not working. If there was multi-path TCP, mobile devices can establish simultaneous streams on both Wi-Fi and 4G. When Wi-Fi is not responsive, the data stream can be automatically offloaded onto 4G seamlessly without causing latency in application layer. Another protocol that may achieve this is SCTP[1]. And it's been around for years[2]. But migrating existing services to another transport protocol is a challenge, which makes it difficult to adopt SCTP. I'm curious how multi-path handles this. Is it an extension to TCP that can handle backward compatibility with TCP, or yet another new transport protocol? [1]: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro... [2]: http://www.sctp.org/implementations.html http://www.sctp.org/implementations.html --- EDIT: More details about its design decisions and goals: http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://multipath-tcp.org/data/MultipathTCP-netsys.pdf
- aray 14y ago
  The tech talk (http://www.youtube.com/watch?v=VWN0ctPi5cw http://www.youtube.com/watch?v=VWN0ctPi5cw) explains how MPTCP can be implemented on top of existing TCP without interrupting the client, the server, or both.
- signa11 14y ago
  with two antennas (antennae ?) simultaneously broadcasting/receiving, i think battery life would be pretty low...
  - brokenparser 14y ago
    Bugs have antennae, radios have antennas (or aerials).
  - songgao 14y ago
    Not necessarily antennas. Antennas are in physical layer, not transport or network layer. 802.11n can have multiple antennas but if you are at the boundary of the coverage, multiple antennas won't help much. Multi-path TCP is more about multiple transport streams. Of course it would require separate antennas for Wi-Fi and 4G but that's already the case on current mobile devices. So nothing changes in this sense. It won't affect battery life much from aspect of antenna power consumption because you can only set 4G to backup link, and MPTCP won't offload to 4G until Wi-Fi is not responsive. If you are using full MPTCP (using two links all the time), then that's the tradeoff between performance and power consumption.
peterwwillis 14y ago
Are there some more detailed docs I haven't found? I have a dozen questions about how their protocol reacts to common problems. It seems like the kernel's just treating it as a "dumb" tcp connection that rx's and tx's on more than one interface. In this case you're taking the problems existing tcp connections have and multiplying them by the number of links. SCTP works around these problems and makes both the connection and the delivery of arbitrary messages more reliable, though seemingly at a heavy cost to performance.
- cpaasch 14y ago
  MPTCP creates multiple independent TCP subflows and distributes the data among these subflows. The receiver can then reorder the packets thanks to the additonal data-sequence number space.
- jlgaddis 14y ago
  There are several related RFCs[0], and the IETF's "Data Tracker" page for the MPTCP[1] working group has a lot of great documents as well. [0]: https://www.google.com/search?q=multipath+tcp+rfc https://www.google.com/search?q=multipath+tcp+rfc [1]: http://datatracker.ietf.org/wg/mptcp/ http://datatracker.ietf.org/wg/mptcp/
jacob019 14y ago
What a wonderful improvement to our old networking design. Can certainly see the benefits of redundancy, but the throughput advantage is huge. It will allow massively high throughput between servers by aggregating commodity hardware, scaling out instead of up. >1Gb server hardware is ridiculously expensive. I've tried interface bonding and the performance sucks. Now I can get a cheap 5Gb link using 5 dirt cheap NIC's. Awesome.
alexchamberlain 14y ago
Isn't this solving the wrong problem? Shouldn't IP support packets with multiple addresses?
- Nrsolis 14y ago
  How do you propose to modify all of the ASICs in routers that are optimized to do lookups on packet headers at the speeds they need to achieve? Routers today are doing 32x100GbE in a single chassis. That's an investment in hardware that isn't going to go away any time soon. SCTP already solved this problem. Multipath TCP is an also-ran.
  - vy8vWJlco 14y ago
    That's the clearest case I've seen for not buying "smart" hardware (firewalls, routers, etc) that know any more of the higher levels of the stack than necessary. I think the parent comment is valid though. If we wind up holding 2 or more TCP connections to multiplex, with failover, we are basically creating an overlay network that will have the same needs as the lower levels. Namely, routing, link cost metrics, fragmentation, etc... This is effectively what IP attempts to add on top of 802.3. With that in mind, it seems like it would be more faithful to the point (possible, if not practical) to use the Ethernet+IP stack directly on top of two TCP connections (providing simulated physical links), creating a throw-away network segment between two hosts that could re-use existing routing and bonding logic. I don't think Linux could handle that many virtual interfaces or taps, but that feels like the right place for it...
    - jlgaddis 14y ago
      The devices handling 32x100GbE connections are only able to do that because of the very specialized ASICs that have been custom developed. I'm not aware of any device that is software-based that could come remotely close to handling that about of traffic. Most current PC-level hardware has trouble w/ 2x10GbE links (if they can even support that).
      - 14y ago
jsaxton86 14y ago
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?
- dsr_ 14y ago
  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.
- songgao 14y ago
  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.
- trotsky 14y ago
  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.
  - obo 14y ago
    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 http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps for measurements showing Multipath TCP aggregating 6 10 Gbps interfaces.
- smutticus 14y ago
  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.
corbet 14y ago
LWN's overview: http://lwn.net/Articles/544399/ http://lwn.net/Articles/544399/
- aray 14y ago
  This is a great short summary, followed by the Tech Talk (on youtube) which goes into a bit more depth about the how and why of the design considerations. What isn't mentioned is basically, because the change is 10KLoC to the kernel (unprecedentedly huge change for just the functionality they added) it hasn't even been submitted yet, and mainline hasn't even considered it yet. I'd love to see it hit mainline, or parts of it start getting submitted, but the biggest thing will probably be re-writing the whole thing to have a much smaller impact on the kernel, while still providing the functionality they need (e.g. use the TCP backoff instead of their own, etc).
trotsky 14y ago
Seems like this is extremely wireless carrier friendly. Once you're able to do transparent tcp handoffs your ability to exploit unlicensed spectrum to offload traffic from your saturated licensed bands without a very obvious service interruption gets much easier. If you deploy devices set to auto associate with a whitelisted set of provider and partner hotspots as soon as the connection is up you can offload the bulk of it, letting you serve more customers with the same amount of spectrum. Addressing heavy demand locations with wifi is way cheaper than minicells or DAS systems and wouldn't involve any regulatory approval or backhaul requirements. I had to laugh when I saw the charts of LTE+wifi beating wifi alone in throughput. Even if the phone os was setup to try to exploit that, any wireless provider able to tie their own shoelaces is going to monitor multipath traffic like that and once they infer your alternate link is reasonably fast they'll start intentionally congesting their side of the path to force the bulk onto the local route. I wonder what sort of additional profiling this could enable. Right now my phone is on 3g and my dual homed wifi network. It seems possible that being able to see my traffic from wireless, wireline ip4 and via my ip6 tunnel provider at the same time along with each path's latency would leak more data than existing hard handoffs.
- yxhuvud 14y ago
  It will probably be usable from the perspective of a mobile carrier, but really, the hard part is the 'transparent tcp handoff' part. They already know all too well how nice it is to offload traffic to wifi. Two problems exist, and that most carriers don't have the servers or the wifi nets to support it nicely, and that mobile phones doesn't support automatic and transparent handover in a nice way (iOS 5 brought support though, so it is not all bad. Android support is mostly lacking though). Also, wifi already tend to be so much better that the bulk of the traffic would already go that way if possible without carrier interference.
  - trotsky 14y ago
    This is the main feature of the design, transparent handoff smoother than anything today, without any existing tcp connections dropping and faster throughput recovery. They demo skype handing off from 3g to wifi keeping the call alive and only suffering ~2seconds of delay during transition. The project has a number of working kernels for various android phones available. Carriers would widely deploy ISM nets or whitespace if the handoff was painless and your streaming video worst case lagged out a couple of seconds.
shawnreilly 14y ago
Awesome Project! I'm curious how this relates to the Mobile IP Standard (RFC 5944). Is Multipath TCP intended to Augment Mobile IP? Replace it? Not related at all? I would be very interested to hear from the Developers / Researches how they envision Multipath TCP working with (or replacing) other Standards. I would also be interested in hearing what needs to be done on the Client End for Multipath TCP to be supported; For example, say I was to build a Linux Server with the Multipath TCP enabled Kernel (to serve my App), would the Clients (likely Mobile Smartphones) also need to run an O/S with a Multipath TCP enabled Kernel? I'm assuming the answer is Yes, but I'm kind of hoping I missed something and the answer is No. Because if this is the case, then both Android and iOS would need to support Multipath TCP (which means this may not become mainstream for quite some time). Also, I noticed the referenced PDF said the Technology was already being Licensed (with a Non-Disclosure Agreement). This seems to imply it will not be Open Source. I checked the Git Repo, and don't see anything about this. Are the Developers / Researchers related to Multipath TCP intending to Open Source this? In any event, Thank you for this release, something fun to play with!
- mad_fab 14y ago
  1. The server and the client must be MPTCP-"aware", so the anwser is yes (but look, someone is talking about a proxy up there, it's a solution to avoid this problem). 2. I'm in the team working in the Linux Kernel implementation and yes this is open source! http://multipath-tcp.org/pmwiki.php?n=Users.DoItYourself http://multipath-tcp.org/pmwiki.php?n=Users.DoItYourself
  - shawnreilly 14y ago
    Thank you!!!
yoran 14y ago
What I especially like about this is that the project was developed in an academic context while being hugely beneficial to society. I mean, improving the performance of a fundamental protocol like TCP has huge effects. If only we had more academic research like this one! Btw, also cool that it was developed 15 minutes from my house.
zokier 14y ago
I wonder how difficult it would be to set up a MPTCP gateway/VPN, so that you could get the benefits of MPTCP all the time without requiring MPTCP support from the server you are connecting to. eg: +--------+ +---------+ +---------+ | Smart- +----WiFi----->| Gateway +---1Gb--->| Youtube | | phone +-----3G------>| | | | +--------+ +---------+ +---------+ MPTCP TCP
- trotsky 14y ago
  It looks like you can do that with a proxy approach, there are active ietf drafts concerning proxies: http://tools.ietf.org/html/draft-hampel-mptcp-proxies-anchors-00 http://tools.ietf.org/html/draft-hampel-mptcp-proxies-anchor... Encapsulating tcp/udp inside it probably doesn't work very due to conflicts between the layers of buffers and congestion control.
- mad_fab 14y ago
  Yes, a proxy solution is definitely a way to go, but to help the deployment only. In the end we shouldn't need those.
mad_fab 14y ago
If you want to try it; it's easy http://multipath-tcp.org/pmwiki.php?n=Users.HowToInstallMPTCP http://multipath-tcp.org/pmwiki.php?n=Users.HowToInstallMPTC... Also, we have a measurements campaign running, if you want to contribute ;) http://multipath-tcp.org/pmwiki.php?n=Users.AboutMeasures http://multipath-tcp.org/pmwiki.php?n=Users.AboutMeasures

124 points by TallGuyShort 14y ago

deleted 14y ago

[deleted]

Since the site is having trouble: MultiPath TCP (MPTCP) is an effort towards enabling the simultaneous use of several IP-addresses/interfaces by a modification of TCP that presents a regular TCP interface to applications, while in fact spreading data across several subflows. Benefits of this include better resource utilization, better throughput and smoother reaction to failures. Slides - explaining MultiPath TCP - are available in .pdf and .pptx format. You can also have a look at our Google Techtalk about MPTCP. The IP Networking Lab is implementing MPTCP in the Linux Kernel and hosting it on this website for users, testers and developers. For questions, feedback,... please contact us at the mptcp-dev Mailing-List http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://www.youtube.com/watch?feature=player_embedded&v=VWN0ctPi5cw http://www.youtube.com/watch?feature=player_embedded&v=V...

diroussel 14y ago
Maybe the site should be using MultiPath TCP?
- cpaasch 14y ago
  It is using MPTCP. We are just having right now an extremly high visitor-count. The server is only running on a tiny XEN-VM and thus it becomes overloaded.
newman314 14y ago
Has MPTCP been tested with CoDel?
- obo 14y ago
  If you use Multipath TCP with a single interface through a router, it will behave like regular TCP (doing NewReno congestion control scheme)

Zash 14y ago

Whatever happened with SCTP?

easytiger 14y ago
I've never seen it mentioned outside the Stevens book and that it was supported in java 7
peterwwillis 14y ago
It's pretty slow and relegated to telcos and people who need HA multihoming.
- jallmann 14y ago
  Is this slowness intrinsic to SCTP, or a matter of implementation?
  - Nrsolis 14y ago
    It's always a matter of implementation. SCTP is the solution to the problem that Multipath TCP is trying to solve. The biggest challenge is the penetration of TCP libraries vs. SCTP libraries.
    - peterwwillis 14y ago
      ...and that SCTP has higher overhead/complexity. But 'slowness' is an imprecise term. Some applications will perform much faster over TCP because the link is short, reliable, and the application only needs to stream data in-line. Heck, even with network loss you can see gains in TCP vs SCTP. Some applications will be faster with SCTP because of either the nature of how the application handles network data, or the properties of the network they're traveling over. But speed was never a design consideration of SCTP. If you want speed, use UDP. If you want something that's fast and "just works", use TCP, or this multipath TCP thing. If you want something designed to pass multiple independent unidirectional data messages across a single "connection" that can span multiple network paths and never miss a beat, use SCTP.

profquail 14y ago

There's also a Multipath TCP patch for FreeBSD 10-CURRENT: http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html Slides with more info: https://www.ietf.org/proceedings/84/slides/slides-84-mptcp-2 https://www.ietf.org/proceedings/84/slides/slides-84-mptcp-2

songgao 14y ago

Multi-path TCP is not only about throughput, but also about providing redundancy to improve stability. And to me, redundant stream is more attractive. It happens a lot when I am with my iPhone at boundary of a Wi-Fi network coverage, the network is very unstable with oscillations between Wi-Fi and 4G. The phone stays in the status with connected Wi-Fi but it's actually not working. If there was multi-path TCP, mobile devices can establish simultaneous streams on both Wi-Fi and 4G. When Wi-Fi is not responsive, the data stream can be automatically offloaded onto 4G seamlessly without causing latency in application layer. Another protocol that may achieve this is SCTP[1]. And it's been around for years[2]. But migrating existing services to another transport protocol is a challenge, which makes it difficult to adopt SCTP. I'm curious how multi-path handles this. Is it an extension to TCP that can handle backward compatibility with TCP, or yet another new transport protocol? [1]: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro... [2]: http://www.sctp.org/implementations.html http://www.sctp.org/implementations.html --- EDIT: More details about its design decisions and goals: http://multipath-tcp.org/data/MultipathTCP-netsys.pdf http://multipath-tcp.org/data/MultipathTCP-netsys.pdf

aray 14y ago
The tech talk (http://www.youtube.com/watch?v=VWN0ctPi5cw http://www.youtube.com/watch?v=VWN0ctPi5cw) explains how MPTCP can be implemented on top of existing TCP without interrupting the client, the server, or both.
signa11 14y ago
with two antennas (antennae ?) simultaneously broadcasting/receiving, i think battery life would be pretty low...
- brokenparser 14y ago
  Bugs have antennae, radios have antennas (or aerials).
- songgao 14y ago
  Not necessarily antennas. Antennas are in physical layer, not transport or network layer. 802.11n can have multiple antennas but if you are at the boundary of the coverage, multiple antennas won't help much. Multi-path TCP is more about multiple transport streams. Of course it would require separate antennas for Wi-Fi and 4G but that's already the case on current mobile devices. So nothing changes in this sense. It won't affect battery life much from aspect of antenna power consumption because you can only set 4G to backup link, and MPTCP won't offload to 4G until Wi-Fi is not responsive. If you are using full MPTCP (using two links all the time), then that's the tradeoff between performance and power consumption.

peterwwillis 14y ago

Are there some more detailed docs I haven't found? I have a dozen questions about how their protocol reacts to common problems. It seems like the kernel's just treating it as a "dumb" tcp connection that rx's and tx's on more than one interface. In this case you're taking the problems existing tcp connections have and multiplying them by the number of links. SCTP works around these problems and makes both the connection and the delivery of arbitrary messages more reliable, though seemingly at a heavy cost to performance.

cpaasch 14y ago
MPTCP creates multiple independent TCP subflows and distributes the data among these subflows. The receiver can then reorder the packets thanks to the additonal data-sequence number space.
jlgaddis 14y ago
There are several related RFCs[0], and the IETF's "Data Tracker" page for the MPTCP[1] working group has a lot of great documents as well. [0]: https://www.google.com/search?q=multipath+tcp+rfc https://www.google.com/search?q=multipath+tcp+rfc [1]: http://datatracker.ietf.org/wg/mptcp/ http://datatracker.ietf.org/wg/mptcp/

jacob019 14y ago

What a wonderful improvement to our old networking design. Can certainly see the benefits of redundancy, but the throughput advantage is huge. It will allow massively high throughput between servers by aggregating commodity hardware, scaling out instead of up. >1Gb server hardware is ridiculously expensive. I've tried interface bonding and the performance sucks. Now I can get a cheap 5Gb link using 5 dirt cheap NIC's. Awesome.

alexchamberlain 14y ago

Isn't this solving the wrong problem? Shouldn't IP support packets with multiple addresses?

Nrsolis 14y ago
How do you propose to modify all of the ASICs in routers that are optimized to do lookups on packet headers at the speeds they need to achieve? Routers today are doing 32x100GbE in a single chassis. That's an investment in hardware that isn't going to go away any time soon. SCTP already solved this problem. Multipath TCP is an also-ran.
- vy8vWJlco 14y ago
  That's the clearest case I've seen for not buying "smart" hardware (firewalls, routers, etc) that know any more of the higher levels of the stack than necessary. I think the parent comment is valid though. If we wind up holding 2 or more TCP connections to multiplex, with failover, we are basically creating an overlay network that will have the same needs as the lower levels. Namely, routing, link cost metrics, fragmentation, etc... This is effectively what IP attempts to add on top of 802.3. With that in mind, it seems like it would be more faithful to the point (possible, if not practical) to use the Ethernet+IP stack directly on top of two TCP connections (providing simulated physical links), creating a throw-away network segment between two hosts that could re-use existing routing and bonding logic. I don't think Linux could handle that many virtual interfaces or taps, but that feels like the right place for it...
  - jlgaddis 14y ago
    The devices handling 32x100GbE connections are only able to do that because of the very specialized ASICs that have been custom developed. I'm not aware of any device that is software-based that could come remotely close to handling that about of traffic. Most current PC-level hardware has trouble w/ 2x10GbE links (if they can even support that).
    - 14y ago

jsaxton86 14y ago

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?

dsr_ 14y ago
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.
songgao 14y ago
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.
trotsky 14y ago
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.
- obo 14y ago
  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 http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps for measurements showing Multipath TCP aggregating 6 10 Gbps interfaces.
smutticus 14y ago
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.

corbet 14y ago

LWN's overview: http://lwn.net/Articles/544399/ http://lwn.net/Articles/544399/

aray 14y ago
This is a great short summary, followed by the Tech Talk (on youtube) which goes into a bit more depth about the how and why of the design considerations. What isn't mentioned is basically, because the change is 10KLoC to the kernel (unprecedentedly huge change for just the functionality they added) it hasn't even been submitted yet, and mainline hasn't even considered it yet. I'd love to see it hit mainline, or parts of it start getting submitted, but the biggest thing will probably be re-writing the whole thing to have a much smaller impact on the kernel, while still providing the functionality they need (e.g. use the TCP backoff instead of their own, etc).

trotsky 14y ago

Seems like this is extremely wireless carrier friendly. Once you're able to do transparent tcp handoffs your ability to exploit unlicensed spectrum to offload traffic from your saturated licensed bands without a very obvious service interruption gets much easier. If you deploy devices set to auto associate with a whitelisted set of provider and partner hotspots as soon as the connection is up you can offload the bulk of it, letting you serve more customers with the same amount of spectrum. Addressing heavy demand locations with wifi is way cheaper than minicells or DAS systems and wouldn't involve any regulatory approval or backhaul requirements. I had to laugh when I saw the charts of LTE+wifi beating wifi alone in throughput. Even if the phone os was setup to try to exploit that, any wireless provider able to tie their own shoelaces is going to monitor multipath traffic like that and once they infer your alternate link is reasonably fast they'll start intentionally congesting their side of the path to force the bulk onto the local route. I wonder what sort of additional profiling this could enable. Right now my phone is on 3g and my dual homed wifi network. It seems possible that being able to see my traffic from wireless, wireline ip4 and via my ip6 tunnel provider at the same time along with each path's latency would leak more data than existing hard handoffs.

yxhuvud 14y ago
It will probably be usable from the perspective of a mobile carrier, but really, the hard part is the 'transparent tcp handoff' part. They already know all too well how nice it is to offload traffic to wifi. Two problems exist, and that most carriers don't have the servers or the wifi nets to support it nicely, and that mobile phones doesn't support automatic and transparent handover in a nice way (iOS 5 brought support though, so it is not all bad. Android support is mostly lacking though). Also, wifi already tend to be so much better that the bulk of the traffic would already go that way if possible without carrier interference.
- trotsky 14y ago
  This is the main feature of the design, transparent handoff smoother than anything today, without any existing tcp connections dropping and faster throughput recovery. They demo skype handing off from 3g to wifi keeping the call alive and only suffering ~2seconds of delay during transition. The project has a number of working kernels for various android phones available. Carriers would widely deploy ISM nets or whitespace if the handoff was painless and your streaming video worst case lagged out a couple of seconds.

shawnreilly 14y ago

Awesome Project! I'm curious how this relates to the Mobile IP Standard (RFC 5944). Is Multipath TCP intended to Augment Mobile IP? Replace it? Not related at all? I would be very interested to hear from the Developers / Researches how they envision Multipath TCP working with (or replacing) other Standards. I would also be interested in hearing what needs to be done on the Client End for Multipath TCP to be supported; For example, say I was to build a Linux Server with the Multipath TCP enabled Kernel (to serve my App), would the Clients (likely Mobile Smartphones) also need to run an O/S with a Multipath TCP enabled Kernel? I'm assuming the answer is Yes, but I'm kind of hoping I missed something and the answer is No. Because if this is the case, then both Android and iOS would need to support Multipath TCP (which means this may not become mainstream for quite some time). Also, I noticed the referenced PDF said the Technology was already being Licensed (with a Non-Disclosure Agreement). This seems to imply it will not be Open Source. I checked the Git Repo, and don't see anything about this. Are the Developers / Researchers related to Multipath TCP intending to Open Source this? In any event, Thank you for this release, something fun to play with!

mad_fab 14y ago
1. The server and the client must be MPTCP-"aware", so the anwser is yes (but look, someone is talking about a proxy up there, it's a solution to avoid this problem). 2. I'm in the team working in the Linux Kernel implementation and yes this is open source! http://multipath-tcp.org/pmwiki.php?n=Users.DoItYourself http://multipath-tcp.org/pmwiki.php?n=Users.DoItYourself
- shawnreilly 14y ago
  Thank you!!!

yoran 14y ago

What I especially like about this is that the project was developed in an academic context while being hugely beneficial to society. I mean, improving the performance of a fundamental protocol like TCP has huge effects. If only we had more academic research like this one! Btw, also cool that it was developed 15 minutes from my house.

zokier 14y ago

I wonder how difficult it would be to set up a MPTCP gateway/VPN, so that you could get the benefits of MPTCP all the time without requiring MPTCP support from the server you are connecting to. eg: +--------+ +---------+ +---------+ | Smart- +----WiFi----->| Gateway +---1Gb--->| Youtube | | phone +-----3G------>| | | | +--------+ +---------+ +---------+ MPTCP TCP

trotsky 14y ago
It looks like you can do that with a proxy approach, there are active ietf drafts concerning proxies: http://tools.ietf.org/html/draft-hampel-mptcp-proxies-anchors-00 http://tools.ietf.org/html/draft-hampel-mptcp-proxies-anchor... Encapsulating tcp/udp inside it probably doesn't work very due to conflicts between the layers of buffers and congestion control.
mad_fab 14y ago
Yes, a proxy solution is definitely a way to go, but to help the deployment only. In the end we shouldn't need those.

mad_fab 14y ago

If you want to try it; it's easy http://multipath-tcp.org/pmwiki.php?n=Users.HowToInstallMPTCP http://multipath-tcp.org/pmwiki.php?n=Users.HowToInstallMPTC... Also, we have a measurements campaign running, if you want to contribute ;) http://multipath-tcp.org/pmwiki.php?n=Users.AboutMeasures http://multipath-tcp.org/pmwiki.php?n=Users.AboutMeasures