QUIC is junk.. You people all care about raw throughput but not about multiuser friendless. Selfish. Problem is, QUIC is UDP and so its hard to police/shape.
I really want to play some FPS game while someone is watching/browsing web.
Also, I really want my corpo VPN have a bit of priority over web, but no, now I cannot police it easly. TCP is good for best effort traffic, and thats where I classify web browsing, downloading, VoD streaming. UDP is good for gaming, voice/video conferencing, VPNs (because they are encapsulate stuff you put another layer somewhere else).
I feel like that’s an ungenerous characterization. First, QUIC should contain some minimal connection info unencrypted that can be middleware to do some basic traffic shaping. It’s also intentionally very careful to avoid showing too much to avoid “smart” middleware that permanently ossifies the standard as has happened to TCP.
Finally, traffic shaping on a single machine is pretty easy and most routers will prefer TCP traffic to UDP.
Finally, the correct response to overwhelm is to drop packets. This is true for TCP and UDP to trigger congestion control. Middleware has gotten way too clever by half and we have bufferbloat. To drop packets you don’t need knowledge of streams - just that you have a non-skewed distribution you apply to dropping the packets so that proportionally all traffic overwhelming you from a source gets equally likely to be dropped. This ironically improves performance and latency because well behaving protocols like TCP and QUIC will throttle back their connections and UDP protocols without throttling will just deal with elevated error rates.
So what? You dropping packets, and they are still coming, eating BW and buckets.
Because traditionally UDP did not have any flow control, you just treat is as kinda CBR traffic and so you just want to leave it queues as fast as it can.
If there was a lot of TCP traffic around, you just drop packets there and vioala, congestion kick sin and you have more room for importand UDP traffic.
Now, if you start to drop UDP packets your UX drops.. packet loss in FPS games is
terrible, even worse than a bit of jitter. Thank you.
But your complaint is about QUIC, not generic UDP. QUIC implements TCP-like flow control on top of UDP, designed to play well with TCP congestion control.
QUIC does play well with others. It's just implemented in the userspace QUIC library instead of the network stack.
I really don’t follow your complaint. QUIC (and other similar UDP protocols like uTP used for BitTorrent) implement congestion control. If packets get dropped, the sender starts backing off which makes you a “fair” player on the public internet.
As for gaming, that remains an unsolved problem, but QUIC being UDP based isn’t any different than TCP. It’s not like middleware boxes are trying to detect specific UDP applications and data flows to prioritize protecting gaming traffic from drops, which I think is what you’re asking for.
Now, I wish ToS/QoS were more broadly usable for traffic prioritization.
It sounds like you're using UDP vs. TCP as a proxy for ToS/QoS. At a minimum, you're still going to have a bad time with TCP streams getting encapsulated in UDP WireGuard VPN connections.
Is your complaint fundamentally that it's harder to tell the difference between games/voip and browser activity if you can't just sort TCP versus UDP?
That's true, but it's not that big of a deal and definitely doesn't make QUIC "junk". Looking at the port will do 90% of the job, and from what I can tell it's easy to look at a few bytes of a new UDP stream to see if it's QUIC.
The quick test is that the first packet is generally going to start with hex C[any nibble]00000001 and be exactly 1200 bytes long, ending with a bunch of 0s.
A better test is to see if the full header makes sense, extract the initial encryption key, and check if the rest of the packet matches the signature.
This is correct, you can recognize Initial packets easily/reliably, and they contain the connection IDs in plaintext so that a stateful packet filter/shaper can recognize individual data flows.
Note that packet numbers (and everything else other than port/IP) are encrypted, so you can't do more than drop or delay the packets. But blocking/shaping/QoS is perfectly doable.
I want to be clear that I was talking about checking the encryption of the very first packet, which isn't secret yet.
Once keys are already established I don't see any particularly reliable test for a single packet, but as you say the connection ids are accessible so if they're in the right place in both directions then that looks good for discovering a QUIC flow.
Somewhat the point. The issue we've had is that multiple ISPs and gov have been "policing" TCP in unsavory ways. Security and QoS are just fundamentally at odds with each other.
QoS is still possible with QUIC: initial connection IDs are in plaintext, and while you can't modify packets (or even see the packet numbers) you can drop or (ugh) delay them.
On the level of entire networks serving multiple end consumers and businesses, I really hope that ISPs get bigger pipes instead of trying to shape traffic based on type. I'm fine with making traffic shaping on a local network a little harder, if it ends up biting those who oppose net neutrality (or want to use middleboxes to screw up traffic in various technical-debt-fuelled ways).
Upvoted because I think you bring up some interesting challenges, but you might consider a softer tone in the future. (Calling the OP "selfish" goes against site guidelines, and generally doesn't make people open to what you're saying.)
That selfish was NOT the the OP. It was for general audiency who prefer all the bandwidth for themselfs. We know how most people behave. They do NOT really care what others are doing. For years, I was proud of my QoS because my entire home could utilize my (not so fast Internet) and I always could do gaming, because everything was QoS correctly. Nothing fancy, just separating TCP vs UDP and futher, doing some tuning between TCP bulk vs interactive traffic. Same went to UDP, some separation for gaming/voip/interactive vs VPN (bulk). HTB is pretty decent for this.
I don’t think they’re super valid concerns though - QUIC isn’t just dumb UDP that transmits as fast as it can, it has congestion control, pacing etc. built in that’s pretty similar to certain TCP algorithms, just it’s happening at the application layer instead of the kernel/socket layer handling it. In the design of these algorithms, fairness is a pretty key design criteria.
If anything, potentially QUIC lets people try better congestion control algorithms without having to rebuild their kernels which could make the web better if anything…
