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)
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.
Comments
This article is from last November. The Google group response linked from the post https://groups.google.com/a/chromium.org/forum/m/#!topic/pro... implied many performance problems would be fixed within 2 weeks. I wonder how it's improved.
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)
The internet does need a faster, multiplexed UDP streaming protocol with great encryption support.
Try MinimaLT: http://www.ethos-os.org/~solworth/minimalt-20131031.pdf
I guess QUIC isn't mature enough yet, I wish someone would do the same with SCTP.
Form https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb... over 13 revised version, and definitely going to improve this 2014
What makes QUIC easier to iterate? just the fact that it's not deployed anywhere and it's less accountable to "breaking things"?
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.
Google controls the client and the server.
How does SPDY fit into this? Is QUIC to UDP what SPDY is to HTTP?
Almost: 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...
There was a GDL session about QUIC the other night - https://developers.google.com/live/shows/4578775316561920
Slides here - https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb...