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.
back
1 comments
> 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.
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.
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.