Distribuzione di Video su Internet

Transcript

1 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

2 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 popolarip Caratteristiche salienti Valutazioni sperimentali su diversi prototipi StreamerOne igridmedia Problemi aperti 2

3 Architettura tt Client-Server Vantaggi Soluzione centralizzata, t facilmente controllabile Svantaggi Le risorse del server rappresentano il collo di bottiglia in termini di banda R = streaming rate B server = 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

4 Quali le possibili soluzioni? 4

5 Content t Distribution ib ti Network Fenomeno relativamente recente Akamai fondata nel 1998 Rete di server distribuiti a livello mondiale sull intera Internet Piattaforma preposta alla distribuzione di contenuti con ritardi minimi 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 CDN La CDN fornisce all utente un meccanismo per recuperare il contenuto dal server che può fornirlo il più rapidamente possibile Il server CDN più vicino spesso Il server collegato all utente via un percorso congestion-free Server del content t provider CDN server Nodo di distribuzione CDN CDN server Asia CDN server Europa 5

6 Qual è il CDN server più adeguato? 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 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

7 El l utente t finale? 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 a 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

8 Graficamente HTTP request per il base object Server del content provider 1 DNS query per 2 DNS authoritative server della CDN company 3 HTTP request per l oggetto distribuito via CDN CDN server (più vicino all utente) 8

9 IP Multicast t Inviare il medesimo pacchetto contemporaneamente a 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

10 IP Multicast t Efficiente 10

11 Svantaggi IP Multicast non ha trovato ampia diffusione Impiegato in alcune reti private, ma non sulla Public Internet Complessità Richiede una per-flow information nei router attraversati dai flussi multicast Viola il principio stateless dei router attuali! Assenza di scalabilità Controllo di flusso e di congestione a livello trasporto - su flussi multicast sono problematici 11

12 P2P Ratio: P2P overlay 1. Perchè non spostare il multicast a livello applicazione? Inoltre 2. ci sono tante risorse inutilizzate in rete e potenzialmente utili Banda 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 + Bvideo _ server bb upload = N R 12

13 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 altri peer i video chunk che già possiedono 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 play-out, dopo lo zapping ) modesti Visione soddisfacente 13

14 Classificazione 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

15 Quali gli svantaggi? 15

16 Tree-based: svantaggi Approccio concettualmente 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

17 Soluzione Multi Albero 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

18 Soluzione mesh-based Denominata anche pull-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 aggiornate dinamicamente a frequenza adeguata così da garantire Robustezza (i peer nascono e muoiono nella overlay, dinamicamente) Efficienza nel processo di diffusione» Es. sostituzione dei peer meno performanti 18

19 Soluzione mesh-based 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 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, 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-up e nel cambio di canale 19

20 Ulteriore soluzione 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 i peer maggiormente fluttuanti, organizzati su mesh (o alberi addizionali) Dunque è possibile distinguere tra architetture TIERED FLAT P2P puro, ma anche Soluzioni ibride: replication server sul tier di primo livello, P2P nel secondo tier Adeguate per TV broadcasters, provider di contenuti ti Architetture P2P pure Tipiche di small overlays di prosumers 20

21 Alcuni prototipi/sistemi ti i/ i t i commerciali PPLive Mesh-based Principalmente TCP-based Media giornaliera di 400K utenti per 200 canali 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 peer hanno 40 partners Peer con accesso residenziale da 10 a 30 21

22 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, impiega 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

23 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 per i dati, TCP per il controllo Babelgum TCP 95% dei peer riceve il contenuto da una media altri 8 peer Entrambi esibiscono un architettura ibrida, con streaming server dislocati in tutto il mondo 23

24 Processo di diffusione i nei sistemi 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

25 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

26 Anatomia dell architettura 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 l update delle liste dei partner 26

27 Gestione dell appartenenza alla overlay 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 2. Il deputy aggiorna la membership list nella sua cache, inserendo una entry per il nuovo peer Vantaggi: agg» diminuzione dello stress sul tracker server» scomparsa di un punto di vulnerabilità del sistema, repository di dati che riguardano la totalità dei peer nel sistema 27

28 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 i partners che lasciano il sistema o che non sono sufficientemente i 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

29 Caratteristiche ti dei sistemi i più recenti Impiego di substream multipli Soluzione ibrida push-pull Adozione di server multipli Collocazione geografica g strategica No architettura P2P pura 29

30 Substream multipli 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

31 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

32 Ibrido push-pull In una architettura a 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 peer Sostituzione dei peer 1. che hanno abbandonato la overlay 2. Che forniscono insufficiente contenuto video 32

33 Metriche di qualità 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 player => 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-TV su architettura P2P, Video switching delay 33

34 Misure sperimentali Possono essere realizzate Network-edge, o client-side Il singolo peer cattura il traffico di upload e di download E/O Server-side Motivazione: Un log-server centralizzato ha una visione completa del sistema, e può rilevare, ad esempio 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 Monitoraggio delle prestazioni che il sistema P2P garantisce agli utilizzatori t i QoE alta, l utente NON abbandonerà il sistema 34

35 Esempi di misure network-edge Numero di pacchetti UDP e TCP scambiati tra il local peer ed i suoi partner SOPCAST 35

36 Continua PPLIVE CONCLUSIONI: 36

37 Misure network-edge Throughput in upload ed in download Peer residenziale, connessione via ADSL PPLIVE 37

38 Continua Scorporo dei contributi PPLIVE 38

39 Una piattaforma italiana StreamerOne Esempio di small overlay Struttura a mesh Un control server e tanti ti streaming server quanti sono i canali Peer contatta control server e riceve le reference di tutti gli streaming server individuato il canale, peer riceve dallo streaming server lista di 50 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

40 Misure network-edge Evoluzione del numero di peer fornitori in StreamerOne 40

41 Misure network-edge Distribuzione di probabilità cumulativa (CDF) per la dimensione dei pacchetti Bimodale 300 e 1500 byte 41

42 Misure server-side StreamerOne, small overlay Evoluzione numero di peer interessati ad un evento televisivo Europei di calcio 42

43 Misure server-side StreamerOne, small overlay Geolocalizzazione e free-rider Free-rider? 43

44 Misure server-side Start-up delay in una LARGE overlay COOLSTREAMING 44

45 Selezione del protocollo a livello ll trasporto 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, poco propensi p a scaricare applicativi non conosciuti SOLUZIONE» streaming effettuato attraverso applicazioni (in Adobe FLASH ) incorporate all interno del sito del fornitore di contenuti, ergo fruibili via web browser risiedono su una rete protetta da firewall 45

46 Problemi con i firewall Sempre più diffusi Presentano impostazioni di default piuttosto stringenti Tecnica più semplice: 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 porta 21 + utilizzo TCP traffico FTP 46

47 Continua Il traffico di video streaming non impiega porte riconosciute per convenzione! Traffico di video streaming marcato come sconosciuto o generico e la regola di default è bloccare il traffico NON riconosciuto i Tuttavia un utente potrebbe mandare tale tipo di traffico sulla porta 21 SOLUZIONE i firewall - più sofisticati - ispezionano ulteriormente il 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

48 Riferimenti i bibliografici 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-to-Peer Networking, ed. Springer,