One of the major problems with TCP often not mentioned is bufferbloat. TCP's common congestion avoidance algorithms usually have no precautions against bufferbloat and frequently induce it, i.e. when probing the congestion window. And those TCP congestion avoidance algorithms which do manage bufferbloat are often not deployed in public for fear of losing out to greedy congestion algorithms.

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.

The problem eventually bubbles up the stack and affects most web applications, so that a single user, just using a web application on one machine, can break the Internet for all other users on the same LAN.

Try this demo for yourself:

1. Run "ping google.com" from another computer on your LAN.

2. Upload a 10-20MB file via Gmail or Dropbox from your computer.

3. Watch the ping times on the other computer skyrocket from around 100ms to upwards of 5-10 seconds.

4. Try a Google search from any other computer on your LAN while this is happening.

Web applications which use protocols such as WebSockets have no way to reduce the bufferbloat footprint of their application, other than re-implement their own delay sensitive congestion avoidance algorithm on top. And actually, if you want to build a robust application which does any uploading (or plenty of downloading), this is what you need to do.

For example, to prevent inducing bufferbloat, Apple's software update actually uses a variant of LEDBAT (the delay sensitive congestion avoidance algorithm from BitTorrent's protocol) when downloading software updates.