Seite 2: Mischbetrieb

Inhaltsverzeichnis

Mischbetrieb

Solche Reibungsverluste dürften noch zunehmen, weil Netzbetreiber ihre schnellen Anschlüsse für Triple-Play-Kombinationen anbieten – Internet, IPTV und VoIP-Telefonie nutzen dann zum Beispiel WG- oder Familienmitglieder parallel zum Mail-Versand und Online-Spielen. Dabei konkurrieren alle Anwendungen unkoordiniert um die Bandbreite eines Anschlusses und dann treten bei der VoIP-Telefonie zu hohe Verzögerungen und Aussetzer auf, Downloads laufen zäh und die Reaktionszeit bei Spielen nimmt überproportional zu.

An der Bandbreite der Internet-Backbones liegen solche Probleme nicht; die haben ausreichend Reserven. Ein Flaschenhals liegt zwischen dem Endkunden und dem Internet-Service-Provider, die "letzte Meile". Diese Teilnehmeranschlussleitung (TAL) zum Provider hat am wenigsten Bandbreite und deshalb stauen sich die Daten davor und dahinter.

Besonders deutlich fällt dieser Effekt bei extrem asymmetrischen Anschlüssen auf, zum Beispiel bei ADSL2+. Dabei liefert der Empfangskanal bis zu 16 MBit/s, während der Sendekanal maximal 1 MBit/s befördert. Geht auf so einem Anschluss ein Download mit maximaler Geschwindigkeit ein, ist der Senderkanal schon zu 50 Prozent allein mit ACK-Paketen gefüllt und sobald eine weitere Anwendung sendet, treten die üblichen Symptome auf.

Es kann daher von Vorteil sein, die Upload-Geschwindigkeit für bestimmte Anwendungen zu begrenzen. Zum Beispiel bringen viele Tauschbörsen-Programme Funktionen für die Bandbreitenbegrenzung mit und wenn man mehrere solcher Programme gleichzeitig nutzt, etwa eMule und BitTorrent, muss man sogar jedem Programm einen festen Teil der Gesamtbandbreite zuordnen. Leider bieten viele andere Anwendungen, etwa FTP-Clients oder Mail-Programme, keine solche Option.

VoIP-Bedürfnisse

Beim Internet-Radio oder auch IPTV müssen die Daten mit einer konstanten Rate abgespielt werden. Die Pakete kommen jedoch nicht mit einer konstanten Datenrate beim Empfänger an, weil sie unterschiedliche Wege nehmen oder zwischengeschaltete Router vorübergehend ausgelastet sind.

Daher puffern die Player die eingehenden Pakete und lesen sie mit einer konstanten Datenrate aus. Die Puffergröße wählt der Player so, dass er Übertragungsaussetzer von einigen Sekunden ausgleichen kann. Wird die Verzögerung zu lang, läuft der Puffer leer und die Musikwiedergabe setzt kurz aus beziehungsweise das Video ruckelt. Um solche Situationen zu vermeiden, würde man den Puffer instinktiv großzügig dimensionieren.

Streaming- oder auch VoIP-Daten kommen nicht mit einer konstanten Geschwindigkeit an. Daher werden sie nach dem Empfang gepuffert und dann mit einer konstanten Rate abgespielt. Das hat bei Streaming-Anwendungen lediglich einen kleinen Nachteil zur Folge: Die Latenz nimmt zu und die Wiedergabe eines Video-Clips setzt später ein als bei kleinem Puffer.

Bei Voice over IP toleriert man aber nur geringe Latenzen. Steigen sie über 200 ms, empfindet man sie als störend, weil unklar ist, wann der Gesprächspartner schweigt, sodass man ihm ungewollt ins Wort fällt.

Einerseits will man also möglichst große Puffer, um Aussetzer zu vermeiden, andererseits will man möglichst kleine Puffer, um kurze Antwortzeiten zu erreichen. Verschiedene Verfahren bieten einen Ausweg aus dieser Zwickmühle. Der eleganteste Ansatz besteht darin, die VoIP-Pakete höher zu priorisieren, damit sie andere Pakete möglichst wenig aufhalten.

Dafür müsste jedoch eine Verbindung Ende-zu-Ende mit definierter Bandbreite und Latenz ausgehandelt werden und alle Router einer Strecke müssten sich daran beteiligen (Quality of Service – QoS). Doch dafür ist nicht nur ein globales Prioritätsschema erforderlich, sondern die Router der Backbones müssten ziemlich viele Daten puffern und priorisieren – also deutlich mehr Speicherkapazität und Rechenleistung haben als heutige. Immerhin wendet aber der eine oder andere Carrier intern schon ein wenig QoS an und befördert etwa VoIP-Pakete bei hohem Andrang bevorzugt.

RWIN-Einfluss
Messergebnisse mit RAS an T-DSL 1024/128 mit Fastpath
RWIN (Byte)	ein Download (KByte/s)	Ping-Zeiten (ms)	ein Upload (KByte/s)	Ping-Zeiten (ms)	je ein Down-/Upload (KByte/s)	Ping-Zeiten (ms)
default	122,7	105	15,7	397	33,9 / 14,4	431
28.000	122,8	196	15,6	414	50,1 / 14,0	458
65.535	122,8	476	15,7	412	94,6 / 12,8	546
26.214	122,7	639	15,6	416	39,1 / 14,5	462
52.428	122,7	638	15,8	426	105,6 / 12,6	627
10.485	122,7	636	15,9	430	37,1 / 14,7	467
Bei gleichzeitigem Up- und Download wird die jeweilige Gegenrichtung für Quittungsmeldungen mitgenutzt, was auf Kosten der Nutzdatenrate geht. Ping-Zeiten sind in ms zum nächsten Knoten angegeben. Antwortpakete des Testservers treffen in 34 ms ein (Roundtrip Time).