Regarding the headline: I am pretty certain it won't fail, but that it will also take a long time to get rolled out and most likely won't see the usage rate (i

Regarding the headline: I am pretty certain it won't fail, but that it will also take a long time to get rolled out and most likely won't see the usage rate (in applications, not worldwide requests/s) of TCP and HTTP/1.1. The same already happened with HTTP/2. Even though that one is available already for many years and yields noticeable benefits for some applications, there exists only a pretty low number of compliant implementations. Other applications/services are helping themselves by being behind HTTP/2 capable proxy servers. So I suspect the main areas where we would see HTTP/3 being used is Google services and some CDNs for a while. Implementing these low level networking protocols is hard, and most organizations won't invest in the time and effort of doing it (or doing it properly). I implemented HTTP/2 for .NET (https://github.com/Matthias247/http2dotnet https://github.com/Matthias247/http2dotnet), and it was for 2 years the only compliant implementation for that ecosystem. Nevertheless it saw not a lot of interest. I suspect something similar will happen for QUIC. And regarding the IoT section: The main challenge with constrained IoT devices is memory, and not necessarily computational power. This makes implementing lots of networking protocols which require higher buffer sizes super hard up to impossible. HTTP/2 would actually be a good protocol for IoT devices, since the permanent connection and logical streams e.g. decrease the cost for TLS establishment a lot compared to HTTP/1.1. And it's a lot easier to use for some use-cases than a message-based protocol like MQTT - e.g. for RPC, or large file downloads or uploads. However the memory requirements of HTTP/2 makes it hard to deploy it for those IoT scenarios - e.g. the default stream window size implies one should have 64kB of buffering per stream - which is immense on <= 300kB RAM CPUs. The other challenge is the lack of good libraries for these constrained devices. A normally dynamically allocating like nghttp2 might not work out there, and building a real embedded implementation is again a task that nobody wants to take on.