Hacker News Reader

Comment by evolve2k | Hacker News Reader

“Today this changes. We've found that IETF QUIC significantly outperforms HTTP over TLS 1.3 over TCP. In particular, Google search latency decreases by over 2%. YouTube rebuffer time decreased by over 9%, while client throughput increased by over 3% on desktop and over 7% on mobile.“

This is the most sickening sentence for me. The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’. This is just blatant exploitation that’s occurring as there is too much centralised ownership. In my opinion this is predatory behaviour packaged up as open source good for all.

View on HN

"The myopic internal focus."

When "everyone" uses your software/websites, you can get away with this, much like Microsoft did back in the day. Internal Windows programs ran faster and seemed more stable than third party software written to run on Windows. It generally offered better "UX", to use today's lingo.

The thing that is totally ignored by the myopic focus is the value of not being part of the Borg. Putting small speed differences aside, that value is not insubstantial, though the Google communications department is not responsible for keeping users informed about anything more than the value of Google.

The fastest internet would be one without ads (not to mention the other benefits). Google will not inform anyone about that. It is not included in any tests.

> The fastest internet would be one without ads

I don't disagree with your sentiment. However, their biggest gains in terms of percentage points (as discussed in the article) are for YouTube. And YouTube wouldn't be significantly faster without ads in the way that browsing primarily textual websites is faster without ads. Getting buffering times down is actually a substantial improvement here esp. on flaky connections. (Though the article doesn't make it clear whether flaky connections specifically benefit from QUIC.)

Waiting for pre-roll ads on YouTube certainly slows down the viewing experience. I do not use the YouTube JavaScript player. I download the video using a custom script and an HTTP client like tnftp and watch offline. Google is suggesting that users use their browser, their website and their internal player to view someone else's video file, so Google can serve ads, do tracking and collect analytics. The testing is not something generic like downloading a file from a server; instead, it uses Google protocol, Google browser, Google website, Google player and is announced on Google blog.

All to show it will benefit everyone, of course.

Ironically, googles internal deployment system is called Borg.

People argue both sides of this. If Google implements a new protocol on their servers and their clients without standardizing it, they're end-running the standards process or embrace-extend-extinguishing the open internet. If they do standardize it and then deploy the standard implementation, they're.. I don't even know, making billions of page loads faster and that's bad because they're Google?

What's the right way for Google to improve their internet-facing services at a protocol level?

I imagine that a prerequisite is to hire every person that'd complain about this stuff on Hacker News, so that they'd be on Google's team.

The underlying concern is that Google is in a position to dictate. They control most phones and most browsers and the most popular websites. Any standardization is pro forma, because what matters is what Chrome/Android/google.com does, and not what the standard says.

An emperor can build trust by relinquishing power.

What you're proposing as a solution has already happened: Google relinquished their control over this protocol to the IETF, where it changed so much as to be incompatible with Google's original.

Now they're updating their own deployment, making it compatible with the updated standard.

Chrome/Android/google.com is literally changing what they do to match what the standard says.

> The myopic internal focus.

Huh? They're reporting for their own products presumably because they have access to that information that is accurate, and they're a couple of the world's most popular, most visited sites.

But the speed improvements will come for everyone who uses the protocols, not just Google, of course. What is sickening about that?

Google Chrome collects performance and usage information for _every_ site you visit, not just Google properties. This is part of "Chrome Lighthouse" or whatever.

That the protocol is designed primarily around saving Google some overhead, and not for reasons of usability, extensibility, or clarity.

All that effort to get a tiny improvement.

The real motivation is probably to merge ads into the same stream as the content, so they can't be blocked by anything outside the browser.

Glad others are starting to articulate this issue. HTTP/3 is derived from HTTP/2. Google's main argument for HTTP/2's existence, its selling point to users, is head-of-line blocking in HTTP/1.1 pipelining. They also complain about the size of repeated HTTP headers.

But no modern browsers actually use HTTP/1.1 pipelining. Interestingly, HTTP/1.1 pipelining works great for non-browser use. Most web servers enable it by default. After all, it works. For example requesting a series of pages from multi-page website, all under a single TCP connection. I have been using HTTP/1.1 pipeplining this way for decades. It is fast and reliable and enables the web to be used as a non-interactive, information retrieval source. It is also 100% ad-free. The user only gets what she requests, nothing more.

As for HTTP headers, privacy-conscious or minimalist users might not send many headers, only the minimum to retrieve the page. That's usually up to three extra lines of text per page for the request headers. (I rarely ever have to send a User-Agent header for HTTP/1.1 pipelining.)

   GET /index.html HTTP/1.1
   Host: example.com
   Connection: keep-alive

Obviously, the web advertising/tracking industry, including companies like Google that serve this sector, use headers for their own purposes. Online advertising services. That's when presumably they could get big. However, as a user, I have no pressing need for the ability to send/receive larger headers.

Websites (IPs represented by domain names) to which users intentionally connect, i.e., the recognisable names that they type and click on, generally don't serve ads. The ads come from other domains, often other servers. Users generally do not intentionally try to connect to ad or tracking servers. HTTP/[01].x's automatic loading of resources, Javascript and other techniques may be used to make those requests, conveniently under the radar and outside the user's awareness.

Still, under HTTP/1.1, ads, nor Javascript files that trigger requests for ads, generally cannnot be delivered without the user's computer making a request first. Users can and do manage to exercise some control over their computers and they can prevent these non-interactive requests from being sent, from inside and outside the browser.

With HTTP/2 and HTTP/3, the necessity of a user-generated request disappears. As soon as the user "connects" (UDP) to the website's server, the server could for example send a Javascript file to the user's browser which can in turn trigger requests to other domains for ads or the purpose of tracking, all without any preceding request for the ad/tracking-related Javascript file. This is another feature of HTTP/[23] called "server push", but interestingly it is not the feature being used to sell HTTP/[23] to users (i.e., pipelining).

So, how does a user stop unwanted ads being "pushed" upon her in the stream (irrespective of the application, e.g., browser)? I generally don't use a "modern" browser, nor Javascript nor graphics. I like my pipelining outside the browser and free of advertising-related cruft.

It's worth considering that the motivation for speeding up websites via HTTP/[23] is solely for the purpose of speeding the delivery of more ads, more "stealthily", to users. This is a classic case of someone trying to sell you on a "solution" to a problem they themselves have created (or to which they are contributing).

Like an ISP trying to upsell customers to faster internet in order that websites bogged down with ads will "load" faster. When the ISP itself injects ads into pages of websites that are weighed down by ads.

Well strictly speaking I guess I'd rather have fast ad-laden pages than slow, but more likely these gains will vanish as ad congestion re-converges to the previous equilibrium. Users' tolerance for sluggishness is the true constant, not the amount of ads companies want to serve.

Is it really faster? I'm thinking if you have blocked the ads, that will be significantly faster. Google's benchmarks of course would not include how much faster HTTP3 is for pages with blocked ad content.

HTTP 2 can't just send content from other domains through the same connection (and any proposal that adds the ability, e.g. through signing, also can be used with HTTP 1.1 connections)

And pushed content needs to be accepted by the browser, just sending someone ad bytes doesn't really do anything useful. It doesn't impact adblocking, and if a browser vendor wants to take the adblocking features away they can also just do that for the traditional model.

Ignoring pushed ad data ia very different from never requesting those ads as far as available bandwidth and data metering are concerned.

Clients can refuse pushed requests (e.g. if they match filtering rules), so it's not like the server will push the full files through. It'd be interesting to check if clients do take e.g. OS settings about metering into account and disable push entirely to even avoid the initial transfer.

A related question: is it faster because it sends less data, or is it faster because it grabs more of the bandwidth by not using TCP-type congestion control?

It is improving performance for EVERYONE. They just published the stats for their own stack so people can compare.

Increases performance by 3%, and complicates HTTP by 100%. I'm not sure I would like that. I would understand if it was 2x performance gain or at least 50%, but a mere 3%?

This is exactly why it's important that they publish their figures - so you can make a decision if it's works for you after weighing the tradeoffs. For high-traffic properties (Google, CDNs, Netflix), 3% can easily translate to millions of dollars saved - they could hire an entire team just to deal with the HTTP complications.

3% of HTTP traffic is a lot.

Web page weight has increased 300% on average in the last decade only.

Most of it is garbage that doesn't need to be there and is shoved in people's faces because it makes other people money/power.

Ex: Why does clicking on a location link in google search load a big slow SPA to display a list of "cards" instead of just having a maps/web link in the search results?

I thought it's because Google isn't allowed to promote Google Maps in its search results, but a cursory search didn't yield any evidence.

Presumably if Search did link to Google Maps, other geographic information systems would have to be represented, just like various streaming platforms are represented in the video tab.

3% less garbage is still a lot. Would you rather more garbage?

3% less garbage is good, but 100% less would be preferable.

Don't forget the 7% throughput increase on mobile. That's a big deal, especially given that mobile users account for the majority of network traffic these days.

And 3% is still a lot if you're looking at global Internet traffic.

My PiHole is currently dropping about 20% of all requests. How about we get rid of all of those and see a REAL speed boost, especially on mobile?

Unless you maintain web servers or http proxies (Maintain as in, nginx/IIS/etc core team) Then it really makes no difference as a user.

Nobody has moved over to HTTP2 yet, let alone HTTP3.

Although that is true, I agree with GP in the sense that the improvements in protocol and browser are motivated by what benefits their own products, rather than what benefits everyone.

Yep, because we've built an economy based on idiotic fiduciary duty instead of duty to technologically advance the civilization.

Myopic focus is exactly what the system rewards.

What utility function would you propose?

I don't have a well-defined solution, but I think the notion of companies selling shares to people in armchairs who neither necessarily use nor feel the side effects of the product is an issue. To a great degree I don't believe in 100% free market valuation of companies. Rather, I think the people most affected by the company (positively or negatively) should have the biggest say in its value.

There also needs to be some adjustment to that valuation based on greater good delivered by the company. If they killed off a bunch of smaller businesses, that's a negative. If they emitted a bunch of carbon, that's a negative. If they caused injuries or deaths, that's a negative. If they contributed to open source products that enabled other companies to exist, that's a positive.

Carbon taxes are one step at capturing one very small aspect of this "greater good" factor, but there need to be other adjustments as well.

Another vague idea I've had is a hypothetical economic system in which the government doesn't print money (or isn't the only one printing money) but rather money is brought to existence by certain good deeds. Money can also be traded for goods and services, of course, in addition. So while you could make money by selling food or selling phones, you could also literally print your own money (translate: government hands it to you, in a controlled fashion) by sucking carbon out of the environment and proving that you did that to claim your money.

> ...but I think the notion of companies selling shares to people in armchairs who neither necessarily use nor feel the side effects of the product is an issue.

Their function is to raise money, whether they use the product or not (you don’t invest in something unless you believe it will provide value to some group of people) they’ve done their job and the company can continue to advance and adapt due to the capital. Further if you set what a company can be worth you’ve limited their resources and limited their innovation as a result.

You’ve also turned human labor into currency in an attempt to get rid of currency. You cannot get rid of the concept of money. Without it you must trade resources (like labor), which history has shown is a very bad idea. The idea of a government being able to print money is a very deliberate feature, not a bug. I cannot do this justice, but read up on why we have money in the first place.

> This is the most sickening sentence for me.

it's three sentences you quoted.

imo this is a quite harsh & pointed take you have presented. you seem to focus on some very-nearby headline sentences that do focus on performance, where-as the real story is much more interesting & the tech much more promising.

> blatant exploitation that’s occurring as there is too much centralised ownership

what makes you think this is so lopsided? yes, the spdy drafts released in 2012 originated from google. and google spent enormous amounts of effort, time & money championing & supporting development of QUIC as it made it's way through the IETF, where other non-Google engineers also worked to improve HTTP and build a powerful new transport protocol that shows enormous progress & is opening doors.

where is the exploitation?

> The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’

actually they made two standards. this is much better than where we were. with http2, we had built a true monster of a specification, untame-able. for good reason! we wanted good things! but the http2 spec was trying to shoe-horn a bunch of streams inside tcp, a streaming transport protocol, and that never quite fit (head of line blocking problems resulted), but just as bad, it made http2 a massive work that was hard to evolve & grow & reuse & enhance.

they took an extremely broad view, & said, these pieces don't belong together. they delegated responsibility into component pieces. they made pieces re-usable.

the result is that there are now a couple dozen efforts related to improve the underlying QUIC transport for lots of interesting use cases. the QUIC working group lists a couple dozen efforts[1] & enhancements, such as multi-path, load-balancing tuning, multicast, ack controls, satcom capabilities, & webtransport, a potential radical simplification & rework of websockets in a more connection-friendly manner. this is all work being done outside of http, being done with quic, because of these advances by these very careful, considerate, thoughtful, aware engineers, & their willingness to work with other engineers & the IETF to figure out how best to improve things, how best to decouple http2's transport protocol from it's application protocols.

> In my opinion this is predatory behaviour packaged up as open source good for all

i would very much like to hear some of what you feel or think any of your numerous very heavy accusations are due or deserved. using acerbaic words like "most sickening sentence", "myopic internal focus", & "blatant explotation" are big big words, big angry moods, and it's really uncomfortable, really hard for me to process & deal with such emotional turmoil directed at something that seems so innocent & like such a natural refinement & progression over the very good solid ideas & improvement that were http2, as it tried to move on & progress beyond http1.1 pipelineing, which everyone wanted very much wanted & in many cases did give up on.

so why do you hold your opinion? it really hurt me to hear your opinion, stated so pointedly, at such a lot of work that so many engineers all over the industry have contributed to & worked hard on. is this new dissent you have? are there other anti-http3 anti-quic folks who have staked some of their problems & claims & issues, or who have other ways they want the community to work through standards & specifications to improve the internet? what are the issues here, what's wrong? i for one thank my lucky stars that there are corporate patrons paying engineers good money to improve the world with works like this, to do the logical & consistent task of breaking http2 into it's transport (quic) and application (http3) protocols, improving the speed & reliability of the net.

thank you Google & IETF for doing all sorts of good for us all, imo.

[1] https://datatracker.ietf.org/wg/quic/documents/

there's a lot here beyond performance. i encourage you to investigate a little further & to see what quic + http3 bring & how they emerged from http2. that there is some performance win is good, but don't let that one statement narrow down your own understanding of this important enhancement.

the best evidence i can point to is a quic look at the IETF work group's active & related documents[1]

[1] https://datatracker.ietf.org/wg/quic/documents/

Reply on news.ycombinator.com