"QUIC uses fundamentally the same basic congestion avoidance algorithm as TCP (QUIC's algorithm is a work in progress AFAIK) so even QUIC is still in the same b

"QUIC uses fundamentally the same basic congestion avoidance algorithm as TCP (QUIC's algorithm is a work in progress AFAIK) so even QUIC is still in the same bloat." This is one of the many disappointing aspects of QUIC apart from the whole focus on just being a replacement option for HTTP(/2). Which means being constrained by many of the problems that have plagued the web (browser) model for so long. And in the case of congestion avoidance, they've decided to just follow the TCP model despite many better techniques available in the literature. E.g. the protocol that I'm working on (see my profile) tries to figure out the buffer bloat case by tracking rtt evolution during a session. This sort of technique is not easy to do in the TCP's lock-step ack based model. But it gets easier to do if you replace lock-step acks with periodic updates from the receiver side combined with special ack packets to measure rtt more accurately. There's an opportunity available today to build a whole new networking stack from the ground up for the new (mostly mobile) use cases. The design space opens up amazingly once you look beyond the web browser as the ultimate client. I'm about to board a very long flight but I'll be happy to engage in further discussion to whoever connects directly.