<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">This tussle has similarities to IPv6 vs IPv4.</div><div class=""><br class=""></div><div class="">-d</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 18, 2020, at 4:00 PM, Ca By <<a href="mailto:cb.list6@gmail.com" class="">cb.list6@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 5:44 PM Daniel Sterling <<a href="mailto:sterling.daniel@gmail.com" class="">sterling.daniel@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">I've AT&T fiber (in RTP, NC) (AS7018) and I notice UDP QUIC traffic<br class="">from google (esp. youtube) becomes very slow after a time.<br class=""><br class="">This especially occurs with ipv4 connections. I'm not the only one to<br class="">notice; a web search for e.g. "Extremely Poor Youtube TV Performance"<br class="">notes the issue.<br class=""><br class="">I assume traffic is being throttled on AT&T's side. And it's not done<br class="">with their CPE; I'm bypassing their NAT box and connecting my laptop<br class="">directly to the ONT.<br class=""><br class="">A quick google search shows people are aware that QUIC can look like<br class="">DoS traffic -- but how widely known is this problem? It may become<br class="">worse if / when sites transition to HTTP/3<br class=""><br class="">For now I reject UDP 443 on the client firewall. Applications using<br class="">QUIC client libraries then fallback to TCP. This works well and I have<br class="">no issues with latency or throughput when using TCP.<br class=""><br class="">May I naively ask if Google staff are working with AT&T to address this?</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Sounds like you found the answer, ATT just needs to scale up your rejection approach that is proven to work well. </div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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. </div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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. </div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">So here we are.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Just say no to udp. </div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class=""><br class="">-- Dan</blockquote></div></div></blockquote></div><br class=""></div></body></html>