A QUIC update on Google’s experimental transport

Google really gets how standardization works. They innovate and once the innovation has proven its value they offer the technology for standardization.<p>I previously saw companies, like Sun, completely fail at this. Eg. The many Java specifications that were created by the standards bodies. Sun tried to do it right by having a reference implementation with the spec. But the Reference implementations were rarely used for real work, so it proved only that the spec could be built, not that the spec elegantly solved real problems.

<i>Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic</i><p>Google says they will eventually submit this to IETF and produce a reference implementation, but it is interesting how a company was able to quietly move a large user base from open protocols to a proprietary protocol.

As part of telehash v3, we&#x27;ve separated out most of the crypto&#x2F;handshake packeting into E3X, which has a lot of similarities to QUIC: <a href="https:&#x2F;&#x2F;github.com&#x2F;telehash&#x2F;telehash.org&#x2F;blob&#x2F;master&#x2F;v3&#x2F;e3x&#x2F;intro.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;telehash&#x2F;telehash.org&#x2F;blob&#x2F;master&#x2F;v3&#x2F;e3x&#x2F;...</a><p>Personally I have a much broader use case in mind for E3X than QUIC is designed for, incorporating IoT and meta-transport &#x2F; end-to-end private communication channels. So, I expect they&#x27;ll diverge more as they both evolve...

MinimaLT [1], developed independently and about the same time as QUIC, also features the minimal latency, but with more (and better IMO) emphasis on security and privacy. (Though both are based on Curve25519). QUIC has an edge with header compression and an available implementation. EDIT: and of course, forward error correction!<p>[1] cr.yp.to&#x2F;tcpip&#x2F;minimalt-20130522.pdf

I wonder if this is why I&#x27;ve been having weird stalls and intermittent failures using GMail the last few weeks. Every time, I try it in Firefox or Safari and it works perfectly.

Possibly silly question: I was under the impression that only TCP allowed for NAT traversal; if I send a UDP packet to Google, how can Google respond without me configuring my router?

Interesting, I wonder if this will will end up gaining enough momentum to become a standard, similarly to how SPDY ended up essentially becoming HTTP&#x2F;2.

It will be interesting to see how this works out with NAT being as difficult to work with UDP as it often can be.<p>It&#x27;s a shame that SCTP is not more widely adopted, as I suspect it may be just as good (if not better) as a transport layer for building a new web protocol on.

I wonder how they managed the zero RTT connections? How would that ever work?

I&#x27;m not sure if this is related. But sometimes I have a slow home internet (60 kbps after I cross a threshold). At those times, I see websites loading really slow, specially HTTPS connections crawling - But YouTube streaming, Google search and Google webcache works really fast! In fact I&#x27;ve been waiting for a normal website to load for a few minutes on my PC, and the whole time YouTube was streaming in another mobile without any interruptions.<p>Does UDP mess up other traffic?

The first image really confused me with the &#x27;Receiver&#x27; looking like a server and the &#x27;Sender&#x27; looking like a laptop.

50% and nobody noticed. Can&#x27;t wait for another marginal latency win that makes the software stack more complex.

I assume they aren&#x27;t counting the transit time of the first SYN equivalent? Are they saying it traverses the network infinitely fast. Because it doesn&#x27;t

Google should investigate (or perhaps just buy outright) a low level communications technology stack from one of the HFT firms - they&#x27;ve already mastered low-latency networking, they just have no incentive to share this knowledge with the outside world.

Wasn&#x27;t the point of QUIC that it&#x27;s basically encrypted UDP? I&#x27;m not seeing that great of a performance improvement here - 1 second shaved off the loading of top 1% slowest sites. Are those sites that load in 1 minute? Then 1 second isn&#x27;t that great.<p>However, if the promise is to be an always-encrypted <i>Transport layer</i> (kind of like how CurveCP [1] wanted to be - over TCP though) with small performance gains - or in other words <i>no performance drawbacks</i> - then I&#x27;m all for it.<p>I&#x27;m just getting the feeling Google is promoting it the wrong way. Shouldn&#x27;t they be saying &quot;hey, we&#x27;re going to encrypt the Transport layer by default now!&quot; ? Or am I misunderstanding the purpose of QUIC?<p>[1] - <a href="http:&#x2F;&#x2F;curvecp.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;curvecp.org&#x2F;</a>