[Cryptography] replacing the whole sodding lot

ianG iang at iang.org
Mon May 4 20:09:34 EDT 2015

One of the snarky predictions I made to the SSL/PKI/CA cabal when they 
refused to respond to security issues was that at some point the whole 
lot would be replaced.  It took a while, but there are now some green 
shoots.  This is spectacularly good, and I will say that all of the 
nasty things I've said about this company are forgiven.  I'll still say 
them, but ALL is FORGIVEN:


  A QUIC update on Google’s experimental transport
Last year we announced QUIC, a UDP-based transport protocol for the 
modern Internet.  Over the last quarter, we’ve been increasing the 
amount of traffic to Google services that is served over QUIC and 
analyzing QUIC performance at scale. Results so far are positive, with 
the data showing that QUIC provides a real performance improvement over 
TCP thanks to QUIC's lower-latency connection establishment, improved 
congestion control, and better loss recovery.

For latency-sensitive services like web search, the largest gains come 
from zero-round-trip connection establishment. The standard way to do 
secure web browsing involves communicating over TCP + TLS, which 
requires 2 to 3 round trips with a server to establish a secure 
connection before the browser can request the actual web page. QUIC is 
designed so that if a client has talked to a given server before, it can 
can start sending data without any round trips, which makes web pages 
load faster. The data shows that 75% percent of connections can take 
advantage of QUIC’s zero-round-trip feature. Even on a well-optimized 
site like Google Search, where connections are often pre-established, we 
still see a 3% improvement in mean page load time with QUIC.

Another substantial gain for QUIC is improved congestion control and 
loss recovery. Packet sequence numbers are never reused when 
retransmitting a packet. This avoids ambiguity about which packets have 
been received and avoids dreaded retransmission timeouts. As a result, 
QUIC outshines TCP under poor network conditions, shaving a full second 
off the Google Search page load time for the slowest 1% of connections. 
   These benefits are even more apparent for video services like 
YouTube. Users report 30% fewer rebuffers when watching videos over 
QUIC. This means less time spent staring at the spinner and more time 
watching videos.

Where do we go from here? Today, roughly half of all requests from 
Chrome to Google servers are served over QUIC and we’re continuing to 
ramp up QUIC traffic, eventually making it the default transport from 
Google clients — both Chrome and mobile apps — to Google servers. We 
plan to formally propose QUIC to the IETF as an Internet standard but we 
have some housekeeping to do first, like changing the wire format and 
updating our reference implementation from SPDY-over-QUIC to 
HTTP2-over-QUIC. In the coming months, we also plan to work on lowering 
handshake overhead to allow better server-side scalability, improving 
forward error correction and congestion control, and adding support for 
multipath connections.

More information about the cryptography mailing list