4 ms·

Note that this seems to be gQUIC (the Google-internal variant of QUIC that it has been using for a few years), and is thus not interoperable with most non-Googl

Note that this seems to be gQUIC (the Google-internal variant of QUIC that it has been using for a few years), and is thus not interoperable with most non-Google QUIC implementations, which follow the IETF drafts.

deleted 8y ago
[deleted]
pilif 8y ago
> most non-Google QUIC implementations, which follow the IETF drafts ... which in practice means that you would be able to actually use QUIC with the most widely deployed client implementation (which might in-fact be the only client implementation that's not a development build right now). IETF QUIC doesn't really exist yet, so offering it over Google's QUIC which exists in Chrome would provide next to no benefit to everybody. However, I do hope, or rather, expect google to very quickly move both Chrome and the load balancers to IETF QUIC once that is finalized. Until then, I keep my pitchfork safely stored in its closet because what is being offered here certainly is the practical offering and the correct offering would be completely impractical.
- delroth 8y ago
  Similarly, SPDY was not compatible with HTTP2 before the standard was finalized, but then Google quickly switched to the standard once it was available. I don't think there is too much to worry about there.
  - jacksmith21006 8y ago
    Plus Google giving them SPDY got us the new http2 standard much more quickly and the benefits. Google controlled the two biggest clients and the two biggest servers and still gave the IP to the community. Love how they just want to push the broader industry forward.
- dochtman 8y ago
  I don't necessarily disagree with all that; however, I do think it would have been good for Google to disambiguate in their announcement and documentation that they don't mean standards-track QUIC here, or more generally, what version of QUIC they mean. At least with SPDY it was clearer that SPDY was something different from HTTP 2.

deleted 8y ago

[deleted]

pilif 8y ago

> most non-Google QUIC implementations, which follow the IETF drafts ... which in practice means that you would be able to actually use QUIC with the most widely deployed client implementation (which might in-fact be the only client implementation that's not a development build right now). IETF QUIC doesn't really exist yet, so offering it over Google's QUIC which exists in Chrome would provide next to no benefit to everybody. However, I do hope, or rather, expect google to very quickly move both Chrome and the load balancers to IETF QUIC once that is finalized. Until then, I keep my pitchfork safely stored in its closet because what is being offered here certainly is the practical offering and the correct offering would be completely impractical.

delroth 8y ago
Similarly, SPDY was not compatible with HTTP2 before the standard was finalized, but then Google quickly switched to the standard once it was available. I don't think there is too much to worry about there.
- jacksmith21006 8y ago
  Plus Google giving them SPDY got us the new http2 standard much more quickly and the benefits. Google controlled the two biggest clients and the two biggest servers and still gave the IP to the community. Love how they just want to push the broader industry forward.
dochtman 8y ago
I don't necessarily disagree with all that; however, I do think it would have been good for Google to disambiguate in their announcement and documentation that they don't mean standards-track QUIC here, or more generally, what version of QUIC they mean. At least with SPDY it was clearer that SPDY was something different from HTTP 2.