QUIC traffic throttled on AT&T residential

Wed Feb 19 00:07:08 UTC 2020

Are you suggesting that ATT block all QUIC across their network?

On Tue, Feb 18, 2020, 7:02 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>
> 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/fe562f92/attachment.html>