Hacker News Reader

Comment by peterwwillis | Hacker News Reader

> It seems like everybody assumes you're on a big fat broadband pipe now and nobody else matters.

This is intentional. The powers that be have an interest in moving everyone to faster networks, and they effectively control all new web standards, and so build their protocols to force the apps to require faster, bigger pipes. This way they are never to blame for the new requirements, yet they get the intended benefits of fatter pipes: the ability to shove more crap down your throat.

It's possible to cache static binary assets using encrypted connections, but I am not aware of a single RFC that seriously suggests its adoption. It is also to the advantage of the powers that be (who have the financial means to do this) to simply move content distribution closer to the users. As the powers that be don't provide internet services over satellite or microwave, they do not consider them when defining the standards.

View on HN

There's a technical reason for this. The Internet2 project spent a lot of time and effort working on things like prioritized traffic to deal with congested links. They found that it was easier and more cost effective to just add more bandwidth than it was to design and roll out protocols that would deal with a lack of bandwidth.

For more info, read this: https://www.webcitation.org/5shCiXna8

A noteworthy quote:

> In those few places where network upgrades are not practical, QoS deployment is usually even harder (due to the high cost of QoS-capable routers and clueful network engineers). In the very few cases where the demand, the money, and the clue are present, but the bandwidth is lacking, ad hoc approaches that prioritize one or two important applications over a single congested link often work well. In this climate, the case for a global, interdomain Premium service is dubious.

"Premium service" in this document refers, basically, to an upgraded Internet with additional rules to provide quality of service for congested links.

(I'm not personally claiming that all these conclusions are correct and that they still apply today, just that there's some backstory here.)

I think more bandwidth is better in every case except geostationary satellites due to their unavoidable latency. And in theory those satellites are going to be obsoleted by LEO ISPs.

Not sure who "The powers that be" are, but anyone can propose and contribute to IETF standards. They are called "Request for Comment" for a reason.

Almost positively that answer is Google. Notice they are behind multiple of the new protocols here (HTTP/2 and QUIC), and are used as an example how bundling DOH with an existing major player can prevent blocking DNS.

Google is effectively the actual determiner of Internet standards. As the article notes, Google implemented QUIC on their servers and their browsers, and therefore, 7% of Internet traffic is already QUIC-based, despite it not being officially accepted at this point. This is essentially the same as what happened with SPDY at the time.

As Google controls both the primary source of Internet traffic (up to 35-40% of all Internet traffic, depending who you ask, and a browser share in the what 65% range), Google can implement any new protocol it wants, and everyone else needs to support it or be left out.

Arguably, the IETF is no longer the controlling organization here: Google is. Should the IETF not approve Google's proposals, Google will continue to use them, and everyone else will continue to need to support them.

As the parent notes, Google both essentially determines these standards, and has an interested in faster networks so they can shove fatter payloads down the pipe. This is in part due to the ability to implement pervasive tracking, and of course, they operate a lot of content distribution products like YouTube.

Note that every method here that makes it harder for governments to censor and ISPs to prioritize also makes it harder for people to detect, inspect, and filter out Google's pervasive surveillance.

For sure the "we've implemented this in Chrome already" aspect is a huge aspect in the standards process.

I do think it's important to say that this isn't a sure-fire deal. We had stuff like NaCl (native code in the browser) that basically died off, and other options as well.

Inversely, SPDY is not what the standard is, and Google instead pulled stuff it learned into HTTP/2. This seems like a positive aspect to me.

It's important to be wary of things that Google won't bring up, but overall I feel like we're getting a lot of benefit from having an implementer "beta test" stuff in this way.

On the upside they provide real world prototyping and testing of protocols at a scale that's never before been available. Standards they submit for consideration will have had a lot of real world usage to iron out kinks and be battle tested. This is a good thing, IMO.

Do not think it is Google fault they run so much of the Internet and also have most browser and mobile phone share.

Google using the standards process to release new things is exactly what we should want and see. You make it like it is some nefarious behavior. Geeze.

Google has offered things for standards which were changed by the standards group and Google adopted the change.

Google could just keep it all closed if they want. Honestly wonder if they will not in the future with posts like yours. Why do it?

I'm very much torn on this phenomenon, and it depends on an org like Google being more or less benevolent when pushing new protocols and tech.

Designing a new protocol to be used at internet scale is really hard. Having the ability to test that on a significant amount of traffic before refining and standardizing is a huge advantage that few groups on the planet are able to make use of. From the IETF's perspective, I would look skeptically upon a new standard that someone dreamed up but had little to no practical real-world data to show how it behaves in practice.

But I also want them to avoid ramming standards down the IETF's throat. If, after due consideration, the IETF says "no" to a new standard, I want Google to stand down and abandon it. If the IETF thinks it's a good idea and is willing to work with Google to iron out issues and standardize in a public manner, then that's the ideal outcome.

While everything you state here is correct, and is clearly of serious concern, my view is that the general public doesn't really have the capacity to fight both of these battles at once.

Right now, I'm convinced we need Google's help to make it harder for governments and ISPs to censor and prioritize.

After that, we'll deal with Google.

As of today Google with it's BBR + QUIC + Chrome combo and Facebook with their Zero protocol, combined with their extensive data center network can get much better end user experience than any other service provider regardless of any government.

We can talk about network neutrality whatever we want - but these companies have built technological capabilities to have "little bit bigger share".

So, probably after some time it is too late to deal with Google:)

> As of today Google with it's BBR + QUIC + Chrome combo and Facebook with their Zero protocol, combined with their extensive data center network can get much better end user experience than any other service provider regardless of any government.

What is your preferred course here? Google has provided free as in freedom source code for all of the above, and in some cases pushed the code upstream. Granted, it will take small players longer to see the benefits of these techs, since they can't afford to integrate it themselves and must wait for vendors to include it. But small players usually have worse user experience regardless of the mechanism. Proposed standards are just one way that happens.

I don't understand why people are more afraid of regional monopolies which have only a portion of one country as their scope, than of a global operation like Google.

I think it's far more important to deal with Google than hand them the keys to the kingdom while fighting smaller fish.

Corporations and governments are not two entities you can divide for conquering.

I agree with you, and it feels dirty, but we're going to end up with neither if we don't start with one. If you have a better idea that can even plausibly attempt to get both, I'm all ears.

I have no better idea, but it's a problematic plan. If you go with this, you will be surprised by underground deals that will stop that division, and will very likely mislead you.

The good part is that it focus on fixing the government. That's the correct entity to fix.

Content creators make this assumption way more than any other party. Webpage bloat is already several years past qualifying as obscenely bloated, new words need to be used to describe it today.

Who are the powers that be that benefit from fatter pipes + content distribution?

See: https://news.ycombinator.com/item?id=15908810

What about these new protocols is antagonistic towards satellite/microwave endpoints? If anything I'd think the 0-rtt support would help.

Then you will greatly relieved to hear that as of 2010 all major browsers cache content delivered over HTTPS.

https://stackoverflow.com/a/174485/262789

I assume they were referring to intermediate caching, not client side caching.

If that is the case, then the GGP is asking for something that would be a huge privacy leak.

I don't understand the down votes on your comment. I think a lot of what you're saying makes sense.

Reply on news.ycombinator.com