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.
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
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
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
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 should block UDP entirely?
Damian Menscher via NANOG wrote:
> As much as I would on principle
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
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
> 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
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
>
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
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
Yes, other than AT increasing their permitted incoming UDP traffic -- the
easiest thing AT can do -- AT 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
as
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
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
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 ipv4 residential connection (and a web search
suggests I'm not alone).
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 fiber (in RTP, NC) (AS7018) and I notice UDP QUIC traffic
>> from google (esp. youtube) becomes very slow
On Tue, Feb 18, 2020 at 5:44 PM Daniel Sterling
wrote:
> I've AT 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.
I've AT 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
Hey there everyone!
Puerto Rico IX is growing stronger each day.
This is the last utilization,
https://ibb.co/2hpp1CT
Now next question is how can we get more caches? If you are experienced
running small isps snd want to help please join our discussion @
www.puertoricoix.net
Mwhmwt
On Fri,
Some clarifications on Xbox One behavior as it pertains to game updates,
standby, and external hard drives:
If an Xbox is set to 'Instant On' mode and it has settings configured to keep
the console OS and games/apps updated, the Xbox will check for updates during
an overnight maintenance
On 2/18/20 2:25 PM, Matt Hoppes wrote:
Power goes out and the pole mounted nodes go out eventually.
Where "eventually" seems to vary a LOT. I've observed hold up times as
long as 8+ hours all the way down to "well, I guess there was a minor
power glitch at the nearest power injection point
This is already how much of the cable networks operate.
Power goes out and the pole mounted nodes go out eventually.
> On Feb 18, 2020, at 2:15 PM, Constantine A. Murenin
> wrote:
>
>> On Tue, 18 Feb 2020 at 10:10, Darin Steffl wrote:
>
>> I believe that when this happens, they should
On Tue, 18 Feb 2020 at 10:10, Darin Steffl wrote:
> I believe that when this happens, they should proactively block or limit
> video and file download/upload traffic as much as possible to make sure
> communications like calls and texts can go through with the highest success
> rate possible.
Agreed, specifically talking about small/micro cells.
Shane
On Tue, Feb 18, 2020, 2:11 PM Jared Mauch wrote:
> On Tue, Feb 18, 2020 at 02:05:15PM -0500, Shane Ronan wrote:
> > I can tell you that most carriers have neither type, at least in the US.
>
> Most towers can survive a
On Tue, Feb 18, 2020 at 02:05:15PM -0500, Shane Ronan wrote:
> I can tell you that most carriers have neither type, at least in the US.
Most towers can survive a brown/blackout lasting a few minutes
(usually enough to last the safety system cycling and the fuses blowing
on a grounded
I can tell you that most carriers have neither type, at least in the US.
Shane
On Tue, Feb 18, 2020, 1:18 PM Stephen Satchell wrote:
> There is power backup and then there is power backup.
>
> The former is a small power pack (batteries, supercapacitors, whatever)
> that will allow the
There is power backup and then there is power backup.
The former is a small power pack (batteries, supercapacitors, whatever)
that will allow the microcell to weather a short blackout or brownout.
We are talking seconds, to bridge switching transits. To be useful in a
deployment, such a
Most of the small or micro cells are there to add data capacity not necessary
device count, which are two different things.
However, where they are added to augment device count we will have problems if
they are not backed up.
As the tech shrinks and battery tech improves this will become
The feasibility of back hauling power from a central location is almost zero.
Conduit can be direct buried and then fiber shot through it, this would be
almost impossible with DC power cables.
Keep in mind that WPS already provides priority to “priority” traffic.
Shane
Sent from my iPhone
>
Net neutrality!*
*Except if someone drives through a power pole.
On Tue, Feb 18, 2020 at 11:11 AM Darin Steffl
wrote:
> Matt,
>
> You're correct that if most of these small cells goes offline during a
> power outage, the remaining macro cells would not be able to handle the
> load well.
>
>
Matt,
You're correct that if most of these small cells goes offline during a
power outage, the remaining macro cells would not be able to handle the
load well.
Data would be nearly useless and phone/texts may be sporadic.
I believe that when this happens, they should proactively block or limit
It will be interesting to see how this plays out as reliance on these small
cells for capacity grows. I'd imagine demand for cellular bandwidth goes up
during a power outage and not down.
Is it reasonable to think that there could be a situation where cell
capacity is not available during a time
32 matches
Mail list logo
