The members of the QUIC WG at IETF have not thought this was a problem as they don't observe it across the board.
The cost for payloads with QUIC is much higher on the CPU side vs TCP as well - this is also not considered an issue either. The explanation I got (which seems fair) from someone was that they only way to roll a new transport was to squat on some existing stuff that would make it through firewalls. We have an internet that is largely fixed around running NATs and TCP and UDP only these days. I for one find this sad and don't see a good way forward on either side. Sent from my iCar > On Feb 18, 2020, at 7:13 PM, Daniel Sterling <sterling.dan...@gmail.com> > wrote: > > 9On Tue, Feb 18, 2020 at 7:07 PM Ross Tajvar <r...@tajvar.io> wrote: >> >> Are you suggesting that ATT block all QUIC across their network? > > One might argue they already *are* doing so; QUIC is essentially > unusable on my AT&T ipv4 residential connection (and a web search > suggests I'm not alone).
