Per-Class Drops: Wie Sie “wo” und “warum” Paketverlust beweisen

Per-Class Drops sind eine der wenigen Messgrößen, mit denen Sie Paketverlust nicht nur vermuten, sondern gerichtsfest „wo“ und „warum“ beweisen können. In vielen QoS-Diskussionen bleibt es bei Aussagen wie „das WAN ist schuld“ oder „das WLAN droppt“, weil nur grobe Interface-Zähler betrachtet werden: Discards, Output Drops oder eine durchschnittliche Linkauslastung. Für Echtzeitdienste wie RTP, WebRTC, Videostreaming oder kritische Applikationen ist das zu ungenau. Ein Paket kann auf dem Weg durch mehrere Hops verloren gehen, und häufig ist nicht die gesamte Schnittstelle überlastet, sondern eine einzelne Queue oder Klasse. Genau hier setzt Per-Class Drops an: Sie zeigen, in welcher QoS-Klasse (z. B. Voice, Video, Best Effort, Bulk) Pakete verworfen wurden – und oft sogar mit Drop Reasons, also dem Grund für den Verlust (Tail Drop, Policer, WRED, Buffer Exhaustion, Policy Drop). Wer Per-Class Drops sauber erhebt und mit Klassifizierungszählern, Queue-Delay und Applikationsmetriken korreliert, kann Paketverlust eindeutig lokalisieren, Fehlmarkierung entlarven und QoS-Policies so nachschärfen, dass sie im Betrieb wirklich schützen.

Warum klassische Interface-Drops nicht ausreichen

Interface-Zähler sind wichtig, aber sie erzählen selten die ganze Geschichte. „Output drops“ können bedeuten, dass eine egress Queue überläuft – oder dass ein Hardwarepuffer erschöpft ist – oder dass ein Policer hart zuschlägt, bevor das Paket überhaupt die Queue erreicht. Manche Plattformen zählen Drops auch erst sehr spät oder aggregiert, sodass Sie nicht erkennen, welche Traffic-Klasse betroffen war. Für die Praxis heißt das: Wenn Sie nur auf Interface-Ebene messen, können Sie weder beweisen, welche Anwendung getroffen wird, noch ob QoS tatsächlich geholfen hat.

• Aggregationsproblem: Ein Interface-Zähler mischt alle Klassen; Voice-Loss und Bulk-Loss sehen gleich aus.
• Microbursts: Kurze Queue-Spikes erzeugen Drops, die im 5-Minuten-Mittelwert unsichtbar bleiben.
• Falsche Schlussfolgerungen: „Link nicht voll“ schließt Drops nicht aus; Queueing kann trotzdem kritisch sein.
• Unklare Ursache: Ohne Drop Reason wissen Sie nicht, ob Congestion, Policing oder Ressourcenlimits zuschlagen.

Was Per-Class Drops genau bedeuten

Per-Class Drops sind Zähler, die pro QoS-Klasse oder pro Queue erfassen, wie viele Pakete/Bytes verworfen wurden. Je nach Plattform liegen die Zähler auf unterschiedlichen Ebenen: in der Policy (Class-Based QoS), in der egress Queue des ASICs oder in einem Shaper/Policer-Modul. Der zentrale Vorteil bleibt: Sie sehen, welche Klasse betroffen ist. Damit lässt sich Paketverlust „an der richtigen Stelle“ diskutieren: Wenn Drops nur in Best Effort auftreten, ist das oft tolerierbar. Wenn Drops in Voice oder einer Media-Klasse auftreten, ist das ein harter Qualitätsvorfall.

• Per-Class Packet Drops: Anzahl verworfener Pakete pro Klasse (gut für RTP/Media, weil Pakete zählen).
• Per-Class Byte Drops: verworfene Bytes pro Klasse (hilfreich bei Video/Sharing, weil Volumen relevant ist).
• Per-Queue Occupancy/Max: Spitzenbelegung je Queue, um Burst-Verhalten zu erkennen.
• Per-Queue Delay: Verweilzeit in der Queue, um Bufferbloat ohne Drops nachzuweisen.

„Wo“ beweisen: Der methodische Ansatz zur Lokalisierung von Paketverlust

Um den Ort des Paketverlusts zu beweisen, brauchen Sie eine Messkette entlang des Pfads. Die Grundidee ist simpel: Wenn Sie an Hop A keine Drops sehen, an Hop B aber schon, dann liegt der Verlust zwischen diesen Punkten – meist direkt auf dem Egress von B oder in dessen vorgelagerten QoS-/Hardware-Mechanismen. Entscheidend ist, dass Sie nicht nur einen Hop messen, sondern mindestens die Engpässe abdecken: Standort-Uplink, WAN/SD-WAN-Edge, Aggregationslinks und Access-Uplinks. In der Praxis sind es oft erstaunlich wenige Stellen, an denen Congestion wirklich entsteht.

• Pfad definieren: Welche Geräte und Interfaces liegen wirklich im Medien-/Applikationspfad?
• Engpässe priorisieren: Uplinks, Oversubscription-Punkte, Tunnel-Edges, WLAN-Controller/AP-Uplinks.
• Per-Class Drops dort messen: Vor allem auf egress Interfaces, weil Congestion meist beim Senden entsteht.
• Zeitfenster exakt setzen: Sekunden-/Minutenauflösung statt Tagesmittelwerte.

Die wichtigste Unterscheidung: Ingress- vs. Egress-Drops

Viele Missverständnisse entstehen, weil Drops an unterschiedlichen Stellen passieren können. Ingress-Drops deuten häufig auf Policers, ACLs, L2/L3-Fehler oder Ressourcenmangel beim Empfang hin. Egress-Drops deuten meist auf Congestion in Queues, Shaping-Grenzen oder egress Buffer-Limits hin. Für QoS-Nachweise sind egress Per-Class Drops besonders aussagekräftig, weil QoS-Scheduler dort arbeiten.

„Warum“ beweisen: Drop Reasons als Übersetzer von Countern zu Ursachen

Ein Drop-Zähler ohne Grund ist wie ein Alarm ohne Meldung. Moderne Plattformen können Drop Reasons liefern, entweder als explizite Counter pro Mechanismus (Tail Drop, Policer Drop, WRED Drop) oder als Telemetry-Felder aus dem ASIC. Der Nutzen ist enorm: Tail Drop in einer Video-Klasse heißt „Queue voll“. Policer Drop heißt „Rate überschritten“. WRED Drop heißt „frühzeitiges Drop-Verhalten“ (meist für TCP). Buffer Exhaustion heißt „Shared Buffer oder Headroom erschöpft“, oft microburst-getrieben. Diese Gründe führen zu unterschiedlichen Maßnahmen und belegen, dass der Verlust nicht „mystisch“ ist, sondern einem klaren Mechanismus folgt.

• Tail Drop / Queue Full: Congestion; Bandbreite/Queue-Parameter/Traffic-Mix anpassen.
• Policer Drop: Rate zu niedrig oder Traffic falsch markiert; Policer entschärfen oder Re-Marking korrigieren.
• WRED Drop: sinnvoll für TCP, meist schädlich für RTP/UDP; WRED-Policy prüfen.
• Buffer Exhaustion: Plattform-/Burst-Thema; Microbursts, Buffer-Pools, Port-Speed-Mismatch prüfen.
• Policy/ACL Drop: Filterung; Pfad/Firewall/NAT-Regeln und Ausnahmen prüfen.

Die Beweiskette: Per-Class Drops mit Klassifizierung verknüpfen

Per-Class Drops beweisen, dass Pakete in einer Klasse verworfen wurden. Um zu beweisen, dass es wirklich Ihre Anwendung war, brauchen Sie den zweiten Beweis: Die Anwendung muss in dieser Klasse angekommen sein. Dafür sind Klassifizierungszähler essenziell: Matched Packets/Bytes pro Klasse, „unmatched“ oder Default-Class-Anteile, Re-Marking-Counter. Ein typischer Fehler in der Praxis ist, Drops in Best Effort zu sehen und daraus abzuleiten, dass Voice sauber ist – obwohl Voice wegen Fehlmarkierung ebenfalls in Best Effort lief. Erst wenn Sie zeigen können, dass RTP/Media tatsächlich in der Media-/Voice-Klasse matched wurde, sind Per-Class Drops wirklich belastbar.

• Matched vs. Unmatched: Stimmen die Volumina in den erwarteten Klassen mit der Realität überein?
• Re-Marking: Wird DSCP am Edge zurückgesetzt oder korrekt normalisiert?
• Default-Class-Wachstum: Steigt Default bei Problemen, fehlt oft eine Regel oder Trust Boundary.
• Class Hit Counters: Belegen, dass die QoS-Policy „greift“ und nicht nur existiert.

Queue-Delay als Ergänzung: Verlust ist nicht das einzige Problem

Sie können Paketverlust beweisen – und trotzdem bleibt die Qualität schlecht, weil Delay und Jitter steigen. Deshalb sollte jede Per-Class-Drop-Analyse immer auch Queue-Occupancy und Queue-Delay betrachten. Das ist besonders wichtig bei großen Puffern (Bufferbloat) oder bei Shaping, wo Pakete bewusst verzögert werden, aber nicht droppen. Für Echtzeitdienste kann ein wachsender Backlog in der Media-Klasse bereits problematisch sein, bevor überhaupt Drops auftreten. Der „Beweis“ lautet dann nicht Verlust, sondern Verzögerung: Queue-Delay korreliert mit Jitter und Qualitätsereignissen.

• Delay-Spikes: zeigen Congestion auch ohne Drops.
• Occupancy-Max: zeigt Burst-Verhalten; relevant bei Microbursts und Replikationspunkten.
• Shaper-Backlog: beweist, dass Shaping aktiv ist und Congestion kontrolliert wird.

Praktisches Vorgehen: Paketverlust auf einen Engpass „festnageln“

Ein praxistauglicher Nachweis besteht aus einem wiederholbaren Ablauf. Zuerst definieren Sie das Symptom und das Zeitfenster (z. B. „10:14–10:18 Uhr ruckelte Video, Audio stotterte“). Dann identifizieren Sie die Engpassstellen im Pfad. Anschließend ziehen Sie Per-Class Drops und Drop Reasons für diese Interfaces. Parallel prüfen Sie Klassifizierungszähler, damit Sie sicher sind, dass die Anwendung in der erwarteten Klasse läuft. Abschließend korrelieren Sie mit Applikationsmetriken (RTP-Sequenzlücken, RTCP Receiver Reports, WebRTC Stats). Wenn alle drei Ebenen zeitlich zusammenpassen, haben Sie Ihren Beweis.

• Schritt 1: Zeitfenster und betroffene Anwendung/Standort eingrenzen.
• Schritt 2: Pfad und Engpässe bestimmen (WAN-Edge, Uplinks, WLAN, Aggregation).
• Schritt 3: Per-Class Drops + Drop Reasons am egress der Engpässe auslesen.
• Schritt 4: Klassifizierungszähler (Matched/Unmatched, Re-Marking) prüfen.
• Schritt 5: Queue-Delay/Occupancy ergänzen (Bufferbloat vs. Loss trennen).
• Schritt 6: Mit Applikationsmetriken korrelieren (Loss/Jitter/RTT, Quality Events).

Typische Muster und was sie beweisen

Im Betrieb begegnen Ihnen wiederkehrende Muster. Wenn Tail Drops nur in Best Effort auftreten, während Media/Voice stabil bleibt, beweist das, dass QoS schützt. Wenn Tail Drops in der Media-Klasse an einem Standort-Uplink auftreten und gleichzeitig RTP-Loss beim Receiver steigt, ist der Engpass klar. Wenn Policer Drops in einer Voice-Klasse auftreten, ist das fast immer ein Designfehler: Echtzeit sollte selten hart gepoliced werden. Wenn Buffer Exhaustion erscheint, ist der Engpass nicht unbedingt „zu wenig Bandbreite“, sondern häufig Microburst- oder Plattform-Headroom.

• Drops nur in Best Effort: QoS wirkt, Echtzeit wird bevorzugt; ggf. akzeptables Verhalten.
• Drops in Media/Voice + Tail Drop: Congestion in dieser Klasse; Bandbreitenreserve/Queue-Parameter erhöhen oder Traffic trennen.
• Policer Drops in Echtzeit: Policer entschärfen, Shaping bevorzugen, Fehlmarkierung ausschließen.
• WRED Drops in Media: Policy-Fehler; WRED aus Echtzeitklassen entfernen.
• Buffer Exhaustion: Microbursts/Shared Buffer; Telemetry auf Burst-Profile und Buffer-Pools prüfen.

Microbursts sichtbar machen: Warum Drops „kurz und heftig“ sein können

Per-Class Drops steigen manchmal sprunghaft, obwohl die durchschnittliche Rate unauffällig ist. Das ist typisch für Microbursts: Viele Flows senden gleichzeitig, oder ein upstream Device bündelt Pakete, etwa durch Encapsulation (VXLAN/IPsec), Replikation (Multicast) oder durch TCP-Congestion-Window-Effekte. Wenn der egress Buffer nicht genug Headroom hat, kommt es zu Tail Drops oder Buffer Exhaustion. Um das zu beweisen, brauchen Sie hochauflösende Telemetry: Queue-Occupancy als Zeitreihe, Peak-Raten und idealerweise Burst-spezifische Counter. Ein einmaliger Snapshot nach dem Ereignis reicht oft nicht.

• Hohe Auflösung: Sekunden- oder Subsekunden-Intervalle für Queue-Stats.
• Peak statt Mittelwert: Max-Occupancy und Peak-Rate sind aussagekräftiger als Durchschnitt.
• Korrelation: Drop-Spike muss zeitlich zu Applikationsstörung passen.

Applikationsbezug herstellen: RTP/WebRTC/Video-Qualität mit Drops verbinden

Per-Class Drops beweisen den Verlust im Netzwerk. Der nächste Schritt ist, zu zeigen, dass die Anwendung ihn spürt. Bei RTP ist das elegant: Sequenznummern zeigen fehlende Pakete, RTCP liefert Jitter/Loss-Indikatoren. Bei WebRTC liefern getStats-Metriken Round-Trip, Jitter, Packet Loss, Bitrate-Änderungen und Transport-Fallbacks. Bei IPTV/Multicast können Probe-Receiver Sequenzlücken erfassen. Wenn Sie diese Applikationsmetriken im gleichen Zeitfenster wie Per-Class Drops sehen, ist die Kausalität überzeugend: „Drops in der Media-Klasse am Standort-Uplink verursachen Loss beim Receiver.“

• RTP: Sequenzlücken, RTCP Receiver Reports, Jitter-Buffer-Underruns.
• WebRTC: packetLoss, jitter, RTT, availableOutgoingBitrate, quality limitation reasons.
• Video/AV: Freeze-Events, Auflösungswechsel, Decoder-Buffer-Events (je nach Plattform).

Best Practices: Per-Class Drops dauerhaft operationalisieren

Damit Per-Class Drops nicht nur im Incident helfen, sollten Sie sie in den Normalbetrieb integrieren. Das heißt: Baselines pro Engpass, Alarme auf Drops und Delay in Echtzeitklassen, sowie Dashboards, die „wo“ und „warum“ in einem Blick beantworten. Besonders hilfreich ist eine Sicht, die pro Standort-Uplink die Top-Klassen nach Drops und Delay zeigt, inklusive Drop Reasons. Ergänzend sollten Sie die Trust Boundary und Klassifizierungsregeln regelmäßig verifizieren, damit Fehlmarkierung nicht unbemerkt die Beweiskette zerstört.

• Dashboards pro Engpass: Drops/Delay/Occupancy pro Klasse auf WAN-Edges und Access-Uplinks.
• Alarmierung: Anstieg von Drops oder Delay in Voice/Media-Klassen als Incident-Kriterium.
• Baselines: Normalwerte für Unmatched/Default, Shaper-Headroom und Queue-Maxima.
• Regel-Audits: DSCP-Mapping und Classifier-Hits prüfen, besonders nach Changes.
• Ursachenbibliothek: Drop Reason → Standardmaßnahme dokumentieren, um schneller zu handeln.