Over-The-Top TV Sind Fernsehen und Internet inkompatibel? · Gibt es gut und schlecht? Nein! SopCast, Zattoo, Joost –Peer-2-Peer, einfach verfügbar –Geringe Qualität, hohe Latenz

Lehrstuhl Nachrichtentechnik

Universität des Saarlandes

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

Thorsten Herfet Lehrstuhl Nachrichtentechnik

Universität des Saarlandes [email protected]

mailto:[email protected]



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

2 Oktober 2011 Deutsche TV-Plattform

Media

Server Media

Server

Das „Internet“ als Übertragungskanal

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


Media

Server

Router/

Cache

Router/

Cache

Client Client Client Client Client

…

Streaming von:

Video on Demand

Near Video on Demand

Live-TV

Geeignete(s) Verfahren:


Ende-zu-Ende Unicast

P2P, P4P


Multicast

P2P, P4P

Multicast


P4P

P2P (low quality)


Streaming

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


DVB und die Kanalkapazität


Nick Wells, BBC

Internet = Auslöschungskanal

Paket-orientiert, daher Auslöschungskanal

– Gestörte Pakete werden von „unteren“ Ebenen verworfen

– Kanalkapazität des Auslöschungskanals:

• Fehlerwahrscheinlichkeit:

• Kanalkapazität:

• Minimale Redundanz:

Oktober 2011 Deutsche TV-Plattform 7

eP

eP1

e

e

P

P

1

Slow-Start

Threshold

Additive

Increase

Multiplicative

Decrease

Threshold

Timeout

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“

Oktober 2011 8 Deutsche TV-Plattform

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


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!

• Modifikationen vorgeschlagen (lineare TFRC-Gleichung)


23218

33,1min

3

2ppT

ppRTT

MSSB

RTO

TCP

Pro

Standardisiert

– ISO/IEC 23001-6 (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


DASH:

Dynamic Adaptive Streaming over HTTP

Ein Vorschlag: PRRT

Predictably reliable real-time transport (PRRT)

– Unterstützt Multicast, arbeitet in WLANs und LFNs

– Excellent kombinierbar mit z. B. linearem TFRC


Anwendungsfall WLAN Multicast

HD-Strom (12 Mbps)

– 2 Empfänger, Dtarget 200 ms

– Paketverlust im „%“-Bereich

Transport behandelt

– Schwankendes SNR

– Schwankende PLR

DFS macht noch Probleme

– Erzeugt Bündelfehler

– Benötigt spezielle Steuerung

am Sender


Anwendungsfall Long Fat Networks (LFNs)

Hohe Korrelation der

Fehlerereignisse

– Angepasstes Scheduling

– Nahezu optimal im

Shannon„schen Sinne


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


Fazit


Backup

P4P: Verizon & Pando – http://www.readwriteweb.com/archives/goodbye_p2p_p4p_is_coming.php

P2P: Zattoo, Joost, PPLive

Linear TFRC: – http://www.advances.et.put.poznan.pl/issues/2/ATE_issue2_p0047.pdf


http://www.readwriteweb.com/archives/goodbye_p2p_p4p_is_coming.php

http://www.advances.et.put.poznan.pl/issues/2/ATE_issue2_p0047.pdf

Documents

Over-The-Top TV Sind Fernsehen und Internet inkompatibel? · Gibt es gut und schlecht? Nein! SopCast, Zattoo, Joost –Peer-2-Peer, einfach verfügbar –Geringe Qualität, hohe Latenz