QUIC traffic throttled on AT&T residential

Wed Feb 19 00:20:39 UTC 2020

Yes, other than AT&T increasing their permitted incoming UDP traffic -- the easiest thing AT&T can do -- AT&T could ask the vendor of their flow restricting device to use bi-directional UDP traffic on same 5-tuple to indicate "desire to receive", rather than solely examining incoming UDP traffic as they are doing today; this is not easy but also not impossible.

While it is true Youtube/Google could treat AT&T-sourced connections as 'bad' and force TCP, but I am sure Youtube/Google is already gathering those statistics and already aware that AT&T is throttling.  For all we know, you and the others noticing the issue have fallen into the pit of A/B testers checking for their current throttling, and others aren't being throttled.  Perhaps it's everyone, the tests are not well described or well announced.  Youtube/Google is hoping customers complain to AT&T so that AT&T removes or improves the flow restrictor, because otherwise AT&T customers won't be able to get QUIC.  Similarly, AT&T could protect their users from AT&T's own rate limiting by blocking QUIC towards major servers that support QUIC but such blocking becomes problematic as QUIC rolls out beyond Google to Cloudflare and elsewhere.

This tussle has similarities to IPv6 vs IPv4.

-d

> On Feb 18, 2020, at 4:00 PM, Ca By <cb.list6 at gmail.com> wrote:
> 
> 
> 
> On Tue, Feb 18, 2020 at 5:44 PM Daniel Sterling <sterling.daniel at gmail.com <mailto:sterling.daniel at gmail.com>> wrote:
> I've AT&T fiber (in RTP, NC) (AS7018) and I notice UDP QUIC traffic
> from google (esp. youtube) becomes very slow after a time.
> 
> This especially occurs with ipv4 connections. I'm not the only one to
> notice; a web search for e.g. "Extremely Poor Youtube TV Performance"
> notes the issue.
> 
> I assume traffic is being throttled on AT&T's side. And it's not done
> with their CPE; I'm bypassing their NAT box and connecting my laptop
> directly to the ONT.
> 
> A quick google search shows people are aware that QUIC can look like
> DoS traffic -- but how widely known is this problem? It may become
> worse if / when sites transition to HTTP/3
> 
> For now I reject UDP 443 on the client firewall. Applications using
> QUIC client libraries then fallback to TCP. This works well and I have
> no issues with latency or throughput when using TCP.
> 
> May I naively ask if Google staff are working with AT&T to address this?
> 
> Sounds like you found the answer, ATT just needs to scale up your rejection approach that is proven to work well. 
> 
> Yes, most ddos traffic is ipv4 udp and yes Google was made aware that they would be mixing with bad company in the pool of ipv4 udp traffic ... but they have reasons. 
> 
> I am not a fan of quic or any udp traffic. My suggestion was that Google use an new L4 instead of UDP, but that was too hard for the Googlers. 
> 
> So here we are.
> 
> Just say no to udp. 
> 
> 
> 
> 
> -- Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200218/21c37df9/attachment.html>