The fact that it isn't deployed certainly makes it easier. It has protocol version negotiation built in too, so it can avoid "breaking things" by falling back to TCP if needed.
QUIC is a great idea in general, but in my personal opinion, it has a lot of weird Google-specific, application- and HTTP-level hacks hanging off of it -- e.g. 'orbit' server state in Snap Start -- and a singular focus on web service/browser receipt and how the thing works with SPDY, and that's unfortunate.
The internet does need a faster, multiplexed UDP streaming protocol with great encryption support. If only it weren't tied to the assumption of odd infrastructure.
(edit: I understand why Google's doing it this way; just wish they started from the bottom layer and worked their way up, rather than starting on all layers and working around to the sides)
11 comments
[ 2.9 ms ] story [ 28.8 ms ] threadAlmost: QUIC improvements are supposed to be put back in TCP, not in UDP. See the FAQ [0]
[0] https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...
Slides here - https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb...
The internet does need a faster, multiplexed UDP streaming protocol with great encryption support. If only it weren't tied to the assumption of odd infrastructure.
(edit: I understand why Google's doing it this way; just wish they started from the bottom layer and worked their way up, rather than starting on all layers and working around to the sides)
Try MinimaLT: http://www.ethos-os.org/~solworth/minimalt-20131031.pdf