Over-The-Top TV Sind Fernsehen und Internet inkompatibel?

Transkript

1 Lehrstuhl Nachrichtentechnik Universität des Saarlandes Over-The-Top TV Sind Fernsehen und Internet inkompatibel? Thorsten Herfet Lehrstuhl Nachrichtentechnik Universität des Saarlandes

2 Oktober Worum soll es heute (nicht) gehen? Es geht um: Over-The-Top (OTT) Web-TV TV über offene IP-Netze Keine Einbindung des ISP, keine SLAs Dienstequalität Quality of Service / Quality of Experience Was geht? Was geht nicht? Die Aufklärung über Push/Pull, CDN, DASH, Multicast, P2P, P4P Es geht nicht um: Internet auf dem Fernseher Fernsehen auf dem PC

3 Oktober Das Internet als Übertragungskanal Client Router/ Cache Media Media Media Server Server Server Router/ Cache Client Client Client Client Ende-zu-Ende Unicast Flexibel, hoher Fan-Out Content Delivery Network Flexibel, teuer, mittl. Fan-Out Multicast niedriger Fan-Out, kein NAT- Traversal, unflexibel Peer-2-Peer (P2P) Flexibel, echtes OTT, niedrige Qualität Peer-4-Peer (P4P) Flexibel, aktive Teilnahme, nicht wirklich OTT

4 Oktober Streaming Streaming von: Video on Demand Near Video on Demand Live-TV Geeignete(s) Verfahren: Content Delivery Network Ende-zu-Ende Unicast P2P, P4P Content Delivery Network Multicast P2P, P4P Multicast Content Delivery Network P4P P2P (low quality)

5 Oktober Gibt es gut und schlecht? Nein! SopCast, Zattoo, Joost Peer-2-Peer, einfach verfügbar Geringe Qualität, hohe Latenz Das Erste und ZDF Mediathek mms:// Streaming Nutzt UDP (Uni- o. Multicast), TCP oder HTTP+TCP Content Delivery Network (Akamai) DVB-IPI RTP+UDP Streaming, Multicast T-Entertain Multicast, IGMPv3, kein OTT

6 Oktober DVB und die Kanalkapazität Nick Wells, BBC

7 7 Oktober 2011 Internet = Auslöschungskanal Paket-orientiert, daher Auslöschungskanal Gestörte Pakete werden von unteren Ebenen verworfen Kanalkapazität des Auslöschungskanals: Fehlerwahrscheinlichkeit: Kanalkapazität: 1 P e Minimale Redundanz: P e 1 P e P e

8 Oktober TCP in a Nutshell TCP (Transmission Control Protocol) 1981 erfunden, weiterentwickelt (RENO, CUBIC) Bietet verlässlichen Datentransport (bit-/byte pipe) Ende-2-Ende Split-TCP vorgeschlagen Unicast Unkontrolliertes Delay Sättigung behandelt Ü.-Fehler aber kritisch Ratenadaption als die Lösung Threshold Additive Increase Slow-Start Multiplicative Decrease Timeout Threshold

9 Warum funktioniert das nicht (gut)? Drahtlose Netze: Mittlerer (Unicast), hoher (Multicast) Verlust durch Ü.-Fehler TCP fällt aus, da Fehler wie Sättigung behandelt werden Rate sinkt schnell, steigt langsam (AIMD) Aber: Funktioniert im Unicast wegen MAC-Layer Und kann eh kein Multicast Großes BDP (sog. Long Fat Networks): Lange Übertragungszeit (n 100ms round trip) ACK-basiertes Schema limitiert den Durchsatz zwischen ACKs Große Datenmengen unacknowledged in transit, große Puffer nötig Sende- und/oder Empfangspuffer begrenzen den Durchsatz TCP basiert auf Ratensteuerung Medienübertragung erlaubt aber keine beliebige Rate Internet (= TCP/IP) & TV nicht wirklich kompatibel Oktober

10 Oktober TCP-friendliness TCP ist sättigungsgesteuert und ratenadaptiv Konkurrierende TCP-Ströme verhalte sich fair UDP ist nicht sättigungsgesteuert Verhält sich normalerweise egoistisch (Sättigungs-Kollaps) Wird daher manchmal durch Router oder ISPs gesperrt TFRC (TCP-Friendly Rate Control, Padhye s Modell) Gleichungsgesteuert (RFC3448, 2003) Integriert in Protokolle wie z. B. DCCP Nicht mediengerecht! B Modifikationen vorgeschlagen (lineare TFRC-Gleichung) TCP 2 p RTT 3 MSS 3p min 1,3 T 8 RTO p 1 32 p 2

11 DASH: Dynamic Adaptive Streaming over HTTP Pro Standardisiert ISO/IEC (Feb. 2011) OIPF v2.1 (Jun. 2011) Löst NAT & Firewall-Problem HTTP/TCP/IP weit verbreitet Nutzt Cache-Infrastruktur Keine speziellen Server nötig Client kontrolliert Pull- vs. Push-Betrieb Fairnis teilweise gelöst Durch Pufferung Mehrere Repräsentationen Kontra Lange Latenz (n 1 Sek.) Segment-weise Übertragung Puffer wegen Ratenschwankung Ineffizient (~200%) TCP-Overhead Ende-2-Ende Nur durch CDNs verbesserbar Unicast-Betrieb Schlecht für Live-Broadcast Pull-Betrieb Keine echte Synchronisation Oktober

12 Oktober Ein Vorschlag: PRRT Predictably reliable real-time transport (PRRT) Unterstützt Multicast, arbeitet in WLANs und LFNs Excellent kombinierbar mit z. B. linearem TFRC

13 Oktober Anwendungsfall WLAN Multicast HD-Strom (12 Mbps) 2 Empfänger, D target 200 ms Paketverlust im % -Bereich Transport behandelt Schwankendes SNR Schwankende PLR DFS macht noch Probleme Erzeugt Bündelfehler Benötigt spezielle Steuerung am Sender

14 Oktober Anwendungsfall Long Fat Networks (LFNs) Hohe Korrelation der Fehlerereignisse Angepasstes Scheduling Nahezu optimal im Shannon schen Sinne

15 Zusammenfassung Das Internet heute ist datengetrieben Fairnis (TCP-friendliness) ist definiert über Datenrate Aufteilung der Ressourcen via Ratenadaption Over-The-Top Web-TV Muss nicht immer fair sein (Minimalanforderungen) Kann hohen Grund-Ressourcenverbrauch haben Dienstequalität Technisch: Latenz und Fehlerrate lösbar Ratenadaption = Fairnis noch nicht gelöst Innovative Zulassungs- oder Ratenkontrolle notwendig Verschiedenste Architekturen heute im Einsatz Unicast-DASH, Multicast, P2P / P4P Jede Lösung hat Vor- und Nachteile Oktober

16 Oktober Fazit

17 Backup P4P: Verizon & Pando P2P: Zattoo, Joost, PPLive Linear TFRC: Oktober