Google is pioneering a protocol it calls QUIC (Quick UDP Internet Connections, pronounced quick), which makes several improvements to modern networking. It’s exciting because it’s built into Chrome and there’s a lot to learn from the years of research by Google’s expert dev team.
QUIC is hugely successful in enhancing network connections, especially to websites. It doesn’t require extensive RTT’s to retrieve website data and implements a whole new world of performance enhancements such as built in compression and built in FEC . Webpages load faster with QUIC, even in environments with packet loss. Some other benefits of QUIC are unique identifiers instead of IP Addresses, meaning the session can resume from a new network interface or IP Address.
And since we’re all about multipathing here at vUnity, the first thing on our minds was, of course… How we can make QUIC multipath! So, is it possible? How hard would it be to add these features to create a new QUIC Multipath? Could this mean a commercially supported alternative to MPTCP?
Probably all future protocols will have multipath support… But, QUIC isn’t a transport-layer protocol like MPTCP and it would be the first time a session-layer protocol did multipath. Since QUIC is an extension of Chrome, it doesn’t have direct access to interfaces depends on the operating systems implementation of UDP. There’s also no definitive answers on how to best implement bonding even when we’re talking about transport layer protocols. MPTCP is the “right” way to do multipath, but even MPTCP has isn’t complete with a packet scheduler to bonding links of drastically different latencies. These challenges, as well as the new challenges in the development of a first-ever session layer bonding application makes the QUIC Multipath a job for an experienced team.
QUIC would need (among other things) the following to multipath:
1. Congestion control algorithms for individual links
2. Coding of a packet scheduler (i.e. how much traffic to put out each interface)
3. A method to configure OS routing tables to route traffic to and from QUIC.
4. Direct access to the operating systems network interfaces (IP/MAC/GW/Etc.)
Multipath QUIC would mean a revolution to the networked world. It would be awesome to work alongside the community to build a QUIC Multipath. We were told Google will be taking a more serious look into developing QUIC Multipath later this year. If anyone has any other information or insight, please don’t hesitate to contact us!