pfSense Traffic Shaper limiter fairness boundary without explicit mask configuration

pfSense exposes FreeBSD dummynet through the Traffic Shaper interface, where administrators create named limiters and attach them to pass rules to cap throughput on low-bandwidth links. The goal is to avoid overprovisioned hardware by enforcing a software ceiling, but only when the resulting fairness behavior is predictable.

When a limiter is applied to a pass rule without an explicit mask or queue discipline, the underlying pipe defaults to FIFO, leaving an unresolved boundary between per-pipe queue discipline and per-rule priority scheduling. Multiple flows then share the bandwidth without per-host or per-application guarantees. On asymmetric circuits, the by-source or by-destination mask choice determines whether the limiter counts individual hosts or aggregate flows, yet the GUI does not enforce a mask selection. Queue discipline defaults and limiter options vary across pfSense releases, making the exact fairness behavior for an unconfigured mask version-sensitive. The shaper also acts only after firewall rule evaluation, so it cannot override block rules, and NIC or virtualization offloads may bypass dummynet entirely.

Does an unmasked limiter on a pass rule enforce FIFO sharing across all flows, or can a single host consume the entire pipe ceiling? Which mask setting is required to guarantee per-host fairness on an asymmetric circuit without creating unintended per-flow queues? How can the default queue discipline be confirmed on a specific pfSense build before relying on it for production traffic capping?