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

[Rpm] 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

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

[rjmcmahon]

Thanks for sharing this. I'm trying to find out what are the key metrics 
that will be used for this monitoring. I want to make sure iperf 2 can 
cover the technical, traffic related ones that make sense to a skilled 
network operator, including a WiFi BSS manager. I didn't read all 327 
pages though, from what I did read, I didn't see anything obvious. I 
assume these types of KPIs may be in reference docs or something.

Thanks in advance for any help on this.
Bob
> 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

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

[Fenwick Mckelvey]

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

Hello from Canada,
I noticed some discussion about FCC and latency again (here and on hacker
news: https://news.ycombinator.com/item?id=39533800). A few years ago, Reza
and I spent considerable work at our national regulator, CRTC, establishing
a latency and packet loss threshold for a minimum service broadband. We
used M-Lab data to do so and I always hoped to see more work on latency as
a measure, especially because you can calculate what would be minimum
theoretical latency from an off-net IXP to a home.

You can see some of our work here:
https://www.tandfonline.com/doi/pdf/10.1080/01972243.2019.1574533 &
https://crtc.gc.ca/public/cisc/nt/NTRE061.pdf

The final decision: https://crtc.gc.ca/eng/archive/2020/2020-408.htm

Happy to offer any advice here and share some experiences if that helps.

Be good,
Fenwick

On Tue, 27 Feb 2024 at 13:32, 'rjmcmahon' via discuss <
discuss@measurementlab.net> wrote:

> Thanks for sharing this. I'm trying to find out what are the key metrics
> that will be used for this monitoring. I want to make sure iperf 2 can
> cover the technical, traffic related ones that make sense to a skilled
> network operator, including a WiFi BSS manager. I didn't read all 327
> pages though, from what I did read, I didn't see anything obvious. I
> assume these types of KPIs may be in reference docs or something.
>
> Thanks in advance for any help on this.
> Bob
> > 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to discuss+unsubscribe@measurementlab.net.
> To view this discussion on the web visit
> https://groups.google.com/a/measurementlab.net/d/msgid/discuss/3d808d9df1a6929ecfba495e75b4fc1b%40rjmcmahon.com
> .
>


-- 
Be good,
Fen

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