Those things that ossified TCP, though, are also many of the reasons that QUIC can't compete with TCP and that TCP is inherently special on the modern internet as one of only two "approved" protocols and something of a "last man standing" even among them.
If anything, the fact that a billion crappy unadjustable unmoving assumptions arent built into QUIC seems like an obvious win. TCP itself has a bunch of modern re-spins on what traffic control might possibly be better (bbr2 being a recent notable), yet there's so many legacy systems which already impeded progress & growth & basic modernization...
Conversely with QUIC, Broken shitty networking gear is about to get found out & replaced, when the modern QUIC internet takes over the vast majority of traffic & is just better. The "smart" middleboxes have long been more problems than aids, & their ancient cruft auto-magic is more hinderances in most places than than help.
Dropping & throttling UDP better will be a fine middleground, one where middleboxes have less control, but the end to end rather than hop to hop to hop protocol will adapt better.
It is fair to suggest that some of that TCP-specific infrastructure impedes progress.
However, I don't think it is fair to suggest that QUIC will do anything to fix that infrastructure. QUIC, for better and worse, intentionally kicks the can further down the road by hopping around on top of UDP infrastructure. Maybe some QUIC successor will have the guts to move things to a proper top-level protocol, but QUIC itself isn't yet that step.
Even on top of UDP, it still bypasses TCP-specific infrastructure. It will still be subject to any UDP-specific infrastructure, but that has a significantly smaller scope, at least if you exclude measures that (for better or worse) middleboxes could just as easily apply to traffic using a new top-level protocol.
Comments
If anything, the fact that a billion crappy unadjustable unmoving assumptions arent built into QUIC seems like an obvious win. TCP itself has a bunch of modern re-spins on what traffic control might possibly be better (bbr2 being a recent notable), yet there's so many legacy systems which already impeded progress & growth & basic modernization...
Conversely with QUIC, Broken shitty networking gear is about to get found out & replaced, when the modern QUIC internet takes over the vast majority of traffic & is just better. The "smart" middleboxes have long been more problems than aids, & their ancient cruft auto-magic is more hinderances in most places than than help.
Dropping & throttling UDP better will be a fine middleground, one where middleboxes have less control, but the end to end rather than hop to hop to hop protocol will adapt better.
It is fair to suggest that some of that TCP-specific infrastructure impedes progress.
However, I don't think it is fair to suggest that QUIC will do anything to fix that infrastructure. QUIC, for better and worse, intentionally kicks the can further down the road by hopping around on top of UDP infrastructure. Maybe some QUIC successor will have the guts to move things to a proper top-level protocol, but QUIC itself isn't yet that step.
Even on top of UDP, it still bypasses TCP-specific infrastructure. It will still be subject to any UDP-specific infrastructure, but that has a significantly smaller scope, at least if you exclude measures that (for better or worse) middleboxes could just as easily apply to traffic using a new top-level protocol.