Are you suggesting that ATT block all QUIC across their network? On Tue, Feb 18, 2020, 7:02 PM Ca By <cb.li...@gmail.com> wrote:
> > > On Tue, Feb 18, 2020 at 5:44 PM Daniel Sterling <sterling.dan...@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 >> >