Qualitätsgarantie

Die Idee von Quality-of-Service für Applikationenwurde eigentlich für die LAN Technologie erdacht, doch der anhaltende Anstieg der zur Verfügung stehenden Ethernet-Bandbreiten in Unternehmen hat in vielen Fällen dazu geführt, dass Quality-of-Service in LANs kaum noch benötigt wird. Selbst in den Core-Netzwerken von Service-Providern steht mehrals genug Kapazität für den Transport verzögerungsempfindlicher Anwendungen ohne nennenswerten Delay zur Verfügung. Tatsächlich garantieren einige Provider eine geringe Verzögerung allein auf der Basis, dass sie über eine so hohe Bandbreite verfügen, dass ein Datenstau praktisch nicht auftreten kann.

Doch was im LAN und für Service-Provider-Core-Netze gilt, lässt sich nicht automatisch auf alle Netzwerkbereiche übertragen.Mindestens einTeil des verteilten Unternehmensnetzwerks hat praktisch immer mit Engpässen zu kämpfen: die»letzte Meile«.Hier ist es nicht möglich, einfachmehr Bandbreite einzusetzen, um genügend Kapazitätbereitzustellen und damit Quality-of-Servicefür Applikationen zu gewährleisten.

Zwischen der Unternehmensniederlassungund dem Core-Netzwerk des Service-Providersklemmt ein Flaschenhals, der lediglich einigekBit/s oder MBit/s Datendurchsatz ermöglicht.

Wenn der Verkehrsstrom das LAN verlässt, sehensich die Applikationen mit dieser beschränktenBandbreite konfrontiert. Der Engpassführt zur Verzögerung von Applikationen, diedarauf angewiesen sind, quasi in Echtzeit übertragenzu werden – zum Beispiel Sprach- undVideoübertragungen über IP oder Thin-Client-Sitzungen.Genau hier besteht die größte Gefahr,dass Applikationen verzögert werden oder garganz ausfallen.

Selbst wenn Service-Provider den Datenverkehrfür den Transport über ihre Core-MPLSWANsin verschiedene Diensteklassen, die Classof-Service, einteilen, bleibt nach wie vor der Flaschenhalsder letzten Meile als Quelle für zahlreichePerformance-Probleme von Applikationen.

Der Wirkungsbereich von Classes-of-Service, diedie Verkehrsströme nach unterschiedlichen Verzögerungs-und Paketverlust-Kategorien innerhalbdes Provider-Cores einteilen, reicht nur biszu den Edge-Routern im Core-WAN – und nichtbis zu den Zugangs-Routern der Unternehmensniederlassungen.

Tatsächlich ist die in den meisten Service-Provider-Netzwerken verwendete Quality-of-Servicemehr eine statistische Schätzung als die echteGarantie einer durchgängigen Anwendungs-Performance.

Wenn Service-Provider anbieten,Applikationen einzelner Serviceklassen inihrem IP-Core zuzuweisen, ist noch lange nichtgarantiert, dass eine bestimmte Anwendung –oder eine bestimmte Sitzung innerhalb dieser Anwendung– mit einer definierten Verzögerungoder exakt festgelegten Paketverlust-Charakteristikaüber das Netzwerk übertragen werden –doch genau dafür steht Quality-of-Service.

Stattdessen werden lediglich die »meisten« Anwendungenin einem betrachteten Zeitintervall»meistens« über das Netzwerk übertragen – mitakzeptablen Parametern.

Eine Analogie für den Unterschied zwischenClass-of-Service und Quality-of-Service findetsich bei der Kapazitätsplanung von Straßen.

Wenn Class-of-Service für eine Autobahn behauptet,dass 50 000 Fahrzeuge pro Stunde darüberfahren können, so ist diese Zahl ein Durchschnittswert,der bei der Betrachtung über einenlängeren Zeitraum generiert wurde. Er bietet jedochkeine Einsicht in die tatsächliche Belastungdes Streckenabschnitts – fuhren 50 000 Autos,Transporter oder Motorräder darüber? Wie hochwar die Geschwindigkeit zur morgendlichenHauptverkehrszeit? 150 oder 15 km/h? Qualityof-Service hingegen soll genau das leisten: Zeigen,welche Fahrzeuge die Straße nutzen, und garantieren,dass einzelne Fahrer innerhalb einerbestimmten Zeitspanne den Streckenabschnittpassieren können – egal, ob es 8.30 Uhr in derFrüh ist oder Mitternacht.

Um echte Quality-of-Service liefern zu können,reicht es nicht aus,Verkehr in generalisierteKlassen einzuteilen und Applikationen zu erlauben,im Flaschenhals der »letzten Meile« umBandbreite zu kämpfen.Damit Quality-of-Servicefunktioniert, ist es vielmehr nötig, einerseitsauf Seiten des Service-Providers die Datenströmeeinzelnen Klassen eines MPLS-Netzwerks zuzuweisenund andererseits ein Traffic-Manage-ment-Schema zu implementieren, das die gegenseitigeBeeinflussung von Applikationen über dieletzte Meile verhindert.

Traffic-Management, oder Bandbreiten-Optimierung,analysiert genau, welche Anwendungenauf dem Netzwerk laufen, und garantiertgleichzeitig eine bestimmte Applikations-Performance über das verteilte Netzwerk. VielenUnternehmen geht es darum,eine bestimmteEndanwender-Erfahrung zu definieren und diesesicherzustellen – etwa, dass Clients innerhalbdes Netzwerks eine konsistente, erwartete Performanceunabhängig von der Belastung desNetzwerks erhalten.Drei einfache Schritte sindder Schlüssel zu dieser konsistenten und vorhersagbarenApplikations-Performance:

•  Auf dem Netzwerk laufende Anwendungen analysieren,
•  Auswirkungen von Bandbreiten-»hungrigen « Anwendungen begrenzen und
•  ein Set von applikationsbasierten SLAs implementieren, um die Endbenutzer-Erfahrung zu überwachen und zu garantieren.

Wissen, was im Netzwerk los ist

Verzögerungsempfindliche Anwendungen, wieSprach- oder Videoübertragungen,sollten immereine faire und gleichmäßige Performance über die»letzte Meile« erhalten. Voraussetzung dafür istdas Identifizieren jeder einzelnen Applikation aufdem Netzwerk anhand ihrer Signatur – nicht anhandeiner well-known TCP-Port-Nummer oderdurch das Vertrauen auf eine Type-of-Service-Markierung,die möglicherweise zuvor für die Anwendungvergeben wurde.Dadurch lassen sich Anwendungen,die so viel Bandbreite wie möglichbelegen (zum Beispiel Datenbank-Replizierungenoder privat genutzte, von der IT oft nicht registrierteProgramme), identifizieren und – wennnötig – entfernen. Es ist eine Tatsache, dass diemeisten Unternehmen nicht wissen,wie viele Anwendungenauf ihren Netzwerken laufen.Meistsind es viel mehr, als sie lizenziert haben.

Die korrekte Klassifizierung des gesamten Datenverkehrsist der erste und wichtigste Schrittauf dem Weg zu einer konsistenten Endbenutzer-Erfahrung. Zahlreiche Applikationen, wiePeer-to-peer-Programme (P2P), die kurzfristigsehr viel Bandbreite beanspruchen (»Burst«-Verhalten),suchen einen offenen Port (»Port hopping«) – und das kann der Port für die IP-Telefonie(IPT) sein. Das ist besonders dann einProblem, wenn das P2P-Programm auf einemNotebook oder Desktop-PC läuft, der ein IPTSoftware-Telefon verwendet.

VoIP-basierte Applikationen wie Skype wählenzufällig eine Port-Nummer aus, die über 1024liegt. Gleichzeitig versucht das Programm, Port80 (HTTP) oder Port 443 (HTTP/SSL) zu verwenden.Andere Applikationen, wie Video, basierenauf dem H.323-Protokoll, verwenden diePorts 1414, 1424 und 1720 bis 2517.Unternehmenmüssen für sich entscheiden,ob Skype oderH.323 geschäftswichtige Anwendungen sind.Doch in jedem Fall ist die Identifizierung der einenoder der anderen Applikation alleine anhanddes TCP-Ports nicht möglich.

Selbst wenn der geschäftswichtige IP-Telefonie-Datenverkehr richtig klassifiziert ist unddurch eine Class-of-Service geschützt innerhalbdes Carrier-Netzwerks übertragen wird,müssenmöglicherweise noch weitere Sprach- und Video-Applikationen klassifiziert und geschützt werden– vor anderen Programmen und untereinander.

Die Klassifizierung des Datenverkehrs ermöglichtes, die Datenströme zuverlässig der gewähltenClass-of-Service für die Übertragungüber das Core-Netzwerk des Service-Providerszuzuweisen. Eine Automatisierung des Klassifizierungsprozesseserlaubt den Aufbau einer skalierbarenLösung, die neue Anwendungen automatischden richtigen Classes-of-Service imUnternehmen zuordnet.

Netzwerk-Applikationen kontrollieren

Unerwartete Applikations-Performance führt oftzu Performance-Problemen – Anwendungen tunnicht mehr, was sie eigentlich tun sollen. ZumBeispiel ist Citrix für seinen geringen Bandbreitenbedarfpro Anwendersitzung bekannt (10bis 20 kBit/s).Trotzdem haben viele Benutzer zuihrem Verdruss herausgefunden, dass bereits einKlick auf die »Drucken«-Schaltfläche alle Sitzungenblockieren kann, wenn 20 MegabyteDruckdaten so schnell wie möglich über WANLinksübertragen werden wollen – die sind aberdafür ausgelegt, die schlanken Citrix-Sitzungenzu unterstützen.Auch wenn das Problem in derCitrix-Umgebung erkannt wurde, stellt manschnell fest, dass auch andere »schlanke« Anwendungenwie IP-Telefonie mit vergleichbarenProblemen kämpfen.Ein Telefongespräch belegtzum Beispiel rund 20 kBit/s.Unglücklicherweisekann der Rufaufbau beziehungsweise der Klingelton– abhängig vom Codec – bis zur vierfachenBandbreite beanspruchen.

Vergleichbare Probleme tauchen bei Videoübertragungenüber das Netzwerk auf. Die ITAbteilungmag eine Regel eingerichtet haben, dassjede Video-Session im Netzwerk maximal 100kBit/s belegen darf. Doch kann jeder Benutzermit etwas Zeit und Expertise die Streaming-Geschwindigkeitdes Videos zu seinem Desktop miteiner einfachen Änderung in den Client-Einstellungenmanipulieren.

Daher ist es wichtig in der Lage zu sein, dieBenutzungs-Charakteristika der Applikationensowohl vor als auch nach der Bereitstellung imverteilten Unternehmen analysieren zu könnenund sicherzustellen, dass Video- oder Sprach-Datenströmeinnerhalb des Netzwerks verwaltetwerden, so dass sie keine anderen Anwendungenbeeinflussen.Wenn die Datenrate, mit derApplikationen Daten ins Netzwerk senden,durch eine ausführliche Analyse bekannt ist, lässtsich ein passender Grenzwert für die Dateneinspeisungfestlegen. Dann ist auch bei stark belastetemNetzwerk eine sichere und konsistenteApplikations-Performance möglich.

Realistische SLAs entwickeln

Es gibt die generelle Annahme, dass ein Service-Level-Agreement (SLA) eine garantierte Applikations-Performance festlegt.Und Service-Pro-vider tun nichts, um diesen Missstand aufzuklären.Doch so lange ein SLA nicht von LANzu LAN gemessen wird und es nicht möglich ist,sie anhand einer einzelnen Anwendung festzumachen,wird es keine Garantie geben, dass Applikationentatsächlich konsistent arbeiten. ImSpeziellen deshalb, weil Service-Provider SLAMessungenhäufig am Edge ihres Core-Netzwerksstarten und beenden – und nicht am Zugangs-Router des Unternehmens (Customer-Premises-Equipment, kurz CPE-Router):

• Von Service-Providern angebotene Verkehrs-SLAs enthalten normalerweise nicht die Netzwerk-Knotenpunkte, die für 70 Prozent Jitter und100 Prozent Paketverlust verantwortlich sind (amCPE-Router).
•  Von Service-Providern angebotene Verkehrs-SLAs berichten normalerweise nicht über Datenverkehr,der nicht die Vereinbarungen des SLAeinhält (wenn es am CPE-Router verworfen oderverzögert wurde).
•  Selbst wenn ein Service-Provider Berichte anbietet,die das Kundennetzwerk mit beinhalten,ist meist kein Mechanismus enthalten, der erkannteProbleme beheben kannDie Tabelle zeigt die SLA-Angebote von dreigroßen Service-Providern, die 2004 MPLSWAN-Dienste angeboten haben. Interessant:Verzögerung, Jitter und Verfügbarkeit variierennicht abhängig von der gewählten Class-of-Service.

Hauptunterschied der Angebote ist die Datenmenge,die verloren gehen darf. Diese Mengebezieht sich auf den im Core verlorenen Traffic,bezieht aber nicht unbedingt den Verkehrmit ein, der am Edge oder am CPE-Router alsFolge von Datenstau auf der »letzten Meile« verlorengehen kann.

Um SLAs wirklich sinnvoll einsetzen zu können,muss man zwischen Netzwerk-SLA und Applikations-SLA sowie zwischen Applikations-Performanceund Netzwerkereignissen unterscheidenkönnen. Für das effektive Management unddie Nachverfolgung eines herkömmlichen Service-Provider-SLA ist es essentiell, die Performancedes Datenverkehrs aus dem LAN herauszu messen,bevor er in den Flaschenhals der letztenMeile am Service-Provider-Netzwerk fließt.

Drei kritische Testparameter werden dafür benötigt:

• Antwortzeit (Response-Time,wichtig für die Kontrolle der Einhaltung des SLA),
•  Performance, Spitzen- und Durchschnittsdurchsatz pro Applikation und
•  Netzwerkeffizienz, gemessen durch die »TCPHealth«.

Durch die Verwendung dieser drei Parameter,die auf einer aussagekräftigen Basis gesammeltwurden – also auf einer Pro-Benutzer-Pro-Anwendungs-Basis –, lässt sich die Effektivitätund die Einhaltung eines Service-Provider-SLAs messen,Kompensation bei Nichteinhaltunggeltend machen und das Problem beheben. DieMessung der Antwortzeiten lässt sich unterteilenin Netzwerkverzögerung – die Zeit, die dieDaten für die Übertragung benötigen – und Server-Verzögerung – die Zeit, die der Server für dieGenerierung der Antwort benötigt.Mit dem Verständnis,welches Netzwerkelement wie zur Verzögerungbeiträgt, ist es möglich, Akzeptanzstandardszu setzen und zu verfolgen,welche Performance-Werte sie erreichen.

Applikations-Performance ist die Messung desBandbreitengebrauchs durch spezifische SprachundVideo-Anwendungen, gemessen an einzelnenLinks. Die Betrachtung der durchschnittlichenBandbreitenraten über lange Streckenkann ein trügerisches Gefühl der Sicherheit geben.

Dabei ist es wichtig, die Spitzenwerte zu verfolgenund kleinere Intervalle zu verwenden, alses das Reporting des Service-Providers vorsieht.Die Betrachtung der Durchschnittswerte magmanchen Anwender zum Glauben verleiten, dassder eigene Datenverkehr niemals die verfügbareKapazität erreicht. Die Darstellung der Spitzenwertehingegen kann einige Momente entlarven,in denen die gesamte Bandbreite ausgeschöpftund dadurch die SLA nicht erfüllt wurde.

Es kann auch das Gegenteil herauskommen:Zum Beispiel, wenn ein Unternehmen wenigerBandbreite benutzt, als es bezahlt – hier zeigt sichOptimierungspotenzial bei den Class-of-Service-Kosten auf.

Die Netzwerk-Effizienz ist die Fähigkeit, dieTCP-Health – also die »Gesundheit« des TCPLayers– zu messen und so ein umfassendes Bildder TCP-Verbindungen für eine Class-of-Serviceoder eine Applikation zu zeichnen. Dies lässtsich nicht direkt für UDP-basierte Verbindungenwie Sprache verwenden. Doch durch denGebrauch von künstlichem, synthetisch erzeugtemDatenverkehr, der neben dem UDPVerkehrherläuft, lassen sich Stauungen undVerzögerungen untersuchen. Im Falle einerTCP-basierten Applikation misst man in einerbestimmten Zeitspanne die Zahl der TCPVerbindungen,die gestartet, abgebrochen, vomServer ignoriert oder vom Server abgewiesenwurden.

Die TCP-Health-Informationen ermöglicheneine Diagnose der Ursachen von schlechter Anwendungs-Performance:Möglicherweise handeltes sich um ein Problem mit dem Server,der nichtalle TCP-Sitzungen gleichzeitig verarbeitenkann – ein Skalierungsproblem,wenn auf Citrixbasierende Applikationen einzeln gestartetwerden –, oder um eine Stauung als Ergebniseines sehr hohen Verkehrsaufkommens aufdem WAN-Anschluss.

Die Implementierung von Bandbreiten-Optimierungs-Technologie in einem Netzwerk isteiner der Schlüssel für die Bereitstellung von Quality-of-Service für Applikationen.Unternehmenkönnen verteilte Anwendungen nicht nur mitbesserer, konsistenterer Performance betreiben,wenn sie die Performance ihrer Schlüsselapplikationenauf dem Netzwerk kennen – sie könnenauch die mit dem Betrieb des WAN verbundenenKosten optimieren.

Christoph Weiss,
Regional Manager D A CH bei Packeteer