While I think Mqtt has its issues and http with response body streaming (as in gRPC) is a legit solution for many pub/sub use-cases I can’t see how quic fits in

While I think Mqtt has its issues and http with response body streaming (as in gRPC) is a legit solution for many pub/sub use-cases I can’t see how quic fits into the „resource constrained“ category: quic is a complicated protocol and implementations have to keep a lot of state around - eg the about the State of individual streams, the connection state, tracking state which information was sent in packets and has to be acknowledged, etc. Quic implementations usually do that via dynamic allocations - and pretty much all the libraries do a lot of them. For resource constrained systems you usually want the opposite: no dynamic allocations to avoid the chance to run out of memory or to be subject to memory fragmentation issues. You might be able to work around this a bit with a custom allocator that is only used by one particular library, but guarantees are still on the low end. Tcp in comparison is easier to implement with static resources. TLS is also easier, it mainly requires a full TLS frame sized buffer for sending and receiving (or at least 16kB for receiving). And still that has shown to be a big implementation hurdle for many devices.