Hacker News Reader

> So we have IP->UDP->QUIC->HTTP3. Which is backwards compatible with HTTP/1.1, because, you guessed it.... nobody wants to add ports 82 and 440.

I’m not sure what you mean by backwards-compatible here. HTTP/3 is not running over TCP port 80. It conveys the same semantics as older TCP HTTP, but that’s so applications can transparently use one or the other.

I’m afraid your rant only goes downhill from there. Your IPv7 and UDPv4 are quite implausible, especially where you’ve put them in the stack.

Look, we’re dealing with people here. You can’t just say “we’re dropping this thing you’ve been using for years, effective immediately”. We’re also dealing with capital investments: half the world is built upon stuff that only supports TCP and UDP at the layer on top of IP and can never support alternatives like SCTP. So replacing things takes a great deal of time. Therefore, sitting on top of existing protocols lets you do something rather than nothing.

All progress in all fields is developed on top of existing things.

> HTTP/3 is not running over TCP port 80

Yes, obviously it's not TCP, and obviously not that port. I explicitly stated "UDP->QUIC->HTTP3", which is only inaccurate because HTTP3 is an implementation of QUICv1.

But it is still running over port 443. So my point is exactly the same. They refuse to change the port so that nobody has to agree to implement something crazy, like a new L4 protocol, or worse. (HTTP/3 does supports the ability advertise additional ports besides 443, but so does HTTP/1.1, in "Location: https://someurl:442/" redirects, and still nobody has ever used anything but 443 for production)

> Look, we’re dealing with people here. You can’t just say “we’re dropping this thing you’ve been using for years, effective immediately”.

But we are saying "All the clients [that effectively 2 companies control] will be using this new thing, so unless you want to be left behind, grandpa, get on the bandwagon." There is plenty of muscle to start the process of upgrading legacy crap. Over 5-10 years we could get 90% adoption of an entirely new network stack. But we have to actually start going there by writing the standards with that intent.

QUIC is a good start, but from the protocol stack's perspective it's a hack. 10-15 years ago, it simply would have been a new revision of SCTP. But the design is being pushed by an advertising company that just wants an 8% reduction in traffic so they can increase their shareholder dividend. They don't give a crap about evolving the stack to actually improve computing as a whole, which is what the standards are really intended for.

UDP port 443 is entirely unconnected to TCP port 443—they’re the same number, but in a completely different namespace. HTTP/3 didn’t have to use UDP ports 80 and 443, it was just most convenient for all parties concerned to use the same numbers as the TCP ports, because there was no obvious reason to change it.

I do wish you could specify which port to use for your HTTP with SRV records, but it’s unlikely that will ever happen.

10–15 years ago, SCTP didn’t work on the internet at large, just like it doesn’t now. Face it, protocols at this layer have ossified so that TCP and UDP are your only options if you want broad compatibility—and that’s nothing to do with any one party, it’s everyone’s fault. TCP and UDP will never get another sibling. (See also how TLS ossified in 1.2 so that fundamental improvement was an enormous effort and 1.3 is still not universally supported.) Fortunately, UDP is pretty close to raw IP, so there’s not a great deal of difference between implementing QUIC on top of UDP and QUIC on top of IP.

> Over 5-10 years we could get 90% adoption of an entirely new network stack.

Nope, this is absolutely false; I even have a concrete counterexample: IPv6. Standardised in 1995–1998, supported by DNS since 2008, supported by all major OSes by 2011, but still unavailable to a very large fraction of internet users. (As a consumer of internet, I’ve encountered IPv6 support in one commercial internet supply in Australia, but not in any other, or any residential or cellular connection in Australia, or in a few stints in India, or in a cellular connection in the USA.)

You’re seriously overestimating the ability to get people to change. If your solution is incompatible with the past, people won’t change because no one’s using the new thing (because it’s incompatible). If your solution is compatible with the past, people won’t change because there’s no good reason to. Most of the time people will only change if there’s a compelling reason to: e.g. with HTTP/2, many adopted it because the multiplexing normally improved page load performance, and with HTTPS, many adopted it because browsers were starting to label their sites as insecure if they didn’t, and they didn’t like that.

> Face it, protocols at this layer have ossified so that TCP and UDP are your only options if you want broad compatibility—and that’s nothing to do with any one party, it’s everyone’s fault. TCP and UDP will never get another sibling.

> Nope, this is absolutely false; I even have a concrete counterexample: IPv6. Standardised in 1995–1998, supported by DNS since 2008, supported by all major OSes by 2011, but still unavailable to a very large fraction of internet users.

> You’re seriously overestimating the ability to get people to change.

I think it's just the opposite: everyone else in the world is just giving up.

Actually changing these things is not some insurmountable, inscruitable task. It's just a protocol! It's ones and zeroes! It's not rocket science, or nuclear fission (which now seems possible?). It's a crappy little specification for a communications protocol. All we have to do is do the work. It's not easy, and it's not fast, but it's also not some unknown, unseen force in the universe that we can't comprehend. It's a damn network protocol (and a simple one at that).

We know how to change it, and we know that the only thing stopping us is the will to do it and cooperation. Giving up on this change is defeatism and laziness. Can you imagine if in any other category of science or technology, researchers refused to make progress because "it's too hard to work with other people" ?

How do you propose to convince literally millions of businesses to spend at least tens or hundreds of thousands of dollars to change something deep in the technical stack that they don't understand, to achieve some nebulous slight improvement, when what they have at present works perfectly? And unless you can convince almost all of them to do it at about the same time, the old will necessarily linger (see also the compatible/incompatible problem I mentioned) and provide further disincentive. And then there are regulations that make any changes like this take an absolute minimum of five or ten years, because of multiple iterations of required regulation changes and certifications (e.g. the regulator must be convinced to allow thing Q, then manufacturer A must make and get certified product X, then manufacturer B that builds on that can make and get certified product Y, then C for Z, and finally the product you need is on the market and now you have to convince your boss you actually need to buy it).

You must have a strong lever if you wish to effect meaningful change. HTTPS adoption is a good example: browsers were in a position to honestly bully people into preferring it; and even then, it has been taking quite some years to get any substantial majority. I see no possible route whereby HTTP/3 could have succeed had QUIC been built upon IP rather than UDP.

Progress fails to happen due to inertia all the time. This is not something specific to software or hardware. The first example that springs to mind is climate change mitigation. Simply as a general observation about life, most people don't want to change what they're doing.

That was an amazing rant. I really respect the level of detail and dedication to the rant.

> The next step is going to be nobody wanting to update to IPv6.

I hate that IPv6 has such low usage, and it is exactly the same problem you describe. We have a protocol meant to replace IPv4 and eliminate several kludges (NAT) in the process. But guess what? People would rather keep on hacking the previous protocol to the extremes than learn and implement a newer better system. IPv6 is better than IPv4 in literally every sense, but your sysadmin can't be bothered to deviate even slightly from her decade old knowledge.

So now we have all sorts of v4 in v6 tunneling, someone even talked about NAT for IPv6 (WTF?!). The end result is that v6 is incredibly complex due to these backward stuff.

We need Apple to deprecate IPv4 like they did 32 bit. Otherwise companies will keep us locked into old technology for eternity.

> IPv6 is better than IPv4 in literally every sense

The addresses are harder to type, harder to yell across an office while setting up equipment, and impossible to remember. I honestly think this is it’s major failing that has prevented wider adoption. Aesthetics make a big difference, like it or mot, and IPv6 is far less accessible than IPv4.

Beyond that, IPv4 is arguably generally simpler for someone not well versed in networking to get a baseline understanding of.

I thought domain names were created so we don’t have to yell IP Addresses.

And yet if you set it up right, you don't need to type them or yell them or remember them.

> Beyond that, IPv4 is arguably generally simpler for someone not well versed in networking to get a baseline understanding of.

And BASIC is easier to program in than Rust if you're not well versed in programming.

IPv6 addresses come in 3 flavors, unicast, anycast, multicast.

Unicast addresses are for a single host, like a unique telephone number

Anycast addresses go to the nearest receiver, like 911

Multicast addresses go to a group of hosts that are listening to the address for that group, like everyone streaming the same show on Netflix at the same time.

Unicast addresses are either local to an interface/LAN/site, or global.

Anycast addresses are global.

Multicast addresses can be very local or across a wider area like a company or can be global.

You can tell what sort of address it is by the start:

* Multicast addresses start with "ff".

* LAN addresses start with "fe".

* Site (multiple LAN) addresses start with "fd"

* Anything else other than "00" is global, but some have special meanings, like "2001" is used for documentation.

There's a protocol called NDP that all the hosts use to give themselves addresses and find out how to connect to other hosts.

That's a start. The fiddly bit twiddling details can come later.

> And BASIC is easier to program in than Rust

And Visual Basic is #6 on the TIOBE rankings despite being officially retired whereas Rust is #25

Simplicity sells.

Look at XML vs JSON. XML is feature packed. Arguably the "better" format but JSON has taken over because it's way easier to use.

REST beat SOAP and XML-RPC because it was less complex and waaay easier to build.

When there is something that is easy and even potentially a little simpler than needed which does the same thing as something complex, the simple thing almost always wins - even if - or especially if - its worse. The whole "Worse is Better" mantra has always proven true.

I've said for like 20 years now that they should have just tacked a couple more octets onto IPv4 and rather than trying to reinvent the wheel.

Exhaustion was and still is the most important problem to fix. Get that out of the way, and then we could have fixed the other things wrong with IP one at a time.

We could have been on like IPv12 by now. Small iterative changes are easier to absorb. Adoption would have happened already. instead we threw the baby out with a bath water, classic second system syndrome.

The telcos use it, ISPs use it. Cloud doesn't use it yet because AWS is backwards at migrating some of their services (eg RDS). But they support IPv6 in VPCs and for ingress/egress to the internet.

Effectively they run dual stack and people are starting to realize that allocating subnets in /24 chunks is getting painful and it's much easier to allocate in /56 then /60 then /64 and that using ULAs and routing and NRDP and DNS is a much better way to do things.

IPv4 in the cloud is mostly people not wanting to understand more than 10/8 and 172.16/12 and 192.168/16.

IPv6 is actually easier but it requires learning about a new Layer 2/3 set of protocols. NDP is really better than arp/bootp/dhcp etc.

Use SLAAC and then mDNS and DNS-SD.

There was a really neat use of IPv6 on here the other day that lets you avoid the port mapping/iptables dance in K8s by treating a node as a LAN and giving each pod its own IPv6 "node area network" address. [1]

[1] https://news.ycombinator.com/item?id=25245057

> IPv6 is actually easier but it requires learning about a new Layer 2/3 set of protocols.

Exactly! It's simple to understand if you throw away the decades of cruft that has accumulated in IPv4.

ARP is a mess, half the specification is vague and everybody just does whatever they want. NDP is amazingly intuitive and sensible, but you have to stop thinking of it in terms of ARP.

Faster computers and network speed will encourage higher level of abstraction. We can't just leave all those extra performance on the table! Unused cpu cycles is wasted cycles, unused ram is wasted ram, and unsaturated bandwidth link capacity is wasted capacity! \s