[Confiks]

The tone of both of your posts is very demeaning. You completely tear down the proposal, making lots of – possibly correct – assumptions, without showing the slightest of doubt about them or any willingness to engage in a constructive debate.

And while you seemingly have a lot of experience with networking programming, and I have hardly any, I think I can easily correct you on the argument of a small MTU.

Many websites that have a more real-time networking need, currently use Websockets over a TCP channel separate from the HTTP stream. Over this channel many small messages are sent, for example updating the player's coordinates in a game. It is tolerable that some of these message may be delivered out of order or may be lost.

Wouldn't that be good fit for UDP?

Aside from that, you say that "the only reason to use UDP is to avoid the complexities of a transport layer", which I think is exactly right. You then say "transport reliability is very hard", which I can imagine it must be.

But then transport reliability is only one of the possible features of a transport layer. The whole point is that when you have access to UDP as a transport primitive, you can pick and choose which transport layer features you do and don't require on top of that.

[mentat]

There are truths about networking, whether people like them or not. They are not debatable, they are facts, so there's not a need to engage. If someone doesn't want to learn, there's not much to do.

[CyberDildonics]

This person seems to be trying to turn UDP into TCP. This seems to be because they don't understand TCP. Sometimes showing people reality isn't about being 'demeaning'.

[mrmoka]

You probably have not read the document. It's clearly stating - there is no need for reliability and ordered delivery of data. The only requirement from security point of view is congestion control. Please, do read the topic content before making assumptions.