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
