Re: understanding IPv6 (was: Re: QUIC traffic throttled on AT&T residential)

On Sun, Jun 7, 2020 at 2:00 AM Fred Baker wrote: > I'm sorry you have chosen to ignore documents like RFC 3315, which is where > DHCP PD was first described (in 2003). It's not like anyone's hiding it. I am sorry as well! I openly admit I am not the smartest bear in the woods. I struggle to rea

understanding IPv6 (was: Re: QUIC traffic throttled on AT&T residential)

On Wed, Feb 19, 2020 at 7:51 PM Mark Andrews wrote: > > I have nothing against using > > v6 -- , I must admit the truth is I have no idea how to make ubuntu > > acquire a v6 -- address? block ? I don't even know the right term -- > > from uverse. > > It should just be a DHCPv6 PREFIX DELEGATION (P

Re: QUIC traffic throttled on AT&T residential

On Mon, Mar 2, 2020 at 4:29 PM Daniel Sterling wrote: > Also: I think ipv6 isn't working for me cuz it's being dropped by a switch > I'm using! > > I will swap that out / remove that and try ipv6 again OK, ipv6 is working for me now. The switch that was dropping ipv6 traffic was: Windows 10 (19

Re: QUIC traffic throttled on AT&T residential

hey usually impose pretty harsh QOS on a link that has an > ATT voice service. > > David > > > > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jay Hennigan > Sent: Thursday, February 20, 2020 12:13 AM > To: nanog@nanog.o

Re: QUIC traffic throttled on AT&T residential

On 21/02/2020 23:37, Owen DeLong wrote: > What’s next? Why not simply eliminate port numbers altogether in favor > of a single 16-bit client-side unique session identifier. I see what you did there. -- Tom

RE: QUIC traffic throttled on AT&T residential

on AT&T residential On 2/18/20 18:40, nanog-l...@contactdaniel.net wrote: > Growing prevalence of IPv6-only > sites is probably the only thing that will get a lot of access > networks to support v6. I recall a similar idea called "The Great IPv6 Experiment" back in 2007

Re: QUIC traffic throttled on AT&T residential

It's okay though, because we freed up UDP/53 by moving DNS to TCP/443, so then we can move HTTPS to UDP/53. On 2/21/20 6:37 PM, Owen DeLong wrote: First we moved the entire internet to TCP/443. Now we propose moving it all to UDP/53. What’s next? Why not simply eliminate port numbers altogeth

Re: QUIC traffic throttled on AT&T residential

At this pace and having adopted CI/CD methodology, we may QUICkly run out of UDP ports to use. I’d actually switch to ICMP. Type 8 code 0 and Type 0, code 0. Then staging a war on rate-limiters around the world. Also, 123/udp seems to look interesting ;) -- ./ > On 22 Feb 2020, at 00:21, Ma

Re: QUIC traffic throttled on AT&T residential

First we moved the entire internet to TCP/443. Now we propose moving it all to UDP/53. What’s next? Why not simply eliminate port numbers altogether in favor of a single 16-bit client-side unique session identifier. Owen > On Feb 21, 2020, at 15:20 , Matthew Petach wrote: > > > > On Fri, F

Re: QUIC traffic throttled on AT&T residential

On Fri, Feb 21, 2020, 13:31 Łukasz Bromirski wrote: > > [...] > > Now… once we are aware, the only question is — where we go from here? > > — > ./ > Well, it's clear the UDP 443 experiment wasn't entirely successful. So clearly, it's time to use the one UDP port that is allowed through at the

Re: QUIC traffic throttled on AT&T residential

Hi Dan! > On 21 Feb 2020, at 20:22, Dan Wing wrote: > > There are choices, such as making connection initiation, connection > acceptance, and connection termination parsable by network elements on the > path so state can be established, maintained, and cleared, DoS can be > identified, and so

Re: [External] Re: QUIC traffic throttled on AT&T residential

On Fri, Feb 21, 2020 at 2:22 PM Hunter Fuller wrote: > On Fri, Feb 21, 2020 at 2:42 PM Jared Mauch wrote: > > I can already hear the QUIC WG types blaming the network in abstentia, > because well, why would an operator want to keep their network functioning? > :-) > > In fairness, it's not actua

Re: [External] Re: QUIC traffic throttled on AT&T residential

On Fri, Feb 21, 2020 at 2:42 PM Jared Mauch wrote: > I can already hear the QUIC WG types blaming the network in abstentia, > because well, why would an operator want to keep their network functioning? > :-) In fairness, it's not actually functioning. For one thing, it's passing some traffic at

Re: QUIC traffic throttled on AT&T residential

> On Feb 21, 2020, at 2:22 PM, Dan Wing wrote: > > There are choices, such as making connection initiation, connection > acceptance, and connection termination parsable by network elements on the > path so state can be established, maintained, and cleared, DoS can be > identified, and so on

Re: QUIC traffic throttled on AT&T residential

There are choices, such as making connection initiation, connection acceptance, and connection termination parsable by network elements on the path so state can be established, maintained, and cleared, DoS can be identified, and so on. The decision was to hide all that from network elements. -

Re: QUIC traffic throttled on AT&T residential

On Thu, Feb 20, 2020 at 8:10 AM Ca By wrote: > > > Not indiscriminate. > > As Google was informed by network operators all along since 2014, ipv4 UDP > is a major uptime threat via DDoS to access networks. > ... > > Google choose not to be sensitive to that, they were told where the > landmines w

Re: QUIC traffic throttled on AT&T residential

Daniel Sterling 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 thought so. My point is that the problem can be another reason t

Re: QUIC traffic throttled on AT&T residential

Lukas Tribus wrote: IPv6 UDP is currently not broken, that doesn't mean v6 is the solution to this problem. It's just means the particular ISP did not yet deploy the same policies or "mitigations" for v6 traffic. It is more likely that the ISP does not support v6 at all. In a much smaller ey

Re: QUIC traffic throttled on AT&T residential

Hello, On Thu, 20 Feb 2020 at 21:30, Daniel Sterling wrote: > As has been continually noted, this issue goes away if you use v4 TCP or v6 > UDP. IPv6 UDP is currently not broken, that doesn't mean v6 is the solution to this problem. It's just means the particular ISP did not yet deploy the sam

Re: [External] Re: QUIC traffic throttled on AT&T residential

On Thu, Feb 20, 2020 at 3:45 PM Jared Mauch wrote: > I can think of many legitimate cases, but i think this is where you have > internet for everyone and internet for the tech-savvy/business split that > becomes interesting. > > I’ve generally been willing to pay more for a business class servic

Re: QUIC traffic throttled on AT&T residential

> On Feb 20, 2020, at 4:53 PM, Blake Hudson wrote: > > As a network operator my goal was always to ensure customers receive the traffic they expected, high rates of UDP were often not what they wanted. Adusting the limits may be useful but I still think the qu

Re: QUIC traffic throttled on AT&T residential

As a network operator my goal was always to ensure customers receive the traffic they expected, high rates of UDP were often not what they wanted. Adusting the limits may be useful but I still think the question of what rate of UDP traffic is acceptable is a practical one for t

Re: QUIC traffic throttled on AT&T residential

> On Feb 20, 2020, at 4:42 PM, Blake Hudson wrote: > > > > On 2/20/2020 1:10 PM, Jared Mauch wrote: >> On Thu, Feb 20, 2020 at 10:57:46AM -0600, Blake Hudson wrote: >>> On 2/20/2020 10:34 AM, Ca By wrote: On Thu, Feb 20, 2020 at 10:19 AM Blake Hudson >>> > wrote:

Re: QUIC traffic throttled on AT&T residential

On 2/20/2020 1:10 PM, Jared Mauch wrote: On Thu, Feb 20, 2020 at 10:57:46AM -0600, Blake Hudson wrote: On 2/20/2020 10:34 AM, Ca By wrote: On Thu, Feb 20, 2020 at 10:19 AM Blake Hudson mailto:bl...@ispn.net>> wrote: Dropping udp is not from a “best practice” doc from a vendor, it is deployed

Re: QUIC traffic throttled on AT&T residential

> On Feb 20, 2020, at 3:30 PM, Daniel Sterling > wrote: > > On Thu, Feb 20, 2020 at 2:57 PM Jared Mauch wrote: >> if the question is will the browser vendor (google) or the broadband >> provider (att) >> move first, i can already predict the answer. my experience (again) with >> the quic

Re: QUIC traffic throttled on AT&T residential

On Thu, Feb 20, 2020 at 2:57 PM Jared Mauch wrote: > if the question is will the browser vendor (google) or the broadband provider > (att) > move first, i can already predict the answer. my experience (again) with the > quic > wg is they seem to think there's many options and bad providers will

Re: QUIC traffic throttled on AT&T residential

> > i don't think you've addressed the "replace your broken ISP" action that > is clearly sane and would fix this, right? > The sanity presumes two things: A: That he could do so without having to change addresses as well. (Something that is still all too true for much of the US.) B: The other pr

Re: QUIC traffic throttled on AT&T residential

On Thu, Feb 20, 2020 at 02:50:58PM -0500, Todd Underwood wrote: > and just to check one thing... > > On Thu, Feb 20, 2020 at 2:33 PM Daniel Sterling > wrote: > > > I don't particularly *want* to block or advocate blocking QUIC, but if > > I keep hitting the issue and can't help people troublesho

Re: QUIC traffic throttled on AT&T residential

and just to check one thing... On Thu, Feb 20, 2020 at 2:33 PM Daniel Sterling wrote: > I don't particularly *want* to block or advocate blocking QUIC, but if > I keep hitting the issue and can't help people troubleshoot, what > other sane option have I? > i don't think you've addressed the "re

Re: QUIC traffic throttled on AT&T residential

On Thu, Feb 20, 2020 at 2:11 PM Jared Mauch wrote: > As a network operator my goal was always to ensure customers receive > the traffic they expected, high rates of UDP were often not what they wanted. Well, I wouldn't say I *want* UDP traffic, but if everyone is bound and determined to s

Re: QUIC traffic throttled on AT&T residential

On Thu, Feb 20, 2020 at 10:57:46AM -0600, Blake Hudson wrote: > On 2/20/2020 10:34 AM, Ca By wrote: > > > > On Thu, Feb 20, 2020 at 10:19 AM Blake Hudson > > wrote: > > Dropping udp is not from a “best practice” doc from a vendor, it is > > deployed by network ops folks tha

Re: QUIC traffic throttled on AT&T residential

On Thu, Feb 20, 2020 at 10:41 AM Dave Bell wrote: > > Not indiscriminate. >> > > Indiscriminate - done at random or without careful judgement. > > Considering that Daniel is complaining that QUIC is broken, it certainly > seems like some network operators are subjecting all UDP traffic on their >

Re: QUIC traffic throttled on AT&T residential

On 2/20/2020 10:41 AM, Dave Bell wrote: Not indiscriminate. Indiscriminate - done at random or without careful judgement. Considering that Daniel is complaining that QUIC is broken, it certainly seems like some network operators are subjecting all UDP traffic on their network to the sa

Re: QUIC traffic throttled on AT&T residential

On 2/20/2020 10:34 AM, Ca By wrote: On Thu, Feb 20, 2020 at 10:19 AM Blake Hudson > wrote: Your comments seem to differentiate IP4 vs IP6, but I don't believe that is relevant to the issue of an ISP throttling or breaking specific applications. If you

Re: QUIC traffic throttled on AT&T residential

> Not indiscriminate. > Indiscriminate - done at random or without careful judgement. Considering that Daniel is complaining that QUIC is broken, it certainly seems like some network operators are subjecting all UDP traffic on their network to the same policers. This feels pretty indiscriminate t

Re: QUIC traffic throttled on AT&T residential

On Thu, Feb 20, 2020 at 10:19 AM Blake Hudson wrote: > > > On 2/19/2020 3:21 PM, Daniel Sterling wrote: > > On Wed, Feb 19, 2020 at 3:34 PM Blake Hudson wrote: > >> Yeah, that was a nice surprise to find that my tethered LTE connection > >> was out performing my wired cable modem service. Of cou

Re: QUIC traffic throttled on AT&T residential

On 2/19/2020 3:21 PM, Daniel Sterling wrote: On Wed, Feb 19, 2020 at 3:34 PM Blake Hudson wrote: Yeah, that was a nice surprise to find that my tethered LTE connection was out performing my wired cable modem service. Of course, I had already signed up for a year of service and there were ear

Re: QUIC traffic throttled on AT&T residential

On Thu, Feb 20, 2020 at 9:56 AM Dave Bell wrote: > > On Thu, 20 Feb 2020 at 15:31, Ca By wrote: > >> UDP is broken >> > > I would argue that UDP isn't broken. Networks which drop it > indiscriminately are broken. > Not indiscriminate. As Google was informed by network operators all along since

Re: QUIC traffic throttled on AT&T residential

On Thu, 20 Feb 2020 at 15:57, Dave Bell wrote: > > On Thu, 20 Feb 2020 at 15:31, Ca By wrote: > >> UDP is broken >> > > I would argue that UDP isn't broken. Networks which drop it > indiscriminately are broken. > Does this errant network behaviour not impact RTP applications like video streams?

Re: Re: QUIC traffic throttled on AT&T residential {5403687}

I didn't contact you. Fuck off. On Thu, 20 Feb 2020 at 16:01, Dead.net Customer Service < d...@wmgcustomerservice.com> wrote: > Thank you for contacting Dead.net customer service. > > Our customer service team will reply to your email as soon as possible. > > Due to our current email volume, repl

Re: QUIC traffic throttled on AT&T residential

On Thu, 20 Feb 2020 at 15:31, Ca By wrote: > UDP is broken > I would argue that UDP isn't broken. Networks which drop it indiscriminately are broken.

RE: QUIC traffic throttled on AT&T residential

On Thursday, 20 February, 2020 08:31, Ca By wrote: >On Thu, Feb 20, 2020 at 8:34 AM Tom Beecher wrote: > 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 i

Re: QUIC traffic throttled on AT&T residential

On Thu, Feb 20, 2020 at 8:34 AM Tom Beecher wrote: > 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 dama

Re: QUIC traffic throttled on AT&T residential

> > 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 QU

Re: QUIC traffic throttled on AT&T residential

On 2/18/20 18:40, nanog-l...@contactdaniel.net wrote: Growing prevalence of IPv6-only sites is probably the only thing that will get a lot of access networks to support v6. I recall a similar idea called "The Great IPv6 Experiment" back in 2007. ;-) -- Jay Hennigan - j...@west.net Network E

Re: QUIC traffic throttled on AT&T residential

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

Re: QUIC traffic throttled on AT&T residential

Daniel Sterling wrote: I received a comment that maybe the issue is not AT&T's "core" network, but rather to do with the NAT device in my house. 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 u

Re: QUIC traffic throttled on AT&T residential

> On 20 Feb 2020, at 11:29, Daniel Sterling wrote: > > On Tue, Feb 18, 2020 at 11:47 PM Daniel Sterling > wrote: >> random-source-port UDP traffic does not impress the AT&T network flow >> control systems, and your DNS traffic becomes unbearably slow (or is > > I received a comment that mayb

Re: QUIC traffic throttled on AT&T residential

On Tue, Feb 18, 2020 at 11:47 PM Daniel Sterling wrote: > random-source-port UDP traffic does not impress the AT&T network flow > control systems, and your DNS traffic becomes unbearably slow (or is I received a comment that maybe the issue is not AT&T's "core" network, but rather to do with the

Re: QUIC traffic throttled on AT&T residential

On Wed, Feb 19, 2020 at 3:34 PM Blake Hudson wrote: > Yeah, that was a nice surprise to find that my tethered LTE connection > was out performing my wired cable modem service. Of course, I had > already signed up for a year of service and there were early termination > fees for cancelling... that

Re: QUIC traffic throttled on AT&T residential

Brian J. Murrell" *To: *nanog@nanog.org *Sent: *Wednesday, February 19, 2020 3:01:20 PM *Subject: *Re: QUIC traffic throttled on AT&T residential On Wed, 2020-02-19 at 13:54 -0600, Blake Hudson wrote: > > Isn't this exactly why Net Neutrality is a thing: Isn't it a "dea

Re: QUIC traffic throttled on AT&T residential

l" To: nanog@nanog.org Sent: Wednesday, February 19, 2020 3:01:20 PM Subject: Re: QUIC traffic throttled on AT&T residential On Wed, 2020-02-19 at 13:54 -0600, Blake Hudson wrote: > > Isn't this exactly why Net Neutrality is a thing: Isn't it a "dead" t

Re: QUIC traffic throttled on AT&T residential

On Wed, 2020-02-19 at 13:54 -0600, Blake Hudson wrote: > > Isn't this exactly why Net Neutrality is a thing: Isn't it a "dead" thing in the USofA? > So that people (or > companies) are free to develop new applications or enhance existing > ones > without running into a quagmire of different po

Re: QUIC traffic throttled on AT&T residential

On 2/19/2020 2:01 PM, Daniel Sterling wrote: On Wed, Feb 19, 2020 at 2:55 PM Blake Hudson wrote: I'm guessing ATT doesn't disclose this policy transparently either. they disclose it pretty transparently to their customers in the form of very slow youtube traffic when using v4 QUIC ;) Yeah

Re: QUIC traffic throttled on AT&T residential

On 2/19/20 2:54 PM, Fred Baker wrote: The argument I have heard is that residential firewalls often block anything that is*not* UDP or TCP. The question for the googlers was existential - can it work at all? I'm not sure that they "block" it, per se, though some probably do have an explicit

Re: QUIC traffic throttled on AT&T residential

On 2020-02-19 1:06 a.m., Masataka Ohta wrote: > Are you saying AT&T should block UDP entirely? No; while I don't presume to have all the answers they should at the minimum take into account how it affects the end-user (CUSTOMER!) experience when making decisions like this. (No they shouldn't bloc

Re: QUIC traffic throttled on AT&T residential

On Wed, Feb 19, 2020 at 2:55 PM Blake Hudson wrote: > I'm guessing ATT doesn't disclose this policy transparently either. they disclose it pretty transparently to their customers in the form of very slow youtube traffic when using v4 QUIC ;)

Re: QUIC traffic throttled on AT&T residential

> On Feb 18, 2020, at 4:00 PM, Ca By wrote: > > 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. The argument I have heard is that residential firewalls often block anything that is *not* UDP or T

Re: QUIC traffic throttled on AT&T residential

On 2/18/2020 6:00 PM, Ca By wrote: On Tue, Feb 18, 2020 at 5:44 PM Daniel Sterling mailto: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 i

Re: QUIC traffic throttled on AT&T residential

Christopher Morrow wrote: 2 way flow means something on your home host or home gateway. It means very little at internet scale... since, in many cases, you -> server and server -> you are not sharing many of the same links / routers / etc. Subject suggests it's retail ISP to homes, which are u

Re: QUIC traffic throttled on AT&T residential

On Wed, Feb 19, 2020 at 3:18 AM Masataka Ohta wrote: > > Christopher Morrow wrote: > > > 2 way flow means something on your home host or home gateway. > > It means very little at internet scale... since, in many cases, you -> > > server and server -> you are not sharing many of the same links / >

Re: Forest HQ Has Received Your Message: Re: QUIC traffic throttled on AT&T residential

"yes, also received" "thannks Toma!" (and nanog owner) On Wed, Feb 19, 2020 at 4:55 AM Töma Gavrichenkov wrote: > > Peace, > > nanog-ow...@nanog.org > > On Wed, Feb 19, 2020 at 12:51 PM Dave Bell wrote: > > Is anyone else receiving this spam? > Yes > > > Is there a better way to report this? > >

Re: Forest HQ Has Received Your Message: Re: QUIC traffic throttled on AT&T residential

Peace, nanog-ow...@nanog.org On Wed, Feb 19, 2020 at 12:51 PM Dave Bell wrote: > Is anyone else receiving this spam? Yes > Is there a better way to report this? nanog-ow...@nanog.org (CC'd) helped me in the past. -- Töma

Fwd: Forest HQ Has Received Your Message: Re: QUIC traffic throttled on AT&T residential

Your Message: Re: QUIC traffic throttled on AT&T residential To: *Electric Forest 2020 will take place on June 25-28, 2020.* Forest HQ has received your email. Help save precious resources by reviewing the information below and looking up common questions in The Forest Frequently Asked

Re: QUIC traffic throttled on AT&T residential

On Wed, 19 Feb 2020 at 08:18, Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Christopher Morrow wrote: > > > 2 way flow means something on your home host or home gateway. > > It means very little at internet scale... since, in many cases, you -> > > server and server -> you are not sha

Re: QUIC traffic throttled on AT&T residential

Christopher Morrow wrote: 2 way flow means something on your home host or home gateway. It means very little at internet scale... since, in many cases, you -> server and server -> you are not sharing many of the same links / routers / etc. Subject suggests it's retail ISP to homes, which are u

Re: QUIC traffic throttled on AT&T residential

Daniel Dent wrote: The explanation I got (which seems fair) from someone was that they only way to roll a new transport was to squat on some existing stuff that would make it through firewalls. If there's clearly a two-way flow occurring, Clearly, it should be DOS amplification.

Re: QUIC traffic throttled on AT&T residential

On Wed, Feb 19, 2020 at 1:28 AM Daniel Dent wrote: > > On 2020-02-18 4:25 p.m., Jared Mauch wrote: > > The members of the QUIC WG at IETF have not thought this was a problem as > > they don't observe it across the board. > > > > The cost for payloads with QUIC is much higher on the CPU side vs TC

Re: QUIC traffic throttled on AT&T residential

On 2020-02-18 4:25 p.m., Jared Mauch wrote: The members of the QUIC WG at IETF have not thought this was a problem as they don't observe it across the board. The cost for payloads with QUIC is much higher on the CPU side vs TCP as well - this is also not considered an issue either. There's ple

Re: QUIC traffic throttled on AT&T residential

Peace, On Wed, Feb 19, 2020 at 7:49 AM Daniel Sterling wrote: > May I naively ask if Google staff have considered scrapping using UDP > and instead proposing a new, first-class transport protocol that OSes > can implement on top of IP? The IETF WG did, at some point. The opinion overall I thin

Re: QUIC traffic throttled on AT&T residential

Michael Brown wrote: Blocking a (for you) undesirable option when an established fallback exists is a much better end user experience than introducing breakage into that option Are you saying AT&T should block UDP entirely? Damian Menscher via NANOG wrote: > As much as I would on principle r

Re: QUIC traffic throttled on AT&T residential

On Wed, Feb 19, 2020 at 12:51 AM Damian Menscher wrote: > [snip impressive debugging story] lol fair. I didn't umm mean to just brag -- my point was that: generally available SoHo internet is worse than mobile networks esp. for UDP traffic! > Rather than hobble your home network to work around a

Re: QUIC traffic throttled on AT&T residential

On Tue, Feb 18, 2020 at 8:48 PM Daniel Sterling wrote: [snip impressive debugging story] As much as I would on principle rather not stick to a legacy, TCP-only > home network -- > > I can say that right now, my home internet, blocking UDP 443, and > making tons of insecure DNS queries -- is the

Re: QUIC traffic throttled on AT&T residential

> On 19 Feb 2020, at 15:47, Daniel Sterling wrote: > > On Tue, Feb 18, 2020 at 8:05 PM Michael Brown wrote: >> Blocking a (for you) undesirable option when an established fallback >> exists is a much better end user experience than introducing breakage >> into that option > >> Or: I no longe

Re: QUIC traffic throttled on AT&T residential

On Tue, Feb 18, 2020 at 8:05 PM Michael Brown wrote: > Blocking a (for you) undesirable option when an established fallback > exists is a much better end user experience than introducing breakage > into that option > Or: I no longer use my ISP's IPv6 access (via 6rd) since it would cause > terrib

Re: QUIC traffic throttled on AT&T residential

On 2020-02-18 4:32 p.m., Michael Brown wrote: With blocking in these cases, QUIC falls back to TCP, Happy Eyeballs falls back to IPv4, everybody's happy. The IPv6 deployment landscape might look considerably better if browser developers were instead to work together to co-ordinate an "unhappy

Re: QUIC traffic throttled on AT&T residential

On 2020-02-18 7:07 p.m., Ross Tajvar wrote: > Are you suggesting that ATT block all QUIC across their network? Blocking a (for you) undesirable option when an established fallback exists is a much better end user experience than introducing breakage into that option When you throttle or subtly bre

Re: QUIC traffic throttled on AT&T residential

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

Re: QUIC traffic throttled on AT&T residential

On Tue, Feb 18, 2020 at 7:20 PM Dan Wing wrote: > 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. Ouch, I hope not -- do A/B tests that result in extreme performance degr

Re: QUIC traffic throttled on AT&T residential

The members of the QUIC WG at IETF have not thought this was a problem as they don't observe it across the board. The cost for payloads with QUIC is much higher on the CPU side vs TCP as well - this is also not considered an issue either. The explanation I got (which seems fair) from someone

Re: QUIC traffic throttled on AT&T residential

9On Tue, Feb 18, 2020 at 7:07 PM Ross Tajvar wrote: > > Are you suggesting that ATT block all QUIC across their network? One might argue they already *are* doing so; QUIC is essentially unusable on my AT&T ipv4 residential connection (and a web search suggests I'm not alone).

Re: QUIC traffic throttled on AT&T residential

Are you suggesting that ATT block all QUIC across their network? On Tue, Feb 18, 2020, 7:02 PM Ca By wrote: > > > On Tue, Feb 18, 2020 at 5:44 PM Daniel Sterling > wrote: > >> I've AT&T fiber (in RTP, NC) (AS7018) and I notice UDP QUIC traffic >> from google (esp. youtube) becomes very slow aft

Re: QUIC traffic throttled on AT&T residential

On Tue, Feb 18, 2020 at 5:44 PM Daniel Sterling 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. "Extr

QUIC traffic throttled on AT&T residential

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 traf