nx_room_l4s.nx

nx_room_l4s.nx -- L4S DUAL-SIGNAL congestion controller (RFC 9330 family): one controller that reacts to EXPLICIT ECN telemetry (the fabric R2 / DCTCP signal) OR to a DELAY setpoint (the room BWE signal) -- whichever fires first. WHY (grounded, knowledge/research/2026-06-23-fabric-applies-to-room-and-elsewhere.md): * fabric R2 nx_fabric_cc = ECN/DCTCP: PRECISE + low setpoint, but requires the bottleneck to MARK. On a dumb-FIFO (non-ECN) path it is BLIND -> bufferbloat (exactly nx_fabric_cc's own NC2: K huge / never mark -> bloat). * room nx_room_bwe = DELAY gradient/level: works on ANY path (no router support) but a delay setpoint is coarser/looser than an explicit mark. They are COMPLEMENTARY. L4S combines them: take the ECN signal when the path marks (tight, low latency) and fall back to the delay setpoint when it does not (bounded, graceful) -- so latency stays bounded across BOTH bottleneck types, which NEITHER single signal achieves alone. That cross-path robustness is the measurable exceed. MODEL: reuses the PROVEN discrete-event link engine shape from nx_fabric_cc (R2) -- ring-buffer bottleneck queue, RTT ack delay line carrying ECN marks, per-RTT controller update, warmup + steady-state percentile histogram, independent telemetry recount (NC liar-kill). Integer-only fixed-point (no float, ecosystem law). ECN arm is DCTCP proportional (alpha EWMA). DELAY arm is a deadbeat setpoint cut: excess standing queue == excess window, so reduce cwnd by the queue overshoot. HONEST SCOPE: software link MODEL (same altitude as R1-R4), single flow, both signals idealised/RTT-coarse (the delay arm reads the bottleneck queue level as the delay proxy, the same simplification nx_room_bwe makes). This is the controller-level rung; wiring it into the live browser room (sites/nishifamily/video/app.js) + the real uplink is the separate operator-gated deploy. expect_exit: 0 license_tier: ORIGINAL