Re: Should the specifications hard-refer to UDP?

[Willy Tarreau <[e-mail]>]

On Tue, Aug 18, 2020 at 02:52:14PM +1000, Mark Nottingham wrote:
> Just to add to what Martin has said - 
> 
> This reminds me of the HTTP/1.1 specification very much. A fair amount of
> effort has been put in over the years to preserve some independence from TCP,
> so that it can be layered on top of other protocols. Apparently that is
> sometimes done, but I don't think at Internet scale (i.e., between parties
> who don't have some  previous agreement).

In fact it's used quite a lot inside hosts between proxies and servers
for example, as UNIX sockets. And I predict the exact same will happen
for QUIC for the exact same reasons (no resource shortage on ports,
easier security, lower system cost etc). But each time it's done, it's
up to the implementation to know how much they deviate from the standard
and in my opinion this is what limits the risks of seeing ugly monsters
appear, because everyone tries to stick as closed as possible to the
initially chosen protocol.

If we start to be vague about what can be used underneath, while the risk
of seeing ugly things was pretty low for HTTP/1 given that it required a
stream protocol, we could expect to see really ugly stuff pretending that
anything is a datagram and could carry a QUIC packet (including ICMP or
infrared beams). I'm not saying that it's not interesting to explore these
areas, just that they are far outside of the scope of what's being done
here, and I'd rather see this explored only by those having a real interest
there.

And FWIW, yes, once we have a working QUIC in haproxy, I really hope that
we'll also support it on UNIX dgram sockets just for completeness, just like
H1 and H2 work pretty fine on UNIX stream sockets. It's just not a goal
right now, and I wouldn't want the draft to tell us how we should implement
OS-specific sockets for internal usage.

Just my two cents,
Willy