QoS mit Microsoft 365 und Teams

Quality of Service ist eine Konfiguration im Netzwerk, um bestimmte Pakete zu priorisieren und ist insbesondere für Audio und Video wichtig. Aber brauchen wir dies auch für Microsoft Teams, einem Dienst der aus der Cloud über das Internet bereitgestellt wird?. Laut Microsoft ja aber wie sieht es in der Praxis aus?

Zum technischen Aspekt von QoS habe ich einen kompletten Bereich auf Netzwerk und QoS veröffentlicht.

Wo findet QoS statt?

Ein Netzwerk-Administrator oder Applikationsadministrator kann Pakete anhand verschiedener Kriterien "Markieren" (DSCP-Taggging) und diese beim Routing entsprechend vorziehen oder verwerfen. Schauen wir uns zuerst noch einmal die "Media Flows" an, die bei Microsoft Teams möglich sind und welchen Weg diese laufen. Es gibt dabei drei Netzwerkzonen zu betrachten.

Zone QoS Beschreibung

LAN

Möglich

Solange die Paket sich in ihrem lokalen Netzwerk oder eigenen WAN bewegen, können Sie an jeder Steller per QoS die Übertragung steuern. Ob das erforderlich ist, wäre zu prüfen. Wenn Sie den Microsoft Empfehlungen folgen und jeder Standort hat sowieso seinen eigenen Internet Breakout, dann sind die Pakete nur wenige Hops in ihrem LAN unterwegs. Die meisten LANs haben heute Gigabit und mehr Reserven als ihre Internet-Leitung und das Server-Backbone mit iSCSI, Backups, VM-Replikation etc. sind hoffentlich separiert.

ISP

Providervorgaben

Der Weg zwischen ihrem Firmenausgang und dem Microsoft-Eingang stellt ihr ISP direkt oder über Peerings mit anderen Providern bereit. Das erste ,was ein ISP in der Regel mit ihrem Paket macht, ist die QoS-Kennzeichnung zu entfernen und eventuell eigene Marker zur eigenen Verwaltung zu setzen. Ihre QoS-Vorarbeit ist fast immer irrelevant und sie können nur drauf hoffen, dass der Provider "genug" Bandbreite hat. ISPs könnten sehr wohl den Teams-Verkehr z.B. anhand der Ziel-Adressen und UDP-Port 3478-3481 erkennen und gegen Aufpreis auch priorisieren.

Tipp: Mit Programme wie Rimscout kann ich solche Dinge wunderbar messen.

Microsoft

Microsoft

Sobald die Pakete im Microsoft Netzwerk (AS8075) sind, kümmert sich Microsoft um die Übertragung. Angeblich ist dort alles QoS gesichert, so dass 0% Paketloss und niedrigste Latenzzeiten sichergestellt sind. Auch dies müssen wir erst einmal glauben. Aber das MGN - Microsoft Global Network ist da sehr gut aufgestellt.

Nun schauen wir uns mal das Bild, bestehend aus einem Firmen-Client, Homeoffice-Client, den ISPs und Microsoft an. Sie sehen sehr gut, dass nur der hellgrüne eigene Bereich überhaupt für QoS relevant ist.

Da ist die Frage durchaus berechtigt, in welchen Fällen QoS eine Verbesserung erreichen kann. Diese Wege können wir auch noch einmal auffalten:

Teams Media Flow

Daher müssen wie uns die verschiedenen Kommunikationsbeziehungen und ihren Weg durch die Netzwerkzonen betrachten. Sie werden schnell sehen, dass es oft nur die ersten Hops in ihrem Netzwerk sind, die durch QoS überhaupt tangiert werden.

Die Beschreibung ist auf Microsoft Teams ausgerichtet aber Sie können die Bilder bis auf wenige Ausnahmen unverändert auch für den Zugriff auf Exchange Online, SharePoint und andere Cloud-Dienste in der "blauen Box" verwenden.

Szenario Beschreibung

Intern 1:1 Audio/Video

Wenn zwei Personen sich direkt "anrufen", dann versuchen die beiden Teams Gegenstellen eine direkte Verbindungen aufzubauen. Dies funktioniert, wenn beide Teilnehmer in einem gerouteten Netzwerk sein, z-B. im gleichen Standort und keine Firewall dies Verbindungen (UDP/TCP-Port 50.000-50059 als Sender und Empfänger) unterbinden.

Dies gilt auch für verschiedene Standorte mit einen gerouteten WAN-Link.

Tunnel VPN

Wenn ein Teilnehmer im Homeoffice ist und ein Tunnel VPN-nutzt, dann sieht die Streck schon schlechter aus, denn der Client zählt quasi als "intern" aber kommt von extern über seinen ISP und ein Peering zum Firmen-ISP

Das ist nicht durch QoS optimierbar. Denken Sie daran, dass sie bei den weiteren Szenarien diesen VPN-Overhead noch vor den internen Firmen-Client stellen müssen

Tipp: Ich würde aber Audio und Video nie durch ein VPNs routen. Bei Cloud-Nutzung ist es ein großer Umweg und selbst intern ist das Provider-Peering oft schlechter und TCP(HTTPS-VPNs stören bei PaketLoss.

Extern 1:1 Audio/Video

Wenn ein Teilnehmer im Homeoffice ist und kein VPN-nutzt oder das VPN die Ports sperrt oder der Teilnehmer per Federation in einer andere Firma ist, dann wird die Verbindung über STUN/TURN hergestellt. Beide Teilstreams verlassen sehr schnell ihr LAN Richtung Internet.

Beide Firmenstandorte können nicht direkt miteinander kommunizieren, so dass Sie über die Microsoft Media Relay-Server gehen.

Nun stellen Sie sich einmal vor, das ein Anwender im Homeoffice per Tunnel-VPN arbeitet und eine andere Firme anruft.

Dies ist eine für Teams sehr ineffektive Konfiguration.

Im Vergleich dazu würde mit einem Split-VPN der Weg über die TURN-Server deutlich kürzer. QoS gibt es dann aber keins.

Konferenz

Sobald drei oder mehr Parteien per Audio/Video kommunizieren, werden die Daten immer über die Konferenz-Bridge bei Microsoft geleitet. Die Paket laufen kurze Zeit durch ihr lokales LAN bis zum Breakout und dann über den ISP zu Microsoft.

Auch hier ist nur die erste Teilstecke mit QoS kontrollierbar und zeigt, wie wichtig eigentlich der ISP und dessen Peering zu Microsoft ist.

PSTN 1:1 Audio

Beider PSTN-Telefonie hängt es davon ab, wo der SBC steht und ob Sie "Local Media Optimization" konfiguriert haben. Normalerweise verbinden sich alle Clients immer mit dem Microsoft Relay-Server, der dann die Verbindung zum entsprechenden SBC weitergibt. Per QoS ist dann nur der Abschnitt in ihrer Firma nutzbar. Alle andere Wege sind vom Betreiber abhängig.

Sie können aber mit Local Media Optimization erreichen, dass der FirmenClient den lokalen SBC per RTP direkt anspricht und damit komplett mit QoS gesichert sein kann.

In allen anderen Fällen von "Direct Routing", bei denen der SBC nicht in ihrem LAN steht, also über einen Provider, Hosted-SBC oder Microsoft Dialpläne, wird die Verbindung einen kurzen Weg durch das lokale LAN bis zum Breakout gehen, um dann über den ISP zu Microsoft zu laufen.

Remote Breakout

Sollten Sie an einem Standort keinen lokalen Breakout haben und die Client erst über ihre eigene WAN-Leitungen zum Ausgang schleusen dann sollten Sie die Überwachung es internen Netzwerks so ausbauen, dass Sie die Latenzzeiten vom Client bis zum Breakout messen können und ggfls. mit QoS nachhelfen.

Sie könnten daher sehr schnell auf den Gedanken kommen, dass QoS gar nicht so wichtig ist. In vielen Fällen stimmt dies sogar und wer eh "genug Bandbreite" hat, kann sich sicher zuerst anderen Aufgaben widmen.

QoS im eigenen WAN

Aber QoS sollten sie nicht vorschnell beiseite schieben, denn es gibt Fälle, in denen QoS wichtig sein kann, z.B.

  • Eigenes WAN
    Wenn Sie ein Konzern mit mehreren Standorten haben, die per WAN und IP-Routing verbunden sind, dann werden zumindest die 1:1 Gespräche direkt zwischen den beiden Teilnehmern übertragen, wenn Sie dies zulassen. Hier ist QoS im eigenen Verbundnetzwerk eine effektive Funktion ,um auf den WAN-Strecken die Qualität zu sichern.
  • Knappe Ressourcen
    QoS ist natürlich immer ein Hilfsmitteln, um knappe Bandbreiten fair zu verteilen. Ein paar 100kBit Audio-Verbindungen sind vermutlich immer noch wichtiger als die Verteilung von Windows Updates oder Office Updates. Bestimmte Datenübertragungen können meist ohne Risiko etwas verzögert werden, um Raum für Realtime-Daten zu schaffen. QoS ist dann aber nicht nur für Audio/Video interessant, sondern auch für interaktive Übertragungen, z.B. RDP/ICA oder SAPGUI, damit die Anwender flüssig arbeiten können und keine VM-Replikation, Site-Backup o.ä. stört.

QoS können Sie auch nutzen, um Audio gegenüber Video zu priorisieren. Video braucht meist 10-20Mal mehr Bandbreite als Audio. Mit QoS können Sie Video gezielt beschränken, so dass es statt FullHD mit 60fps vielleicht auch mit 720p und 30fps auskommt und so mehr Raum für Audio verfügbar ist.

Local Breakout

Aber sobald ein "Mehrwert" durch das Teams Backend in der Cloud zu erbringen ist, d.h. Konferenzen, Call-Queues, Auto-Attendant, Call Recording, Federation, Homeoffice ohne Tunnel-VPN, sollten Sie schon aus Eigeninteresse ihre Audio/Video-Daten möglichst auf dem kürzesten Weg aus ihrem Netzwerk Richtung Cloud routen, um die interne Bandbreite zu schonen. Besonders nachteilig sind Standorte ohne Internet-Ausgang oder Tunnel-VPN-User im Homeoffice, die Ihre Daten erst über lange Weg bis zum Internetausgang der Firma routen.

Nicht umsonst beschreibt Microsoft in seinen Netzwerkprinzipien, dass Local Breakout, Proxy-Bypass, keine Deep Inspection etc. für Cloud-Dienste wichtig sind. Dies muss nicht ihren Sicherheitsvorgaben widersprechen. "Local Breakout" bedeutet ja nicht, das alle Ziele im Internet nun komplett ohne Proxy, ohne Inspektion, ohne Authentifizierung durch jeden Client erreichbar sein müssen. Es geht um bestimmte Ziele und bestimmte Protokolle, die klar dokumentiert sind.

Fragen Sie ihre IT-Security oder ihren Firewall-Betreiber, wie er SRTP mit Sprache und Video denn "inspizieren" möchte?

Daher verwende ich oft einige Zeit mit der iT-Security, dem Firewall-Admin und Netzwerk-Administratoren, um Sie über die verschiedenen Payloads von Microsoft 365 auf technischer Ebene abzuholen. In der Regel ist es dann überhaupt kein Problem mehr, die erforderlichen Freischaltungen in kurzer Zeit zu erreichen. Denn auch die Firewall und der Proxy-Betreiber profitieren davon, wenn z.B. Audio/Video den "Grenzschutz" geplant umgehen darf.

Monitoring

Ob sie nun QoS brauchen oder nicht, können Sie entweder auf technischer Ebene bewerten und entscheiden, oder sie "messen" einfach. Mittlerweile haben die meisten Firmen schon Microsoft Teams im Einsatz und der Service erfasst automatisch Telemetrie-Daten der Verbindungen. So können sie zumindest auf dieser Basis z.B. Paketverluste und Latenzzeiten abfragen, die einen Hinweis auf schlechte Verbindungen oder Standorte sein können. Natürlich können Sie auch die Rückmeldungen von Anwendern einsammeln, wenn diese "Tickets" eröffnet haben oder das Teams User Feedback/ Rate my Call bzw. RateMyCall Awareness nutzen.

Diese Quellen liefern aber immer nur Momentaufnahmen, wenn eine Verbindung stattgefunden hat und keine kontinuierliche oder vergleichbare Werte, die Sie für eine Fehlersuche benötigen. Auch ein Monitoring der Netzwerkverbindungen per SNMP mit Zählung der Paketanzahl und übertragenen Bytes können zwar den Füllgrad einer Netzwerkteilstrecke aber keine Latenzzeiten oder Paketverluste aufzeigen. Zudem stehen solche Messpunkte meist im Rechenzentrum und erfassen damit nicht den Anwenderclient oder dessen Verbindung. Dies gilt insbesondere auch für Benutzer im Homeoffice oder auf Reisen.

Aus meiner Sicht ist es daher ratsam eine Überwachung vom Endgerät zu den vom Anwender genutzten Diensten umzusetzen, die kontinuierlich die Konfiguration, die Erreichbarkeit und die Qualität der Verbindung anhand Latenzzeiten und Paketverlust regelmäßig überprüft und eine zentrale Auswertung erlaubt. Dazu habe ich aber auf verschiedene anderen Seite schon Hinweise zur Umsetzung gegeben:

Meine Einschätzung

QoS ist wichtig und wenn Sie die Möglichkeit und den Bedarf dazu haben, dann sollten Sie mit ihrem Netzwerkteam überlegen, wie Sie Audio und Video in ihrem Netzwerk die gewünschte Priorisierung einräumen ohne andere Übertragungen über Gebühr zu benachteiligen. Aber QoS ist aus meiner Sicht nicht die wichtigsten Komponente, denn deutlich größeren negativen Einfluss haben klassische Fehlkonfigurationen, die Microsoft auch klar benennt, z.B.

  • Falsche DNS-Konfiguration
    Ihr Teams Client nutzt DNS, um das netztechnisch nahestehende Media Relay zu finden. Wenn eine Niederlassung auf Kontinent-A über das eigene WAN den DNS-Server der Firmenzentrale auf Kontinent-B fragt, dann ist die Antwort sicher nicht optimal.
  • UDP nicht verstanden
    Noch immer blocken Firewalls die Teams Media Endpunkte über UDP/3478-3481 aus Unwissenheit oder Sorge um die Sicherheit. Damit muss Teams auf TCP oder HTTPS umsteigen und das sind nun mal schlechtere Transportmittel für Audio und Video. Sobald Paketverluste auftreten, wird es richtig schlecht
  • Lange interne Wege statt "Local Breakout"
    Der kürzeste Weg zu Microsoft ist der Beste. Sorgen Sie dafür, dass der Client sehr schnell einen potenten ISP erreicht, der gut an Microsoft angebunden ist
  • Split-VPN für Teams und Cloud-Dienste
    Für A/V im Besonderen aber auch für normale Datendienste sollten ihre Clients von zuhause oder auf der Reise nicht erst durch das VPN und mehrere ISP und Peerings in ihre Firmennetzwerk routen um dann wieder ins Internet zu Microsoft zu kommen.

Wen Sie diese Vorgaben umgesetzt haben, dann können wir uns auch gerne über die Optimierung der ersten Hops in ihrem LAN hinsichtlich QoS unterhalten.

Weitere Links