sync: auto-sync from HOWARD-HOME at 2026-06-18 18:50:25

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-18 18:50:25

clients/cascades-tucson/docs/network/network-optimization-master-plan.md

@@ -50,8 +50,13 @@ already too low) starves edge clients. **Sequence matters.**
   `radio-usage.sh cascades ng 77 > .claude/tmp/usage-pre.txt`.
 - Pick a watch AP per floor (`watch-ap.sh <ip>`).
 
-### PHASE 1 — QoS for voice (do FIRST; orthogonal, lowest risk, guaranteed win)
+### PHASE 1 — QoS for voice (orthogonal, lowest risk — but INSURANCE, not the everyday fix)
 Voice VLAN 30 is isolated → mark + prioritize it end-to-end so calls beat data under load.
+> **Reframe (measured 2026-06-18):** WAN1 fiber upload is **~522 Mbps** vs ~98 Mbps peak usage — huge
+> headroom, so the WAN is **not** the day-to-day voice bottleneck (that's RF, Phases 2–4). QoS still earns its
+> place as insurance for **WAN2 (coax) failover** and **rare WAN1 saturation** (you hit 680 Mbps down). Build
+> it (cheap, correct), but don't expect it to fix the complaints — the RF work does. Full design:
+> `docs/network/phase1-voice-qos-design.md`. **Phones confirmed marking DSCP EF** → rely on DSCP; subnet match is the net.
 - **UniFi (WLAN/switch):** ensure WMM/QoS on; the AudioCodes/Poly tag voice DSCP — trust/honor it. On the
   USW, voice VLAN traffic should hit the high-priority queue.
 - **pfSense:** add a traffic-shaper/limiter or floating QoS rule that puts `VOICE net (10.0.30.0/24)` DSCP EF

clients/cascades-tucson/docs/network/phase1-voice-qos-design.md

@@ -21,8 +21,21 @@ became possible because we isolated voice onto VLAN 30.
 - **Dual-WAN:** WAN1 `igc0` (Cox Fiber, primary, 1G link), WAN2 `igc3` (Cox Coax, 2.5G link); `WAN_Group`
   failover (`downlosslatency`). Shaping must be applied on **both** WAN interfaces.
 - pfSense Plus 25.07 (ALTQ shaper + dummynet limiters available).
+- **Phones mark DSCP EF — CONFIRMED (Howard 2026-06-18).** So we can rely on DSCP for WMM (Layer 2) + switch
+  QoS (Layer 3); the `10.0.30.0/24` subnet match (Layer 1) is the safety net. **No pfSense set-DSCP rule needed.**
 
-## Three layers (in priority order)
+## Measured WAN bandwidth (2026-06-18) — REFRAMES QoS priority
+- **WAN1 (fiber, primary): upload ~522 Mbps** (Cloudflare single-stream from pfSense). RRD 3-day peaks:
+  **680 Mbps down / 98 Mbps up** (actual usage).
+- **WAN2 (coax): not measurable remotely** (source-route bind to `72.211.21.217` failed; needs a WAN2-routed
+  host or the Cox bill). Coax is typically asymmetric ~20–50 Mbps up — **size its shaper conservatively**.
+- **Implication:** 30 calls ≈ ~3 Mbps. WAN1 upload (~522 Mbps) vs peak usage (98 Mbps) = **huge headroom →
+  the WAN is NOT the everyday voice bottleneck.** Everyday dropped-calls = **RF** (Phases 2–4 of the master
+  plan). **QoS here is INSURANCE, not the day-to-day fix** — it earns its keep in two cases: (1) **WAN2
+  failover** (small coax upload + a big upload → real congestion), (2) **rare WAN1 saturation** (backup /
+  large upload; you do hit 680 Mbps down). Build it (cheap, correct), but set expectations: RF is the substance.
+
+## Three layers (priority order; Layer 1 = insurance, see reframe above)
 
 ### Layer 1 — pfSense WAN shaper (PRIMARY — this is where calls break)
 **Type: HFSC** (hierarchical, lets us guarantee voice a floor while letting it borrow idle bandwidth).
@@ -47,10 +60,11 @@ critical direction for cloud-PBX voice, but do both.
 - Or manual: Firewall → Traffic Shaper → By Interface → add HFSC on WAN1 + WAN2, create the 3 queues,
   then Firewall → Rules → Floating → match `10.0.30.0/24` out → Ackqueue/Queue = qACK/qVoice.
 
-> **INPUT NEEDED (the one missing number):** the **Cox plan UPLOAD speed** for WAN1 (fiber) and WAN2 (coax).
+> **Sizing inputs:** WAN1 upload **~522 Mbps (measured 2026-06-18)** → shape `qVoice`'s parent to ~480–500
-> Shape `qVoice`'s parent to ~**90–95% of actual upload** so the queue forms in pfSense (where we control
+> Mbps. **WAN2 (coax) upload still UNKNOWN** (remote source-route test failed) — get from the Cox bill or a
-> priority), not at the ISP. The physical link is 1G/2.5G but the *plan* upload is what to shape to — get it
+> speedtest from a host routed via WAN2; size conservatively (assume ~35 Mbps up until measured). Shaping to
-> from the Cox bill / a speedtest from a LAN host. Without it the shaper can't be sized correctly.
+> ~90–95% of actual upload keeps the queue in pfSense (where we control priority), not at the ISP. WAN2 is the
+> one that actually constrains voice (on failover), so its number matters most.
 
 ### Layer 2 — UniFi WMM (the WiFi phones — Poly)
 Over the air, **WMM** maps DSCP → WiFi access categories; voice (DSCP EF/46) → **WMM Voice AC** (gets TXOP