Streaming:
framework di riferimento
Con il termine Streaming si fa riferimento ad una particolare classe di ap-plicazioni di multimedia networking che consente la gestione del trasferimento di informazioni audio-video attraverso Internet e la loro contemporanea riproduzione con il medesimo controllo che si opera su di uno stereo od un videoregistratore. Ad una applicazione di Streaming partecipano un Client che fa richiesta di un file di contenuto multimediale ed un Server che è il destinatario della richiesta. I dati audio-video possono essere memorizzati nel file system del Server (Stored Audio
and Video Streaming), oppure possono provenire da trasmissioni live nel qual
ca-so il Server non ha a disposizione tutto il file sin dall’inizio (Streaming of Live
Audio and Video). Il Server invia il file al Client e questi, dopo un po’ dalla
rice-zione dei primi pacchetti, avvia la riprodurice-zione del loro contenuto mentre i pac-chetti con la parte finale del file continuano ad arrivare: c’è vantaggio evidente per il Client nel non dover aspettare di aver scaricato l’intero file prima di poterne av-viare la riproduzione.
L’utente presso il Client ha la possibilità, durante la riproduzione, di im-partire i comandi di Pausa, Avanzamento Veloce, Riavvolgimento etc., ovvia-mente nel caso di trasmissioni live il set di comandi è limitato (banalovvia-mente: non è
possibile l’Avanzamento Veloce). I comandi impartiti dal Client vengono eseguiti in remoto dal Server ed il Client ne avverte l’esecuzione con un leggero ritardo causato proprio dall’esecuzione remota.
Lo Streaming di contenuto live multimediale prevede normalmente l’utilizzo di canali di comunicazione multicast mentre lo Streaming di contenuto
Stored prevede solitamente canali unicast.
Le problematiche nella realizzazione di un sistema che operi lo Streaming audio/video sono legate soprattutto alla necessità di adeguare le modalità di trasfe-rimento in Internet alla particolare natura del traffico audio/video. Le applicazioni di networking classiche trattano dati in formato testo, HTML o simile e conside-rano l’integrità dei dati di importanza preminente rispetto al ritardo nel loro trasfe-rimento che può essere invece tollerato anche se fastidioso. Le applicazioni che operano lo Streaming invece, al pari di tutte le altre applicazioni di multimedia networking, sono altamente sensibili ai tempi di trasferimento (end-to-end delay) al punto che un ritardo eccessivo può far scartare il dato pervenuto in quanto inuti-lizzabile; sono altresì critiche le differenze sperimentate nei tempi di trasferimento dei pacchetti appartenenti al medesimo flusso (jitter), mentre possono essere tolle-rate delle perdite occasionali di dati (packet loss). Quanto detto in breve riesce a dare un’idea dell’inadeguatezza di Internet a supportare il traffico oggetto dello Streaming e della necessità di sperimentare delle soluzioni di compromesso.
Nella trattazione seguente vengono illustrate con maggiore dettaglio le problematiche generali legate alla trasmissione di traffico audio-video in Internet e quelle specifiche dello Streaming. Si comincia con l’illustrare i vincoli Real-Time che caratterizzano la riproduzione di una sequenza audio-video (vincoli dell’applicazione) e quindi, di riflesso, anche la sua trasmissione: si evidenziano le carenze delle infrastrutture attualmente utilizzate a supporto delle applicazioni multimediali e si pone l’attenzione sulle tecniche in uso in questo momento per ovviare a tali mancanze. Successivamente si restringe il campo sullo Streaming descrivendo, dapprima, lo scenario tipico in cui si esegue ed introducendo poi le
problematiche relative all’allocazione delle risorse di rete e delle entità Server e Client durante il trasferimento di un file audio/video in Streaming.
2.1 Servizio Best Effort e traffico audio-video
2.1.1 Vincoli Real-Time e garanzie di Quality of Service
Le informazioni audio-video che viaggiano in Internet sono una successio-ne di campioni che consistono successio-nella rappresentaziosuccessio-ne binaria di informazioni au-dio e video emesse da sorgenti sonore e luminose e prelevate ad intervalli di tem-po regolari. I campioni vengono optem-portunamente organizzati in blocchi (chunks), incapsulati in pacchetti e spediti attraverso un qualche canale UDP o TCP. Presso lo host di destinazione il contenuto dei pacchetti deve essere riprodotto e la ripro-duzione, una volta avviata, deve avanzare nel rispetto dei rigidi vincoli temporali posti in essere in fase di campionamento della sorgente emissiva. Per ascoltare un file audio ad esempio, che sia stato campionato alla sorgente a 44,1kHz, è neces-sario che vengano riprodotti 44.100 campioni al secondo ossia un campione ogni 22.7msec (1/44.100). A ciascun pacchetto, in fase di riproduzione, è attribuibile una “autonomia temporale” determinata dal numero di campioni che contiene, e-saurita questa autonomia è necessario che sia pronto un nuovo pacchetto con i campioni successivi: il pacchetto successivo non può arrivare né prima né dopo il termine dell’esecuzione del pacchetto corrente (riproduzione on the fly). Gli istanti di riproduzione dei campioni costituiscono delle deadline nel processo di esecu-zione ed impongono conseguentemente delle deadline nel processo di arrivo dei pacchetti: il trasferimento dei dati attraverso Internet deve dunque rispettare questi tempi che costituiscono dei vincoli Real-Time molto stringenti.
Internet offre un tipo di servizio per la trasmissione dei dati che non è pro-priamente adatto alle esigenze Real-Time di un traffico audio-video. Il termine
pos-sibile per portare a termine con successo il trasferimento di un dato ma di fatto non offra garanzia alcuna né sui tempi di trasferimento, né sull’effettivo arrivo dei pacchetti spediti. I pacchetti che attraversano Internet possono arrivare in ritardo e fuori ordine, possono perdersi e dunque non arrivare affatto ed ancora è possibile che pacchetti diversi sperimentino ritardi di attraversamento differenti. E’ in atto un acceso dibattito sulle tecniche da adoperare per consentire il trasferimento di informazioni audio-video attraverso Internet nel rispetto dei loro vincoli Real-Time. Alcuni ricercatori ritengono che il servizio Best Effort di Internet sia suffi-ciente e che non si debba intervenire modificando i protocolli di livello network (IP) né sottostanti mentre ci si dovrebbe concentrare sull’aumento di banda sui link e sull’introduzione di una maggiore capacità di memorizzazione (caching) as-sieme ad un supporto multicast sui nodi intermedi. Gli oppositori di questa teoria sostengono che l’aumento di banda non riuscirà mai a seguire il passo della ri-chiesta da parte di applicazioni sempre nuove e più potenti e che sia invece neces-sario introdurre importanti modifiche a livello network, aggiungendo ad esempio la possibilità di riservare delle risorse (si legga banda) su di un cammino
end-to-end ad un particolare flusso di dati (approccio IntServ) oppure la capacità di
diver-sificare il traffico viaggiante in classi di servizi che godano di privilegi diversi in base ai quali vengano trattate lungo il cammino end-to-end (approccio DiffServ).
2.1.2 Situazione attuale
Attualmente comunque, i sistemi a garanzia di QoS (Quality of Service) in Internet sono ancora in fase di sviluppo e l’unica certezza a livello network resta solo il servizio Best Effort. Per consentire il trasferimento di traffico audio-video pertanto, è necessario adottare delle strategie a livello trasporto-applicativo. Dette strategie consistono in una serie di accorgimenti:
· usare UDP piuttosto che TCP;
· adottare delle tecniche per mascherare la perdita dei pacchetti;
· dotare lo host ricevitore, il Client, di un buffer per l’accumulo dei pac-chetti in ingresso;
· introdurre un ritardo iniziale di riproduzione.
La scelta di UDP invece che di TCP è motivata dal fatto che TCP allunga eccessivamente i tempi di trasferimento dei dati. Per offrire un servizio affidabile infatti, TCP gestisce le ritrasmissioni in caso di mancato arrivo o di corruzione dei pacchetti e riordina i pacchetti all’arrivo. TCP inoltre, implementa il controllo di congestione che provoca ulteriori rallentamenti, in fase di trasmissione, a causa dello slow start. La scelta di UDP viene solitamente affiancata dall’adozione a li-vello applicativo di tecniche semplici, talvolta rudimentali (o comunque più leg-gere di quelle usate da TCP) per la gestione degli arrivi fuori ordine, delle situa-zioni di congestione e delle perdite.
Fra le tecniche usate per risolvere i problemi di congestione stanno pren-dendo piede ultimamente quelle che prevedono l’adozione da parte dello host che trasmette in rete, il Server, di un sistema di regolamentazione della velocità di tra-smissione di tipo TCP-like: si parla di TCP-friendly rate adaptation. I protocolli che fanno TCP-friendly rate adaptation indagano lo stato della rete allo scopo di definire istante per istante la banda disponibile. Essi forniscono al Server indica-zioni utili (fondamentalmente un vincolo superiore per la velocità di trasmissione) per inviare pacchetti senza generare né perdite né congestioni. Per stimare la ban-da disponibile in rete, la tendenza è quella di utilizzare delle formule matematiche (tecniche equation-based), applicate alla probabilità di perdita di un pacchetto (packet loss), al RTT (Round Trip Time), alla MTU (Maximum Transmission
U-nit) del livello trasporto, etc. Per un protocollo non TCP, i fattori più difficili da
valutare sono certamente la packet loss ed il RTT. E’ stato recentemente ideato il protocollo TFRC (TCP-Friendly Rate Control) che stabilisce come eseguire que-ste stime lato Client per fornirle poi al Server che calcola finalmente la banda e
stabilisce gli intertempi di trasmissione dei pacchetti: il protocollo TFRC fa
con-gestion avoidance.
Le tecniche per il recupero o il mascheramento delle perdite dei pacchetti possono prevedere l’invio di informazioni ridondanti (Forward Error Correction) oppure l’interallacciamento dei dati prima del loro invio, in modo che le perdite si ripartiscano fra tanti pacchetti risultando nel complesso impercettibili o quanto-meno trascurabili (Interleaving), oppure infine, l’interpolazione dei dati pervenuti per ricostruire quelli persi. A seconda della tecnica utilizzata è possibile che un’applicazione di multimedia networking arrivi a tollerare dall’1% al 20% delle perdite in rete.
L’introduzione di memoria presso il ricevitore e di un ritardo iniziale pri-ma della riproduzione ha infine lo scopo di eliminare i problemi causati dal jitter. Il fatto che i pacchetti sperimentino in rete dei ritardi differenti causa dei problemi quando si vogliano riprodurre i pacchetti immediatamente dopo l’arrivo (on the
fly) a causa dei rigidi vincoli di riproduzione da rispettare. Con l’introduzione di
un buffer nel quale i pacchetti vengano accumulati all’arrivo e dal quale vengano prelevati poi, dopo un po’ di ritardo, con frequenza costante per essere avviati alla riproduzione, si riesce a svincolare la velocità di arrivo da quella di riproduzione (quest’ultima coincidente con la velocità di prelievo dal buffer). La probabilità che, in corrispondenza dell’istante di riproduzione di un campione, il pacchetto che lo contiene sia effettivamente presente presso il Client aumenta, mentre il
jit-ter è responsabile semplicemente di tempi di attesa differenti per i pacchetti nel
buffer: i pacchetti che arrivano in anticipo sperimentano tempi di attesa maggiori, quelli in ritardo inferiori.
Il ritardo iniziale di riproduzione serve a spostare in avanti tutte le deadline di riproduzione e ad assorbire, di fatto, il jitter. Ovviamente, ritardi iniziali ecces-sivi sono mal tollerati dall’utente che abbia richiesto la riproduzione; i limiti con-sentiti variano a seconda del tipo di applicazione. Nel caso particolare dello
Stre-aming: le applicazioni di Stored Audio and Video Streaming hanno maggiore
Real-Time e pertanto un utente che richieda la riproduzione di un file audio-video prememorizzato riesce a tollerare attese (5-10sec.) maggiori rispetto ad un utente che voglia seguire una trasmissione live.
Nel seguito si descrive lo scenario Internet tipico nel quale si sviluppano i servizi di Streaming e si evidenziano le entità coinvolte, i loro ruoli e le fasi suc-cessive in cui si articola una trasmissione.
2.2 Scenario classico per trasmissioni in Streaming
Una trasmissione in Streaming prevede, come più volte sottolineato, un Client dal quale parte la richiesta ed un Server remoto che gestisce la Base di Dati multimediale. Lato
Client eseguono un Web Browser ed una cosiddetta helper
appli-cation, nella fattispecie
un Media Player (si ve-dano Windowsâ Media Player o Realâ Player); lato Server invece ese-guono un Web Server ed uno Streaming Server (fig. 2.1).
La richiesta
del-la riproduzione parte dal Web Browser che esegue del-lato Client: è una richiesta HTTP che ha come destinatario il Web Server. Questi, ricevuta la richiesta, ge-nera una risposta HTTP nella quale include un meta file (o presentation file) con l’indirizzo completo del file oggetto della richiesta ed il nome dell’applicazione
HTTP GET Meta file SETUP PLAY Media Stream PAUSE TEARDOWN Client Server fig. 2.1: Interazione fra Client e Server utilizzando RTSP
Web Browser Web Server Media Player Streaming Server
che deve essere lanciata presso il Client per gestire la riproduzione. L’indirizzo in-serito nel meta file fa riferimento al file system dello Streaming Server. Quando il Web Browser riceve la risposta, chiude la connessione con il Web Server e lancia il Media Player passandogli il meta file. Il Media Player attiva una connessione con lo Streaming Server con il quale poi gestisce la riproduzione. Il Media Player fornisce un’interfaccia grafica all’utente per consentirgli di controllare la riprodu-zione ed impartire i comandi, si occupa inoltre di risolvere i problemi di jitter, di mascherare le perdite di pacchetti e di decomprimere infine i dati in arrivo dallo Streaming Server. Lo Streaming Server risponde alle richieste del Media Player, trasmette il file ed implementa infine le tecniche di congestion avoidance (qualora previste). La connessione fra Media Player e Streaming Server può essere UDP oppure TCP: di solito, per quanto detto sopra, UDP; a livello applicativo la comu-nicazione viene gestita da protocolli diversi da HTTP, più leggeri ed adatti al tra-sferimento delle informazioni audio-video e soprattutto dei comandi che gesti-scono la riproduzione. Questi protocolli sono:
· RTP (Real Time Protocol): definisce il formato dei pacchetti con conte-nuto audio-video ed è uno standard di dominio pubblico. E’ possibile che alcuni prodotti software in commercio utilizzino standard propri per il tra-sporto di informazioni audio-video, tuttavia l’utilizzo di RTP garantisce uniformità e portabilità all’interno di Internet, come pure intercomunica-bilità fra applicazioni multimediali differenti e sviluppate indipendente-mente. Maggiori dettagli su RTP verranno forniti nel prossimo capitolo. · RTSP (Real Time Streaming Protocol): regola l’invio dei comandi di
SE-TUP, PLAY, PAUSE, etc.; i comandi viaggiano out of band su di un ca-nale di comunicazione diverso da quello su cui viaggiano i pacchetti RTP con i dati veri e propri (si veda lo stile FTP);
· RTCP (Real Time Control Protocol): viene usato per lo scambio di infor-mazioni di controllo fra il Media Player e lo Streaming Server, per lo più nell’ambito multicast e delle trasmissioni live. I pacchetti RTCP tra-sportano delle statistiche comportamentali sul flusso dei pacchetti RTP e
possono servire allo Streaming Server ad esempio, per rallentare la velo-cità di trasmissione laddove il ricevitore denunci nei suoi report una ele-vata perdita di pacchetti. E’ da dire però che le specifiche non parlano di come il contenuto di questi pacchetti debba essere usato da Media Player e Streaming Server, lasciando piena libertà alla implementazione.
Nella fig. 2.2 è riportato l’aspetto tipico della pila protocollare nel caso di applicazioni che operano lo Streaming; resta valido anche per le altre applicazioni di multimedia networking.
Si riporta di seguito la versione esemplificata, tratta da [4], di uno scambio fra Media Player (C) e Streaming Server (S) allo scopo di gestire la riproduzione di un brano audio; lo scambio costituisce una sessione RTSP:
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode = PLAY
S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP 1.0 Session 4231 Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session 4231 S: 200 3 OK
fig. 2.2: Aspetto della pila protocollare adattata per supportare traffico Real-Time Fisico Data Link IP UDP RTP, RTSP, RTCP Applicazione
La sessione viene aperta da una richiesta lanciata dal Media Player: una RTSP
SETUP request, in cui il Media Player specifica l’indirizzo URL (metodo
rtsp://) del file che vuole riprodurre così come riportato nel meta file ricevuto dal Web Browser. Lo Streaming Server risponde con una RTSP SETUP response fornendo oltremodo un identificatore di sessione. Il Media Player trasmette allora una RTSP PLAY request ed il Server risponde dapprima con una RTSP PLAY
re-sponse, poi inizia a trasmettere il file. I pacchetti RTP viaggiano attraverso un
ca-nale differente da quello dei pacchetti RTSP: si parla di trasmissione in-banda per i pacchetti RTP e fuori-banda per i pacchetti RTSP. Successivamente il Media Player chiede l’interruzione momentanea della riproduzione spedendo una RTSP
PAUSE request: il Server risponde allora con una RTSP PAUSE response ed
inter-rompe la trasmissione del flusso di pacchetti RTP. Quando l’utente decide di in-terrompere definitivamente la riproduzione lo comunica attraverso l’interfaccia del Media Player ed il Media Player genera una RTSP TEARDOWN request per terminare la sessione; il Server risponde con una RTSP TEARDOWN response. Nell’esempio riportato sono omesse, per brevità, le risposte dello Streaming Server ad eccezione di quelle alle richieste di SETUP e di TEARDOWN.
Nell’occuparsi della trasmissione del file, lo Streaming Server deve orga-nizzare lo schedule dei pacchetti RTP verso il Media Player. La schedulazione o-perata dallo Streaming Server è una fase molto delicata delle trasmissioni in Stre-aming poiché deve tener conto di tutte le problematiche relative all’allocazione delle risorse di rete; nel seguito se ne affrontano obiettivi e vincoli.
2.3 Algoritmi di Smoothing per il traffico VBR
Il traffico audio/video è caratterizzato da una frequenza di trasmissione va-riabile nel tempo, meglio definito come traffico VBR (Variable-Bit-Rate). Si
pen-si alle trasmispen-sioni MPEG video: l’applicazione che genera la sequenza video de-ve inviare un numero costante di frame per unità di tempo; ogni frame tuttavia, può essere codificato su di un numero di bit differente. I frame che contengono cambiamenti di scena sono più pieni e codificati su di un numero di bit elevato ri-spetto ai frame che contengono particolari già introdotti in scene precedenti, dun-que la trasmissione coinvolge un numero diverso di bit per ogni unità di tempo (bit-rate). La variabilità del bit-rate è una conseguenza della compressione che rie-sce così a ridurre il numero di bit su cui codificare l’intera sequenza video ma causa problemi all’allocazione delle risorse di rete ed in particolare della banda.
Assegnare una banda fissa ad una trasmissione VBR è difficile: si può de-cidere di assegnare una banda pari al Peak Rate (bit-rate massimo che caratterizza tutta la sequenza) ma si finisce col sottrarre inutilmente banda alle altre trasmis-sioni in quei momenti in cui il fabbisogno è inferiore al Peak Rate (in caso di forte variabilità, queste situazioni sono molto frequenti). Assegnando invece, una banda inferiore al Peak Rate, ad esempio coincidente con l’Average Rate (bit-rate medio della sequenza), si rischia di non avere banda sufficiente quando il fabbisogno è prossimo al Peak Rate.
E’ possibile ancora, pensare di non assegnare affatto una banda fissa ad un sin-golo flusso VBR, ma di assegnarla invece a più flussi contemporaneamente ge-stendone il multiplexing statistico sui link e cercando di combinare i momenti di maggiore richiesta di banda di taluni flussi con quelli di minore richiesta di altri. Detta soluzione risulta tuttavia alquanto complessa.
2.3.1 Definizione di Smoothing
Quello che viene fatto tipicamente per consentire ad un traffico VBR di viaggiare attraverso Internet è uniformare il più possibile la richiesta di banda da parte di ciascun singolo flusso in maniera tale che non si commettano grossi errori allocando la banda in base al solo Peak Rate. Questa operazione è meglio
cono-sciuta con il termine Smoothing e può essere eseguita, nel caso di audio o video prememorizzati, grazie all’utilizzo combinato dei seguenti strumenti (Server e Client siano gli host presso cui eseguono rispettivamente l’applicazione che tra-smette e quella che riceve):
· adozione di una appropriata politica di scheduling lato Server; · introduzione di un buffer lato Client;
· introduzione di un ritardo iniziale di riproduzione lato Client.
Oltre ad agire per regolarizzare il traffico VBR, è necessario inoltre ridurre il più possibile il valore del Peak Rate per minimizzare la richiesta di banda.
L’idea alla base dello Smoothing è che è possibile abbassare la frequenza di trasmissione di un frame, caratterizzato da un elevato bit-rate nominale, a patto di anticiparne la trasmissione di quel tanto, almeno, che ne garantisca l’arrivo a destinazione prima dell’istante di riproduzione. Ovviamente, è necessario predi-sporre un buffer lato Client per accogliere i pacchetti spediti in anticipo e dal qua-le l’esecuzione può prequa-levare i dati con la velocità variabiqua-le imposta dalla com-pressione. Variando la dimensione del Client buffer e l’entità del ritardo iniziale di riproduzione è possibile applicare degli algoritmi di scheduling che realizzino uno Smoothing più o meno efficace; le variazioni tuttavia sono soggette a dei vin-coli legati, non da ultimo, alle esigenze di riproduzione, e non possono pertanto essere arbitrarie.
Si deve sottolineare che, in questo ambito, l’introduzione del Client buffer e del ritardo iniziale di riproduzione è svincolata dalle problematiche legate al jitter. Tutte le trattazioni sullo Smoothing ipotizzano che l’istante di invio dei pacchetti, lato Server, coincida con quello di ricezione dei medesimi lato Client e che il tempo di trasferimento dal Server al Client sia nullo o trascurabile. Il dimensio-namento del Client buffer e del ritardo iniziale di riproduzione viene così fatto e-sclusivamente in funzione delle esigenze di Smoothing. Per tener conto dei ritardi di trasferimento e del jitter è sufficiente aumentare ulteriormente la dimensione del Client buffer e la durata del ritardo iniziale di riproduzione: è importante dun-que che entrambi i dimensionamenti, dun-quello in funzione dello Smoothing e dun-quello
in funzione del jitter, tendano a minimizzare i valori ricercati per evitare di otte-nere alla fine delle somme troppo elevate. Limitare l’utilizzo del buffer è oltre-modo opportuno per permettere di condividere il buffer stesso fra più sequenze audio-video oppure fra più applicazioni ed ancora per consentire operazioni di riavvolgimento ed avanzamento veloce, qualora previste dall’applicazione, senza eccessivi sprechi nelle risorse di rete e del Server impiegate nel trasferimento in anticipo dei frame che poi vengono buttati via.
Le problematiche dello Smoothing vengono risolte, per quanto detto sopra a livello dei soli Server e Client concentrandosi su come il Server debba inviare una sequenza di frame nel buffer del Client. E’ tuttavia possibile obiettare che, es-sendo il cammino tra Server e Client, in uno scenario realistico, formato da un in-sieme di nodi (siano: router, switch, proxy) e di link, per garantire lo Smoothing del traffico audio-video viaggiante debbano essere allocate delle zone di memoria in corrispondenza dei vari nodi e riservata una certa quantità di banda su ciascun link del percorso. La situazione poi, è ancora più complicata se si considera il fat-to che queste allocazioni devono essere gestite da diversi Provider dei servizi di rete in quanto è assai improbabile che un solo Provider controlli l’intero percorso dal Server fino al Client. In [6] il problema della trasmissione di un file audio-vi-deo da un Server ad un Client viene affrontato con l’introduzione di un modello matematico chiamato Tandem nel quale il cammino del file è rappresentato da un insieme di nodi collegati tra di loro da dei rami. Server e Client costituiscono i nodi terminali di partenza e di arrivo, rispettivamente, mentre i rami schematiz-zano le singole tratte che uniscono le entità intermedie del cammino percorso dal file. Obiettivo dello studio affrontato in [6] è ottimizzare l’allocazione di memoria e di banda presso i nodi ed i link del cammino. Viene dimostrato come, in realtà, questo problema sia scomponibile in un insieme di problemi indipendenti cia-scuno dei quali si preoccupa di ottimizzare l’allocazione delle risorse in un si-stema ridotto che comprende solo due nodi consecutivi del percorso ed il link compreso fra di essi. Anche quest’ultimo problema è schematizzabile
matemati-camente ed il modello matematico adottato prende il nome di modello
Single-Link. Viene dimostrato infine come il caso ottimo preveda che l’allocazione di
memoria avvenga soltanto presso i nodi estremi del cammino, Server e Client, e come il problema del Tandem Smoothing possa dunque essere ridotto ad un sem-plice problema di Single-Link Smoothing fra Server e Client.
2.3.2 Modello Single-Link
Il modello Single-Link è rappresentato nella fig. 2.3. I due nodi, quello di ingresso e quello di uscita, hanno entrambi capacità di memoria. Sia M la capacità
complessiva, in byte, dei due nodi: M-b quella del primo nodo, b quella del se-condo. La sequenza completa da trasferire sia composta da N frame ed il tempo sia scandito in unità pari ciascuna alla durata temporale di un frame della sequen-za: così, l’istante generico k è tale che kÎ
{
0,1,...,N -1}
. Il flusso dei dati in arrivo al nodo di ingresso è rappresentato dal vettore degli arrivi A=A0,...,AN-1
; Ak
con k = 0, 1,…, N-1, è il numero di byte complessivamente arrivati al nodo di in-gresso fino all’istante k, deve valere che A0 £M -b e che Ak ³ Ak-1 per k = 1,
…, N-1. Ak-Ak-1 rappresenta il numero di byte arrivati al nodo di ingresso
nell’istante k.
Il flusso in uscita dal nodo terminale è rappresentato dal vettore di riproduzione
0,..., -1
= D DN
D ; Dk con k = 0, 1,…, N-1, esprime il numero di byte
Ak Dk
fig. 2.3: Modello Single-Link
Sk
ingresso uscita
vamente già avviati alla riproduzione fino all’istante k; si ha che D0 =0 e
1
-³ k
k D
D mentre Dk-Dk-1 rappresenta il numero di byte avviati alla riproduzione
nell’istante k.
Nell’istante k generico si deve avere che Ak ³Dk (il numero di byte già riprodotti non può essere maggiore del numero di byte arrivati al nodo di ingresso), la quan-tità Ak -Dk £M è memorizzata in parte presso il buffer di ingresso ed in parte presso quello di uscita; solo alla fine del trasferimento si verifica che
1 1 -- = N N D A .
0, 1,..., -1
= S S SN
S rappresenta la sequenza di scheduling; Sk con k = 0, 1, …, N-1, è il numero di byte complessivamente già spediti dal nodo di ingresso a quello
di uscita fino all’istante k; vale che Sk ³Sk-1 e la differenza Sk-Sk-1 rappresenta il
numero di byte schedulati nell’istante k.
Una sequenza di scheduling S deve evitare che si verifichino overflow ed under-flow sia presso il nodo di ingresso, sia presso il nodo di uscita; devono pertanto essere rispettate le condizioni: A-vec
M -b
£S£ A, per il nodo di ingresso e
b vec D S
D£ £ + , per il nodo terminale; vec
= è un vettore di N elementi tutti uguali e pari ad = . E’ necessario inoltre minimizzare l’allocazione di memoria presso i due nodi: M-b ed b rispettivamente.
E’ possibile ipotizzare che il vettore degli arrivi sia noto a priori: questo non è sempre vero, non nel caso delle trasmissioni live ad esempio; tuttavia, è sta-to dimostrasta-to come anche solo sfruttando la conoscenza dei frame appartenenti ad una ristretta finestra temporale nel futuro, sia possibile eguagliare con buona ap-prossimazione le prestazioni degli algoritmi di scheduling che partono invece dal-la conoscenza completa delle dimensioni dei frame di una sequenza.
Nel caso in cui il nodo di ingresso coincida con il Server e quello di uscita con il Client, ipotesi che varrà per il seguito, vale che Ak = DN-1 (pari alla dimensione
dell’intera sequenza) per ogni kÎ
{
0,1,...,N-1}
, poiché tutta la sequenza è dispo-nibile presso il file system del Server, ed il problema dell’allocazione ottimaledella memoria si riduce al problema della minimizzazione della dimensione del Client buffer (b).
2.3.3 Rappresentazione grafica dei vincoli
Per evidenziare i vincoli che le esigenze di riproduzione impongono alla schedulazione di una sequenza audio-video viene presentato un ulteriore modello, illustrato in fig. 2.4 ( si
vedano [5, 10] ). Nel piano cartesiano sono riportati, sull’asse delle ascisse il tempo, su quello delle ordinate il numero di byte. Siano:
N il numero di frame di
cui è composta la se-quenza audio o video da riprodurre; fi la
di-mensione, in byte, dell’i-esimo frame (1£i£N); M la dimensione complessiva, in byte, della sequenza (
å
= = N i i f M 1
); B la dimensione del buffer lato Client
( i N i f B £ £ ³ 1
max ); ed infine, , l’intervallo temporale che intercorre fra un frame ed il successivo: la sua lunghezza è determinata dal numero di campioni presenti in un frame e dalla frequenza di campionamento che caratterizzano la sequenza e corri-sponde al tempo di esecuzione di un frame (D= numero di campioni in un frame / frequenza di campionamento).
La prima funzione V(t), in basso, è la curva di riproduzione (o curva di playout) ottenuta sommando le dimensioni dei frame della sequenza; ciascun frame viene
y y=M VB(t) V(t) B S(t) t
sommato in corrispondenza del suo istante di riproduzione (meglio: istante di ri-produzione del primo campione contenuto nel frame).
å
êëê úûú+ D = = it1 1 fi t VNell’istante generico t il valore V(t) rappresenta la quantità di dati (in byte) già consumata dal Client perché avviata alla riproduzione; il Server deve trasmettere dati a sufficienza nel buffer del Client per impedirne l’underflow: se S(t) è il nu-mero di byte schedulati dal Server (si legga: arrivati al Client) fino all’istante t, deve valere che S
t ³V t . La funzione VB(t) è ottenuta traslando verso l’alto di B byte la funzione V(t).
å
êêéDúúù = + = it i B t B f V 1Nell’istante generico t, il Client deve aver sperimentato l’arrivo di non più di
t
VB byte complessivi, pena l’overflow del buffer e la perdita dei frame in
ec-cesso. Una curva di schedulazione S(t) che rispetti le esigenze della riproduzione e la capacità di memoria del Client deve essere compresa fra le due funzioni V(t) e
VB(t):
t S t V
t V £ £ B .
S(t) è una funzione lineare a tratti, monotona non decrescente. I tratti lineari (siano m) corrispondono ciascuno ad una sequenza di trasmissioni eseguite a rate
inva-riato, ininterrottamente. Il rate di trasmissione di un singolo tratto lineare è dato dalla sua pendenza: rj con 1£ j£m.
Il modello descritto è riportato anche, seppure con terminologia leggermente di-versa, in [6-8].
2.3.4 Criteri di valutazione degli algoritmi più comuni
Obiettivi di una buona politica di scheduling orientata allo Smoothing sono (ripetendo in parte quanto detto finora):
i. ottimizzare l’utilizzo delle risorse di rete;
ii. minimizzare la dimensione del Client buffer e del ritardo iniziale di ripro-duzione;
iii. impedire situazioni di overflow ed underflow del Client buffer al fine di
garantire una riproduzione regolare della sequenza inviata.
Inoltre, come sempre buona norma, è auspicabile ottenere questi risultati nella maniera più semplice possibile per minimizzare la complessità computazionale dello scheduling.
Per ottimizzare l’utilizzo delle risorse di rete la maggior parte degli algo-ritmi di scheduling [5-8] prevede la minimizzazione del Peak Rate ( j
m j£ r £ 1
max ): in genere la banda in rete viene assegnata proprio in base al Peak Rate così, valori più bassi permettono al Provider dei sevizi di rete di servire più utenti contempo-raneamente, ed ai singoli utenti, che pagano in base all’impiego di banda, di ri-sparmiare. Ultimamente, tuttavia, l’ottimizzazione nell’uso delle risorse di rete viene sempre più spesso intesa nell’ottica di TCP-friendly rate adaptation [9]. Come spiegato in precedenza, la tecnica di TCP-friendly rate adaptation prevede che vengano condotte delle indagini (dal Client o dal Server) sullo stato della rete allo scopo di definirne istante per istante la banda disponibile e che il Server vari dinamicamente la velocità di trasmissione mantenendola al di sotto del vincolo stimato.
In [7] è possibile leggere un confronto fra le tecniche di Smoothing mag-giormente accreditate e dedicate al traffico video. Le soluzioni prese in considera-zione propongono dei piani di trasmissione statici, basati sulla conoscenza a priori della dimensione dei frame da inviare; il rate di trasmissione viene fatto cambiare in funzione della necessità di ottimizzare uno o più parametri fissati come obiet-tivo. Come criteri di valutazione vengono adottati, oltre alla capacità di minimiz-zare il Peak Rate e la dimensione del Client buffer, la capacità di minimizminimiz-zare il numero di cambiamenti del rate di trasmissione (m) e la differenza fra i rate di tra-smissione successivi (rj+1–rj, per 1£ j£m) allo scopo di ridurre la complessità
Al-cune soluzioni lasciano che il rate di trasmissione vari con cadenza irregolare, al-tre impongono che possa essere cambiato solo ad intervalli regolari, alal-tre usano tecniche di programmazione lineare per scegliere la posizione ottima degli istanti di commutazione.
Viene osservata l’impossibilità di eleggere un algoritmo di Smoothing ot-timo: gli algoritmi migliori sono considerati quelli che dimostrano prestazioni buone (meno che ottime) relativamente a più parametri contemporaneamente piut-tosto che quelli che ottimizzano un solo parametro. Le prove sperimentali di-mostrano infatti che Peak Rate, variazioni e frequenza di variazione del rate di tra-smissione e dimensione del Client buffer non possono essere ottimizzati contem-poraneamente, ed ancora, che la natura stessa della sequenza trasmessa (si veda il tipo di compressione) influisce pesantemente sulle prestazioni di un algoritmo: si può verificare infatti, che uno stesso algoritmo generi una schedulazione ottimale per una sequenza e scadente per un’altra.
2.3.5 Smoothing On-Off
In [5, 10] viene proposto un modello di Smoothing On-Off nel quale il Server che genera il traffico alterna periodi di trasmissione a periodi di non-tsmissione, rispettivamente: On-period ed Off-period. Durante gli Off-period il ra-te di trasmissione è nullo, duranra-te gli On-period è costanra-te e sempre uguale. Alla base di questo modello c’è l’idea che per evitare l’underflow lato Client è ne-cessario che il Server trasmetta e che il Client abbia una buona capacità di accu-mulo nel buffer mentre, per evitare l’overflow, è sufficiente che il Server smetta di trasmettere ogni tanto. La forma della funzione di scheduling costruita dal Server risulta lineare a tratti con, alternati, segmenti orizzontali relativi agli intervalli di non trasmissione, e segmenti di pendenza diversa da zero per gli intervalli di tra-smissione. I parametri che caratterizzano la funzione di Smoothing On-Off sono: il rate di trasmissione (On-rate), invariato all’interno di un singolo On-period come
pure per tutta la schedulazione e che coincide con il Peak Rate; il burst-number, pari al numero di Off-period di cui si compone la schedulazione; l’idle-ratio, pari al rapporto fra la durata complessiva degli Off-period e la durata complessiva del-la trasmissione. Il burst-number fornisce il numero di interruzioni eseguite du-rante la trasmissione e quindi il numero di variazioni del rate di trasmissione. L’idle-ratio dice quanto incidono gli intervalli di non trasmissione sulla durata complessiva della trasmissione.
In [5, 10] si sostiene che per ottimizzare l’utilizzo delle risorse di rete è necessario minimizzare sia l’idle-ratio, sia il burst-number: la trasmissione risulta così più regolare, prossima cioè ad una retta continua; inoltre è necessario utilizzare un opportuno On-rate, il più basso possibile, per impegnare meno banda. Idle-ratio e
burst-number diminuiscono entrambi al diminuire dell’On-rate, ma la riduzione
dell’On-rate provoca un aumento nel fabbisogno di memoria per l’accumulo dei pacchetti in arrivo lato Client per cui è necessario trovare un compromesso tra dimensione del Client buffer ed esigenza di minimizzare burst-number, idle-ratio, ed On-rate.
La forza dello Smoothing On-Off sta soprattutto nella semplicità della schedula-zione che talvolta è più importante della perfetta ottimizzaschedula-zione degli altri para-metri prestazionali. [7] sottolinea come lo Smoothing On-Off alternando conti-nuamente il rate di trasmissione tra zero ed il Peak Rate, di fatto massimizzi la va-riabilità tra rate di trasmissione consecutivi, tuttavia, preoccupandosi di minimiz-zare il Peak Rate, l’idle-ratio ed il burst-number, come viene fatto in [5, 10], di fatto si tende a minimizzare sia la frequenza delle variazioni, sia la loro entità.
2.3.6 Smoothing lato Proxy
Fin qui è stato sottointeso che la schedulazione finalizzata allo Smoothing fosse realizzata dal Server; in [8] vengono messi in evidenza i limiti di questa ipo-tesi: il Server, pur conoscendo in anticipo (almeno nel caso di audio-video
pre-memorizzati) il numero e la lunghezza dei frame che compongono la sequenza da inviare, manca spesso di informazioni che riguardano il Client quali la dimensione del buffer ed il ritardo di riproduzione massimo tollerabile dall’applicazione ri-chiedente. Viene pertanto proposto un nuovo scenario per lo Smoothing che vede una terza entità interposta fra Client e Server: un Proxy. In un simile scenario è possibile studiare il problema dello Smoothing applicando il modello Single-Link prima fra Server e Proxy, poi fra Proxy e Client.
Il Proxy offre servizi di Smoothing on-line del traffico: riceve i frame che gli ven-gono man mano inviati dal Server e calcola la sequenza di scheduling da trasmet-tere al Client senza conoscere in anticipo la lunghezza dei frame futuri. Uno dei limiti del Proxy nel gestire lo Smoothing è proprio il fatto che non ha a disposi-zione tutto il file da trasmettere (si parla per questo di Smoothing on-line), un pro-blema simile lo affronta il Server quando deve inviare una sequenza live. Lo
Smo-othing on-line prevede l’introduzione di un ritardo di 1-60sec da consumarsi
pres-so il Proxy stespres-so per ripres-solvere i problemi dovuti all’assenza del file completo e dunque dei futuri frame e l’adozione di tecniche di caching per limitare in parte il ritardo iniziale di riproduzione causato presso il Client. La presenza di una entità Proxy con funzione di Smoothing fra Client e Server è riproposta pure in [9] dove si evidenzia l’opportunità di eseguire lo Smoothing a due livelli: tra Server e Proxy prima e fra Proxy e Client dopo. Il Server si preoccupa principalmente di rispettare le esigenze Real-Time della sequenza da inviare, e pertanto invia i dati al Proxy prima possibile, sfruttando l’elevata capacità di memoria del Proxy. Il Proxy invece si preoccupa soprattutto di minimizzare l’utilizzo del Client buffer e trasmette così i dati al Client più tardi possibile: (il cammino Proxy-Client è in genere meno critico dal punto di vista dello end-to-end-delay e dovrebbe pertanto offrire maggiori garanzie per il rispetto dei vincoli temporali nel trasferimento). Il caso ottimo, infine, viene studiato in [9] ipotizzando che il Proxy disponga già in memoria di tutta la sequenza da inviare al Client, esemplificando così il modello
Single-Link fra Proxy e Client. I risultati mostrati in precedenza dimostrano come,
di complessità computazionale, sia possibile approssimare in maniera soddisfa-cente il caso ottimo ideale.
2.4 Scenario per lo Streaming in ambiente mobile
In [9] viene esteso il problema dello Streaming ad un ambiente mobile: vengono discussi i vincoli introdotti dalla presenza di terminali mobili e link wi-reless e proposto alfine uno scenario per la realizzazione che prevede un Server su rete fissa, un Client su terminale mobile ed una terza entità Proxy, su rete fissa come il Server, con capacità di memorizzazione.
Il Client è dotato di un buffer ed avvia la riproduzione dopo un certo ri-tardo iniziale per assorbire il jitter e favorire lo Smoothing (si veda sopra). La di-mensione del Client buffer viene ridotta il più possibile visto il costo ancora di ri-lievo della memoria dei terminali mobili.
La presenza del Proxy serve a sfruttare le potenzialità dei link wireless ed a contenere il ritardo di propagazione end-to-end. Le perdite sui link wireless sono responsabili (come già sottolineato in precedenza), in presenza di TCP, dell’aumento del ritardo end-to-end sperimentato dai pacchetti. Questo aumento è immotivato quando si fa Streaming: la perdita di pochi pacchetti è infatti cosa sopportabile mentre l’aumento del ritardo end-to-end va a ricadere inevitabilmente su più pacchetti che rischiano di essere scartati tutti se arrivano, a causa della ve-locità di trasmissione rallentata dalle ritrasmissioni e dallo slow start, dopo le
de-adline di riproduzione. Il Proxy viene interposto fra Server e Client e comunica
con il Server su rete fissa e con il Client su rete wireless. Ha capacità di memoriz-zazione ed opera il prefetch dei dati che provengono dal Server così da poterli tra-smettere al Client soltanto quando sono effettivamente disponibili e con la velo-cità massima consentita dal link wireless. Il prefetching inoltre, assicurando il di-saccoppiamento fra rete wireless e rete wired, contribuisce ad evitare che pro-blemi di nodi congestionati vadano a ripercuotersi sulla connessione con il mobile
host. Altro compito del Proxy: implementare una politica di scheduling per gestire l’invio dei pacchetti al Client secondo le esigenze di Smoothing.
Il Server gestisce le trasmissioni verso il Proxy. [9] propone due soluzioni per gestire queste trasmissioni: la prima prevede il tunneling dei pacchetti RTP su TCP mentre la seconda utilizza UDP a livello trasporto assieme al protocollo TFRC per gestire la congestion avoidance ed un semplice meccanismo di ritra-smissione per ovviare alla perdita dei pacchetti. Le prove sperimentali eviden-ziano un comportamento migliore della soluzione UDP rispetto a quella TCP in quanto necessita di un buffer di dimensioni minori lato Client ed introduce un ri-tardo pure inferiore di riproduzione.
