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

[Fenwick Mckelvey <mckelveyf@gmail.com>]

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