Re: QUIC traffic throttled on AT&T residential

[Daniel Dent <nanog-list () contactdaniel net>]

On 2020-02-18 4:25 p.m., Jared Mauch wrote:
> 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.
There's plenty of room for system call/interface improvements and 
hardware acceleration in UDP stacks, both of which should help with CPU 
concerns. Now that UDP may represent a significant portion of internet 
traffic, it will be easier for the necessary engineering expense to be 
justified.
> 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.
If there's clearly a two-way flow occurring, i.e. as is the case with a 
stream of QUIC traffic, that is a clearly distinguishable case from a 
DoS where the recipient is going to be dropping traffic. While this may 
be considerably harder to implement at scale than simply throttling UDP 
indiscriminately, hopefully there can be enough user suffering that AT&T 
feels compelled to do the right thing and allow the internet to continue 
to develop new protocols. Not everything fits neatly into a 
circuit-switched head-of-line-blocking request-response/HTTP paradigm.
> 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.

Hopefully situations like this where Google swings their Chrome hammer 
for good instead of for evil can help get us there... now if we can just 
get those 100 gigabyte game downloads to get delivered over UDP too...

---

Daniel Dent

https://www.danieldent.com