[higherpurpose]

Wasn't the point of QUIC that it's basically encrypted UDP? I'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't that great.

However, if the promise is to be an always-encrypted Transport layer (kind of like how CurveCP [1] wanted to be - over TCP though) with small performance gains - or in other words no performance drawbacks - then I'm all for it.

I'm just getting the feeling Google is promoting it the wrong way. Shouldn't they be saying "hey, we're going to encrypt the Transport layer by default now!" ? Or am I misunderstanding the purpose of QUIC?

[1] - http://curvecp.org/

[comex]

The first diagram, if I'm interpreting it correctly, shows two whole round trip times shaved off compared to TCP + TLS, and one compared to plain TCP (which is basically no longer acceptable). For a newly visited site, that becomes one and zero.

The 100ms ping time in the diagram may be pretty high for connections to Google, with its large number of geographically distributed servers, but for J. Random Site with only one server... it's about right for US coast-to-coast pings, and international pings are of course significantly higher. [1] states that users will subconsciously prefer a website if it loads a mere 250ms faster than its competitors. If two websites are on the other coast, have been visited before, and are using TLS, one of them can get most of the way to that number (200ms) simply by adopting QUIC! Now, I'm a Japanophile and sometimes visit Japanese websites, and my ping time to Japan is about 200ms[2]; double that is 400ms, which is the delay that the same article says causes people to search less; not sure this is a terribly important use case, but I know I'll be happier if my connections load faster.

Latency is more important than people think.

[1] http://www.nytimes.com/2012/03/01/technology/impatient-web-u...

[2] http://www.cloudping.info

[nomel]

> Packet sequence numbers are never reused when retransmitting a packet. This avoids ambiguity about which packets have been received and avoids dreaded retransmission timeouts.

How does this work?

As a total guess, I assume the client gets a stream of packets, buffers them all up, waits for some threshold before re-requesting any missing sequence numbers. When that missing packet comes back in (all while the stream continued) with its new number, it puts in in place, and pushes the data up to the application and clears it's buffer. Client probably sends "I'm good up to sequence n" every once and a while so the server can clear it's re-transmit buffer.

That's pretty cool. Treat it as a lossy stream, rather than a "OH CRAP EVERYBODY STOP EVERYTHING, FRED FELL DOWN!". With this, FRED IS DED!

[asuffield]

(Tedious disclaimer: my opinion, not my employer's. Not representing anybody else. I work at Google and have some involvement in this project.)

Others have discussed the technical aspects of what QUIC is achieving, but you can understand its purpose fairly easily by saying "QUIC" out loud ;)

If that's not clear enough, it stands for "Quick UDP Internet Connections", which I think makes it fairly clear what it achieves. You can read more about it in the FAQ: https://docs.google.com/a/chromium.org/document/d/1lmL9EF6qK...

Note that the blog post doesn't say "1% slowest sites", it says "1% slowest connections" - that's the mobile and satellite users. Think about how many seconds it takes to load google.com on your phone when your signal isn't great. How does taking a second off that sound to you?

[wmf]

QUIC was never intended to be encrypted UDP, although plenty of people had that misinterpretation. (DTLS is already encrypted UDP.) QUIC is a replacement for TCP and TLS.

[higherpurpose]

So then it's an "always-encrypted" TCP? Or is the "always-encrypted" part wrong? Is it going to be like HTTP/2 where it still has an option for plain-text? (hopefully not)

[billyhoffman]

You got the stats wrong. Its always the same site specifically some unnamed Google property (they used Search and Youtube as other examples so it could be one of them).

Google is say that, for clients connecting to the same site, the slowest 1% of those clients saw a 1 second improvement in page load time by using QUIC instead of TCP. (presumably its SPDY + QUIC against SPDY + TCP as they say at the end of the article). That's pretty good.

It was 1 second shaved

[ricardobeat]

Not sure what you are getting at, s/sites/clients/. The definition of 'pretty good' depends on how slow that 1% of clients are, as the parent said, 1 second out of 60 (or even 30 or 10) would not really be anything of note.