Most active commenters
  • tsimionescu(4)
  • api(3)

←back to thread

306 points carlos-menezes | 16 comments | | HN request time: 1.333s | source | bottom
Show context
jrpelkonen ◴[] No.41891238[source]
Curl creator/maintainer Daniel Stenberg blogged about HTTP/3 in curl a few months ago: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...

One of the things he highlighted was the higher CPU utilization of HTTP/3, to the point where CPU can limit throughput.

I wonder how much of this is due to the immaturity of the implementations, and how much this is inherit due to way QUIC was designed?

replies(4): >>41891693 #>>41891790 #>>41891813 #>>41891887 #
therealmarv ◴[] No.41891887[source]
"immaturity of the implementations" is a funny wording here. QUIC was created because there is absolutely NO WAY that all internet hardware (including all middleware etc) out there will support a new TCP or TLS standard. So QUIC is an elegant solution to get a new transport standard on top of legacy internet hardware (on top of UDP).

In an ideal World we would create a new TCP and TLS standard and replace and/or update all internet routers and hardware everywhere World Wide so that it is implemented with less CPU utilization ;)

replies(1): >>41891927 #
1. api ◴[] No.41891927[source]
A major mistake in IP’s design was to allow middle boxes. The protocol should have had some kind of minimal header auth feature to intentionally break them. It wouldn’t have to be strong crypto, just enough to make middle boxes impractical.

It would have forced IPv6 migration immediately (no NAT) and forced endpoints to be secured with local firewalls and better software instead of middle boxes.

The Internet would be so much simpler, faster, and more capable. Peer to peer would be trivial. Everything would just work. Protocol innovation would be possible.

Of course tech is full of better roads not taken. We are prisoners of network effects and accidents of history freezing ugly hacks into place.

replies(7): >>41892225 #>>41892686 #>>41892920 #>>41893968 #>>41894183 #>>41894543 #>>41895155 #
2. johncolanduoni ◴[] No.41892225[source]
Making IPv4 headers resistant to tampering wouldn't have helped with IPv6 rollout, as routers (both customer and ISP) would still need to be updated to be able to understand how to route packets with the new headers.
replies(1): >>41892516 #
3. ajb ◴[] No.41892516[source]
The GP's point is that if middle boxes couldn't rewrite the header, NAt would be impossible. And if NAT were impossible, ipV4 would have died several years ago because NAT allowed more computers than addresses.
replies(1): >>41893989 #
4. ocdtrekkie ◴[] No.41892686[source]
This ignores... a lot of reality. Like the fact that when IP was designed, the idea of every individual network device having to run its own firewall was impractical performance-wise, and decades later... still not really ideal.

There's definitely some benefits to glean from a zero trust model, but putting a moat around your network still helps a lot and NAT is probably the best accidental security feature to ever exist. Half the cybersecurity problems we have are because the cloud model has normalized routing sensitive behavior out to the open Internet instead of private networks.

My middleboxes will happily be configured to continue to block any traffic that refuses to obey them. (QUIC and ECH inclusive.)

replies(1): >>41893112 #
5. dcow ◴[] No.41892920[source]
Now that’s a horse of a different color! I’m already opining this alt reality. Middle-boxes and everyone touching them ruined the internet.
6. codexon ◴[] No.41893112[source]
Even now, you can saturate a modern cpu core with only 1 million packets per second.
7. tsimionescu ◴[] No.41893968[source]
I completely disagree with this take.

First of all, NAT is what saved the Internet from being forked. IPv6 transition was a pipe dream at the time it was first proposed, and the vast growth in consumers for ISPs that had just paid for expensive IPv4 boxes would never have resulted in them paying for far more expensive (at the time) IPv6 boxes, it would have resulted in much less growth, or other custom solutions, or even separate IPv4 networks in certain parts of the world. Or, if not, it would have resulted in tunneling all traffic over a protocol more amenable to middle boxes, such as HTTP, which would have been even worse than the NAT happening today.

Then, even though it was unintentional, NAT and CGNAT are what ended up protecting consumers from IP-level tracking. If we had transitioned from IPv4 directly to IPv6, without the decades of NAT, all tracking technology wouldn't have bothered with cookies and so on, we would have had the trivial IP tracking allowed by the one-IP-per-device vision. And with the entrenched tracking adware industry controlling a big part of the Internet and relying on tracking IPs, the privacy extensions to IPv6 (which, remember, came MUCH later in IPv6's life than the original vision for the transition) would never have happened.

I won't bother going into the other kinds of important use cases that other middle boxes support, that a hostile IPv4 would have prevented, causing even bigger problems. NAT is actually an excellent example of why IPs design decisions that allow middle boxes are a godsend, not a tragic mistake. Now hopefully we can phase out NAT in the coming years, as it's served its purpose and can honorably retire.

replies(1): >>41896125 #
8. tsimionescu ◴[] No.41893989{3}[source]
Very unlikely. Most likely NAT would have happened to other layers of the stack (HTTP, for example), causing even more problems. Or, the growth of the Internet would have stalled dramatically, as ISPs would have either increased prices dramatically to account for investments in new and expensive IPv6 hardware, or simply stopped acceptong new subscribers.
replies(1): >>41894692 #
9. AndyMcConachie ◴[] No.41894183[source]
A major mistake of the IETF was to not standardize IPv4 NAT. Had it been standardized early on there would be fewer problems with it.
10. bell-cot ◴[] No.41894543[source]
> It would have forced IPv6 migration immediately (no NAT) and forced endpoints to be secured...

There's a difference between "better roads not taken", and "taking this road would require that most of our existing cars and roads be replaced, simultaneously".

11. ajb ◴[] No.41894692{4}[source]
Your first scenario is plausible, the second I'm not sure about. Due to the growth rate central routers had a very fast replacement cycle anyway, and edge devices mostly operated at layer 2, so didn't much care about IP. (Maybe the was done device in the middle that would have had a shorter lifespan?). I worked at a major router semiconductor vendor, and I can tell you that all the products supported IPv6 at a hardware level for many, many years before significant deployment and did not use it as a price differentiator. (Sure, they were probably buggy for longer than necessary, but that would have been shaken out earlier if the use was earlier). So I don't think the cost of routers was the issue.

The problem with ipv6 in my understanding was that the transitional functions (nat-pt etc) were half baked and a new set had to be developed. It is possible that disruption would have occurred if that had to be done against an earlier address exhaustion date.

12. kbolino ◴[] No.41895155[source]
The only mechanism I can think of that could have been used for that purpose, and was publicly known about (to at least some extent) in the late 1970s, would be RSA. That is strong crypto, or at least we know it is when used properly today, but it's unlikely the authors of IP would have known about it. Even if they did, the logistical challenges of key distribution would have sunk its use, and they would almost certainly have fallen into one of the traps in implementing it that took years to discover, and the key sizes that would have been practical for use ca 1980 would be easy to break by the end of the 1990s.

Simply put, this isn't a road not taken, it's a road that didn't exist.

13. api ◴[] No.41896125[source]
The cost of NAT is much higher than you think. If computers could just trivially connect to each other then software might have evolved collaboration and communication features that rely on direct data sharing. The privacy and autonomy benefits of that are enormous, not to mention the reduced need for giant data centers.

It’s possible that the cloud would not have been nearly as big as it has been.

The privacy benefits of NAT are minor to nonexistent. In most of the developed world most land connections get one effectively static V4 IP which is enough for tracking. Most tracking relies primarily on fingerprints, cookies, apps, federated login, embeds, and other methods anyway. IP is secondary, especially with the little spies in our pockets that are most people’s phones.

replies(1): >>41902268 #
14. tsimionescu ◴[] No.41902268{3}[source]
End to end connectivity without a third party server for discovery is either complicated for the end-user (manually specifying IPs, ports, etc) or it relies on inherently insecure techniques like multicast/broadcast. And once you introduce a third party server that both peers connect to, establishing a connection even through NAT is not that much harder. And yes, NAT does have some costs, but transitioning to IPv6 also does, and I don't think that the Internet justified that cost at the time IPv4 addresses first started running out. NAT's cost is much more diffuse and in the future.

We'll see if this more direct communication actually happens as IPv6 becomes ubiquitous, but I for one doubt it. Especially since ISPs are not at all friendly to residential customers trying to run servers, often giving out dynamic prefixes or small subnets (/128s even!) even on IPv6. And I think the LTE network is decent evidence in support of my doubts: it was built from the ground up with IPv6-only internally, and there are no stable IP guarantees anywhere.

As to the privacy benefits, those are real and have made IP tracking almost useless. Your public IP, even in the developed world, very commonly changes daily or weekly. Even worse for trackers, when it does change, it changes to an IP that someone else was using.

replies(1): >>41903927 #
15. api ◴[] No.41903927{4}[source]
> establishing a connection even through NAT is not that much harder.

This is false. Because of the inconsistency of NATs and other middle-boxes out there and the fact that many are broken, it's far less reliable. You end up having to relay some traffic, which imposes external cost that unlike a third party locator server isn't trivial. Now you're already losing the benefits of end-to-end connectivity.

Also if E2E is easy there are distributed algorithms for location like DHTs that can be implemented. With trivial end to end they're pretty easy and would be fast and reliable.

The way the Internet has developed has basically broken it for end to end connectivity, forcing everything into the cloud. That is far worse for privacy and autonomy (and cost, making everything a subscription) than IP tracking.

I think you're a little blinded by what is and unable to imagine an alternate path.

Evolution is very path dependent and small changes at one point make things massively different later. One less asteroid and we'd be warm blooded bird-reptile like things that laid eggs.

replies(1): >>41905997 #
16. tsimionescu ◴[] No.41905997{5}[source]
Perhaps, but I'm not at all convinced. The hard problems of running distributed peer-to-peer services are not end-to-end connectivity. While that is a problem, it's a relatively small hurdle; you can connect the vast majority of clients with some not huge effort.

The much bigger problems are related to moderation, copyright enforcement, spam prevention, security. All of those are extremely hard if you don't have a centralized authority server.

Could Zoom have better quality more cheaply if it could easily do P2P connections for small meetings? Very likely. Could you make a fully distributed Zoom where anyone can call anyone else without a centralized authority server handling all calls? No, not without significant legal hurdles and effort on preventing malicious actors from spamming the network, from distributing illegal content, etc.

Also, back to middleboxes: not having NAT would not get rid of middleboxes. Even on IPv6, there will always be a stateful firewall blocking all outside connections to the internal network in any sane deployment, at least for home networks. And that firewall will probably be about as buggy as cheap NAT boxes are. And for corporate networks, you have all sorts of other middlemen critical to the security of the network, I clouding IDS and IPS systems, TLS listeners to protect from data e filtration etc. Those will interfere with your traffic far more than relatively regular NAT boxes would.