4 ms·

Taking Google’s QUIC For a Test Drive (2013)

26 points by babawere 13y ago

shacharz 13y ago
I guess QUIC isn't mature enough yet, I wish someone would do the same with SCTP.
- babawere 13y ago
  Form https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb6wRlm79gN6hnPFHByEXXptk/present#slide=id.g2af01bdeb_050 https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb... over 13 revised version, and definitely going to improve this 2014
  - shacharz 13y ago
    What makes QUIC easier to iterate? just the fact that it's not deployed anywhere and it's less accountable to "breaking things"?
    - JulianMorrison 13y ago
      Google controls the client and the server.
    - loganfsmyth 13y ago
      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.
jamesmoss 13y ago
How does SPDY fit into this? Is QUIC to UDP what SPDY is to HTTP?
- rakoo 13y ago
  > 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/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/mobilebasic?pli=1 https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...
- youngtaff 13y ago
  There was a GDL session about QUIC the other night - https://developers.google.com/live/shows/4578775316561920 https://developers.google.com/live/shows/4578775316561920 Slides here - https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb6wRlm79gN6hnPFHByEXXptk/present#slide=id.g176a9a2e9_0143 https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb...
drp 13y ago
This article is from last November. The Google group response linked from the post https://groups.google.com/a/chromium.org/forum/m/#!topic/proto-quic/xoooxrixCis 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.
felixgallo 13y ago
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)
- wmf 13y ago
  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 http://www.ethos-os.org/~solworth/minimalt-20131031.pdf

26 points by babawere 13y ago

shacharz 13y ago

I guess QUIC isn't mature enough yet, I wish someone would do the same with SCTP.

babawere 13y ago
Form https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb6wRlm79gN6hnPFHByEXXptk/present#slide=id.g2af01bdeb_050 https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb... over 13 revised version, and definitely going to improve this 2014
- shacharz 13y ago
  What makes QUIC easier to iterate? just the fact that it's not deployed anywhere and it's less accountable to "breaking things"?
  - JulianMorrison 13y ago
    Google controls the client and the server.
  - loganfsmyth 13y ago
    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.

jamesmoss 13y ago

How does SPDY fit into this? Is QUIC to UDP what SPDY is to HTTP?

rakoo 13y ago
> 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/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/mobilebasic?pli=1 https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...
youngtaff 13y ago
There was a GDL session about QUIC the other night - https://developers.google.com/live/shows/4578775316561920 https://developers.google.com/live/shows/4578775316561920 Slides here - https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb6wRlm79gN6hnPFHByEXXptk/present#slide=id.g176a9a2e9_0143 https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb...

drp 13y ago

This article is from last November. The Google group response linked from the post https://groups.google.com/a/chromium.org/forum/m/#!topic/proto-quic/xoooxrixCis 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.

felixgallo 13y ago

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)

wmf 13y ago
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 http://www.ethos-os.org/~solworth/minimalt-20131031.pdf