I had no idea QUIC was so poorly specified (at least outside of the walls of Google).
> the protocol is under rapid development, with extensive rewriting of the protocol occurring over the scale of months
Once it stabilizes, I don't see a reason why it couldn't go the same route SPDY -> HTTP/2 did. A faster internet is a win for Google.
(I work at Google, but I'm not aware of the QUIC team's plans).
I guess Google will still continue to experiment, but then probably based on the standardized version.
Example: its benefits diminish or entirely disappear compared to unproxied TCP in low loss/latency cases, and
when there is 1% loss. In the case of high delay links, QUIC still
outperforms TCP [...]. Thus, proxies can help TCP to recover
many of the benefits of QUIC, but primarily in lossy scenarios, and
when the proxy is equidistant from the client and server
Contrary to negative tonne, Figure 12 looks like it favors Quic on almost all cases?