<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <div class="moz-cite-prefix">On 2/18/2020 6:00 PM, Ca By wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAD6AjGTGC548zbcMsq7xzZG61-YSThXROcySwoqOPVs_jPHmSQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div>On Tue, Feb 18, 2020 at 5:44 PM Daniel Sterling <<a
          href="mailto:sterling.daniel@gmail.com" moz-do-not-send="true">sterling.daniel@gmail.com</a>>
        wrote:<br>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">I've
            AT&T fiber (in RTP, NC) (AS7018) and I notice UDP QUIC
            traffic<br>
            from google (esp. youtube) becomes very slow after a time.<br>
            <br>
            This especially occurs with ipv4 connections. I'm not the
            only one to<br>
            notice; a web search for e.g. "Extremely Poor Youtube TV
            Performance"<br>
            notes the issue.<br>
            <br>
            I assume traffic is being throttled on AT&T's side. And
            it's not done<br>
            with their CPE; I'm bypassing their NAT box and connecting
            my laptop<br>
            directly to the ONT.<br>
            <br>
            A quick google search shows people are aware that QUIC can
            look like<br>
            DoS traffic -- but how widely known is this problem? It may
            become<br>
            worse if / when sites transition to HTTP/3<br>
            <br>
            For now I reject UDP 443 on the client firewall.
            Applications using<br>
            QUIC client libraries then fallback to TCP. This works well
            and I have<br>
            no issues with latency or throughput when using TCP.<br>
            <br>
            May I naively ask if Google staff are working with AT&T
            to address this?</blockquote>
          <div dir="auto"><br>
          </div>
          <div dir="auto">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"><br>
          </div>
          <div dir="auto">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"><br>
          </div>
          <div dir="auto">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"><br>
          </div>
          <div dir="auto">So here we are.</div>
          <div dir="auto"><br>
          </div>
          <div dir="auto">Just say no to udp.<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Isn't this exactly why Net Neutrality is a thing: So that people (or
    companies) are free to develop new applications or enhance existing
    ones without running into a quagmire of different policies
    implemented by any number of different networks between the
    application developer and the application's users?<br>
    <br>
    For what it's worth, Cox cable also treats UDP traffic differently -
    impacting the performance of VPNs using UDP. Cox provides a list of
    blocked ports on their website, but makes no mention that they
    throttle or otherwise treat UDP as a special case. I'm guessing ATT
    doesn't disclose this policy transparently either.<br>
    <br>
  </body>
</html>