TP6 geschlossen -- und der kritische Pfad ist leer

Abschluss wie entschieden. CAKE-Queue vom Geraet entfernt, Template-Abschnitt [11]
bleibt als BEGRUENDET LEER stehen: er traegt jetzt die Messreihe und die zwei
Fallen, damit der naechste QoS-Gedanke nicht bei null anfaengt.

  ohne CAKE 42,4 ms | 88 % 43,3 | 73 % 44,0 | 52 % der Linerate 44,6  (idle 12,9)

Die ComplianceRule `queue` BLEIBT und bewacht den Abschnitt weiter -- als leer.
Das ist derselbe Gedanke wie bei wifi-access-list: ein leerer Soll-Zustand ist
eine Aussage, kein fehlender Eintrag. 100/100 compliant, keine Drifts.

NEU: TP6.1 -- Saettigung vermeiden statt Bufferbloat bekaempfen.
Christophs Einwand beim Abschluss ("dann koennten wir zumindest den Sync von der
NAS zurueckhalten") trifft eine echte Luecke im TP6-Urteil: die 30 ms Zusatzlatenz
sind nicht wegzushapen, aber sie treten NUR unter Saettigung auf -- im Leerlauf
misst dieselbe Strecke 12,9 ms. Ein NAS-Sync, der bei laufendem Call zurueckweicht,
haelt die Leitung aus der Saettigung. Das ist eine groessere Verbesserung, als
Bufferbloat-Bekaempfung hier je gebracht haette.

Entwurf steht als TP6.1, bewusst NICHT gebaut:
  - Global-HTB (in TP6 als wirksam bewiesen) + zwei Prioritaetsklassen
  - Prioritaet statt hartem Cap: nimmt dem Sync die Bandbreite nur, solange
    jemand anders sie braucht
  - src-address=10.40.20.10, NICHT ganz VLAN20 -- dort haengen auch HA, Nautobot
    und pve, die nicht pauschal hinten anstehen sollen
  - Vorbedingung: /ip firewall mangle steht unter KEINER ComplianceRule
  - Abnahme misst den Call, nicht die Queue
  - und zuerst pruefen, ob der Fall ueberhaupt auftritt oder DSM schon drosselt

Kritischer Pfad: LEER. deny-by-default steht, Golden Config steht, WLAN steht,
VLAN1 ist weg, TP6 ist beantwortet statt offengelassen.

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

docs/teilprojekte.md

@@ -421,7 +421,7 @@ 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 ▸ 🟢 **BEANTWORTET 2026-08-23: CAKE ist baubar, wirkt technisch — und hilft nicht. Der Puffer gehoert nicht uns.**
+### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ ✅ **GESCHLOSSEN 2026-08-23 — gebaut, gemessen, wieder ausgebaut. CAKE wirkt, reicht aber nicht an die Ursache.**
 > 🔴 **A/B gemessen, gleicher Client, gleiche Methode, Minuten auseinander:**
 >
 > | Konfiguration | avg Latenz unter Upload-Last |
@@ -549,6 +549,51 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   Ohne diese Zahl ist die übliche CAKE-Vorgabe „85–95 % Linerate" geraten.
 - **Abh.:** TP5 ✅ (keine Blocker mehr). Vorgelagert: die Messung oben.
 
+### TP6.1 — Saettigung vermeiden statt Bufferbloat bekaempfen (Bulk-Uploads zuruecknehmen) ▸ 🟠 **VORSCHLAG 2026-08-23, aus dem TP6-Abschluss heraus**
+> **Der Gedanke kommt von Christoph** („dann koennten wir zumindest den Sync von der NAS
+> zurueckhalten“) und er trifft eine Luecke im TP6-Urteil. TP6 hat gezeigt: die ~30 ms
+> Zusatzlatenz sind **nicht** wegzushapen, weil sie im DOCSIS-Uplink entstehen. Aber sie
+> treten **nur unter Saettigung** auf — im Leerlauf misst dieselbe Strecke **12,9 ms**.
+>
+> ⚖️ **Damit ist das Ziel ein anderes: nicht die Latenz unter Last senken, sondern die Last
+> gar nicht erst entstehen lassen.** Ein NAS-Sync, der bei laufendem Call zurueckweicht,
+> haelt die Leitung aus der Saettigung — und dann liegt der Call bei 12,9 statt 42 ms. Das
+> ist die Verbesserung, die CAKE nicht liefern konnte, und sie ist **groesser** als alles, was
+> Bufferbloat-Bekaempfung hier je gebracht haette.
+>
+> ✅ **Die Vorarbeit ist erledigt und bewiesen** (TP6): der **Global-HTB-Weg funktioniert** auf
+> diesem Geraet — `mangle chain=postrouting out-interface=vlan100 action=mark-packet` plus
+> `/queue tree parent=global packet-mark=…`. Gemessen: zaehlt 6 MB, drosselt 9,3 → 7,78 Mbit.
+> Der Interface-Weg (`parent=<interface>`) ist dagegen tot, s. TP6.
+>
+> **Entwurf (zu bauen, nicht gebaut):** ein Parent-Tree mit `max-limit` knapp unter der
+> Linerate — nur so muss HTB ueberhaupt entscheiden — und darunter zwei Klassen:
+> - `priority=8` **Bulk**: Upload **von der NAS** (`src-address=10.40.20.10`). Bewusst die
+>   Host-IP, **nicht** ganz VLAN20 — dort haengen auch HA, Nautobot und pve, die nicht
+>   pauschal hinten anstehen sollen.
+> - `priority=1` **Rest**: alles andere, insbesondere Calls.
+>
+> 🔴 **Priorisierung, kein hartes Limit.** Ein festes Cap wuerde den Sync auch dann bremsen,
+> wenn die Leitung frei ist. Prioritaet nimmt ihm die Bandbreite nur, solange jemand anders
+> sie braucht — das ist genau die Bedingung, unter der es hier ueberhaupt weh tut.
+>
+> **Preis, ehrlich:** der Parent muss unter die Linerate shapen (~1 Mbit Spitze weniger,
+> derselbe Preis wie bei CAKE), und Mangle kostet CPU pro Paket — bei 9,6 Mbit WAN irrelevant.
+>
+> 🔴 **Governance-Vorbedingung, dieselbe wie bei TP6:** `/ip firewall mangle` steht unter
+> **keiner ComplianceRule**. Die Regeln waeren also unsichtbarer Drift. Vor dem Bau eine Rule
+> `ip-firewall-mangle` anlegen — Muster liegt mit `nautobot/ingest-queue-rule.py` vor. Die
+> Rule `queue` existiert bereits und deckt den Tree-Teil ab.
+>
+> 🔴 **Abnahme misst den Call, nicht die Queue:** Ping-Latenz waehrend eines echten
+> NAS-Syncs, gegen die 12,9 ms idle. Ein Queue-Zaehler beweist hier gar nichts — genau der
+> Fehler, der in TP6 eine Nacht gekostet hat (`feedback_abnahme_wirkung_nicht_anzeige`).
+> **Vorher pruefen, ob der Fall ueberhaupt auftritt:** laeuft der Synology-Sync tatsaechlich
+> ins offene Messer, oder drosselt DSM ihn ohnehin schon? Ohne diesen Nachweis waere TP6.1
+> eine Loesung auf Verdacht — und davon hatte TP6 genug.
+>
+> **Abh.:** keine harten. Erbt die Erkenntnisse aus TP6; blockiert nichts.
+
 ### TP7 — Media-Discovery (mDNS) für VLAN 40 ▸ ✅ FERTIG (2026-07-02) — `docs/tp7-mdns.md`
 - ✅ **Built-in mDNS-Repeater** aktiv — **Live-Stand `crs326-core` (verifiziert 2026-08-14):**
   `mdns-repeat-ifaces=vlan10,vlan20,vlan30,vlan40,vlan90` → MAIN/INFRA/IOT/GUEST ↔ MEDIA. Reversibel (Feld leeren).
@@ -2000,12 +2045,15 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 
 ## Reihenfolge / Abhängigkeiten
 
-### 🎯 Kritischer Pfad (Stand 2026-08-22)
+### 🎯 Kritischer Pfad (Stand 2026-08-23) — **LEER**
 
 ```
-TP5 E1 ✅ ─► E2 ✅ ─► E2-Nachtrag ✅ ─► E3 Drop ✅ ─► E4 input+MGMT ✅ ─► E5 MAIN→IOT ✅ ─► TP6 (CAKE) ◄ Ziel
+TP5 E1 ✅ ─► E2 ✅ ─► E2-Nachtrag ✅ ─► E3 Drop ✅ ─► E4 input+MGMT ✅ ─► E5 MAIN→IOT ✅ ─► TP6 ✅ GESCHLOSSEN
-                                                                                            ▲
+
-                                                                                  ab hier ist alles frei
+                        🎯 DER KRITISCHE PFAD IST LEER (2026-08-23).
+              Das Projekt ist in seinem Kern fertig: deny-by-default steht, Golden Config
+              steht, WLAN steht, VLAN1 ist weg, und TP6 ist beantwortet statt offengelassen.
+              Was jetzt kommt, entscheidet Christoph — nichts blockiert mehr etwas.
 ```
 > ➡️ **Update 2026-08-22 (Sitzungsende):** TP25 hat den Pfad seit dem 08-20 blockiert und ist im
 > Kern **erledigt** — die Terrasse ist repariert, der Dead Spot weg, Fund E abgestuft. Damit ist
@@ -2041,7 +2089,14 @@ 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: 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**.~~
+2. ✅ **TP6 — QoS/CAKE ▸ GESCHLOSSEN 2026-08-23.** Gebaut, gemessen, wieder ausgebaut. CAKE ist
+   auf diesem Geraet baubar (Global-HTB + Mangle) und wirkt technisch — verbessert die Latenz
+   unter Last aber bei **keiner** Bandbreite, auch nicht bei 52 % der Linerate. Der Puffer sitzt
+   im DOCSIS-Uplink, nicht im Router. Queue und Template-Block sind entfernt, die ComplianceRule
+   `queue` bleibt und bewacht den Abschnitt als leer. **Damit ist der kritische Pfad leer.**
+   💡 Aus dem Abschluss ist **TP6.1** entstanden (Saettigung vermeiden statt Bufferbloat
+   bekaempfen) — Christophs Gedanke, den NAS-Sync zurueckzuhalten. Steht als Vorschlag, nicht
+   auf dem Pfad. ~~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
@@ -2065,6 +2120,9 @@ den Weg, über den man den Fehler zurücknehmen wollte.
   Datenpfad (im TP5-Log mit 137 Zeilen belegt); Container braucht nur noch der **öffentliche** Ingress.
   Vorschlag: `nautobot` als Probe aus dem CF-Ingress nehmen.
 - ~~**DoH-Cloudflare auf `crs326-core`**~~ ✅ **erledigt 2026-08-18** (TP23 Stufe 1 = TP21.1 TODO 1).
+- **TP6.1 — Saettigung vermeiden (NEU 2026-08-23):** NAS-Sync per Prioritaet zuruecknehmen,
+  damit ein Call gar nicht erst in die Saettigung geraet (12,9 statt 42 ms). Vorarbeit aus TP6
+  ist bewiesen; Vorbedingung ist eine ComplianceRule fuer `/ip firewall mangle`.
 - **TP24 — DC-USV** (seit 2026-08-16 eigener TP, aus TP15 herausgelöst).
 - ~~**TP19 — VLAN1-Client-Retirement / cudy-Teardown**~~ ✅ **geschlossen 2026-08-18** (VLAN1-ARP = 0). Die zwei Reste sind dorthin verschoben, wo sie hingehören: tote CF-Tunnel → TP16, HA-Portainer `setup_retry` → TP11.
 - ~~**TP3.3 — WLAN-Coverage-Kur**~~ → **in TP25 aufgegangen** (2026-08-17). 802.11k/v ist repariert (08-13);
@@ -2099,7 +2157,7 @@ steht unten unter „Durch". Nachfolger ist **TP16.3**, das oben unter Follow-up
 
 TP1 · TP2 · TP2.1 · TP3 (Rebuild 2026-08-08) · TP3.1 · TP4 (Rolle seit 08-08 auf dem Core) · TP7 · TP7.2 ·
 TP10 (Kern) · TP14 (+14.1/14.2/14.2a/14.3/14.5) · TP15 · TP16 (Kern) · TP17 · TP19.1 · TP20 · TP21 · TP21.1 ·
-TP22 · TP-R · **TP3.2** (08-17) · **TP5** (08-18) · **TP7.1** (08-18) · **TP19** (08-18) · **TP23 Stufe 1** (08-18) · **TP26** (08-17) · **TP27** (08-17/18) · **TP28** (08-17, GC-Modell 08-18). **Verworfen:** TP9 (Gateway-HA, User-Entscheid 2026-08-08). **Obsolet:** Omada-PVID-Fix
+TP22 · TP-R · **TP3.2** (08-17) · **TP5** (08-18) · **TP7.1** (08-18) · **TP19** (08-18) · **TP23 Stufe 1** (08-18) · **TP6** (08-23, geschlossen statt gebaut) · **TP26** (08-17) · **TP27** (08-17/18) · **TP28** (08-17, GC-Modell 08-18). **Verworfen:** TP9 (Gateway-HA, User-Entscheid 2026-08-08). **Obsolet:** Omada-PVID-Fix
 (User-Entscheid 2026-07-22 — „nie wieder aufgreifen").
 
 <details><summary>📜 Historische Fassung dieses Abschnitts (bis 2026-08-14 fortgeschrieben, hier bewusst erhalten)</summary>

nautobot/mikrotik_routeros.j2

@@ -288,52 +288,31 @@
 /ip address add address=100.96.0.6 comment="TP16.1 Mesh-Overlay" interface=cf-mesh network=100.96.0.6
 /ip route add comment="TP16.1 Mesh" disabled=no distance=1 dst-address=100.96.0.0/12 gateway=cf-mesh
 
-# [11] QoS / CAKE (TP6, 2026-08-23) — gebaut gegen eine Zahl, nicht gegen ein Ritual.
+# [11] QoS — BEWUSST LEER (TP6 geschlossen 2026-08-23).
 #
-#      GEMESSEN am 2026-08-20/21 (tp6-praemisse-messrunbook.md §5), Linerate erstmals
+#      Hier stand einen Tag lang eine CAKE-Queue. Sie ist entfernt, weil sie GEMESSEN
-#      dokumentiert: Upload 9,6 Mbit, Download 54,6 Mbit.
+#      nichts gebracht hat — und das ist die Aussage dieses Abschnitts:
 #
-#                       idle      Upload-Last   Download-Last
+#        ohne CAKE 42,4 ms | 88 % 43,3 | 73 % 44,0 | 52 % der Linerate 44,6   (idle 12,9)
-#        Durchlauf 1    12,9 ms   60,4 ms       41,3 ms
-#        Referenz 06-16 12   ms   17,5 ms       nie gemessen
 #
-#      Der Anstieg liegt in der SENDERICHTUNG bei +28..+47 ms und damit ueber der
+#      Selbst bei halber Linerate keine Verbesserung. Dort MUSS die Warteschlange im Router
-#      §3-Schwelle von <=30 ms -> Fall B. Der Download liegt mit +23..+28 ms DARUNTER
+#      liegen — also entsteht die Zusatzlatenz stromabwaerts, im Arris/DOCSIS-Uplink
-#      und ist damit nach demselben Kriterium Fall A.
+#      (Request/Grant-Scheduling auf MAC-Layer, gar keine Queue). Kein Shaper hier erreicht das.
 #
-#      🔴 Deshalb wird hier NUR die Senderichtung geshaped. Das ist keine Sparsamkeit,
+#      🔴 Zwei Dinge, die beim naechsten QoS-Gedanken Zeit sparen:
-#      sondern dasselbe Abbruchkriterium in beide Richtungen angewandt: eine Queue fuer
+#      1. `/queue tree parent=<interface>` ist auf diesem Geraet WIRKUNGSLOS — MikroTik:
-#      den Download waere gegen ein Problem gebaut, das die Messung nicht gezeigt hat.
+#         "Interface HTB will not work correctly when the out-interface is hardware offloaded
-#      Ingress-Shaping kostet auf RouterOS ausserdem Mangle-Umwege, weil man die
+#         and the bridge Fast Path is not active." Der Weg ist `parent=global` + ein
-#      Gegenstelle nicht kontrolliert -- Aufwand fuer einen unbelegten Nutzen.
+#         `mangle chain=postrouting out-interface=vlan100 action=mark-packet`. So gebaut
+#         zaehlt und drosselt es nachweislich (9,3 -> 7,78 Mbit bei cake-bandwidth=7M).
+#      2. Eine Simple Queue auf `10.40.0.0/16` taugt hinter NAT NICHT als Probe: src-nat
+#         laeuft VOR der Simple Queue, das Target matcht nie.
+#      Merkregeln: Memory `ref_queue_htb_platzierung_docsis`.
 #
-#      🔴 parent=vlan100, NICHT target=10.40.0.0/16. Eine simple queue auf das
+#      ⚖️ Was hier sehr wohl ginge und offen ist: nicht Bufferbloat bekaempfen, sondern
-#      LAN-Supernetz wuerde auch INTER-VLAN-Verkehr erfassen (NAS <-> MAIN laeuft
+#      Saettigung VERMEIDEN (Bulk-Uploads zuruecknehmen, damit ein Call gar nicht erst in
-#      geroutet ueber dieselbe CPU) und ihn auf WAN-Tempo drosseln. vlan100 traegt
+#      die Saettigung geraet). Das ist ein anderes Ziel und steht als TP6.1.
-#      ausschliesslich WAN-Verkehr, der Rest bleibt unberuehrt.
+#      Die ComplianceRule `queue` BLEIBT — sie bewacht diesen Abschnitt weiter als leer.
-#
-#      Bandbreite = 8,5 Mbit ~= 88 % der gemessenen 9,6. CAKE muss die Warteschlange
-#      selbst halten koennen; bleibt der Puffer beim ISP, regelt es nichts. Der Preis
-#      sind ~1,1 Mbit Spitzendurchsatz und er ist im A/B-Nachweis sichtbar.
-#
-#      cake-nat=yes ist hier kein Beiwerk: hinter srcnat saehe CAKE sonst nur EINE
-#      Adresse und koennte die Hosts nicht gegeneinander fair halten -- genau das ist
-#      aber der Zielfall ("jemand laedt hoch, waehrend jemand telefoniert").
-#      cake-diffserv=diffserv4 trennt dabei latenzkritisch von bulk.
-#
-#      ⚠️ Fasttrack ist auf diesem Geraet faktisch tot (accept steht vor fasttrack,
-#      0 von 445 Verbindungen) und BLEIBT es -- Entscheid 2026-08-19, §4.2. Fasttrack
-#      umgeht Queues; fuer CAKE ist der Zustand die guenstigere Ausgangslage. Wer die
-#      Regelreihenfolge je "repariert", setzt diese Queue mit ausser Kraft.
-#      ⚠️ FORMAT: RouterOS exportiert `cake-bandwidth=8.5Mbps`, nicht `8500000` (gleiche
-#      Klasse wie `hw-offload=true` vs `yes`), UND schiebt vor die Tree-Zeile eine eigene
-#      Hinweiszeile. Dadurch flacht der Backup-Normalisierer `/queue tree` nicht ab: die
-#      add-Zeile steht ohne Pfad-Praefix da. Beide Eigenheiten muessen hier nachgebaut
-#      werden, sonst meldet die Compliance einen Dauer-Drift, bei dem das GERAET recht hat.
-/queue type add cake-bandwidth=8.5Mbps cake-diffserv=diffserv4 cake-nat=yes kind=cake name=cake-wan-up
-/queue tree
-# CAKE type with bandwidth setting detected, configure traffic limits within queue itself
-add comment="TP6: CAKE auf der Senderichtung (WAN-Egress)" name=qos-wan-up parent=vlan100 queue=cake-wan-up
 {% elif obj.role.name == "Switch" %}
 # =====================================================================================
 # L2-Switch (crs326-branch) — Sollzustand des Mgmt-Layers.