[NNagain] some chatter about the fcc news

Nathan Simington nsimington at gmail.com
Tue Mar 19 14:27:00 EDT 2024


Hi everyone,

It goes without saying that I would prefer not to have the following candid
remarks widely disseminated :)

I'm sorry — I couldn't get to the right answer inside the FCC building on
this one. I tried to persuade our staff and my colleagues, but for almost
10 years, DC has been mentally parasitized by artificial and bogus line
speed-only measurements and the assumption that line speed is the only
relevant measurement of QoS.

The original version of the IAJA actually required symmetrical 100/100 for
program fundability. They got talked down to 100/20 largely because of
Congressional testimony, particularly by former Democratic FCC
commissioner, later Rural Utilities Service Administrator Jonathan
Adelstein, who was running WISPA at the time. There is a strong FTTH-only
constituency in DC, which has as its holy text this 8-page paper:
https://docs.fcc.gov/public/attachments/DOC-343135A1.pdf. The (specious)
analogy btw universal FTTH and rural electrification is very appealing to a
common type: nostalgic, non-technical New Dealers wanting to "make every
American a first-class digital citizen" and similar rhetoric.

The adjustment of the FCC definition of "broadband" was driven partly by
this holy-war belief and partly by the desire to harmonize with NTIA's
definitions under BEAD.

Dave is of course 100% right about the negative effects on connectivity of
bogus capacity requirements. I personally expect that many people who are
expensive to serve will be the last in line for BEAD and RDOF builds,
meaning that these programs may have no positive effects at all on their
connectivity (indeed, may hold it back.)

The only potential good news that I have to offer is that my staff knows
the score, and if they work in future administrations, they will be pushing
back on the mistaken priorities of the present admin.

Re technical depth at the agency, it's worse than you think. The OET has
great staff, but they are not politically independent and no longer enjoy
the hortatory power they had under Knapp or Dale Hatfield. Also, they are a
relatively small part of the agency. As in many politicized organizations,
they are expected to deliver to spec and otherwise shut up about policy.

The one piece of good news there is that the FCC's relevance as a media
regulator, which is part of why it became so politicized, is on the wane.
I've joked that we're turning into the "Federal Physical Connectivity
Commission," with more in common e.g. with Canada's ISED than its CRTC, but
maybe that isn't a bad thing.

We will need to get a deeper RF engineering bench to deal with HI issues in
the enormous amounts of unlicensed centimeter-wave that have been
permitted; users there are going to keep pushing upward on power levels,
and it's going to fall to us to address this. We need a network engineering
bench, period — I was horrified to learn that no one at the Commission had
any knowledge of peering and transit anymore, to say nothing of actual
implementation. I'm a peering-and-transit amateur, but no one else even
knew what I was talking about when I said things like "how do we
incentivize building in an era of unlimited settlement-free peering?",
which is a big deal considering that this was one of the fundamental
questions raised by Title II classification!

Traditionally, this was hard to staff because office and bureau budgets
were allocated based on regulatory fee collection; that's been decoupled
recently, starting with the 2018 RAY BAUM's Act, and my team has pushed
this decoupling farther every year. It just makes no sense to put 1/4+ of
the agency's budget into broadcast regulation while starving the satellite
and RF engineering sides. I also suspect that our field enforcement is
getting increasingly marginalized (in fact, Dale Hatfield warned me almost
3 years ago that that was already his impression.)

I know things are tough right now, but please feel free to email me or talk
on-list about FCC structural reforms. I and my team are listening and it
will help us to make recommendations to any future admin.

To switch gears for a second (and sorry for going off-topic,) the FCC
actually did do something really good lately:
https://docs.fcc.gov/public/attachments/FCC-24-26A1.pdf. There's a lot to
chew on in this thing, but I think the key wins are:

1) No federal pre-emption. If someone harms you by not living up to their
security label commitments, you can take them to state court under a
contract or negligence theory. For the first time, you can really
discipline your equipment vendors! (The FCC can also go after them on its
own initiative.)

2) Disclosure of OTA patch-support periods. At time of sale, a vendor has
to provide a minimum date for OTA patch support, and by getting a label,
they assume a duty to patch critical vulnerabilities through that period.

3) No safe harbors. If you suffer harm through a vendor's failure to live
up to their label commitments, the label will not protect them.

4) Protection of open source/third-party firmware. Installing new software
or firmware on a device does not void the representations in a label. For
example, installing your own queue and buffer management system on a router
does not free the company from its duty to keep the radio components
patched or to secure internal data traffic.

I have high hopes that the next version of the label will focus on
industrial techs and other non-consumer-facing applications. Also,
addressing security at the consumer level should cause better practices to
propagate through the entire wireless networking industry.

I mention this because we couldn't have done this without Dave, Hacker
News, and many discussions with the tech community. I will be posting a one
page round-up to HN this week and I hope that everyone jumps on to tell us
how to do the next phase better! Tech consultation works, we just need to
pull our heads out of our [REDACTED] and actually do it!

All best--
Nathan

On Tue, Mar 19, 2024 at 11:50 AM Dave Taht via Nnagain <
nnagain at lists.bufferbloat.net> wrote:

> from brett glass:
>
>
> https://www.broadband.io/c/get-broadband-grant-alerts-news/it-s-on-fcc-officially-increases-its-broadband-speed-requirement-to-100-20-mbps#comment_wrapper_32464006
>
> This decision is the equivalent of saying, “If you don’t have a
> Cadillac, you don’t have a car.”
>
> It also confuses “speed” (an ill-defined term) with capacity, latency,
> jitter, and other factors which do matter, and ridiculously overstates
> the amount of bandwidth needed for common Internet activities. Unless,
> of course, the service is very bad, in which case you can compensate
> somewhat - not completely - by throwing more bandwidth at the problem.
>
> In short, it’s a bad decision, made by politicians who have most
> likely been deceived by corporate lobbyists, rather than the sort of
> rational decision that would be made if the FCC were an apolitical
> expert agency. Or if the Commissioners had even consulted a
> knowledgeable practicing network engineer. (Are there any engineers
> left at the FCC? Or have most of them, like Julie Knapp, retired after
> being frustratingly ignored?)
>
> For my company, a WISP, it means deploying more expensive equipment
> than I need to, when folks don’t need the capacity. (Our quality is so
> good that most of our customers peak at 5-10 Mbps of capacity - the
> data rate is still typically 200-500 Mbps - and don’t need to pay for
> more, though some do.) This depletes capital, needlessly increases the
> cost of broadband service and discourages uptake of service (we still
> see a lot of folks who rely entirely on cell phones and tethering).
> Yet another example of destructive overregulation and government
> bureaucracy. Government should stay out of the broadband business and
> quit meddling with it. It’s not competent and is doing a LOT more harm
> than good.
>
>
> --
> https://www.youtube.com/watch?v=N0Tmvv5jJKs Epik Mellon Podcast
> Dave Täht CSO, LibreQos
> _______________________________________________
> Nnagain mailing list
> Nnagain at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>


-- 
Nathan Simington
cell: 305-793-6899
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/nnagain/attachments/20240319/1bf85b66/attachment-0001.html>


More information about the Nnagain mailing list