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.

> Wait, are you thinking about using UDP to transport HTTP?! Do you even know what your MTU is?

> If you're insane and send HTTP headers in each packet, you've wasted most of your data space.

I think header in the requirement just means protocol/PDU header, which is required to deploy any kind of higher level protocol on top of UDP. Just like the UDP header and the IP headers are used at the start of data received in ethernet frames. These headers can be anything depending on the use case, even only a single or even zero bytes. The whole document does not mention that sending HTTP headers on top of UDP (which obviously could cause MTU problems, but nevertheless this kind of mechanism was standardized with CoAP).

Great, you have an expertise to contribute. And with this discussion you already are.

> If you don't know what your requirements are, you shouldn't be choosing a transport technology. It sounds like you want an library that wraps WebSockets or WebRTC and handles most of the complexity. There are "libraries" that wrap over some protocols. They don't make adoption of underlying technology easier, WebRTC in this case.

This effort is to establish clear requirements, not yet to propose exact solution. So this discussion is just a process of establishing those requirements.

High level requirements are clearly stated in the document, and important one is: simplicity. Currently there is no simple solution for low-latency server-client communication.

> > WebUDP could implement it's own [transport] layer over pure UDP > Then you want TCP. The only reason to use UDP is to avoid the complexities of a transport layer. Transport reliability is very hard; this isn't something that is easy to re-implement by yourself in UDP.

Layer on top doesn't have to involve full on replication of TCP techniques or alternatives. Just like WebSockets only adds very little to pure TCP in form of a data framing (header) for messages.

> More importantly, I take it you don't know what your MTU is? The Maximum Transmission Unit[2] the maximum packet size. On ethernet-based networks, it's probably ~0-100 octets less than ethernet's 1500 octet MTU. You need to keep UDP packets under this limit, or they will fragment. Fragmented IP packets may not arrive at all and even when they do, the OS will wait until all fragments arrive before passing the data up to the app. If you're insane and send HTTP headers in each packet, you've wasted most of your data space. Each packet? Shouldn't we send headers in the first packet only? Except that every packet IS the "first packet" in stateless protocol like UDP. It's the transport features of TCP that create ordered-data semantics.

This is really valuable input, and is exactly what is needed to fuel further requirements for an implementation.

You know, you can provide valuable input without trying to "argue" ;)