Hacker News Reader

Comment by minikites | Hacker News Reader

>Google has the largest QUIC deployment, and has reported that more than 85% of requests from Chrome browsers to Google servers (about 90% of Chrome bytes received) are now using QUIC, which accounts for 7% of Internet traffic!

>Taking a closer look at the congestion window changes (Figure 6), we found that while both protocols use Cubic, QUIC increases its window more aggressively (both in terms of slope, and in terms of more frequent window size increases). As a result, QUIC is able to grab available bandwidth faster than TCP does, leaving TCP unable to acquire its fair share of the bandwidth.

First AMP and now QUIC. As I see it, Google is emerging as the biggest enemy of both the web and the underlying internet.

View on HN

> First AMP and now QUIC.

Um, pretty sure QUIC was in the pipeline a few years longer than AMP. Besides, it's literally a protocol in the network stack -- would you say IPv6 is an enemy of the web and underlying internet?

Please stop the needless fear mongering.

Do you even know the OSI-model? Yes QUIC is a protocol, but not on the same layer as IPv6. So the comparison is useless.

It is one layer above IPv6, but what difference does that make? It's an improvement over an existing protocol to solve real problems.

I don't think anyone can really know the OSI model. I know I frequently use HTTP as a Transport Layer protocol myself, so you got me there. ¯\_(ツ)_/¯

I pasted that initial quote ("Google has the largest QUIC deployment...") to point out that Google has a significant advantage in owning the most popular web browser and also most of the top-tier web properties in Google search, Gmail, and YouTube. Because they control the whole chain from browser to content, they can release things that make those experiences better for Chrome users (using QUIC) at the expense of non-Chrome users (who get worse TCP performance until everyone else completely adopts QUIC). Then, toss up some banner ads for non-Chrome users who visit YouTube saying, "YouTube too slow? Switch to Chrome!"

>would you say IPv6 is an enemy of the web and underlying internet?

If IPv6 made IPv4 performance worse and was pushed by one company who controls both the browser and the most popular web content, yes, I would.

Everything you say is true, yet... the Google approach works and the others don't. If our choice is free and mostly-open protocols from Google or using HTTP/1.1 + TLS 1.1 + TCP w/ CUBIC + IPv4 w/ NAT forever, Google doesn't sound too bad.

This is related to the AV1 vs. MPEG discussion from the other day where people pointed out that we basically have a a choice between free codecs developed by Google/Netflix or codecs that suck you dry from legal fees.

This has nothing to do with Google's politics. TCP is broken for modern networks, and the faster we ditch it for a protocol capable of reliable pipes with low latency and high throughput, the better off we'll all be.

Not all networks are modern, what about the unreliable networks in most of the developing world?

QUIC still works better than TCP on these networks, but the benefits are not as dramatic.

That doesn't seem to be supported by the article?

"While it outperforms TCP in a wide range of scenarios, we found that it underperforms in the presence of packet reordering and on resource-constrained mobile devices."

1) "We shared this result with a QUIC engineer, who subsequently informed us that the QUIC team is experimenting with dynamic threshold and time-based solutions to avoid falsely inferring loss in the presence of reordering."

2) "We find that, similar to the desktop environment, in mobile QUIC outperforms TCP in most cases; however, its advantages diminish across the board... The reason for this behavior is that QUIC runs in a userspace process, whereas TCP runs in the kernel." (i.e. putting it in the kernel should help.)

https://conferences.sigcomm.org/imc/2017/papers/imc17-final3...

I'm not sure it's all that bad. AMP is awful, particularly because of the way in which Google abuses it, but QUIC is less of a problem – it's on an IETF standards track with a couple of implementations.

Reply on news.ycombinator.com