Erste Ansätze zur Übertragung
von Video oder Sound erfolgten durch die Nutzung von TCP als Transport-Protokoll.
TCP stellt hierbei sicher, daß die Daten
Bei ersten Versuchen (z.B. in einem gering ausgelasteten LAN Ethernet-Segment) ergeben sich hierbei i.d.R. sehr gute Resultate. Die Datenrate kann zugesichert werden, und selbst bei stationären Störungen im Ethernet-Segment, kann TCP diese Fehler noch beheben.
Es stellt sich also unmittelbar die Frage, warum TCP nicht grundsätzlich für die Übertragung von Video und Sound benutzt werden sollte?
Die Antwort hierauf ist, daß die hierbei gemachten Annahmen für weite Teile des Internet völlig unrealistisch sind. Statt einem quasi immer verfügbaren Ethernet-Segment mit 10MBit/s bieten die meisten Internet Verbindungen deutlich geringere Bandbreiten und vor allem sehr hohe Paketverluste durch falsches Routing, „verstopfte Leitungen“ ("congestion") und Netzwerkausfall an.
Diese wesentlichen Fakten
in einer "realen Welt":
TCP stellt grundsätzliche immer eine fehlerfreie Datenübertragung zur Verfügung. Da in einem realen IP Netz dies jedoch per se nicht möglich ist, werden Fehler durch erneutes Senden von fehlerhaften Paketen ausgeglichen. Dies wird als „retransmit“ bezeichnet. Ein solcher retransmit hat jedoch erhebliche Folgen für die Übertragungsrate, bei einer vorgegebenen Paketverlustrate.
Werden z.B. 10% aller Pakete
erneut gesendet, so reduziert sich die effektive Übertragungsrate
auf 100/(100+10)=90%. Die nachfolgende Tabelle zeigt andere Wert an:
| retransmit-Rate | effektive Übertragsungsrate |
| 10% | 90,9% |
| 20% | 83,3% |
| 30% | 76,9% |
| 50% | 66,6% |
Bei einer großen "retransmit"-Rate fällt somit die maximale Übertragungsrate dramatisch ab, so daß eine sinnvolle Übertragung hinsichtlich des vorgegebenen zeitlichen Verhaltens nicht mehr sicherzustellen ist.
Da TCP sich möglichst optimal an gegebene und sich ändernde Übertragungsraten anpassen will, entstehen neben dem effektiven Abnehmen der Übertragungsrate noch weitere nachteilige Folgen.
TCP benutzt das "sliding window" Prinzip bei der Übertragung. Hierbei wird nicht vor jeder Übertragung eines einzelnen Pakets auf die Bestätigung des entsprechenden Vorgängerpakets gewartet, sondern es werden auch Pakete unter der Annahme, daß diese i.d.R. fehlerfrei ankommen werden, von Absender abgeschickt. Die Anzahl der Pakete, die ohne einzelne Bestätigung abgesandt werden, stellen die "window" Größe dar. Treten jetzt jedoch bei einer Übertragung Fehler auf, so reduziert der sendende TCP Prozeß diese "window" Größe. Hierbei wird zumeist das "window" auf die halbe Größe eingestellt. Wird die Übertragungsqualität dann wieder besser, so wird die "window" Größe nicht auf einmal auf den alten Wert erhöht, sondern das "window" wird Schritt für Schritt wieder auf den alten Wert erhöht, bis eine weitere Störung eintritt. Diese Strategie macht bei herkömmlichen Datenübertragungen durchaus Sinn. Denn durch ein zu schnelles hin- und herschalten der "window" Größe könnte eine Resonanz bei der Übertragung eintreten, die eine effektiv niedrigere Übertragungsrate zur Folge hätte. Andererseits ergibt sich bei der eingesetzten Strategie ein Sägezahn-Verlauf der Übertragungsrate, was sich auf das zeitliche Verhalten der Übertragung natürlich sehr erheblich auswirkt. Denn es kann weder eine vorgegebene Datenrate noch die entsprechende Syncronität zugesichert werden.
Deshalb läßt sich
eindeutig feststellen, daß TCP als Transportmedium für Medienströme
völlig unbrauchbar ist.
Denn gerade die wichtigsten
Kriterien werden durch TCP verletzt: