Re: [NNagain] The FCC 2024 Section 706 Report, GN Docket No. 22-270 is out!

Re: [NNagain] The FCC 2024 Section 706 Report, GN Docket No. 22-270 is out!

[Livingood, Jason]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

Interesting blog post on the latency part at https://broadbandbreakfast.com/untitled-12/.

Looking at the FCC draft report, page 73, Figure 24 – I find it sort of ridiculous that the table describes things as “Low Latency Service” available or not. That is because they seem to really misunderstand the notion of working latency. The table instead seems to classify any network with idle latency <100 ms to be low latency – which as Dave and others close to bufferbloat know is silly. Lots of these networks that are in this report classified as low latency would in fact have working latencies of 100s to 1,000s of milliseconds – far from low latency.

I looked at FCC MBA platform data from the last 6 months and here are the latency under load stats, 99th percentile for a selection of ten ISPs:
ISP A  2470 ms
ISP B  2296 ms
ISP C 2281 ms
ISP D 2203 ms
ISP E  2070 ms
ISP F  1716 ms
ISP G 1468 ms
ISP H 965 ms
ISP I   909 ms
ISP J   896 ms

Jason

[-- Attachment #2: Type: text/html, Size: 3632 bytes --]

Re: [NNagain] The FCC 2024 Section 706 Report, GN Docket No. 22-270 is out!

[rjmcmahon]

> Interesting blog post on the latency part at
> https://broadbandbreakfast.com/untitled-12/.
> 
> Looking at the FCC draft report, page 73, Figure 24 – I find it sort
> of ridiculous that the table describes things as “Low Latency
> Service” available or not. That is because they seem to really
> misunderstand the notion of working latency. The table instead seems
> to classify any network with idle latency <100 ms to be low latency
> – which as Dave and others close to bufferbloat know is silly. Lots
> of these networks that are in this report classified as low latency
> would in fact have working latencies of 100s to 1,000s of milliseconds
> – far from low latency.
> 
> I looked at FCC MBA platform data from the last 6 months and here are
> the latency under load stats, 99th percentile for a selection of ten
> ISPs:
> ISP A  2470 ms
> 
> ISP B  2296 ms
> 
> ISP C 2281 ms
> 
> ISP D 2203 ms
> 
> ISP E  2070 ms
> 
> ISP F  1716 ms
> 
> ISP G 1468 ms
> 
> ISP H 965 ms
> 
> ISP I   909 ms
> 
> ISP J   896 ms
> 
> Jason

It does seem like there is a lot of confusion around idle latency vs 
working latency. Another common error is to conflate round trip time as 
two "one way delays." OWD & RTT are different metrics and both have 
utility. (all of this, including working-loads, is supported in iperf 2 
- https://iperf2.sourceforge.io/iperf-manpage.html - so there is free 
tooling out there that can help.)

Bob

Re: [NNagain] The FCC 2024 Section 706 Report, GN Docket No. 22-270 is out!

[Jack Haverty]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 3327 bytes --]

Has any ISP or regulatory body set a standard for latency necessary to 
support interactive uses?

It seems to me that a 2+ second delay is way too high, and even if it 
happens only occasionally, users may set up their systems to assume it 
may happen and compensate for it by ading their own buffering at the 
endpoints and thereby reduce embarassing glitches. Maybe this explains 
those long awkward pauses you commonly see when TV interviewers are 
trying to have a conversation with someone at a remote site via Zoom, 
Skype, et al.

In the early Internet days we assumed there would be a need for multiple 
types of service, such as a "bulk transfer" and "interactive", similar 
to analogs in the non-electronic transport systems (e.g., Air Freight 
versus Container Ship).   The "Type Of Service" field was put in the IP 
header as a placeholder for such mechanisms to be added to networks in 
the future,

Of course if network capacity is truly unlimited there would be no need 
now to provide different types of service.   But these latency numbers 
suggest that users' traffic demands are still sometimes exceeding 
network capacities.  Some of the network traffic is associated with 
interactive uses, and other traffic is doing tasks such as backups to 
some cloud.  Treating them uniformly seems like bad engineering as well 
as bad policy.

I'm still not sure whether or not "network neutrality" regulations would 
preclude offering different types of service, if the technical 
mechanisms even implement such functionality.

Jack

On 2/27/24 14:00, rjmcmahon via Nnagain wrote:
>> Interesting blog post on the latency part at
>> https://broadbandbreakfast.com/untitled-12/.
>>
>> Looking at the FCC draft report, page 73, Figure 24 – I find it sort
>> of ridiculous that the table describes things as “Low Latency
>> Service” available or not. That is because they seem to really
>> misunderstand the notion of working latency. The table instead seems
>> to classify any network with idle latency <100 ms to be low latency
>> – which as Dave and others close to bufferbloat know is silly. Lots
>> of these networks that are in this report classified as low latency
>> would in fact have working latencies of 100s to 1,000s of milliseconds
>> – far from low latency.
>>
>> I looked at FCC MBA platform data from the last 6 months and here are
>> the latency under load stats, 99th percentile for a selection of ten
>> ISPs:
>> ISP A  2470 ms
>>
>> ISP B  2296 ms
>>
>> ISP C 2281 ms
>>
>> ISP D 2203 ms
>>
>> ISP E  2070 ms
>>
>> ISP F  1716 ms
>>
>> ISP G 1468 ms
>>
>> ISP H 965 ms
>>
>> ISP I   909 ms
>>
>> ISP J   896 ms
>>
>> Jason
>
> It does seem like there is a lot of confusion around idle latency vs 
> working latency. Another common error is to conflate round trip time 
> as two "one way delays." OWD & RTT are different metrics and both have 
> utility. (all of this, including working-loads, is supported in iperf 
> 2 - https://iperf2.sourceforge.io/iperf-manpage.html - so there is 
> free tooling out there that can help.)
>
> Bob
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain


[-- Attachment #1.1.1.2: Type: text/html, Size: 5035 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2469 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

Re: [NNagain] The FCC 2024 Section 706 Report, GN Docket No. 22-270 is out!

[Jeremy Austin]

[-- Attachment #1: Type: text/plain, Size: 4052 bytes --]

On Tue, Feb 27, 2024 at 2:17 PM Jack Haverty via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> Has any ISP or regulatory body set a standard for latency necessary to
> support interactive uses?
>

I think we can safely say no. Unfortunately, no.

>
> It seems to me that a 2+ second delay is way too high, and even if it
> happens only occasionally, users may set up their systems to assume it may
> happen and compensate for it by ading their own buffering at the endpoints
> and thereby reduce embarassing glitches.  Maybe this explains those long
> awkward pauses you commonly see when TV interviewers are trying to have a
> conversation with someone at a remote site via Zoom, Skype, et al.
>

2 second delays happen more often than you'd think on "untreated"
connections. I have seen fiber connections with 15 seconds of induced
latency (latency due to buffering, not end-to-end distance.) I have seen
cable connections with 5 or 6 seconds of latency under *normal load*. This
is in the last year alone.


>
> In the early Internet days we assumed there would be a need for multiple
> types of service, such as a "bulk transfer" and "interactive", similar to
> analogs in the non-electronic transport systems (e.g., Air Freight versus
> Container Ship).   The "Type Of Service" field was put in the IP header as
> a placeholder for such mechanisms to be added to networks in the future,
>

In many other cases, high latency is a result of buffering at *every*
change in link speed. As Preseem and LibreQoS have validated, even dynamic
home and last-mile RF environments benefit significantly from flow
isolation, better drops and packet pacing, no matter the ToS field.



>
> Of course if network capacity is truly unlimited there would be no need
> now to provide different types of service.   But these latency numbers
> suggest that users' traffic demands are still sometimes exceeding network
> capacities.  Some of the network traffic is associated with interactive
> uses, and other traffic is doing tasks such as backups to some cloud.
> Treating them uniformly seems like bad engineering as well as bad policy.
>

It's not quite as simple as "traffic demands… exceeding network capacities"
when you take into account dynamic link rates. Packets are either on the
wire or they are not, and "capacity" is an emergent phenomenon rather than
guaranteed end-to-end. Microbursts guarantee that packet rates will
occasionally exceed link rates on even a high-capacity end-user connection
fed by even faster core and interchange links. Treating types of traffic
non-uniformly (when obeying other, voluntary, traffic- or offnet-generated
signals) is susceptible to the tragedy of the commons. So far we have
decent compromises, such as treating traffic according to its behavior. If
it walks and quacks like a duck…


>
> I'm still not sure whether or not "network neutrality" regulations would
> preclude offering different types of service, if the technical mechanisms
> even implement such functionality.
>
>
Theoretically L4S could be a "paid add-on", so to speak, but at this point,
the overall market is the primary differentiator — as an end user, I will
happily spend my dollars with an ISP that serves smaller plans that have
better-managed latency-under-load ("Working Latency" per Stuart Cheshire, I
believe), than one that gives me gigabit or multi-gigabit that falls on its
face when under load. It will take a long time before everyone has an
option to choose — and to your original question, better standardized
metrics are needed.

Our customers so far have not pressed us to productize
good-latency-as-a-service; they regard it as essential to customer
satisfaction and retention.

Jack
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

These are largely my opinions, not necessarily my employer's.
-- 
--
Jeremy Austin
Sr. Product Manager
Preseem | Aterlo Networks

[-- Attachment #2: Type: text/html, Size: 5877 bytes --]

Re: [NNagain] The FCC 2024 Section 706 Report, GN Docket No. 22-270 is out!

[Jack Haverty]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1795 bytes --]

On 2/26/24 07:06, Dave Taht via Nnagain wrote:
> I wish we could do a live demonstration on
> television

It's been years, but when I talked with non-techie people to help them 
understand the difference between bandwidth and latency I used a 
familiar human-human task to get the ideas across.  E.g., take a group 
of people at the end of a work session, who are trying to reach a 
consensus about where to go for lunch.  When everyone's sitting around a 
table, a quick discussion can happen and a decision reached.   Then make 
them all go to separate offices scattered around the building and 
achieve a similar consensus, communicating only by sending short notes 
to each other carried by volunteer couriers (or perhaps 140-character 
SMS texts).   The difference in "latency" and its effect on the time it 
takes to finish the task becomes clear quickly.

It seems like one could orchestrate a similar demonstration targetted 
toward a non-technical audience -- e.g., members of some government 
committee meeting in a room versus the same meeting with participants 
scattered across the building and interactions performed by staffers 
running around as "the network".   Even if the staffers can convey huge 
stacks of information (high bandwidth), the time it takes for them to 
get from one member to others (latency) quickly becomes the primary 
constraint.

This was also a good way to illustrate to non-techies how web pages 
work, and why it sometimes takes a long time to get the entire page 
loaded.   Go to the library to get the text.   Now go to the art 
department to get the banners.   Now go to the photo archives to get the 
pictures.   Now go to that customer to get the ads you promised to 
show.  .....

Jack Haverty


[-- Attachment #1.1.1.2: Type: text/html, Size: 2237 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2469 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

[NNagain] The FCC 2024 Section 706 Report, GN Docket No. 22-270 is out!

[Dave Taht]

And...

Our bufferbloat.net submittal was cited multiple times! Thank you all
for participating in that process!

https://docs.fcc.gov/public/attachments/DOC-400675A1.pdf

It is a long read, and does still start off on the wrong feet (IMHO),
in particular not understanding the difference between idle and
working latency.

It is my hope that by widening awareness of more of the real problems
with latency under load to policymakers and other submitters
downstream from this new FCC document, and more reading what we had to
say, that we will begin to make serious progress towards finally
fixing bufferbloat in the USA.

I do keep hoping that somewhere along the way in the future, the costs
of IPv4 address exhaustion and the IPv6 transition, will also get
raised to the national level. [1]

We are still collecting signatures for what the bufferbloat project
members wrote, and have 1200 bucks in the kitty for further articles
and/or publicity. Thoughts appreciated as to where we can go next with
shifting the national debate about bandwidth in a better direction!
Next up would be trying to get a meeting, and to do an ex-parte
filing, I think, and I wish we could do a live demonstration on
television about it as good as feynman did here:

https://www.youtube.com/watch?v=raMmRKGkGD4

Our original posting is here:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit

Larry's wonderful post is here:
https://circleid.com/posts/20231211-its-the-latency-fcc

[1] How can we get more talking about IPv4 and IPv6, too? Will we have
to wait another year?

https://hackaday.com/2024/02/14/floss-weekly-episode-769-10-more-internet/

-- 
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos