Mailing List Archive

1 2 3  View All
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
On Thu, Feb 20, 2020 at 2:11 PM Jared Mauch <jared@puck.nether.net> 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 send it to me for web / video traffic unless I block
it, I suppose we should all work together to improve my (average v4
end-user) experience.

I set up a rolling tcpdump to capture QUIC / HTTP/3 traffic.

tcpdump -C 100 -w quic -W 100 -i eth1 'udp and port 443'

I can make this dump available for inspection if (when) I organically
experience the issue again.

Is there anything else I can do to help Google or AT&T improve things?
Any magic debugging I can turn on on the client side?

Feel free to ping me off list...

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?

-- Dan
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
and just to check one thing...

On Thu, Feb 20, 2020 at 2:33 PM Daniel Sterling <sterling.daniel@gmail.com>
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 "replace your broken ISP" action that is
clearly sane and would fix this, right?

i'm assuming that this is not an option to get a functional IP layer?

t


>
> -- Dan
>
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
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 <sterling.daniel@gmail.com>
> 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 "replace your broken ISP" action that is
> clearly sane and would fix this, right?
>
> i'm assuming that this is not an option to get a functional IP layer?

often one has to live in the world of reality. if google is very worried about
the broadband experience they can continue to invest in this space and challenges.

it seems the corporate overlords has led it to not continue to persue this option.

it's hard to have it both ways, wanting unlimited UDP, low cost (free?) ports for
bits, etc..

there's natural dynamics at play here with business interests that haven't quite
balanced out yet. perhaps the LTE/5G overlay will replace fixed broadband at home
with managed CPE from the cellular providers.

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 be replaced
which seems disconnected from reality.

- jared

--
Jared Mauch | pgp key available via finger from jared@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
>
> 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 provider is not doing anything on their network that might
similarly be impacting this specific traffic. (But could very well be doing
something to impact other traffic.)


On Thu, Feb 20, 2020 at 2:53 PM Todd Underwood <toddunder@gmail.com> wrote:

> and just to check one thing...
>
> On Thu, Feb 20, 2020 at 2:33 PM Daniel Sterling <sterling.daniel@gmail.com>
> 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 "replace your broken ISP" action that
> is clearly sane and would fix this, right?
>
> i'm assuming that this is not an option to get a functional IP layer?
>
> t
>
>
>>
>> -- Dan
>>
>
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
On Thu, Feb 20, 2020 at 2:57 PM Jared Mauch <jared@puck.nether.net> 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 be replaced
> which seems disconnected from reality.

Agreed. Since I'm in RTP, I *am* lucky enough to live in an area where
there are multiple ISPs.

But not everyone is, and local-loop unbundling is no longer a thing :(

The average user is at the mercy of their local ISP. So the major
providers should (but may not have much incentive to) provide decent
service.

As has been continually noted, this issue goes away if you use v4 TCP or v6 UDP.

And one may argue that most users *will* by default have v6 UDP
connectivity from their ISP -- to Google at least.

But HTTP/3 is coming -- and site operators may not realize deploying
HTTP/3 on v4 only will break connectivity for their users.

We're currently in a limbo where v4, which had been working fine, has
been *broken* -- and not everyone uses v6.

Site operators aren't used to deploying services that break when
served over ipv4. HTTP/3 will be the first widely-deployed service
that only properly works when served from v6.

So something is going to give:

* site operators will have to deploy v6 before they deploy HTTP/3, or

* network operators will have to make v4 UDP as reliable as v4 TCP (or
block HTTP/3)

If neither happens, then as more sites start pushing v4 UDP, more and
more users will start seeing issues, even if they *do* have v6 working
well at their house.

It may become common practice to block HTTP/3 on the client side to
improve connectivity to v4-only services.

Exciting times lay ahead, indeed

-- Dan
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
> On Feb 20, 2020, at 3:30 PM, Daniel Sterling <sterling.daniel@gmail.com> wrote:
>
> On Thu, Feb 20, 2020 at 2:57 PM Jared Mauch <jared@puck.nether.net> 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 be replaced
>> which seems disconnected from reality.
>
> Agreed. Since I'm in RTP, I *am* lucky enough to live in an area where
> there are multiple ISPs.
>
> But not everyone is, and local-loop unbundling is no longer a thing :(
>
> The average user is at the mercy of their local ISP. So the major
> providers should (but may not have much incentive to) provide decent
> service.
>

Honestly, there’s part of me that wants to say be lucky you have a choice.

My options here are (1.5m DSL, fixed wireless ISP behind several layers of NAT,
Cellular data or dial-up).

“Watch this space” for my solution. Several people know what it is, but
my solution isn’t for everyone.

- Jared
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
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 <blake@ispn.net
>>> <mailto:blake@ispn.net>> wrote:
>>> Dropping udp is not from a “best practice” doc from a vendor, it is
>>> deployed by network ops folks that are trying to sleep at night.
>> I get it Ca, I happen to be one of those network ops folks that likes to
>> sleep at night. However, I've never thought it was a good practice to break
>> applications in fun ways for my customers to discover on their own and I've
>> never sold someone a 150Mbps package that actually only delivers 10Mbps for
>> certain applications. Regardless of the intent, ATT and Cox's policies are
>> not transparent, open, or neutral on this topic. This leaves us to speculate
>> on what their intentions might have been and whether their actions are an
>> appropriate response to any concerns they might have had.
> I was responsible for deploying such policies in the past, going back as
> far as the UDP/1434 filters I was forced to deploy due to persistent network
> congestion. Rolling these back took some time.
>
> The same is true for UDP policers we ended up rolling out for NTP, chargen
> and other activities.
>
> Extending these to consumer side where the traffic often originated makes
> sense until the devices can be secured. You can blame the providers for deploying
> filters, or not disconnecting consumers that have devices that can be exploited
> or whatever other reason you believe.
>
> 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 the future.
>
> - Jared

I think that's a fair statement Jared. How about this question: Would it
be reasonable for one to presume that someone purchasing a 25Mbps
internet connection might potentially want to send or receive 25Mbps of
UDP traffic? I can think of a few (not uncommon) applications where this
would be the case (VPNs, security cameras using RTP, teleconferencing,
web browsers implementing QUIC, DNS servers, hosted PBX, etc).
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
> On Feb 20, 2020, at 4:42 PM, Blake Hudson <blake@ispn.net> 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 <blake@ispn.net
>>>> <mailto:blake@ispn.net>> wrote:
>>>> Dropping udp is not from a “best practice” doc from a vendor, it is
>>>> deployed by network ops folks that are trying to sleep at night.
>>> I get it Ca, I happen to be one of those network ops folks that likes to
>>> sleep at night. However, I've never thought it was a good practice to break
>>> applications in fun ways for my customers to discover on their own and I've
>>> never sold someone a 150Mbps package that actually only delivers 10Mbps for
>>> certain applications. Regardless of the intent, ATT and Cox's policies are
>>> not transparent, open, or neutral on this topic. This leaves us to speculate
>>> on what their intentions might have been and whether their actions are an
>>> appropriate response to any concerns they might have had.
>> I was responsible for deploying such policies in the past, going back as
>> far as the UDP/1434 filters I was forced to deploy due to persistent network
>> congestion. Rolling these back took some time.
>>
>> The same is true for UDP policers we ended up rolling out for NTP, chargen
>> and other activities.
>>
>> Extending these to consumer side where the traffic often originated makes
>> sense until the devices can be secured. You can blame the providers for deploying
>> filters, or not disconnecting consumers that have devices that can be exploited
>> or whatever other reason you believe.
>>
>> 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 the future.
>>
>> - Jared
>
> I think that's a fair statement Jared. How about this question: Would it be reasonable for one to presume that someone purchasing a 25Mbps internet connection might potentially want to send or receive 25Mbps of UDP traffic? I can think of a few (not uncommon) applications where this would be the case (VPNs, security cameras using RTP, teleconferencing, web browsers implementing QUIC, DNS servers, hosted PBX, etc).

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 service for support and improved response SLA. The average user isn’t going to detect that 10% of their UDP has gone missing, nor should they be expected to.

- Jared
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
>>> 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 the future.
>>>
>>> - Jared
>> I think that's a fair statement Jared. How about this question: Would it be reasonable for one to presume that someone purchasing a 25Mbps internet connection might potentially want to send or receive 25Mbps of UDP traffic? I can think of a few (not uncommon) applications where this would be the case (VPNs, security cameras using RTP, teleconferencing, web browsers implementing QUIC, DNS servers, hosted PBX, etc).
> 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 service for support and improved response SLA. The average user isn’t going to detect that 10% of their UDP has gone missing, nor should they be expected to.
>
> - Jared
And here I think is where one crosses the threshold between providing an
"internet connection" and providing a connection "that can be used to
access specific applications or services" (as defined by your provider).
This is one step away from your ISP selling you a connection to access
Facebook, if you want to access Twitter that's available on their
premium package. Oh, you want to access Slack, sorry we don't offer that
as a package yet. Call back in a month. You need to esss-esss-achhh?
I've never heard of that, why would you want to do that?
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
> On Feb 20, 2020, at 4:53 PM, Blake Hudson <blake@ispn.net> 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 question of
>>>> what rate of UDP traffic is acceptable is a practical one for the future.
>>>>
>>>> - Jared
>>> I think that's a fair statement Jared. How about this question: Would it be reasonable for one to presume that someone purchasing a 25Mbps internet connection might potentially want to send or receive 25Mbps of UDP traffic? I can think of a few (not uncommon) applications where this would be the case (VPNs, security cameras using RTP, teleconferencing, web browsers implementing QUIC, DNS servers, hosted PBX, etc).
>> 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 service for support and improved response SLA. The average user isn’t going to detect that 10% of their UDP has gone missing, nor should they be expected to.
>>
>> - Jared
> And here I think is where one crosses the threshold between providing an "internet connection" and providing a connection "that can be used to access specific applications or services" (as defined by your provider). This is one step away from your ISP selling you a connection to access Facebook, if you want to access Twitter that's available on their premium package. Oh, you want to access Slack, sorry we don't offer that as a package yet. Call back in a month. You need to esss-esss-achhh? I've never heard of that, why would you want to do that?

AT&T has rarely offered internet service, their required devices for their U-Verse often munged traffic. I recall when you could reboot their boxes by sending SIP packets to devices behind them and it would intercept them and think it was for itself for their POTS service.

If you have any NAT/ALG in there, it’s not pure internet, but most people want access to the “web” and aren’t running ftp/finger/ytalk/uucp/sip etc.. This is why SSL VPNs on 443 became a thing over time.

- jared
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
Hello,


On Thu, 20 Feb 2020 at 21:30, Daniel Sterling <sterling.daniel@gmail.com> 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 same policies or "mitigations" for v6 traffic. As v6 adoption
increases, so will abuse/misuse, especially when attackers notice that
their attack traffic is rate-limited on v4 but not on v6 and P2P
gaming switches from v4 to v6. And at some point this will lead to
"feature parity" in IPv6. So while v6 UDP currently works, I don't
think we can assume that's permanent.

I disagree this approach is necessary to keep the network running and
the pagers from buzzing. In a much smaller eyeball environment (with
much smaller chokepoints), we have mapped possibly amplificated
packets (ip frag, dns, ntp, memcached, et all) to a specific queue.
Unless the links are congested, this traffic passes just as any other
traffic and during congestion it only uses whatever bandwidth the
queue has - no static rate-limits. I'm not saying this will fix
whatever the policies discussed here are supposed to fix, but there is
always a way to improve and make the mitigations more nuanced.

Of course ISPs will protect the network and the customers. But whether
you apply a simple rate-limiting for some traffic or some AI-assisted
auto-mitigation for traffic misuse, you gotta be prepared to monitor
and update it, staying on top of at least the major false-positives,
short-term but long-term as well. After all, things tend to change
over time.



lukas
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
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 eyeball environment (with
> much smaller chokepoints), we have mapped possibly amplificated
> packets (ip frag, dns, ntp, memcached, et all) to a specific queue.
> Unless the links are congested, this traffic passes just as any other
> traffic and during congestion it only uses whatever bandwidth the
> queue has - no static rate-limits.

That is a bad idea.

Static rate limit is necessary to discourage DoS attackers.

If the attacker send 10Mbps stream to an amplifier and the stream
is redirected to a victim at 100Mbps, 10Mbps rate limiting negates
the amplification.

Masataka Ohta
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
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
to avoid QUIC.

Masataka Ohta
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
On Thu, Feb 20, 2020 at 8:10 AM Ca By <cb.list6@gmail.com> 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 were, they choose to go on anyhow.
>
>
It isn’t like they had a choice. You can’t build a transport protocol like
QUIC on top of TCP (I know, I built one of its ancestors, which also uses
UDP underneath). And if you think getting UDP through existing networks is
hard, try using a novel IP protocol number.

Matthew Kaufman

>
>
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
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.

-d


> On Feb 20, 2020, at 7:54 PM, Matthew Kaufman <matthew@matthew.at> wrote:
>
>
>
> On Thu, Feb 20, 2020 at 8:10 AM Ca By <cb.list6@gmail.com <mailto:cb.list6@gmail.com>> 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 were, they choose to go on anyhow.
>
>
> It isn’t like they had a choice. You can’t build a transport protocol like QUIC on top of TCP (I know, I built one of its ancestors, which also uses UDP underneath). And if you think getting UDP through existing networks is hard, try using a novel IP protocol number.
>
> Matthew Kaufman
>
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
> On Feb 21, 2020, at 2:22 PM, Dan Wing <danwing@gmail.com> 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. The decision was to hide all that from network elements.

I think those design choices lead directly to these known cases where a UDP policer is encountered. I can drive along the road and not crash into the trees, but when I make a choice to deploy something without the proper safety equipment and it crashes, blaming the road seems like a poor response.

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? :-)

- Jared
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
Hi Dan!

> On 21 Feb 2020, at 20:22, Dan Wing <danwing@gmail.com> 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. The decision was to hide all that from network elements.

Because monetization of content delivery should be constrained only
for those, that are able to make new standards, while ignoring
openness and cooperation.

Google is the new AOL? With AMP, QUIC and other nice, shiny,
closed and proprietary stuff? Oh, and BTW, please sync your life
with our cloud.

Now… once we are aware, the only question is — where we go from here?


./
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
On Fri, Feb 21, 2020, 13:31 ?ukasz Bromirski <lukasz@bromirski.net> 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 top of everyone's ACL rules, and update QUIC in the next iteration to
use UDP/53.

*THAT* should solve the whole problem, once and for all.

;)

Matt
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
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 <mpetach@netflight.com> wrote:
>
>
>
> On Fri, Feb 21, 2020, 13:31 ?ukasz Bromirski <lukasz@bromirski.net <mailto:lukasz@bromirski.net>> 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 top of everyone's ACL rules, and update QUIC in the next iteration to use UDP/53.
>
> *THAT* should solve the whole problem, once and for all.
>
> ;)
>
> Matt
>
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
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, Matthew Petach <mpetach@netflight.com> wrote:
>
> ?
>
>
>> On Fri, Feb 21, 2020, 13:31 ?ukasz Bromirski <lukasz@bromirski.net> 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 top of everyone's ACL rules, and update QUIC in the next iteration to use UDP/53.
>
> *THAT* should solve the whole problem, once and for all.
>
> ;)
>
> Matt
>
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
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 altogether in favor
> of a single 16-bit client-side unique session identifier.
>
> Owen
>
>> On Feb 21, 2020, at 15:20 , Matthew Petach <mpetach@netflight.com
>> <mailto:mpetach@netflight.com>> wrote:
>>
>>
>>
>> On Fri, Feb 21, 2020, 13:31 ?ukasz Bromirski <lukasz@bromirski.net
>> <mailto:lukasz@bromirski.net>> 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 top of everyone's ACL rules, and update QUIC in the next
>> iteration to use UDP/53.
>>
>> *THAT* should solve the whole problem, once and for all.
>>
>> ;)
>>
>> Matt
>>
>
RE: QUIC traffic throttled on AT&T residential [ In reply to ]
We find that they usually impose pretty harsh QOS on a link that has an ATT voice service.

David



-----Original Message-----
From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Jay Hennigan
Sent: Thursday, February 20, 2020 12:13 AM
To: nanog@nanog.org
Subject: Re: QUIC traffic throttled on AT&T residential

On 2/18/20 18:40, nanog-list@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 - jay@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

----------------------------------------------------------------------
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
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 [ In reply to ]
No voice service on my line, or TV. Just gigabit internet.

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

-- Dan

On Thu, Feb 27, 2020, 9:10 AM Hiers, David <David.Hiers@cdk.com> wrote:

> We find that they usually impose pretty harsh QOS on a link that has an
> ATT voice service.
>
> David
>
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Jay Hennigan
> Sent: Thursday, February 20, 2020 12:13 AM
> To: nanog@nanog.org
> Subject: Re: QUIC traffic throttled on AT&T residential
>
> On 2/18/20 18:40, nanog-list@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 - jay@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>
> ----------------------------------------------------------------------
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, notify the sender immediately by
> return email and delete the message and any attachments from your system.
>
Re: QUIC traffic throttled on AT&T residential [ In reply to ]
On Mon, Mar 2, 2020 at 4:29 PM Daniel Sterling
<sterling.daniel@gmail.com> 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 (1909)
hyper-v switch! I was running Windows -> hyper-v -> openwrt, since
openwrt's kernel didn't have support for a USB NIC I'm using. I know,
this is ridiculous.

I switched to ubuntu 19.10 -> kvm -> openwrt, and ipv6 works out of the box.

Next step may be to see if I can get ipv6 working with just plain
ubuntu (and to stop using USB NICs)

-- Dan

1 2 3  View All