Hinterfragen der aktuellen Technik im Videostreaming
Der Großteil des derzeitigen Internetverkehrs wird über Content Delivery Networks (CDNs) abgewickelt. Die ständig steigenden Anforderungen der Endbenutzer an Bandbreite und Latenzzeit deuten auf eine zukünftige ständige Zunahme des über CDNs bereitgestellten Datenvolumens hin. Typischerweise transportiert das CDN Daten von der Quelle (d.h. den Inhaltsanbietern) zu seinen Backend-Servern, verschiebt diese Daten dann über ein ausgeklügeltes Overlay-Netzwerk zu seinen Frontend-Servern und stellt die Daten von dort den Endbenutzer zur Verfügung. Wenn wir uns auf den Weg der Inhalte von der Herkunft bis zum Endverbraucher über ein CDN konzentrieren, wird eine einfache Tatsache deutlich: ein erheblicher Teil dieses Pfades durchläuft die CDN-Infrastruktur, zwischen Backend und Frontend-Servern. Die durch diese Pfade gebildete „Server-zu-Server-Landschaft“ wird zunehmend „länger“, da Front-End-Server näher an den Endbenutzern eingesetzt werden, um die Latenz der letzten Meile zu minimieren. Seitdem CDNs ihre Infrastruktur durch den Einsatz von mehr Servern in verschiedenen Netzwerken und geografischen Standorten erweitern, wird die Landschaft auch „breiter“.
Die Server-zu-Server-Landschaft bietet einige einzigartige Perspektiven sowie Möglichkeiten zur Lösung einiger langjähriger Netzwerkprobleme im Internet. Die Endpunkte (oder Server) in dieser Landschaft liegen in der Kontrolle einer einzelnen Organisation (d.h. der CDNs, denen die Server gehören), obwohl die Pfade zwischen den Endpunkten immer noch den Launen des größeren Internets unterliegen können. Es ist also möglich, Netzwerkprotokolle in dieser Landschaft zu entwerfen, zu experimentieren und zu validieren, die ansonsten im Internet nicht einsetzbar wären, auch nicht für Tests. Angenommen, CDNs könnten die Software auf den Endbenutzergeräten steuern (z.B. eine JavaScript-basierte Anwendung, die Web-Objekte abruft), dann könnten wir auch einige der suboptimalen Protokolle bei der Bereitstellung von Inhalten, z.B. Video, wieder hervorholen, die bisher nicht in Betracht kamen.
Heute ist TCP das dominierende Transportprotokoll für Video-Streaming, da das dynamische adaptive Streaming über HTTP (DASH) weit verbreitet ist. Der reiche Bestand an früheren Arbeiten zur Optimierung von TCP, adaptiven Algorithmen zur Bitratenauswahl oder TCP-Varianten zeigt jedoch die Mängel von TCP auf. Unsere vorläufige Untersuchung zeigt, dass selbst bei einer Verlustquote von 0,16% – niedriger als die im Internet üblicherweise beobachtete – der Videoplayer, wenn er über TCP streamt, 20% der gesamten Videozeit im Wartezustand verbringt, während er darauf wartet, dass die verlorenen Pakete in den Wiedergabepuffer gelangen. Da CDNs (z.B. Akamai Technologies) und gängige Webbrowser (z.B. Google Chrome) QUIC (ein aktuelles Transportprotokoll von Google, das derzeit von der IETF standardisiert wird) bereits unterstützen, lohnt es sich, diesen Status-Quo beim Streaming zu überprüfen.
Um ein Video mit H.264 (dem am weitesten verbreiteten Videocodec im Internet) zu kodieren und über DASH zu streamen, werden die Videodaten in Chunks aufgeteilt. Jeder Chunk enthält die gleiche Anzahl von Videobildern (mit Ausnahme des letzten Chunks, der weniger Einzelbilder enthalten könnte), wie in der Abbildung gezeigt. Häufig wird das Video mit unterschiedlichen Qualitäten (d.h. mit unterschiedlichen Bitraten und/oder Auflösungen) kodiert und Details (z.B. Qualitätsstufen und Namen der Dateien, die jeder Ebene zugeordnet sind) werden in einer Manifest-Datei gespeichert. Clients (oder Videoplayer) holen zunächst die Manifestdatei und laden das Video Stück für Stück herunter. Vor dem Abrufen jedes Chunks bestimmen adaptive Bitraten-(ABR)-Algorithmen im Videoplayer die Qualitätsstufe dieses Chunks basierend auf abgeleiteten Netzwerkbedingungen. Wenn der Stream auf dem Weg zwischen Server und Client eine Überlastung aufweist, kann der ABR beispielsweise den nächsten Chunk mit geringerer Qualität abrufen und dadurch einen Stillstand (d.h. eine Pause) des Videostreams vermeiden. Um ein schnelles Umschalten zu ermöglichen, liegt die Chunk-Dauer üblicherweise im Bereich von 2 s bis 10 s.
Eine einfache Beobachtung zeigt, dass zuverlässige Transporte für Videostreaming ungeeignet sind: Videodaten bestehen aus verschiedenen Arten von Einzelbildern, von denen einige Typen keine zuverlässige Lieferung erfordern. Der Verlust einiger Arten von Frames hat minimale oder gar keine Auswirkungen (da solche Verluste wieder ausgeglichen werden können) auf die Qualität, die der Endbenutzer empfindet (QoE). Durch die Unterstützung von unzuverlässigen Streams in QUIC und einen selektiv zuverlässigen Transport, bei dem nicht alle Videobilder zuverlässig geliefert werden, können wir daher das Video-Streaming optimieren und die Benutzerfreundlichkeit verbessern. Dieser Ansatz hat mehrere Vorteile: (a) es baut auf QUIC auf, das sich schnell durchsetzt; und (b) es handelt sich nur um eine einfache, rückwärtskompatible, schrittweise einsetzbare Erweiterung – Unterstützung für unzuverlässige Streams in QUIC.achusetts, Amherst and Akamai Technologies to design a practical, scalable solution for video streaming.
Unser aktueller Fokus liegt auf einer gründlichen Untersuchung der Verwendung unzuverlässiger Streams für Video-Streaming und dem Zusammenspiel zwischen so einem teilweise zuverlässigen Transport und den ABR-Schemata der Anwendungsschicht. Zu diesem Zweck arbeiten wir mit Forschern der University of Massachusetts, Amherst und Akamai Technologies zusammen, um eine praktische, skalierbare Lösung für Videostreaming zu entwickeln.
