RE: home router battery backup

Hi NANOG mailing list,

I am a graduate student, currently conducting research on how power outages affect home Internet users. I know that the FCC has a regulation since 2015 (47 CFR Section 9.20) requiring ISPs to provide an option to voice customers to purchase a battery backup for emergency voice services during power outages. As this is only an option and only applies to customers who subscribe to voice services, I was wondering if anyone had any insights on the prevalence of battery backup for home modem/routers? I.e., what percentage of home users actually install a battery backup in their home modem/router or use an external UPS?

Thanks.

Scott

Reference for 47 CFR Section 9.20: https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9/subpart-H/section-9.20

So your voice is part of the modem which isn't a router? I assume it uses IP for voice.

Mike

Yes. In our scenario the ONT is basically an ethernet bridge and provides a SIP end-point for calls. There are models that have the router built-into them as well, but we’ve chosen not to use them at this point.

The battery we install is designed to run the voice portion for ~ 8 hours (customers are offered a longer run-time battery for an additional fee). There’s some sensor wires from the ONT to the UPS so that we know when power is out, the battery is low or needs to be replaced, etc. It also tells the ONT to turn off ethernet services when the power is out to preserve battery for the phone portion. Though that behavior can be changed in software.

Does anyone have any insight as to the OS and overall capabilities of
various ONT's? Traffic shaping/QoS and statistics?

That’s usually an OMCI control thing on the OLT (traffic shaping, qos). Do you have a specific question in mind?

That's usually an OMCI control thing on the OLT (traffic shaping, qos). Do you have a specific question in mind?

My dream, of course, is fq_codel (nowadays, sch_cake) on every
potential bottleneck link. FQ for essentially zero latency for sparse
packets, AQM for achieving
far shorter queue lengths.

I'd settle for an ONT that applied ethernet pause frames sanely so a
smarter router upstream did the right things. There's a ton of smarter
routers nowadays. Any ONT's
that use pause frames and have very small onboard buffers?

Been working on getting mikrotik up to speed on this incredibly long
thread over here; some quick comments on configuring cake - MikroTik

I would have to imagine any QOS/traffic shaping is done in the OMCI and hence would probably be in the GPON spec, g.984. I would look there.

Just guessing it would hold true with XG/s/PON, NGPON, etc.

It appears that Shawn L via NANOG <shawnl@up.net> said:

In $dayjob I work for a telco that deploys fiber to the home. If we are
providing voice services over fiber a battery backup is installed (we main
tain) that powers the customer's phone in the event of a power outage.

I have fiber service from my local RLEC. The modem comes with a 12V battery
UPS which looks big enough to keep the phone and internet on for several days.

But as you say, it's the modem, not the router. If the power went out
and the UPS I have for my other equipment ran down, which would take about
half an hour, I suppose I could run an ethernet cable from my laptop to
the modem.

R's,
John

The way at least my gear (Adtran) works is that you configure shaping/policing as part of the provisioned service. That information is communicated to the ONTs via the OMCI.

AFAIK, the ONT enforces admission control on the upstream (and coordinates for timeslot assignments with the OLT since upstream oversubscription is supported and common), and the OLT enforces downstream egress control.

You can configure whether you want rate control to be based on hard policers (instantaneous drop once CIR+CBS+EIR+EBS is exceeded) or whether you want it to "shape" the traffic by delaying things. The latter is usually more user-friendly and certainly easier to set up, but it can result in bufferbloat, and they don't provide very friendly knobs to tune the maximum queue length. I haven't heard any real complaints from folks. DSLReports gives me like a C for bufferbloat but doesn't really make it clear why. The queue is, at most, a few ms in depth.

You can tell it to honor 802.1p CoS, IP ToS, or IP DSCP in various ways and map them to separate queues with separate policers/shapers and WRR priority. This is semi-automated if you are doing voice/video via their provisioning environment.

YMMV on other vendors' gear.

> I would have to imagine any QOS/traffic shaping is done in the OMCI and
> hence would probably be in the GPON spec, g.984. I would look there.
>
> Just guessing it would hold true with XG/s/PON, NGPON, etc.

The way at least my gear (Adtran) works is that you configure
shaping/policing as part of the provisioned service. That information
is communicated to the ONTs via the OMCI.

AFAIK, the ONT enforces admission control on the upstream (and
coordinates for timeslot assignments with the OLT since upstream
oversubscription is supported and common), and the OLT enforces
downstream egress control.

You can configure whether you want rate control to be based on hard
policers (instantaneous drop once CIR+CBS+EIR+EBS is exceeded) or
whether you want it to "shape" the traffic by delaying things. The
latter is usually more user-friendly and certainly easier to set up, but
it can result in bufferbloat, and they don't provide very friendly knobs
to tune the maximum queue length. I haven't heard any real complaints
from folks. DSLReports gives me like a C for bufferbloat but doesn't
really make it clear why. The queue is, at most, a few ms in depth.

The nice thing about the Codel, Cobalt, and PIE aqms is they work beautifully
with hardware flow control so long as the interval of the pause is closely tied
to the uplink's chances to transmit. I've perpetually shown off how well
fq_codel worked with the very first (and ancient) dslmodem we tried that
had minimal buffering in nearly every preso I did... (and have ranted that
"modern" ones required shaping instead and also pointed at how to do it
hw flow control very wrong as all the ethernet over powerline devices did)

so it would be cool if you could put fq_codel or cake in front of your ONT
and see if you have pause frames negotiated on your ethernet interface.

Anyway;

What I've been observing, however, in the fiber data from dslreports,
is a disturbing growth of roughly 250ms of uplink buffering in 100Mbit
fiber services:

(If you look at this data over time its otherwise quite pleasing to
see cable's massive improvements at lower tiers of service)

You can tell it to honor 802.1p CoS, IP ToS, or IP DSCP in various ways
and map them to separate queues with separate policers/shapers and WRR
priority. This is semi-automated if you are doing voice/video via their
provisioning environment.

YMMV on other vendors' gear.

Thx. I started a thread over on the cerowrt-devel mailing list on this,
it was cool to find several linux based SFPs worth playing with, Finding
a set of "common" ONTs worth configuring in a way more suited for
an fq_codel'd router (and especially not using policing) is on my mind.

On that, someone finally wrote up a little thing:

I'm still quite tempted to order a few and play myself.