The are statistics. But those are mostly available for teams which are currently running quic in production at large scale and see the success and fallback rate

The are statistics. But those are mostly available for teams which are currently running quic in production at large scale and see the success and fallback rates. Roughly it works for > 90% of users, and you might be able to add more 9s depending on the region. Buts as you said the details are tricky, because there’s many reasons for it to fail. Network ACLs where either UDP is totally blocked or certain ports (like 443) are the obvious ones. But we’ve also experienced other issues where eg VPN setups didn’t support the minimum required MTU size for Quic. The recommendation to deal with situation where it does not work are the fallbacks you mentioned. For HTTP, both clients and servers are still expected to support lower versions for both interoperability and reliability. For other use cases creating plain TCP/TLS connections can be a fallback - even if it’s one per stream. Or running one of them and another multiplexing layer like yamux on top. I wouldn’t recommend tunneling quic over tcp or things alike - this might end up in flow control and congestion control mechanisms fighting having bad interactions and leading to poor performance. Quic assumes an unreliable datagram based transmission layer, and having a reliable layer below it will mean retransmission of data which is no longer required by the quic layer.