Es muss bereits im Voraus klar gestellt werden, dass ganze Bücher über Quality-of-Service gibt. Es ist also nicht möglich alles in einem kurzen Artikel zu erfassen. Dennoch möchte ich trotzdem die Gelegenheit nutzen mein Wissen und Erfahrungen mit euch zu teilen. Vieles musste ich recherchieren, denn von der Theorie auf die Praxis liegen Welten. Wenn ich Traffic zuordne und klassifiziere, dann denke ich selten, welche Bits welchen Wert haben.

Ich hoffe, falls jemand dieses Artikel liest, dass es hilfreich ist und falls ich Fehler gemacht habe, dann freue ich mich über ein kurzes Feedback.

Artikel in dieser Reihe:
Quality of Service (QoS) – Kurze Einführung
Quality of Service (QoS) – Congestion Management

Congestion Management

Queuing

Erreicht einen Link sein maximales Durchsatz, dann müssen Pakete in den Queues verschoben, um das weiterleiten des Verkehrs zu kontrollieren. Pakete die markiert sind, können in verschiedene Queues platziert werden. Hingegen Pakete, die nicht zugeordnet werden konnten, landen in der Default Klasse (CS0) und werden nach Best Effort (BE) verarbeitet.

FIFO (First in, First out)

Hier kann man nicht all zu viel kommentieren. Das erste Paket am Interface, wird dieses als erster verlassen. Dafür werden keine Queues verwendet.

Priority Queuing

Priority Queuing (PQ) gewährleistet, dass der Verkehr im Netzwerk gemäss gegebene Priorisierung behandelt wird. Wir haben 4 Warteschlangen zur Verfügung: Low, Normal, Medium und High. Alles was nicht klassifiziert wurde, geht automatisch in die Queue Normal. Die Queues mit der höheren Priorität müssen vor den anderen Queues geleert werden. Erreicht eine Queue seie maximale Kapazität, so kann diese nicht mehr betreten werden, das führt dazu, dass Pakete in tieferen Queues willkürlich verworfen (Tail Drop) werden.

Mit diesem Algorithmus hat der Netzwerk Engineer die Wahl, wie der Verkehr im Netzwerk zu regulieren ist.

Weighted Fair Queuing (WFQ)

Das in 1989 eingeführtes Algortihmus brachte mit sich ein faires Output basiert auf die bestehenden Flows und die IP-Precedence. Der Faktor für die „Gewichtung“ ist einfach zu berechnen. Machen wir ein einfaches Beispiel damit es halbwegs klarer wird wie WFQ funktioniert.

Wir gehen davon aus, dass über einen Router vier Flows bestehen:

F1 = 10.0.0.2 -> 172.16.23.44:21 / Precedence 2

F2 = 10.0.0.7 -> 192.168.10.25:80 / Precedence 1

F3 = 10.0.0.22 -> 10.240.15.23:443 / Precedence 5

F4 = 10.0.0.54 -> 192.168.10.32:80 / Precedence 3

Die Flows werden nur einen proportionalen Anteil der Bandbreite zugeteilt. Um die Gesamte Bandbreite zu berechnen, muss man die Precedence jeder einzelnen Flow + 1 rechnen und alles zusammen addieren. Warum alles + 1? Das habe ich mich auch gefragt und das kann ich nicht mit Garantie beantworten. Ich gehe davon aus, dass sonst ein Paket mit einer Precedence von 0 (Default Traffic) keinen Anteil bekommen würde.

(Precedence(F1) + 1) + (Precedence(F2) + 1) + (Precedence(F3) + 1) + (Precedence(F4) + 1)

(2 + 1) + (1 + 1) + (5 + 1) + (3 + 1) = 15

F1 Anteil = (2 + 1) / ((2 + 1) + (1 + 1) + (5 + 1) + (3 + 1) ) = 3/15
F2 Anteil = (1 + 1) / ((2 + 1) + (1 + 1) + (5 + 1) + (3 + 1) ) = 2/15
F3 Anteil = (5 + 1) / ((2 + 1) + (1 + 1) + (5 + 1) + (3 + 1) ) = 6/15
F4 Anteil = (3 + 1) / ((2 + 1) + (1 + 1) + (5 + 1) + (3 + 1) ) = 4/15

Verkehr aus dem Flow 3 und 4 66% der Bandbreite und das ist gut so, sie haben eine höhere Precedence und sind somit wichtiger als die anderen zwei Flows 1 & 2.

Das funktioniert nicht immer so gut. Was passiert wenn man 47 Flows mit einer Precedence von 1 und einen einzigen Flow mit Precedence 5?

Die Flows mit einer Precedence von 1 werden einen 2/100 Anteil haben und unser Flow mit Precedence 5 nur 6/100.

Class-Based Weighted Fair Queuing (CBWFQ)

Wie wir aus dem letzten Algorithmus gesehen haben, kann es manchmal vorkommen, dass die Verarbeitung des Netzwerkverkehrs mit einer höheren Precedence trotzdem zu unerwünschte Resultate führen kann (Z.B. erhöhte Latenz).

Mit Class-Based Weighted Fair Queuing hat man die Wahl manuell bis zu 64 Klassen und deren exakten Bandbreite, welche vollständig ausgeschöpft wird, zu definieren. Dass die Queue sich so verhält, bedeutet nicht, dass alle Pakete zugestellt werden. Wie ebenfalls oben beschrieben, Verkehr, welcher nicht klassifiziert wurde, wird automatisch in die Default Klasse eingereiht.

Um den Verkehr zu einer Klasse zu binden, muss man dieser anhand von Eigenschaften, wie zum Beispiel Protokoll, Source oder Destination IP/Port und oder DSCP-Value, identifizieren. Sobald ein bestimmter Verkehr zu einer Klasse zugeordnet worden ist, kann man die Eigenschaften dieser Klasse, wie zu Beispiel Bandbreite oder Queue-limit, anpassen.

Wie auch unter anderen Mechanismen, erreicht eine Queue seine maximale Kapazität, dann werden die Pakete, die nicht mehr in der Queue Platz haben, verworfen (Tail Drop). Ich habe jetzt mehrmals diese Tail Drops erwähnt, mehr dazu werden wir im nächsten Artikel über „Congestion Avoidance“ erfahren

Low Latency Queuing (LLQ)

Bleiben wir bei unserem letzten Topic… CBWFQ. Low Latency Queuing ist nicht anders als Class-based Weighted Fair Queuing, mit dem Unterschied, dass wir hier einen zusätzliche Queue, mit einer fixen Bandbreite, anlegen, welche nicht über den CBWFQ-Scheduler verarbeitet wird.