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@gmail.com> wrote:

On Wed, Feb 19, 2020 at 8:27 PM Masataka Ohta
<mohta@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