Quality of Service, die Anwendung muss mitmachen – unbedingt!

Kommentieren Drucken


Sie erinnern sich? Bereits vor 3 Jahren habe ich an dieser Stelle über das Thema QoS geschrieben. Damals mit dem klaren Ausblick, dass QoS der Vergangenheit angehöre. In der Welt der über das Internet vernetzten Endgeräte – eine Folge der allumfassenden Mobilität – ist QoS einfach nicht zu gebrauchen. Wer kann schon Übertragungsgüte im Internet, geschweige denn auf Funkverbindungen, sicherstellen? Hier sind die Anwendungen in der Pflicht, dem User auch ohne QoS ein angenehmes Arbeiten zu ermöglichen. Die zahlreichen „Apps“ unserer Mobile Devices machen es vor, ganz selbstverständlich.

Aber es gibt auch die andere Seite. So diskutierte ich neulich mit einem RZ-Betreiber. Er meinte, ein Verschieben virtueller Maschinen zwischen seinen Rechenzentren belaste das Netzwerk so sehr, dass bestimmte zeitkritische Anwendungen darunter leiden könnten. Jetzt, wo doch die neuen Server mit 10 Gigabit Ethernet angeschlossen seien.

Zugegeben, auch wenn ich nach wie vor der Ansicht bin (und in zahlreichen Analysen gesehen habe), dass das allem zugrundeliegende Transmission Control Protokol (TCP) für eine faire Verteilung der verfügbaren Bitrate sorgt, so weiß ich, dass hohe Auslastung für zusätzliche Paketlaufzeit sorgt, weil die Warteschlangen der Netzkomponenten mehr oder weniger gefüllt sein werden. Und geringe Laufzeit spielt gerade bei der Kopplung von Rechenzentren über größere Entfernungen eine wichtige Rolle.

Hier kann also QoS durchaus von Nutzen sein. Blicken wir also noch einmal auf die drei Elemente von QoS:

Die Klassifizierung: Netze bestehen heute (noch) aus autonomen Komponenten. Jede Komponente betrachtet die eingehenden Pakete völlig unabhängig davon, was vorher mit ihnen passiert ist. Damit das Paket einer bestimmten Dienstegüte zugeordnet werden und entsprechend weitergeleitet werden kann, muss es eine Markierung aufweisen. Diese Markierung wird entweder bereits vom Endgerät vorgenommen oder aber von der Netzkomponente, an der das Paket in das Netz eingeleitet wird.

Das Queuing: Die Netzkomponente (Switch, Router) ordnet die Pakete anhand ihrer Markierung in eine Warteschlange (Queue) ein. Die einfachste Variante besteht aus einer „Priority Queue“, die quasi als Überholspur an allen anderen Warteschlangen vorbeiführt. Die übrigen Queues werden nur bedient, sobald die Priority Queue leer ist. Demgegenüber basiert „Rate Queuing“ auf mehreren Warteschlangen, die mit einer gewissen Häufigkeit nacheinander abgefragt werden.

Das Verkehrs-Management: Es wacht darüber, dass Datenverkehr bestimmter Klassen bestimmte Grenzwerte einhält. Insbesondere sorgt es dafür, dass Verkehr in der Priority Queue den übrigen Verkehr nicht vollständig lahmlegt. Eine zuweilen als „Policer“ oder „Packet Shaper“ bezeichnete Instanz erledigt das, indem sie entweder Pakete verwirft oder diese in eine Warteschlange sehr niedriger Priorität schickt.

Was nützt das beste Verkehrs-Management, wenn die Anwendung davon nichts weiß? Nehmen wir als Beispiel ein Video Streaming. Videos sind bekanntermaßen besonders anfällig auf Paketverluste – ganz im Gegensatz zu Voice. Wenn Sie Videos über die Priority Queue schicken und diese auf 10 Mbit/s begrenzt ist (z.B. in einem WAN), gibt es massive Störungen, sobald die 10 Mbit/s überschritten werden, etwa weil auf einmal mehrere Videos gleichzeitig zu übertragen sind.

Wüsste die Anwendung, hier der Video Server, um die maximal zugewiesene Bitrate, würde er von vorneherein die Zahl der Videos begrenzen und den Anwender entsprechend informieren. Ein Anwender erhielte eine aussagekräftige Fehlermeldung, die anderen genössen störungsfreie Videos. Ohne Wissen und Mitwirkung der Anwendung werden aber alle Anwender gestörte Videos beklagen, das haben Sie wahrscheinlich schon einmal erlebt.

Und genau hier mangelt es: Die Anwendung weiß nichts vom Netz und das Netz weiß nichts von der Anwendung. Im Bereich der VoIP-Telephonanlagen gibt es erste Ansätze in Form eines Call Admission Control. Aber auch das ist nur eine „Krücke“. Wie wäre es also, wenn Anwendung und Netz miteinander sprächen und sich über Bitratenbedarf und –Angebot austauschten?

Ein Ansatz dafür könnten die Software-defined Networks (SDN) sein. Bei SDN existieren grundsätzlich entsprechende Schnittstellen. Und die Hersteller haben es erkannt. Bei Microsoft beispielsweise findet man inzwischen eine SDN-API für Lync, die mit dem Ziel bereitgestellt wurde, QoS-Parameter mit dem Netz aushandeln zu können.

Ich bin also ganz gespannt darauf, wie die praktische Umsetzung von QoS in der Zukunft aussehen wird. Vielleicht gelingt es ja am Ende doch, Übertragungsqualität in Netzen mit einem überschaubaren Aufwand sicherstellen zu können.

zugeordnete Kategorien: Archiv, Klassiker
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.