sync: auto-sync from HOWARD-HOME at 2026-06-18 19:16:07

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-18 19:16:07

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

@@ -133,13 +133,50 @@ a clean channel from the plan, 40 MHz. Verify Lauren `.202` retry drops after.
 - **min-RSSI + power interact** — raising min-RSSI while lowering power can orphan clients; tune one lever at a time.
 - **Mesh-protected APs** (`2nd Floor Atrium, CC Bridge, salon, 206 U7 Pro, 108`) — never disable; power changes only with watch.
 
-## 5. Validation methodology (so we KNOW it worked)
-- **Time-of-day controlled:** compare to the same hour on a prior day, not just before/after minutes (load varies).
-- Metrics: 2.4 retry% + cu_interf (down), 5 GHz retry on busy APs (down), satisfaction (up, recovering from 30),
-  client band split (5g→6g shift), per-voice-phone retry (Lauren, Dining, rm204/206/210).
-- Per-phase **GATE**: client counts steady, no AP offline, no new dead zone/complaint. Else rollback that step.
-- **Rollback:** every `apply-radio`/`apply-wlan` has a rollback JSON in `.claude/tmp/`; `device-control poe-cycle`
-  for a hung AP (NOT force-provision). Power-up/width-80/re-enable are all safe reversals.
+## 5. Data-driven decision framework — improve quality for ALL devices (measure → decide → adjust)
+
+**Principle (Howard 2026-06-18): every choice is made FROM measured network data, not assumptions.** Each
+change is a hypothesis; we gate it on fleet-wide metrics before keeping it or moving on. The goal is *all*
+devices (CSCNet 427 + CSC ENT 131 + Guest 13), not just the 31 voice phones.
+
+### 5.1 How each change affects the OTHER (non-voice) devices
+Almost every change targets the **shared RF environment**, so it helps everyone — voice is just the most
+sensitive canary:
+| Change | Effect on non-voice devices |
+|---|---|
+| QoS (voice VLAN priority) | **Negligible** — voice is ~3 Mbps of 522; normally zero effect; ACK queue can make others snappier under load |
+| Enable 6 GHz on CSCNet | **Positive** — 6E devices move to clean 6 GHz → faster for them + clears 5 GHz for everyone left |
+| 2.4 Low→Medium power | **Positive for ALL 2.4 devices** — undoes the over-thinning regression (IoT/printers/2.4 DirecTV get signal back) |
+| 5 GHz 80→40 MHz | **Net positive (reliability), small peak-speed cost** — density win; lone heavy transfer sees lower peak |
+| AP 103 relief | **Positive for all 16 clients on 103**, not just Lauren |
+| 2.4 1/6/11 channel plan | **Positive for all 2.4 devices** (less co-channel) |
+| Phone-side (Vertical) | Phones only — **no effect on others** |
+
+### 5.2 Trade-offs to WATCH in the data (don't help voice, hurt others)
+1. **Non-DFS 5 GHz + 5 GHz-only devices** — the DirecTV fleet + older laptops **can't use 6 GHz**, so they
+   stay on the fewer non-DFS channels. 6 GHz offloading the newer devices is what keeps this OK; **watch
+   non-DFS 5 GHz cu_total** — if it climbs, that's the signal to rebalance.
+2. **min-RSSI** affects every client on the AP — too aggressive orphans weak IoT/resident devices. Tune gently.
+3. **40 MHz** trades single-user peak for fleet reliability — right in density, but it is a trade.
+
+### 5.3 Fleet-wide metrics we pull at every gate (the data we decide on)
+Same time-of-day comparison (load varies hourly). Capture before each change and ~15 min after:
+- `live-stats.sh cascades` → per-band **avg retry%, cu_total, cu_interf, satisfaction (min/median), client counts**
+- `radio-usage.sh cascades <band>` → per-AP outliers (saturated/high-retry APs)
+- `/stat/sta` band split (2.4 / 5 / 6 distribution) + count of clients retry>15% (by band) + satisfaction<70 count
+- Per-AP: any AP whose client count drops toward ~0 in a covered area (= coverage hole)
+
+### 5.4 The GATE decision rule (per change, per zone)
+- **KEEP + proceed** only if: the target metric improved **AND** fleet-wide **satisfaction did not fall**,
+  **retry% did not rise**, band split moved the intended way, and **no AP lost its clients** (no hole).
+- **HOLD** (stop, don't expand) if: target improved but a secondary metric regressed → investigate before more.
+- **ROLLBACK that step** if: fleet-wide retry up / satisfaction down / a coverage hole / user complaint.
+- Do **one lever per zone at a time** so cause/effect is attributable (the over-thinning happened because power-down
+  + disables were stacked).
+
+### 5.5 Rollback
+Every `apply-radio`/`apply-wlan` writes a rollback JSON to `.claude/tmp/`; `device-control poe-cycle` for a hung
+AP (NOT force-provision). Power-up / width-80 / re-enable / channel-revert are all safe reversals.
 
 ## 6. Out of scope tonight (explicit)
 - **Floors 5 & 6 (MemCare)** — all RF + the MemCare voice phones (`.217/.218/.219/.220`) DEFERRED per Howard.
@@ -151,3 +188,10 @@ a clean channel from the plan, 40 MHz. Verify Lauren `.202` retry drops after.
 2. **QoS depth:** UniFi WMM + DSCP-honor only, or also a pfSense WAN priority queue/limiter for RTP? Recommendation: both (additive).
 3. **802.11r** on CSCNet: enable for seamless voice roaming, or k/v only (safer for mixed phones)? Recommendation: k/v now, test r on one phone first.
 4. Tonight's stopping point: Phases 1–2 alone are a legitimate, lower-risk night; 3–4 can be a second night.
+5. ~~**Dedicated voice SSID?**~~ — **RESOLVED 2026-06-18: NO — voice stays on the shared CSCNet PPSK.** UniFi
+   3-SSID cap (sound RF hygiene — each SSID = beacon airtime overhead at 77 APs). The only retirement candidate,
+   CSC ENT, still has **131 active clients** (staff PCs, printers, DirecTV fleet) → not retireable soon. And it's
+   not needed: **QoS is VLAN/DSCP-based (SSID-independent)**, band preference is best done **phone-side** (Vertical),
+   and roaming/power-save are phone+AP settings — all work on the shared SSID. A dedicated voice SSID would only
+   add voice-specific WiFi *policy* (per-SSID DTIM/min-RSSI/airtime), a marginal gain not worth a slot. Revisit only
+   if/when CSC ENT's 131 clients migrate off it.