Sure -- but I do value the fact that UDP + some upper layer option is better than plain TCP (essentially you can always build TCP on top of UDP but not UDP on top of TCP per-say). There's no reason that advancements in TCP cannot be "backported" to QUIC or UDP

I'd go so far as to say that it's possible TCP should always have been another layer up the stack rather than an alternative to UDP.

But coming back to concrete use cases, here's one I've been kicking around in my head lately -- it would be great to build a video calling application that relied exclusively on SFUs (so just redistributing frames, no WebRTC stuff) but only needed one port for all the traffic. It seems that HTTP/3 brings benefits to this use case, two things in particular:

- Running all off of ~one port (443/tcp or 443/udp)

- The ability to easily take advantage of a bidirectional stream with UDP semantics (I guess HTTP/2 could have done this), something we rely on WebRTC to do now.

I say this because I've felt the pain of trying to set up complicated video conferencing software and while WebRTC is awesome, it is a bit heavy weight, if you're alright with an intermediary forwarding the frames.

[EDIT]: as far as perf goes, Cloudflare has a good blog post on this: https://blog.cloudflare.com/cubic-and-hystart-support-in-qui...