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.
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.