QoS im SASE-Umfeld ist ein Balanceakt zwischen Sicherheit, Nutzererlebnis und operativer Kontrolle. Während klassische QoS-Designs meist innerhalb einer eigenen WAN-Domäne stattfinden (MPLS, SD-WAN, Metro), verlagert SASE zentrale Funktionen in Cloud-PoPs: Secure Web Gateway, CASB, ZTNA, Firewall-as-a-Service, DLP und häufig auch Cloud-Routing. Damit ändert sich die „Physik“ der Pfade. Ein Nutzer oder Standort baut Tunnels (z. B. IPsec oder GRE) zu einem SASE-PoP auf, der Verkehr wird dort inspiziert und dann weiter zu SaaS, Internet oder privaten Anwendungen geführt. Genau hier entstehen Latenz-Trade-offs: Der nächste PoP ist nicht immer der beste PoP, Inspection kostet Rechenzeit, und Routing zwischen PoPs kann zusätzliche Hops erzeugen. QoS im SASE bedeutet deshalb nicht nur „DSCP markieren“, sondern End-to-End Qualität in einem Multi-Domain System herzustellen: Underlay (letzte Meile), Tunnel-Encapsulation, PoP-Auswahl, Service-Chaining in der Cloud und Rückführung zu Applikationen müssen zusammenpassen. Wer das professionell plant, definiert klare SLOs für Voice/Video und interaktive Apps, setzt Shaping und Queueing am Edge konsequent um, bewertet PoPs nach messbarer Performance statt nach Marketingkarten und schafft Transparenz darüber, wo Latenz entsteht: im Access, im Tunnel, im PoP oder auf dem Weg zum Ziel.
Warum SASE die QoS-Frage neu stellt
In vielen Unternehmen war QoS lange ein WAN-Thema: Link priorisieren, Echtzeitklasse schützen, vielleicht AQM gegen Bufferbloat. SASE verschiebt die Engpässe und die Verantwortlichkeiten. Der Datenpfad wird häufiger: Endpunkt → Tunnel → Cloud-PoP → Security-Services → Egress → SaaS/Internet/Private App. An mehreren Stellen können Verzögerung, Jitter und Loss entstehen. Außerdem ist der QoS-Einflussbereich geteilt: Sie kontrollieren den Access-Link, Ihr CPE/Edge und Ihre Policies – nicht aber die interne Architektur und Auslastung des SASE-Providers. Das macht „QoS über Providergrenzen“ zur Normalität, auch wenn es sich aus Unternehmenssicht wie „ein Service“ anfühlt.
- Mehr Hops: PoP-Ingress, Inspection, Weiterleitung erzeugen zusätzliche Pfadsegmente.
- Mehr Encapsulation: Tunnel-Overhead beeinflusst MTU, effektive Rate und Burstiness.
- Geteilte Kontrolle: Sie steuern bis zum PoP, danach sind Sie auf Messbarkeit und Provider-Transparenz angewiesen.
- Neue Engpässe: nicht nur Linkkapazität, sondern auch PoP-Compute und Service-Chaining.
Cloud-PoPs als Congestion Domains: Nähe ist nicht gleich Qualität
SASE-Anbieter betreiben weltweit PoPs, die idealerweise nahe an Nutzern und Standorten liegen. „Nearest PoP“ ist jedoch nur ein Startpunkt. Entscheidend ist die tatsächlich gemessene Qualität: Latenz-Perzentile, Jitter, Loss und Stabilität unter Last. Ein geografisch naher PoP kann durch peeringseitige Umwege, lokale Internetqualität oder PoP-Auslastung schlechter sein als ein etwas weiter entfernter PoP. Für QoS-Designs bedeutet das: PoP-Auswahl ist ein aktiver Steuerhebel – und muss messgetrieben erfolgen, nicht nur anhand von Standorten auf einer Karte.
- PoP-Latenz: nicht nur Median, sondern p95/p99 in kurzen Zeitfenstern betrachten.
- PoP-Auslastung: Security-Inspection ist compute-intensiv; Peak-Zeiten können zusätzliche Verzögerung verursachen.
- Peering-Qualität: der Weg vom PoP zu SaaS/Internet kann je nach Region stark variieren.
- Stabilität: häufiger PoP-Wechsel („PoP Flapping“) erhöht Jitter und stört Echtzeit.
Tunnels im SASE: Overhead, MTU und warum QoS „unsichtbar“ werden kann
SASE-Anbindungen nutzen häufig IPsec- oder GRE-Tunnels. Diese Encapsulation fügt Header-Overhead hinzu und reduziert die effektive Nutzlast pro Paket. Das hat direkte QoS-Auswirkungen: Erstens steigt die effektive Bitrate im Underlay (mehr Bytes pro Paket), was Engpässe schneller erreicht und Shaper/Policer früher triggert. Zweitens steigt das Risiko von MTU-Problemen. Wenn Underlay-MTU und Tunnel-Overhead nicht sauber zusammenpassen, entstehen Fragmentierung oder Drops – für Voice/Video sofort spürbar. Drittens ist relevant, ob DSCP/ECN korrekt in den Outer Header übernommen werden, damit Underlay-QoS überhaupt greifen kann.
- MTU-Disziplin: Underlay-MTU und MSS-Clamping so planen, dass Fragmentierung vermieden wird.
- DSCP/ECN Propagation: inneres Marking muss in den Outer Header übernommen werden, wenn Provider-QoS oder lokale Queues darauf reagieren sollen.
- Effektive Rate: Overhead in Bandbreitenmodellen berücksichtigen, besonders bei Echtzeitpaketen.
- Crypto-Processing: Verschlüsselung kann bei hoher Last Latenz erzeugen, wenn Offload oder Kapazität fehlt.
Latenz-Trade-offs: Security-Inspection vs. Echtzeit-Qualität
SASE ist attraktiv, weil es Security-Funktionen zentralisiert. Diese Funktionen kosten jedoch Zeit: TLS-Inspection, DLP, AV-Scanning, Policy-Evaluierung, Identity-Checks. Für viele Web- und SaaS-Anwendungen ist das akzeptabel, solange es stabil bleibt. Für Echtzeit (Voice/Video) und für sehr interaktive Workloads (VDI, Remote IDEs, Trading, industrielle Steuerung) kann zusätzliche Latenz schnell zum Problem werden. In der Praxis entsteht deshalb ein Trade-off: maximale Security-Tiefe vs. minimale Latenz. Professionelle SASE-QoS-Designs lösen das nicht mit Bauchgefühl, sondern mit Serviceklassen und Ausnahmen: Echtzeit-Traffic wird anders behandelt, bestimmte Flows werden von tiefen Inspektionen ausgenommen oder über optimierte Pfade geführt – wohlgemerkt kontrolliert und auditierbar.
- Full Inspection: maximaler Schutz, aber höhere und variablere Verzögerung möglich.
- Selective Bypass: nur für klar definierte Echtzeit-/kritische Flows, mit strengen Richtlinien.
- Service-Chaining: je mehr Funktionen in Reihe, desto höher das Latenzbudget im PoP.
- QoE-Fokus: Voice/Video benötigt stabile Perzentile, nicht nur „im Mittel okay“.
QoS im SASE ist zweigeteilt: Edge-Queueing bleibt Pflicht
Auch wenn SASE „Cloud-first“ ist: Die meisten QoS-Probleme entstehen weiterhin an der ersten Engstelle – typischerweise am Standort-Uplink oder im Upstream der letzten Meile. Dort entstehen Bufferbloat und Mikrobursts, die Echtzeit zerstören, bevor der Traffic überhaupt den PoP erreicht. Deshalb bleibt klassisches WAN-Shaping und Queueing am Edge ein Pflichtbaustein. Der Unterschied: Edge-QoS muss auf Tunnelverkehr angewandt werden, nicht nur auf „natives IP“. Wenn die entscheidende Queue beim Provider liegt, verlieren Sie Kontrolle und Messbarkeit.
- Egress Shaping: knapp unter die realistische Upstream-Rate, damit Congestion lokal und steuerbar ist.
- Realtime-Queue: Voice/Video in eigene Klasse, strikt priorisiert, aber strikt limitiert.
- Best Effort mit AQM/ECN: reduziert Bufferbloat und stabilisiert RTT-Spitzen.
- Bulk/Scavenger: Backups/Updates nachrangig, damit sie Echtzeit nicht verdrängen.
Application Awareness im SASE: Welche Apps brauchen welche Behandlung?
SASE-Plattformen sind oft anwendungsbewusst: Sie erkennen SaaS, Web, private Apps und identitätsbasierte Flows. Für QoS ist das entscheidend, weil nicht jede Anwendung die gleichen Anforderungen hat. Voice und Video sind jitter- und loss-sensitiv, SaaS ist RTT-sensitiv, Bulk ist throughput-orientiert. Ein gutes SASE-QoS-Design ordnet Anwendungen in Klassen ein und verknüpft diese Klassen mit PoP-Auswahl, Tunnel-Priorität, optionalen Bypass-Regeln und Underlay-Queueing. Wichtig ist dabei, dass „Unknown Apps“ nicht in Premiumklassen landen – sonst wird das System instabil.
- Realtime: UC/Voice/Video – strenge Jitter/Loss Ziele, stabiler Pfad, geringe Flaps.
- Interactive: VDI, Remote-Apps, Kollaboration – gute RTT-Perzentile, geringe Loss-Spitzen.
- Business Critical: ERP/CRM/Transaktionen – stabil, bevorzugt, aber nicht strict priority.
- Best Effort: normales Web/SaaS ohne harte Echtzeitanforderungen.
- Bulk: Backups, Updates, große Downloads – bewusst nachrangig.
PoP-Auswahl-Strategien: Primary/Secondary statt „immer automatisch“
Viele SASE-Lösungen wählen PoPs dynamisch. Das kann sinnvoll sein, birgt aber das Risiko von Instabilität. Für QoS ist Stabilität häufig wichtiger als minimaler Median. Ein bewährtes Muster ist daher: pro Standort oder Nutzergruppe einen Primary-PoP und einen Secondary-PoP definieren, dazu klare Kriterien, wann gewechselt wird (Hysterese, Hold-down). Für Echtzeit sollte der Wechsel restriktiver sein als für Best Effort, weil Pfadwechsel Jitter erzeugt und Sessions stören kann.
- Primary PoP: bevorzugt, optimiert auf p95/p99 Latenz und Stabilität.
- Secondary PoP: qualitativ ähnlich, nicht nur „irgendein“ Backup.
- Hysterese: verhindert PoP-Flapping bei kleinen Schwankungen.
- Klassenabhängige Umschaltung: Realtime wechselt konservativer, Bulk aggressiver.
Interconnect-Realität: Ab dem PoP ist QoS oft „messbar“, aber nicht steuerbar
SASE-PoPs sind Übergänge in andere Netze: zu SaaS-Providern, zu Clouds, zu Internet-Exits. Ab hier sind DSCP-Semantik und Queueing nicht garantiert, insbesondere im öffentlichen Internet. Realistische SASE-QoS-Strategien formulieren deshalb: „Wir kontrollieren bis zum PoP“, danach wird Qualität über Messungen und Provider-SLOs bewertet. Für kritische Services kann ein Anbieter private Interconnects oder optimierte Cloud-Peerings anbieten; dort sind bessere Garantien möglich. Wichtig ist, diese Unterschiede nicht zu vermischen: Ein „Internet Exit“ ist nicht gleichwertig zu einem „Private Connect“.
- In-Domain: Standort/Edge/Tunnel bis PoP – hier können Sie QoS aktiv gestalten.
- Out-of-Domain: PoP zu SaaS/Internet – hier ist QoS vor allem eine Frage von Peering und Kapazität.
- Produktdifferenzierung: Private Interconnects sind oft die Basis für strengere QoS-Profile.
SLOs statt Bauchgefühl: QoS-Ziele im SASE sauber definieren
In SASE-Architekturen sollten Qualitätsziele als SLOs formuliert werden, nicht als vage Versprechen. Für Realtime zählt nicht der Durchschnitt, sondern die Verteilung: p95/p99 Latenz und Jitter in kurzen Zeitfenstern, plus ein Fehlerbudget für seltene Ereignisse (PoP-Wartung, Failover). Für SaaS sind RTT-Perzentile und Paketverlust wichtiger. Für Bulk ist Throughput sekundär, solange er planbar bleibt. Diese SLOs müssen entlang der Servicekette messbar sein: Edge→PoP, PoP→SaaS, und idealerweise auch End-to-End.
- Realtime SLO: Jitter p95 sehr niedrig, Loss p95 sehr niedrig, PoP-Wechsel selten.
- Interactive SLO: RTT p95/p99 stabil, Queue-Delay Peaks vermeiden.
- Best Effort SLO: Latenzspitzen durch AQM/ECN reduzieren, Durchsatz stabil halten.
- Fehlerbudget: begrenzte „Bad Minutes“ pro Monat statt unrealistische 100%-Perfektion.
Monitoring: Wo Latenz wirklich entsteht
Damit QoS im SASE nicht zur Black Box wird, brauchen Sie Messpunkte auf mehreren Ebenen. Auf der Edge-Seite sind Queue-Delay, Drops, Shaper-Auslastung und DSCP/ECN-Propagation entscheidend. Für den Tunnel benötigen Sie Latenz/Jitter/Loss zum PoP (aktive Messungen) und PoP-Wechsel-Events. Für die Cloud-Seite benötigen Sie Performance zu relevanten SaaS-Zielen, idealerweise aus mehreren Regionen, weil Anycast und CDN-Pfade variieren. Der wichtigste Punkt ist die Korrelation: Wenn Voice-Qualität sinkt, muss sichtbar sein, ob der Upstream überlastet war, ob der PoP gewechselt hat oder ob das PoP→SaaS Segment degradiert ist.
- Edge Telemetrie: Queue-Delay/Drops pro Klasse, Shaping-Rate, lokale Congestion-Indikatoren.
- Tunnel Metriken: Latenz/Jitter/Loss zum PoP, PoP-Auswahl und Umschaltgründe.
- Service Metriken: App-Response-Zeiten, UC-KPIs (Jitter/Loss/MOS) falls verfügbar.
- Perzentile: p95/p99 in kurzen Fenstern, um Peaks sichtbar zu machen.
Typische Failure Patterns im SASE-QoS
Die meisten Probleme folgen wiederkehrenden Mustern. Wer diese Muster kennt, kann SASE-QoS wesentlich schneller stabilisieren. Häufige Ursachen sind: fehlendes Shaping am Upstream, MTU/Overhead-Probleme im Tunnel, zu aggressive PoP-Umschaltung, inkonsistente Marking-Propagation oder zu tiefe Inspektion für Echtzeitflüsse.
- Voice/Video ruckelt bei Upload: Bufferbloat am Standort-Uplink; Shaping und Echtzeitklasse fehlen oder sind zu groß gepuffert.
- Plötzliche Latenzsprünge: PoP-Flapping oder Routing-Änderung im PoP→SaaS Segment.
- Unerklärliche Drops: MTU/Fragmentierung durch Tunnel-Overhead; MSS/MTU prüfen.
- QoS wirkt „nicht“: DSCP wird nicht propagiert, oder Underlay ignoriert Marking; lokale Queueing-Policies müssen kompensieren.
- Inspection verursacht Delay: zu aggressive Security-Kette für Realtime; kontrollierte Ausnahmen nötig.
Blueprint: QoS im SASE robust planen
Ein praxiserprobtes Vorgehen beginnt mit einem App-Klassenmodell und klaren SLOs pro Klasse. Danach wird die Edge-Seite stabilisiert: Egress Shaping knapp unter die reale Rate, limitierte Realtime-Queue, AQM/ECN für Best Effort, Bulk nachrangig. Parallel wird die Tunnel-Architektur sauber gemacht: MTU/MSS, DSCP/ECN-Propagation, und eine definierte PoP-Strategie mit Primary/Secondary sowie Hysterese gegen Flapping. Anschließend werden Security-Policies so gestaltet, dass sie Latenz-Trade-offs bewusst managen: Echtzeitflüsse werden nicht wahllos durch tiefe Inspection-Ketten geschickt, sondern nach klaren Regeln behandelt. Abschließend wird Monitoring aufgebaut, das Edge-Queue-Health, Tunnel-Metriken, PoP-Events und App-QoE korreliert. So wird QoS im SASE zu einem operativen System: Cloud-PoPs, Tunnels und Latenz-Trade-offs sind nicht länger „unerklärliche Effekte“, sondern planbare, messbare Designentscheidungen.
