TP6 beantwortet: CAKE ist baubar, wirkt -- und reicht nicht an die Ursache

Korrigiert den Befund von heute Nacht. Der stand so nicht richtig da.

WAS FALSCH WAR: "der CRS326 fuehrt keine Software-Queue". Die These stuetzte sich
auf zwei eigene Testfehler und ist widerlegt. ipv4-fast-path-active=no und
fasttrack-packets=0 belegen sogar, dass die CPU jedes Paket im Slow Path sieht --
die Hardware war nie die Grenze.

WAS RICHTIG IST (MikroTik-Doku, woertlich): "Interface HTB will not work correctly
when the out-interface is hardware offloaded and the bridge Fast Path is not
active." Das war die Ursache der wirkungslosen Queue auf parent=vlan100. Ueber
parent=global + mangle mark-packet funktioniert CAKE einwandfrei:
  6.040.563 Bytes gezaehlt
  cake-bandwidth=7000000 -> Durchsatz faellt 9,3 auf 7,78 Mbit
Sie zaehlt UND drosselt. Es scheitert nicht am Bau.

Die zweite "Gegenprobe" von heute Nacht war ebenfalls untauglich: Simple Queue auf
10.40.0.0/16 laeuft im Postrouting NACH src-nat, wo die Quelle laengst die WAN-IP
ist. Sie konnte nie matchen und bewies nichts.

DER BEFUND, DER TP6 BEENDET -- A/B, gleicher Client, Minuten auseinander:
  ohne CAKE                     42,4 ms
  CAKE 8,5 Mbit (88 %)          43,3 ms
  CAKE 7   Mbit (73 %)          44,0 ms
  CAKE 5   Mbit (52 %)          44,6 ms   (idle 12,9 ms)

Selbst bei halber Linerate keine Verbesserung -- und dort MUSS die Warteschlange im
Router liegen. Die ~30 ms entstehen stromabwaerts im Arris/DOCSIS-Uplink, wo
Request/Grant-Scheduling auf MAC-Layer sitzt und gar keine Queue ist. Das kann kein
Shaper im Router beheben. Die max-Werte steigen mit haerterer Drosselung
(53 -> 94 -> 148 ms): die eigene Queue waechst, die DOCSIS-Latenz bleibt.

EMPFEHLUNG: TP6 schliessen. Nicht mangels Nutzen, sondern weil das Werkzeug nicht an
die Ursache reicht -- ein staerkeres Ergebnis als das "marginal" von 2026-06-16.
Weder hw-offload opfern noch Chip-QoS ist noetig; der Global-HTB-Weg braucht beides
nicht. Es lohnt nur nicht.

Am Geraet steht weiterhin die wirkungslose Interface-Queue (qos-wan-up), in der SoT
und compliant, aber ohne Funktion -- markiert, gehoert beim Abschluss entfernt.
Alle Testaenderungen liefen als Transaktion, alle zurueckgebaut, 100/100 compliant.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -421,51 +421,58 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **(b) Live-Torch als Ad-hoc-Observability:** DNS ist bei direktem 1.1.1.1 blind, **Flows nicht** (NATen über ap1). `torch` auf `vlan30`/`vlan50` gefiltert auf die Geräte-IP zeigt Ziel-IPs live (Versuni → AWS `eu-west-1` IoT erkennbar). Voraussetzung: Gerät aktiv. Merkregel: Airfryer nur online wenn er kocht → Capture ans Einschalten koppeln.
 - **Abh.:** UNTRUSTED-Move des Airfryers (Kandidat, s. VLAN50) + TP5-Deny-by-default. Kein Blocker.
 
-### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ 🔴 **GEBAUT 2026-08-23 — UND NACHWEISLICH WIRKUNGSLOS. Der CRS326 fuehrt keine Software-Queue.**
-> 🔴 **Der Befund, der TP6 neu stellt (2026-08-23):** CAKE ist gebaut, deployt und compliant
-> (100/100) — **und es passiert nichts.** Drei unabhaengige Belege am Geraet:
+### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ 🟢 **BEANTWORTET 2026-08-23: CAKE ist baubar, wirkt technisch — und hilft nicht. Der Puffer gehoert nicht uns.**
+> 🔴 **A/B gemessen, gleicher Client, gleiche Methode, Minuten auseinander:**
 >
-> | Beleg | erwartet | gemessen |
-> |---|---|---|
-> | `/queue tree` Zaehler nach 6 MB Client-Upload | > 0 Bytes | **0 Bytes** |
-> | Simple Queue auf `10.40.0.0/16` (Gegenprobe) | > 0 Bytes | **0 Bytes** |
-> | Upload-Durchsatz gegen `cake-bandwidth=8.5Mbps` | <= 8,5 Mbit | **9,48 Mbit** |
+> | Konfiguration | avg Latenz unter Upload-Last |
+> |---|---|
+> | ohne CAKE | **42,4 ms** |
+> | CAKE 8,5 Mbit (88 % der Linerate) | 43,3 ms |
+> | CAKE 7 Mbit (73 %) | 44,0 ms |
+> | **CAKE 5 Mbit (52 %)** | **44,6 ms** |
 >
-> Der dritte ist der harte: die Queue **drosselt nicht**, sie zaehlt nicht, sie wirkt nicht.
-> Das ist kein Zaehler-Anzeigeproblem, sondern die Sache selbst.
+> idle 12,9 ms. **Selbst bei halber Linerate aendert sich nichts** — und dort muss die
+> Warteschlange zwingend im Router liegen, der Modem-Puffer also leer bleiben. Die ~30 ms
+> Zusatzlatenz entstehen damit **stromabwaerts**: im Arris/DOCSIS-Uplink, wo das
+> Request/Grant-Scheduling auf MAC-Layer sitzt und gar keine Warteschlange ist.
+> **Das kann keine Queue im Router beheben.** Nebenbefund: die max-Werte *steigen* mit
+> haerterer Drosselung (53 → 94 → 148 ms) — die eigene Queue wird laenger, die DOCSIS-Latenz
+> bleibt. ⚖️ **Empfehlung: TP6 schliessen — nicht mangels Nutzen, sondern weil das Werkzeug
+> nicht an die Ursache reicht.** Das ist ein staerkeres Ergebnis als „marginal“ von 2026-06-16.
 >
-> **Sehr wahrscheinliche Ursache (nicht abschliessend bewiesen):** `crs326-core` ist ein
-> **CRS326 mit Marvell-98DX3236-Switch-Chip**. Die Bridge faehrt `hw-offload` (`H`-Flag auf
-> ether16), **alle** Ports stehen auf `only-hardware-queue`, das Bridge-Interface auf
-> `no-queue`. Ein Geraet, dessen Ports der Switch-Chip bedient, hat an dieser Stelle keine
-> Software-Queue, in der ein Scheduler arbeiten koennte. Passend dazu: `l3-hw-offloading=no`
-> und `qos-hw-offloading=no` — die CPU *routet* zwar (die Firewall zaehlt 32,9 Mio Pakete),
-> aber die Serialisierung passiert im Chip.
+> ✅ **Dass CAKE technisch funktioniert, ist dabei bewiesen, nicht angenommen:** Global-HTB
+> zaehlte 6.040.563 Bytes, und bei `cake-bandwidth=7000000` fiel der Durchsatz von 9,3 auf
+> **7,78 Mbit**. Sie zaehlt *und* drosselt. Es scheitert nicht am Bau.
 >
-> 🔎 **Kontrollen, die ausgeschlossen sind:** kein WARP auf dem Testclient (Default-Route
-> `10.40.20.1`, en0); der Verkehr lief ueber den Core; Fasttrack ist ohnehin tot (0 von 445).
-> Zwei eigene Testfehler sind dokumentiert und korrigiert: ein `parent=global`-Tree **ohne**
-> `packet-mark` faengt per Definition nichts, und `target=0.0.0.0/0` wird von RouterOS
-> stillschweigend zu `target=""` verworfen — beide sahen wie Befunde aus und waren keine.
+> 🔴 **KORREKTUR der ersten Fassung dieses Abschnitts (ebenfalls 2026-08-23):** dort stand
+> „der CRS326 fuehrt keine Software-Queue“ — **das war falsch** und stuetzte sich auf zwei
+> eigene Testfehler. Richtig ist praeziser:
+> - **`/queue tree parent=<interface>` ist bei hw-offloadetem out-interface wirkungslos.**
+>   MikroTik dokumentiert das: *„Interface HTB will not work correctly when the out-interface
+>   is hardware offloaded and the bridge Fast Path is not active.“* Das war die echte Ursache
+>   der ersten, wirkungslosen Queue auf `parent=vlan100`.
+> - **`/queue tree parent=global` + `packet-mark` wirkt sehr wohl** — die HTB Global sitzt im
+>   IP-Stack, nicht an der Interface-Queue. Rezept: `mangle chain=postrouting
+>   out-interface=vlan100 action=mark-packet` (postrouting laeuft **vor** src-nat, die
+>   LAN-Quelle ist dort noch sichtbar), dann Tree auf `parent=global`.
+> - **Die Simple-Queue-„Gegenprobe“ auf `10.40.0.0/16` war untauglich:** die Reihenfolge ist
+>   mangle postrouting → **src-nat** → HTB Global → simple queues. Zum Zeitpunkt der Simple
+>   Queue ist die Quelle laengst die WAN-IP; das Target konnte nie matchen.
+> - `ipv4-fast-path-active: no` und `ipv4-fasttrack-packets: 0` belegen zudem: die CPU sieht
+>   jedes Paket im Slow Path. Die Hardware war nie die Grenze.
+> Details und die restlichen Sackgassen: Memory `ref_queue_htb_platzierung_docsis`.
 >
-> ⚖️ **Damit ist die offene Frage nicht mehr „lohnt CAKE“, sondern „geht CAKE auf dieser
-> Hardware ueberhaupt“.** Drei Wege, keiner geschenkt:
-> 1. **`hw-offload` auf dem WAN-Pfad abschalten** — dann sieht die CPU den Verkehr und die
->    Queue greift. Preis: der Switch-Chip faellt fuer diesen Pfad aus, die 800-MHz-CPU traegt
->    ihn allein. Bei 9,6 Mbit WAN plausibel, **aber die Inter-VLAN-Messung dazu steht bis
->    heute aus** (dieselbe offene Messung wie in §4.2 zu Fasttrack).
-> 2. **QoS auf den Switch-Chip legen** (`qos-hw-offloading`) — kann Priorisierung, **kein
->    CAKE**. Waere ein anderes, aermeres Werkzeug.
-> 3. **TP6 schliessen** — mit dem staerksten Argument, das es je hatte: nicht nur „messbar,
->    nicht hoerbar“, sondern „auf dieser Hardware nicht ohne Gegenleistung baubar“.
+> ✅ **Was aus beiden Anlaeufen bleibt:** die **ComplianceRule `queue`** (Feature + Rule,
+> `match_config` = `/queue type` + `/queue tree`) schliesst die blinde Stelle aus §4.1 —
+> dieselbe, die TP26 fuer `/ip firewall filter` geschlossen hat. Wirksamkeit bewiesen: erst
+> 99/100 mit der fehlenden Queue als `missing`, nach dem Deploy 100/100. Zaehler jetzt
+> **25 Rules x 4 Geraeten = 100 Checks**.
+> ⚠️ **Am Geraet steht weiterhin die wirkungslose Interface-Queue** (`qos-wan-up` auf
+> `parent=vlan100`) — in der SoT, compliant, **aber ohne jede Funktion**. Sie gehoert entfernt,
+> sobald der Abschluss entschieden ist; bis dahin NICHT fuer aktives QoS halten.
 >
-> ✅ **Was aus diesem Anlauf bleibt und Bestand hat:** die **ComplianceRule `queue`**
-> (Feature + Rule, `match_config` = `/queue type` + `/queue tree`) schliesst die blinde
-> Stelle aus §4.1 — dieselbe, die TP26 fuer `/ip firewall filter` geschlossen hat. Sie hat
-> sich sofort bewiesen: erst 99/100 mit exakt der fehlenden Queue als `missing`, nach dem
-> Deploy 100/100. Der Zaehler steht jetzt bei **25 Rules x 4 Geraeten = 100 Checks**.
-> Die Queue selbst steht am Geraet und in der SoT — **wirkungslos, aber dokumentiert**, bis
-> ueber die drei Wege oben entschieden ist. Sie NICHT fuer aktives QoS halten.
+> 💡 **Falls QoS hier je wieder Thema wird:** weder `hw-offload` opfern noch Chip-QoS ist
+> noetig — der Global-HTB-Weg funktioniert ohne beides. Es lohnt nur nicht.
 
 *(Vorheriger Kopf, als Messbefund weiter gueltig:)* 🟡 **GEMESSEN 2026-08-20/21 — Fall B, aber „messbar, nicht hörbar"**
 > ✅ **Die Prämisse ist geprüft. Ergebnis + Rohdaten: [`tp6-praemisse-messrunbook.md`](tp6-praemisse-messrunbook.md) §5.**
@@ -2008,14 +2015,16 @@ TP5 E1 ✅ ─► E2 ✅ ─► E2-Nachtrag ✅ ─► E3 Drop ✅ ─► E4 inp
 > nächste Sitzung entscheidet daher **bauen oder begründet schließen** — sie misst nicht neu.
 > Übergabe mit den Sitzungszuschnitten: [`handoff-20260822-naechste-schritte.md`](handoff-20260822-naechste-schritte.md).
 
-> 🔴 **Update 2026-08-23: die Entscheidung ist gefallen — gebaut — und der Bau hat die
-> Frage veraendert.** CAKE steht auf `crs326-core` (ComplianceRule `queue` + Template-Block,
-> 100/100 compliant) und ist **nachweislich wirkungslos**: 0 Bytes in der Queue nach 6 MB
-> Client-Upload, und 9,48 Mbit Durchsatz gegen ein 8,5-Mbit-Limit. Ursache sehr wahrscheinlich
-> die **Switch-Chip-Architektur** des CRS326 (Bridge-`hw-offload`, alle Ports
-> `only-hardware-queue`). **TP6 steht damit weiter auf dem Pfad**, aber die offene Frage ist
-> jetzt eine Hardware-Abwaegung (`hw-offload` opfern? Chip-QoS? schliessen?) und keine
-> Nutzenfrage mehr. Details und die drei Wege: TP6-Abschnitt oben.
+> 🟢 **Update 2026-08-23 (Endstand): TP6 ist beantwortet — und der kritische Pfad damit leer.**
+> Gebaut wurde, wie entschieden. Der erste Anlauf (`/queue tree parent=vlan100`) war wirkungslos,
+> **aber nicht aus dem zuerst notierten Grund**: nicht der Switch-Chip, sondern die
+> MikroTik-dokumentierte Regel, dass Interface-HTB bei hw-offloadetem out-interface nicht greift.
+> Ueber `parent=global` + Mangle-Mark **funktioniert CAKE einwandfrei** (zaehlt 6 MB, drosselt
+> 9,3 → 7,78 Mbit). Und genau deshalb ist das Ergebnis belastbar: **die Latenz unter Last bessert
+> sich trotzdem nicht — bei keiner Bandbreite, auch nicht bei 52 % der Linerate** (42,4 / 43,3 /
+> 44,0 / 44,6 ms). Der Puffer sitzt im **DOCSIS-Uplink**, nicht im Router. ⇒ **TP6 schliessen:
+> nicht mangels Nutzen, sondern weil das Werkzeug nicht an die Ursache reicht.** Details im
+> TP6-Abschnitt oben, Merkregeln in `ref_queue_htb_platzierung_docsis`.
 
 **TP5 ist am 2026-08-18 abgeschlossen.** Damit steht rechnerisch nur noch **TP6** auf dem kritischen Pfad —
 🟠 **aber dessen Prämisse ist offen**: eine Messung von 2026-06-16 (`docs/call-quality-diagnosis.md`)
@@ -2032,7 +2041,7 @@ Ziel ist. Alles andere läuft nebenher und blockiert nichts.
    Anlernen eines IoT-Geraets (User 2026-08-17). Wer im IOT-SSID sitzt, ist im selben VLAN wie das
    Geraet und beruehrt die `forward`-Kette gar nicht; fuer Ad-hoc-Zugriffe aus MAIN gibt es jetzt die
    selbstverfallende Gruppe `jit-admin`.
-2. 🔴 **TP6 — QoS/CAKE + Call-Quality-A/B-Test.** **Stand 2026-08-23: gebaut, aber wirkungslos** (s. TP6-Abschnitt — Switch-Chip-Befund). Der naechste Schritt ist weder Messen noch Bauen, sondern die Entscheidung ueber `hw-offload`. ~~Das eigentliche Projektziel; **keine offenen Blocker mehr**.~~
+2. 🟢 **TP6 — QoS/CAKE + Call-Quality-A/B-Test.** **Stand 2026-08-23: beantwortet** (s. TP6-Abschnitt). CAKE ist baubar und wirkt technisch, verbessert die Latenz aber bei keiner Bandbreite — der Puffer liegt im DOCSIS-Uplink. Offen ist nur noch der formale Abschluss (Queue entfernen, TP schliessen). ~~Das eigentliche Projektziel; **keine offenen Blocker mehr**.~~
    **Korrigiert 2026-08-19:** kein *Blocker*, aber eine offene **Prämisse** — der Satz oben und dieser
    Punkt widersprachen sich seit dem 18. Richtig ist: der nächste Schritt ist eine **Messung**, kein Bau.
    Runbook liegt bereit: `docs/tp6-praemisse-messrunbook.md`. Fällt sie A/A+ aus, wird TP6 **geschlossen

docs/transaktionen/TEST-cake-global-htb.ab-off.rsc

@@ -0,0 +1 @@
+/ip firewall mangle disable [find where comment="TEST-cake-global-htb"]

docs/transaktionen/TEST-cake-global-htb.commands.rsc

@@ -0,0 +1,2 @@
+/ip firewall mangle add action=mark-packet chain=postrouting comment="TEST-cake-global-htb" new-packet-mark=wanup out-interface=vlan100 passthrough=no
+/queue tree add comment="TEST-cake-global-htb" name=qostestglobal packet-mark=wanup parent=global queue=cake-wan-up

docs/transaktionen/TEST-cake-global-htb.json

@@ -0,0 +1,16 @@
+{
+  "change_id": "TEST-cake-global-htb",
+  "device": "crs326-core",
+  "scope": "queue",
+  "match_config": [
+    "/queue type",
+    "/queue tree"
+  ],
+  "reason": "TP6: prueft Global-HTB + Mangle-Mark statt Interface-HTB (letztere ist laut MikroTik-Doku bei hw-offloaded out-interface unwirksam). Enthaelt eine temporaere mangle-Regel ausserhalb des queue-Scopes, wird im Rueckbau mitentfernt.",
+  "started": "2026-08-23",
+  "expires": "2026-08-24",
+  "state": "rolledback",
+  "snapshot": "docs/transaktionen/TEST-cake-global-htb.snapshot.rsc",
+  "device_backup": "",
+  "closed": "2026-08-23"
+}

docs/transaktionen/TEST-cake-global-htb.rollback.rsc

@@ -0,0 +1,11 @@
+# Rueckbau-VORSCHLAG fuer TEST-cake-global-htb (crs326-core, Scope queue)
+# Aus dem Snapshot vom 2026-08-23. NICHT ungeprueft deployen:
+# `add`-Zeilen legen neu an, statt zu aendern — was hier gebraucht wird,
+# ist in der Regel ein `set [find ...]`. Zeilen entsprechend anpassen.
+
+/queue type
+add cake-bandwidth=8.5Mbps cake-diffserv=diffserv4 cake-nat=yes kind=cake \
+name=cake-wan-up
+/queue tree
+add comment="TP6: CAKE auf der Senderichtung (WAN-Egress)" name=qos-wan-up \
+parent=vlan100 queue=cake-wan-up

docs/transaktionen/TEST-cake-global-htb.rueckbau.rsc

@@ -0,0 +1,3 @@
+/queue tree remove [find where name="qostestglobal"]
+/ip firewall mangle remove [find where comment="TEST-cake-global-htb"]
+/queue type set [find where name="cake-wan-up"] cake-bandwidth=8.5Mbps

docs/transaktionen/TEST-cake-global-htb.snapshot.rsc

@@ -0,0 +1,9 @@
+# Snapshot des Scopes 'queue' auf crs326-core, 2026-08-23 (Transaktion TEST-cake-global-htb)
+# Bewusst NUR dieser Abschnitt — der Vollexport gehoert nicht ins Repo.
+
+/queue type
+add cake-bandwidth=8.5Mbps cake-diffserv=diffserv4 cake-nat=yes kind=cake \
+name=cake-wan-up
+/queue tree
+add comment="TP6: CAKE auf der Senderichtung (WAN-Egress)" name=qos-wan-up \
+parent=vlan100 queue=cake-wan-up

docs/transaktionen/TEST-cake-global-htb.tune.rsc

@@ -0,0 +1,2 @@
+/ip firewall mangle enable [find where comment="TEST-cake-global-htb"]
+/queue type set [find where name="cake-wan-up"] cake-bandwidth=7000000

docs/transaktionen/TEST-cake-global-htb.tune5.rsc

@@ -0,0 +1 @@
+/queue type set [find where name="cake-wan-up"] cake-bandwidth=5000000