Belgian researchers at ICTEAM have announced a Multipath TCP (MPTCP) demonstration that's routed 50 Gbps of traffic across multiple different paths. While there wouldn't be much to crow about doing this at the physical layer, the ICTEAM researchers have squeezed this performance out of a system that needs to make various kinds …
... unlike channel bonding, this will run all available connections flat-out independently from each other, and from their website the data transfer can survive the drop-in/out of one or more of them. I wonder how long it will be before this becomes default? Even if they are pitching it at data centres right now, it's got benefits even down to mobile phones (like in areas covered by wifi and cellular, but with variable or marginal signals), where often the switch between them mid-transfer drops the file and a restart is needed. Good stuff, well done.
ship a Blu-Ray disk in five seconds
so what you're saying is the real data rate has gone down again!
GB != Gb
Bluray in five seconds? Not at that speed.
Though still pretty damned quick.
Re: GB != Gb
Would you please care to do the math for us to show how astronomically far you bring us from 5 seconds ? I'm curious.
Re: GB != Gb
Do it yourself. At the same time, look up "gigabyte" versus "gigabit".
It's still blindingly quick, mind.
Re: GB != Gb
So if time is still volume divided by speed, if a Blue Ray is still 25GB, if a byte is still 8 bits,
50Gb/s becomes 6.25 GB/s, right ? Or in a real world scenario, about 5 GB/second ? And 25GB / (5GB/s) is damned close to 5s. No ?
why not SCTP?
Multipath TCP sounds like an interesting thing. It however tries to solve a problem which has already been solved.
SCTP is available since over 10 years and has multipath built into its core. Its made for robustness so you can add / remove links as you want and the upper layer connection will not go down. So why not use an industry standard protocol which has been implemented in every major operating system and which has proven its working well already?
IETF has documents on both...
... and it seems the main reasons boil down to transparency. MPTCP is transparent to NAT and firewalls, and it presents a standard TCP face to applications. SCTP trips up on these two points, so isn't as easy to drop into the existing infrastructure. SCTP is a different transport that needs a new API and program support, whereas MPTCP looks like TCP to the upper layers. SCTP has features that are missing from TCP, which MPTCP provides.
Check www.ietf.org/mail-archive/web/multipathtcp/current/msg00072.html - "TCP modification vs switching to SCTP"
- Tricked by satire? Get all your news from Facebook? You're in luck, dummy
- Google straps on Jetpac: An app to find hipsters, women in foreign cities
- Updated Microsoft Azure goes TITSUP (Total Inability To Support Usual Performance)
- The Return of BSOD: Does ANYONE trust Microsoft patches?
- Munich considers dumping Linux for ... GULP ... Windows!