QUIC traffic throttled on AT&T residential

Tom Beecher beecher at beecher.cc
Thu Feb 20 14:33:19 UTC 2020


>
> I only wish I were insane; but from where I'm sitting, QUIC has broken
> my internet, and the resolution is blocking QUIC.
>

The QUIC protocol itself isn't breaking anything ; some middlebox is
breaking QUIC. It's likely collateral damage from honest attempts to
mitigate bad stuff. Blocking QUIC at your home edge surely helps to some
degree, but the upstream issue still remains.

I recall reading a draft from the WG about having things open a
parallel TCP connection in case UDP got horked for seamless fallback, but I
don't remember if it ever moved past that, or if anyone actually
implemented it.


On Wed, Feb 19, 2020 at 11:33 PM Daniel Sterling <sterling.daniel at gmail.com>
wrote:

> On Wed, Feb 19, 2020 at 8:27 PM Masataka Ohta
> <mohta at necom830.hpcl.titech.ac.jp> wrote:
> > A problem of QUIC with NAT is that existing NAT can not detect
> > graceful shutdown of QUIC and must depends on timeout.
> >
> > So, port numbers may be used up before timeout.
>
> Hmm, this is not what is happening.
>
> I managed to (fairly easily!) reproduce the issue earlier tonight. I
> generated a fair bit of UDP traffic via xbox, a corporate VPN, and
> youtube over quic.
>
> Sure enough, after about 45 minutes, the YouTube app on my iPad paused
> and then auto-reset the stream quality to "144p" resolution.
>
> I was able to set it back to 720p60, but that only lasted about 2
> minutes before the stream stopped playing. I waited several minutes
> for it to resume; it did not. So, I then blocked UDP 443 on my router.
> The video then *immediately* resumed at 720p60.
>
> I didn't run tcpdump but I did grab some screenshots of iftop. It
> looks like my iPad connected to AS15169 with a single UDP connection.
> I see one consistent source and dest IP / port combo for those 10s of
> minutes, up until UDP is blocked. Local port 58053, remote port 443 on
> the same IP for the whole time.
>
> At first the connection averages around 2mbps; when the issue occurs,
> I see it has dropped to a rate of under 200kbps.
>
> I've no idea what to make of that. Surely Google isn't throttling
> their traffic to me? If so why allow a fallback to TCP?
>
> When I originally discovered this issue, I was of course not trying to
> do anything odd with my internet connection. And I didn't immediately
> know QUIC was the issue.
>
> Only after it happened several times did I dig into the traffic and
> then block QUIC, and I was shocked to see that both resolve the issue
> and prevent its recurrence.
>
> So again -- I hit this issue repeatedly without trying to --
>
> And just now, I was able to reproduce it simply by generating a bit of
> UDP traffic on purpose!
>
> I only wish I were insane; but from where I'm sitting, QUIC has broken
> my internet, and the resolution is blocking QUIC.
>
> -- Dan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200220/46978500/attachment.html>


More information about the NANOG mailing list