Architetture per la Distribuzione di Video su Internet

Università degli Studi di Modena e Reggio Emilia
Dipartimento di Ingegneria dell’Informazione
Architetture per la
Distribuzione
di Video su Internet
Maria Luisa Merani
1
INDICE
Le soluzioni perseguibili
Per ciascuna, vantaggi e punti deboli
Architettura Client-Server tradizionale
Content Delivery Networks
IP Multicast
Peer-to-Peer (P2P)
Soluzioni maggiormente
gg
p
popolari
p
Caratteristiche salienti
Valutazioni sperimentali su diversi prototipi
– StreamerOne
– iGridMedia
Problemi aperti
2
A hit tt
Architettura
Client-Server
Cli t S
Vantaggi
Soluzione
S
l i
centralizzata,
t li
t ffacilmente
il
t
controllabile
Svantaggi
Le risorse
L
i
d
dell server rappresentano
t
il collo
ll di
bottiglia
– in termini di banda
R = streaming rate
Bserver = R X N
– … ma anche di
» risorse computazionali
» numero di connessioni
simultaneamente attive che è
possibile supportare
Se poi è la medesima informazione ad essere
distribuita simultaneamente a ciascun utente,
ulteriore inefficienza
3
Quali le p
possibili soluzioni?
4
C t t Di
Content
Distribution
t ib ti Network
N t
k
Fenomeno relativamente recente
Akamai fondata nel 1998
Server del
content
t t provider
id
Rete di server distribuiti a livello mondiale
sull’intera Internet
Piattaforma preposta alla distribuzione di contenuti
con ritardi minimi
Nodo di distribuzione
CDN
Alloggiati negli hosting center
La CDN replica il contenuto fornitole dai
clienti (i content provider) nei CDN server
Aggiornamento del contenuto da parte del content
provider immediatamente riflessi nei server della
p
CDN
La CDN fornisce all’utente un meccanismo per
CDN server …
recuperare il contenuto dal server che può fornirlo
il
più rapidamente possibile
CDN server Asia
CDN server Europa
Il server CDN più vicino
– spesso
Il server collegato all’utente via un percorso
congestion free
congestion-free
5
Q l è il CDN server più
Qual
iù adeguato?
d
t ?
La CDN company ridireziona la richiesta verso uno dei possibili
server basandosi sulla conoscenza
delle Internet routing table
dell’ISP dell’utente richiedente il contenuto (la destinazione)
dell’RTT tra q
quell’ISP e i diversi CDN server
Periodicamente attua e memorizza stime di RTT per un numero elevato di ISP
Obiettivo: individuazione – attraverso una stima - di quale CDN server
garantisce il tempo di risposta più basso
6
E l’utente
l’ t t finale?
fi l ?
Q. Come viene forzato a scaricare il contenuto desiderato da uno
specifico CDN server ?
R. Attraverso un meccanismo di ridirezione basato sul DNS
Vediamolo:
1. Operazione preliminare: modifica dei tag da parte del content provider
Da http://www.content.com/leisure/hawaii.gif a
http://www.cdn_company.com/www.content.com/leisure/hawaii.gif
2. Richiesta dell’oggetto base HTML da parte dell’utente al content provider
3. Replica dell’origin server/content provider con indicazione sul nuovo riferimento
4. Interrogazione da parte dell’utente al DNS per risolvere l’indirizzo simbolico e
5. Replica da parte di un authoritative server
1. fornisce l’IP del CDN server opportuno
(es. il più vicino all’IP address dell’utente che ha inviato la DNS query)
7
G fi
Graficamente
t
HTTP request
per il base object
Server del
content provider
d
1
DNS query per
www.cdn_company.com
2
DNS authoritative
server della CDN
company
HTTP request
per l’oggetto distribuito via CDN
3
CDN server
(più vicino all’utente)
8
IP Multicast
M lti
t
Inviare il medesimo p
pacchetto contemporaneamente
p
ap
più destinazioni
con un multicast a livello 3, anziché aprire tante connessioni unicast
quanti sono i client che richiedono il flusso video rappresenterebbe la
soluzione più naturale
9
IP Multicast
M lti
t
Efficiente
10
S
Svantaggi
t
i
IP Multicast non ha trovato ampia diffusione
Impiegato in alcune reti private, ma non sulla Public Internet
Complessità
Richiede una per
per-flow
flow information nei router attraversati dai flussi
multicast
Viola il principio stateless dei router attuali!
Assenza di scalabilità
A
l bili à
Controllo di flusso e di congestione – a livello trasporto - su flussi
multicast sono problematici
p
11
P2P
Ratio:
1. Perchè non spostare il multicast a livello applicazione? Inoltre …
2. ci sono tante risorse inutilizzate in rete e potenzialmente utili
Banda
B
d
Capacità di processing
Memoria
Perché non impiegarle per contribuire alla distribuzione di uno o più
contenuti di interesse per una certa community di utenti?
Collaborazione fattiva degli utenti nella distribuzione video
P2P overlay
Bvideo _ server + ∑ bupload = N × R
12
P2P
Nelle soluzioni P2P per il video streaming il flusso viene suddiviso in chunk
Tipicamente un chunk contiene alcuni secondi di video
I peer della overlay mettono a disposizione la propria banda di upload per passare ad
peer i video chunk che g
già p
possiedono
altri p
Sollecitazione sul video server fortemente ridotta ☺
Richieste infrastrutturali minimali ☺
P2P è già ampiamente diffuso nelle applicazioni di file sharing
Specificità rispetto a queste ultime
Vincolo del real-time (near real-time)
Es. IP-TV ed evento sportivo
Richiesta in banda può essere significativa
Ergo, la QoE garantita deve prevedere
Ritardi ((nel p
play-out,
y
, dopo
p lo “zapping”)
pp g ) modesti
Visione soddisfacente
13
Cl
Classificazione
ifi
i
Possibile distinzione dei sistemi P2P per lo streaming
Tree-based
Mesh-based
Tree-based
Albero a livello applicazione, ma connessioni unicast a livello IP!
Criteri per la formazione dell’albero
14
Quali gli svantaggi?
15
T
Tree-based:
b
d svantaggi
t
i
Approccio concettualmente semplice
semplice, ma
Prono a malfunzionamenti
1. Partenza di un peer che non occupa la posizione di foglia nell’albero
Inefficiente nell’impiego delle risorse (banda) condivise
1. La banda in upload dei peer foglia è completamente inutilizzata
Soluzione: overlay multi-tree
Vincolo: peer foglia in un albero NON sono tali negli altri alberi
Esempio con due sottoflussi
16
S l i
Soluzione
Multi
M lti Albero
Alb
Su ogni albero il video server provvede a diffondere un sottoflusso
Un peer esegue il “join” su più alberi
Lettura semplice: ogni peer deve recuperare tutti i sottoflussi originari
Alternative più sofisticate
– MDC Multiple Description Coding
– FGS Codifica video scalabile
Es. (un albero sufficientemente ridondato) convoglia il base layer, gli altri
distribuiscono gli enhancement layer
17
S l i
Soluzione
mesh-based
hb
d
Denominata anche pull
pull-based
based
È il peer interessato al contenuto che ne esegue il “PULL” dal parent
Nessuna topologia predefinita
Ciascun peer mantiene una lista di partners con cui periodicamente
scambia informazioni sui chunk video disponibili
I chunk desiderati (mancanti) vengono richiesti al peer che li ha in
precedenza pubblicizzati
Partnership
p aggiornate
gg
dinamicamente a frequenza
q
adeguata
g
così da g
garantire
– Robustezza (i peer nascono e muoiono nella overlay, dinamicamente)
– Efficienza nel processo di diffusione
» Es. sostituzione dei peer meno performanti
18
S l i
Soluzione
mesh-based
hb
d
Analogia con P2P per il file sharing (BitTorrent)
MA differenza significativa
I chunk video devono essere consegnati rispettando una deadline temporale
ERGO
scheduling significativamente diverso rispetto al P2P per il file sharing
Q. Quale soluzione è la migliore?
Push-based: confina i ritardi, ma il costo per mantenere alberi stabili e robusti è
elevato
l
t
complessità nella fase di design e di management (segnalazione)
Pull-based: semplice da implementare e mantenere, efficiente, poiché il processo di
diffusione dei dati non è vincolato a seguire specifiche direzioni
direzioni, robusto a
dinamiche veloci nell’ingresso/uscita dei peer dal sistema
Impiegato nella maggior parte dei prototipi e dei sistemi commerciali
Può esibire ritardi considerevoli in fase di start
start-up
up e nel cambio di canale
19
Ult i
Ulteriore
soluzione
l i
Albero e mesh presuppongono una topologia non gerarchica
Alternativa: peer organizzati in “tier”, o livelli
Tier di primo livello o backbone: peer più stabili, con sufficiente banda in
upload organizzati ad albero
Tier di secondo livello: raccoglie
g ip
peer maggiormente
gg
fluttuanti,,
organizzati su mesh (o alberi addizionali)
Dunque è possibile distinguere tra architetture
TIERED
P2P puro, ma anche
Soluzioni ibride: replication server sul tier di primo livello, P2P nel secondo tier
– Adeguate
Ad
t per TV b
broadcasters,
d
t
provider
id di contenuti
t
ti
FLAT
Architetture P2P pure
– Tipiche di small overlays di prosumers
20
Al
Alcuni
i prototipi/sistemi
t ti i/ i t i commerciali
i li
PPLive
Mesh-based
Principalmente TCP-based
M di giornaliera
Media
i
li
di 400K utentii per 200 canalili
Rate dei programmi televisivi distribuiti
Da 250 a 400 Kbit/s
Alcuni canali a 800 Kbit/s
Numero di partner nodes dipendente dalla popolarità del canale
Campus
p p
peer hanno 40 p
partners
Peer con accesso residenziale da 10 a 30
21
C ti
Continua
SopCast
Fornisce servizi
Live streaming ed anche
VoD
Architettura mesh-based
Principalmente UDP a livello trasporto
Tipicamente un peer SopCast esegue il dowload da 2-5 altri peer
UUSee
Ulteriore esempio di sistema P2P per lo streaming su larga scala
Architettura ibrida
Diversi streaming servers dislocati in tutto il mondo
Mesh-based,
M
hb
d iimpiega
i
TCP
Numero di partner per ciascun peer: circa 50
Offre circa 800 diversi canali con una media di 100K utenti simultanei
Streaming rate: 400 Kbit/s
22
C ti
Continua
GridMedia
Ulteriore esempio di sistema P2P su
larga scala cinese
Protocollo ibrido push-pull
Interessante …
Soluzioni europee P2P per il VoD
Joost
Mesh bashed, 95% dei peer riceve il
contenuto da circa altri 25 peer
UDP p
per i dati, TCP p
per il controllo
Babelgum
TCP
95% dei peer riceve il contenuto da una
media altri 8 peer
Entrambi esibiscono un’architettura
un architettura
ibrida, con streaming server dislocati in
tutto il mondo
23
P
Processo
di diffusione
diff i
neii sistemi
i t i a MESH
All’atto del join, un nuovo peer contatta l’origin server
Caso semplice:
l’origin server lo ridirige verso un tracker, che mantiene la membership list
Il tracker fornisce a peer una lista, sottoinsieme della precedente, di partner
potenziali che il peer contatta per ricevere le loro buffer map
– BUFFER MAP?
– Dimensione indicativa: stringhe di 120 bit => nel buffer il peer ha circa un
paio di minuti del video
Dalle buffer map ricevute, il peer identifica i suoi potenziali parent
24
C ti
Continua
Ricevute le buffer map, il peer richiede i chunk mancanti
Tutti, non appena è entrato nel sistema ☺
Esempio di scheduling nelle richieste:
Per ogni chunk si determinano tutti i potenziali fornitori
Quello con più banda è individuato come il migliore
Si comunica a ciascun fornitore selezionato quali chunk il fornitore deve
trasmettere al peer (PULL)
25
A t i d
Anatomia
dell’architettura
ll’ hit tt
SW di un peer
Presenza di
Streaming engine
Media player
Streaming engine
Si occupa
del recupero dei video chunk
della loro memorizzazione
temporanea
del loro trasferimento al media
player
Gestisce le buffer map
Richiede i chunk mancanti e
fornisce quelli desiderati dagli altri
peer
Esegue ll’update
update delle liste dei
partner
26
G ti
Gestione
dell’appartenenza
d ll’
t
alla
ll overlay
l
Overlay membership
Sistemi di dimensioni medio/piccole SOLUZIONE CENTRALIZZATA
un nuovo peer recupera la lista dei peer da contattare dal tracker server, che
conosce tutti i peer della overlay
– Come? …
Sistemi di grandi dimensioni SOLUZIONE DISTRIBUITA
Possibile alternativa alla precedente: il nuovo peer viene reindirizzato verso un
deputy peer, selezionato (ad es. in modo random) dalla lista presente nella
cache del video server – non esaustiva –
1 Il deputy fornisce al nuovo peer una lista di possibili contatti
1.
2. Il deputy aggiorna la membership list nella sua cache, inserendo una
entry per il nuovo peer
– Vantaggi:
a agg
» diminuzione dello stress sul tracker server
» scomparsa di un punto di vulnerabilità del sistema, repository di dati
che riguardano
g
la totalità dei p
peer nel sistema
27
Possibile mantenimento membership list
Perché una cache in ogni peer con una vista – parziale – della
membership list nell’ultima soluzione citata?
Necessaria per disseminare, quando il peer assume il ruolo di deputy, ad
altri peer tale vista
Inoltre
Ogni peer periodicamente consulta la sua membership cache per
sostituire
tit i partners
t
che
h llasciano
i
il sistema
i t
o che
h non sono sufficientemente
ffi i t
t
performanti
E come viene aggiornata?
Una possibilità è attraverso algoritmi di gossiping, o epidemici
Il peer invia un messaggio (gossip) ad un subset, tipicamente random, di altri
peer di cui conosce l’esistena
Al round successivo sono questi peer a farsi carico di rilanciare il messaggio
– Un messaggio viene ritrasmesso da un peer solo quando lo riceve per la
prima volta
28
C
Caratteristiche
tt i ti h dei
d i sistemi
i t i più
iù recenti
ti
Impiego di substream multipli
Soluzione ibrida push-pull
Adozione di server multipli
Collocazione g
geografica
g
strategica
g
No architettura P2P pura
29
S b t
Substream
multipli
lti li
Il video viene come in precedenza suddiviso in chunk
I chunk sono tuttavia ripartiti in substream distinti
Se K substream, il j-simo è costituito dai chunk j+i*K, i=0,1,2, … del
video originario
30
C ti
Continua
Il punto critico risiede nel mantenere la sincronizzazione tra i diversi
substream
Nel peer la struttura della cache per i chunk viene modificata
Un buffer di sincronizzazione precede il cache buffer
Struttura logica del buffer per K=4
Substream distinti
31
Ib id push-pull
Ibrido
h
ll
In una architettura a mesh
mesh, i peer eseguono il PULL dei chunk dagli
altri peer
Nella soluzione ibrida, il meccanismo di PULL è impiegato solo per il
primo chunk del generico substream
Una volta che si è identificato il peer fornitore per tale chunk, tale peer
automaticamente provvederà a fornire – in PUSH – anche i chunk
successivi al primo
Periodicamente si provvede ad aggiornare i peer fornitori, i parent
p
peer
Sostituzione dei peer
1. che hanno abbandonato la overlay
2. Che forniscono insufficiente contenuto video
32
M t i h di qualità
Metriche
lità
Start-up
Start
up delay
intervallo che intercorre dall’istante di selezione del canale video
(programma televisivo) desiderato e l’istante in cui inizia il playout sullo
schermo
Ritardo critico, influenza fortemente la soddisfazione dell’utente
Video playback continuity
Ciascun chunk video ha una propria deadline temporale di playback
Se il chunk non raggiunge il buffer del peer entro tale deadline e
1. non ci sono video chunk nel buffer del p
player
y => video FREEZING,, se si
esegue il payback dell’ultimo frame video
2. Sono presenti alcuni chunk video nel buffer, ma non contigui => video
SKIPPING
Operativamente, si misura in modo indiretto misurando la chunk miss
ratio
Ulteriore metrica importante nel caso di IP
IP-TV
TV su architettura P2P,
Video switching delay
33
Mi
Misure
sperimentali
i
t li
Possono essere realizzate
Network-edge, o client-side
Il singolo peer cattura il traffico di upload e di download
E/O
Server-side
Un log-server centralizzato ha una visione completa del sistema, e può
rilevare,, ad esempio
p
– Evoluzione del numero dei peer connessi
– Durata delle sessioni
– Contributo in upload fornito dai peer
» Peer “robusti” e peer “deboli”
– Indirizzo IP dei peer
» Utile per geolocalizzazione
Motivazione:
Monitoraggio delle prestazioni che il sistema P2P garantisce agli
utilizzatori
tili
t i
QoE alta, l’utente NON abbandonerà il sistema
34
E
Esempi
i di misure
i
network-edge
t
k d
Numero di pacchetti UDP e TCP scambiati tra il local peer ed i suoi
partner
SOPCAST
35
C ti
Continua
PPLIVE
CONCLUSIONI: …
36
Mi
Misure
network-edge
t
k d
Throughput in upload ed in download
Peer residenziale, connessione via ADSL
PPLIVE
37
C ti
Continua
Scorporo dei contributi
PPLIVE
38
U piattaforma
Una
i tt f
it
italiana
li
StreamerOne
Esempio di small overlay
Struttura a mesh
Un control
U
t l server e ttantiti streaming
t
i server quantiti sono i canalili
– Peer contatta control server e riceve le “reference” di tutti gli streaming
server
– individuato il canale,
canale peer riceve dallo streaming server lista di 50 peer
peer,
selezionati casualmente tra quelli che attualmente guardano il canale
– Periodicamente il peggior fornitore viene eliminato dalla lista e sostituito
da un altro peer
Diffusione di canali televisivi nazionali
Trasmissione video H.264 a 224 kbit/s
39
Mi
Misure
network-edge
t
k d
Evoluzione del numero di peer fornitori in StreamerOne
40
Mi
Misure
network-edge
t
k d
Distribuzione di probabilità cumulativa (CDF) per la dimensione dei
pacchetti
Bimodale
300 e 1500 b
byte
te
41
Mi
Misure
server-side
id
StreamerOne small overlay
StreamerOne,
Evoluzione numero di peer interessati ad un evento televisivo
– Europei di calcio
42
Mi
Misure
server-side
id
StreamerOne small overlay
StreamerOne,
Geolocalizzazione e free-rider
– Free-rider?
43
Mi
Misure
server-side
id
Start-up
p delay
y in una LARGE overlay
y
COOLSTREAMING
44
S l i
Selezione
del
d l protocollo
t
ll a livello
li ll trasporto
t
t
UDP rappresenta indubbiamente la scelta più adatta alle specificità
dei flussi multimediali
Tuttavia …
Oggi i servizi client-server più popolari per lo streaming video su Internet
impiegano TCP
???
Inefficienza che trova diverse giustificazioni – correlate – :
fruitori del servizio
inesperti,
p , poco
p
p
propensi
p
a scaricare applicativi
pp
non conosciuti
– SOLUZIONE
» streaming effettuato attraverso applicazioni (in Adobe FLASH©)
incorporate all’interno del sito del fornitore di contenuti, ergo
g fruibili
via web browser
risiedono su una rete protetta da firewall
45
P bl i con i firewall
Problemi
fi
ll
Sempre più diffusi
Presentano impostazioni di default piuttosto stringenti
Tecnica più semplice: “Ispeziona
Ispeziona per ogni singolo pacchetto IP: indirizzo
IP sorgente e destinazione, porta sorgente e porta destinazione,
protocollo di livello trasporto impiegato”
Classificazione in macrocategorie, ottenuta incrociando le convenzioni sulle
well-known ports con le precedenti informazioni
– Esempi: traffico su porta 80 + utilizzo TCP marcato come traffico HTTP
traffico su p
porta 21 + utilizzo TCP
traffico FTP
46
C ti
Continua
Il traffico di video streaming non impiega porte riconosciute per
convenzione!
Traffico di video streaming marcato come sconosciuto o generico e …
l regola
la
l di d
default
f lt è bloccare
bl
il ttraffico
ffi NON riconosciuto
i
i t
Tuttavia … un utente p
potrebbe mandare tale tipo
p di traffico sulla p
porta
21
SOLUZIONE
i firewall - più sofisticati - ispezionano ulteriormente il pacchetto
pacchetto,
spingendosi sino all’identificazione del protocollo di livello applicazione
Meglio: far interpretare il flusso multimediale come traffico web
Obbligo di impiego del TCP per la sessione Web
Impiego dell’HTTP a livello applicazione per operare con il flusso
multimediale erogato in streaming
47
Rif i
Riferimenti
ti bibli
bibliografici
fi i
J.K. Kurose, Keith W. Ross “Computer Networking - A Top-Down
Approach Featuring the Internet”, ed. Addison Wesley
M.L. Merani, D. Saladino “Live Video and IP-TV” Book Chapter in
Handbook of Peer
Peer-to-Peer
to Peer Networking, ed. Springer, 2010
48