Capitolo 3 - Implementazione e valutazione di uno schema
di migrazione del server coordinato con il livello di rete
Nel presente capitolo viene proposta una possibile implementazione dello schema di affidabilità presentato nel capitolo precedente, nonché una sua valutazione sperimentale. In particolare è stato scelto di adottare come client, un software open-source, apportando tutte le modifiche necessarie. Inoltre stato predisposto un testbed MPLS-DiffServ allo scopo di simulare il funzionamento dello schema proposto. In particolare l’architettura di rete proposta garantisce al servizio una connessione a banda garantita mediante tunnel LSP (Figura 3-1).Figura 3-1: Connessione a banda garantita mediante LSP
Lo schema di principio proposto è il seguente:
• Tra tutti i server disponibili sulla rete, uno eroga il servizio (server primario), un altro è scelto come server di backup. Il loro indirizzo di rete è notificato preventivamente al
client.
• Schema di protezione a livello di rete di tipo prestabilito: dai due server (primario e
backup) è attivato un LSP a banda garantita verso il client, ma solo quella dal primario
viene effettivamente utilizzata per lo streaming, mentre le risorse occupate da quello di
backup possono essere utilizzate dal traffico best-effort, finché il tunnel rimane
inutilizzato. Tali connessioni sono soggette ai fault di rete presentati nel capitolo precedente.
• La fault detection è operata direttamente dal client, il quale opera la migrazione verso il
continuità del servizio. La coordinazione delle tecniche di ripristino si basa su differenti tempi impiegati dalla fase di fault detection.
Il software VideoLAN
Il software utilizzato per la decodifica e la visualizzazione dello streaming è VideoLAN
Client ( VLC ) nella sua versione 0.7.2 [18]. Si tratta di un video client open-source, che
permette la visualizzazione di file multimediali codificati secondo lo standard MPEG [2], che possono essere reperiti mediante uno streaming attraverso una normale rete IP secondo un approccio di tipo client-server. L’utente può richiedere e gestire il servizio mediante un’interfaccia grafica o testuale.
Figura 3-2: Video streaming
Video on Demand
Il software VideoLAN prevede la possibilità di effettuare diversi tipi di streaming attraverso l’utilizzo di diversi protocolli e modalità. La modalità Video on Demand (VoD) così come supportato dal software VideoLAN, prevede l’utilizzo del protocollo HTTP versione 1.1 sia per la comunicazione di controllo tra client e server, sia per lo streaming del contenuto multimediale da server a client. Tutti i messaggi utilizzati fanno riferimento allo standard HTTP, il quale non prevede un formato dei messaggi strutturato in campi, bensì un formato interamente testuale.
La modalità VoD ha un approccio di tipo client-oriented, in quanto è il client che accede alla risorsa remota attraverso un meccanismo di request / reply. Lo stack protocollare utilizzato dall’applicazione è illustrato in Figura 3-3. Dal lato client il software VLC fa uso di un modulo di accesso alla rete che incorpora le funzionalità di HTTP client; tale modulo si preoccupa di gestire il socket di rete, i messaggi HTTP, nonché la memorizzazione dei dati letti dal socket nel buffer dell’applicazione. Dal lato server è sufficiente un normale HTTP
Figura 3-3: Stack protocollare della modalità Video on Demand
Quando l’utente a lato client richiede il servizio, Il client HTTP provvede automaticamente ad accedere alla risorsa remota attraverso un messaggio testuale di tipo HTTP GET che viene inviato al server. Il contenuto del messaggio così come viene utilizzato dal software VideoLAN è mostrato di seguito:
GET /<path>/<nome file> HTTP/1.1 Host: <nome client>
User-agent: <http client>
Range: bytes=<#byte iniziale> - <#byte finale> Connection: Close
HTTP GET permette funzionalità di file retrieval non dissimili da FTP. Il parametro Range in particolare permette di stabilire un intervallo di byte di cui il client richiede lo streaming, piuttosto che effettuare comunque la trasmissione dell’intero file.
Il server effettua lo streaming della sola parte del file richiesta, a partire dal byte iniziale incluso nella request: normalmente, poiché la mole dei dati da inviare eccede la Maximum
Transfer Unit del protocollo Data Link, è necessario inviare i dati su diversi pacchetti IP. Il
messaggio HTTP di reply, che viene incluso solo nel primo pacchetto, ha il formato seguente:
HTTP/1.1 206 Partial Content Date: <Data e ora attuali>
Server: <Server http> (<Sistema operativo>)
Last-Modified: <Data e ora dell’ultima modifica al file richiesto> Accept-Ranges: bytes
Content-Length:
Content-Range: bytes <#byte iniziale> - <#byte finale>/<Dimensione totale del file>
Connection: Close
Content-Type: <Tipo di file> DATA(PART)
I pacchetti successivi nel payload HTTP contengono solamente dati di streaming; la ricostruzione dell’ordinamento dei dati (inoltro ordinato), nonché il recupero di eventuali pacchetti persi (inoltro affidabile), viene gestito dal solo protocollo di trasporto TCP [21]. E’ noto che per trasmissione multimediali in tempo reale è raccomandato l’utilizzo del protocollo di trasporto UDP [20], il quale a fronte della semplicità non offre alcuna garanzia di inoltro affidabile. Tuttavia, anche nell’ottica di un’implementazione ad alta affidabilità del servizio, è possibile utilizzare il protocollo di trasporto TCP, che garantisce insieme all’inoltro affidabile dei dati anche meccanismi di flow e congestion control, che garantiscono un parametro di BER al lato client virtualmente nullo, con conseguente miglioramento della qualità multimediale percepita dall’utente. In questo modo il protocollo HTTP si trova a gestire solamente il canale di controllo tra client e server per quanto riguarda la comunicazione
request-reply.
In Figura 3-4 sono mostrati i livelli dello stack protocollare attraversati dai dati di streaming nel client host dalla lettura dalla rete, fino alla loro visualizzazione. Prima dell’inizio dello
streaming, VLC provvede, attraverso un modulo di accesso alla rete, all’apertura del socket
su cui il server invia il data stream. I dati che dalla rete giungono al client host vengono in primis memorizzati nel buffer del socket di rete, che viene gestito direttamente dal sistema operativo.
Il modulo di accesso HTTP provvede a leggere i dati di streaming dal buffer del socket, verso il buffer del Decoder, gestito dall’applicazione, il quale ha la funzionalità di assorbire i picchi di bit-rate con il quale il decoder MPEG richiede dati in ingresso: è noto infatti che uno
streaming MPEG viene inoltrato a bit-rate costante, mentre il decoder, per produrre un’us cita
video continua, richiede dati in ingresso con bit-rate variabile, caratterizzato da burst e nulli di richiesta, che dipendono dalle caratteristiche di dinamicità del contenuto multimediale. Non appena i primi dati sono disponibili al socket, VLC provvede alla loro lettura e alla memorizzazione in tale buffer. L’uscita audio / video prodotta dal decoder MPEG, costituita dai frame, viene poi accodata in un altro buffer dell’applicazione, il video buffer. L’utente ha la possibilità di fissare la dimensione di tale buffer in termini temporali, cioè è possibile fissare l’intervallo di tempo tra la memorizzazione dei dati e la loro lettura e visualizzazione. Non appena il buffer raggiunge la dimensione stabilita, l’applicazione inizia la visualizzazione dei dati. L’applicazione VLC cerca in ogni modo di mantenere costante il video buffer.
Il buffer del decoder e il video buffer, costituiscono insieme il playout buffer, già descritto nel
Capitolo 1 - Garanzie di QoS richieste da uno streaming multimediale. Il fatto di avere buffer
gestiti dall’applicazione che affiancano il buffer del socket di rete potrebbe a prima vista sembrare una ridondanza inutile; in realtà un buffer gestito direttamente dall’applicazione risulta necessario per avere un controllo sulla lunghezza del playout buffer, che non sarebbe possibile ottenere utilizzando il buffer del socket di rete, che viene invece gestito dal sistema operativo. Il playout buffer infatti ha la funzione di compensare gli effetti del jitter e dei fault di rete che possono portare all’ underflow del flusso dati con conseguenze dirette sulla qualità del contenuto multmediale in riproduzione. Difatti la quantità di dati memorizzata nel buffer del socket risulta di molto inferiore a quella dei dati nel buffer dell’applicazione.
Implementazione della migrazione
Si va ora a descrivere quale come è stato implementata la funzionalità di migrazione sull’applicativo VLC, e in particolare come sono state implementate le funzionalità di fault
detection, notification, e recovery. Le modifiche apportate al codice del software VLC sono
riportate e commentate in Appendice A.
Fault detection: triggering della migrazione
Per prima cosa è da stabilire quando la migrazione debba avere luogo; l’appro ccio
client-driven a livello di applicazione consente di ricorrere alla migrazione solo nel caso in cui
effettivamente il servizio lo richieda, cioè quando un cambiamento dello stato del sistema pregiudichi del tutto o in parte la connettività end-to-end, mettendo in pericolo la continuità del servizio, in questo caso la corretta visualizzazione del contenuto video. Secondo i criteri esposti nel capitolo precedente, allo scopo di minimizzare il tempo di recupero dopo una fault, si è cercato in caso di fault di rete, di far intervenire la migrazione del server solo nel caso in cui la rete non sia in grado di recuperare tempestivamente il fault. Questo è stato ottenuto facendo in modo che i meccanismi di fault detection che innescano la migrazione impieghino un tempo superiore a quello che la rete normalmente impiega a portare a termine il ripristino in caso di fault.
Timeout lettura socket di rete
Come primo approccio si è scelto di utilizzare un approccio basato sulla lettura dei dati dal
socket: nel caso di un’interruzione totale della connettività end-to-end, e quindi qualora lo stream dei dati smetta di pervenire al socket buffer, quest’ultimo si svuota rapidamente.
Il modulo di accesso alla rete (gestito dal client HTTP) è stato modificato in modo che nel caso esso tenti di accedere al socket buffer quando quest’ultimo è vuoto, il modulo di accesso si pone in attesa e viene fatto partire un time-out:
• Se dei dati divengono disponibili dalla rete nel socket buffer prima dello scadere del
time-out, si procede normalmente alla loro lettura e scrittura nel buffer dell’applicazione.
• Se allo scadere del time-out nessun dato si rende disponibile al socket di rete e quindi il
buffer è ancora vuoto, è probabile che si sia verificato un malfunzionamento; il modulo di
accesso dà inizio alla procedura di migrazione del server.
In Figura 3-5 è illustrato il funzionamento di questo metodo, il quale è in grado allora di effettuare la fault detection in tutti quei casi che portano all’interruzione dello streaming al
client, vale a dire:
• Tutti i fault localizzati sul server • Guasto di rete
Figura 3-5: Fault detection attraverso time-out in lettura socket
Il parametro di time-out deve essere fissato tenendo conto di due vincoli:
• Non deve essere troppo piccolo, perché in caso di fault di rete potrebbe innescare la migrazione prematuramente, senza dare il tempo ai meccanismi di recupero al livello di rete di completare il recupero, nei casi in cui questo sia possibile; ciò non è consistente con i criteri di precedenza esposti nel capitolo precedente. Un valore teorico ottimale in questo senso potrebbe essere il tempo massimo di recupero della rete, che si sperimenta in caso di guasto di link. Dopo tale lasso di tempo è ragionevole pensare che il guasto non possa essere recuperato dalla rete ed è allora possibile far intervenire la migrazione. Purtroppo tale valore non è quantificabile con precisione, ed è possibile solo darne una stima ragionevole.
• Non deve essere troppo grande, perché se i meccanismi di rete non possono recuperare, ma la migrazione interviene troppo tardi, essa può non essere in grado di garantire la continuità del servizio, causando l’ underflowing del video buffer (si veda fault notification). In particolare vale la semplice considerazione
Tout + Tmigr-rec < Tbuf
Dove Tout è il time-out di lettura socket, Tmigr-rec è il tempo richiesto dalla fault recovery in
caso di migrazione, mentre Tbuf è la lunghezza temporale del Video Buffer. Si tenga
utilizzo proporzionale di memoria al client host, che potrebbe raggiungere richieste eccessive; è allora opportuno minimizzare la lunghezza temporale del buffer. Se allora la procedura di recovery ha una durata abbastanza prevedibile, come difatti è (vedi fault
recovery) è possibile fissare Tout e Tbuf nel seguente criterio:
Tout = max( Trec-rete ) mentre Tbuf = Tout + Tmigr-rec Underflow del buffer del decoder
Il time-out in lettura socket consente di rilevare tutte le fault individuate nel Capitolo 2, tranne uno: la fault di rete dovuta alla preemption del LSP a banda garantita. Un fault di tale natura, nel caso non sia recuperabile a livello di rete, può portare ad un’interuzione completa dello
streaming ( in tal caso il fault è rilevato dal time-out del socket), ma più probabilmente causa
un deterioramento della QoS end-to-end, e in particolare una riduzione del throughput; tale eventualità porta a due conseguenze:
• Un thrughput inferiore al bit-rate dello streaming porta inevitabilmente all’interruzione o alla degradazione in qualità nel servizio, a causa dell’ underflowing del video buffer
• Tale riduzione del throughput può non essere rilevata dal time-out lettura socket, in quanto pur causando un incremento nell’intervallo di arrivo dei pacchetti, questo probabilmente non sarà sufficiente.
In particolare è stato implementato un algoritmo che monitora costantemente il buffer del
decoder, campionandone periodicamente la lunghezza. Viene calcolata una stima della sua
lunghezza media Lmed attraverso la seguente formula, basata su un semplice algoritmo ricorsivo:
Lmed = Lmed*(1-k) + k*Lsample, (1)
dove Lmed è la lunghezza media del buffer, Lsample è la l’ultima lunghezza rilevata,. k è una costante compresa tra 0 e 1. Scegliendo k sufficientemente piccolo (minore di 0,1) l’equazione (1) fornisce una stima lunghezza media del buffer su un periodo sufficientemente lungo.
La migrazione scatta quando è soddisfatta la condizione
Dove c è una costante nell’intervallo 0 -1 e N è un intero positivo.. La disuguglianza in (2) rileva una dimensione del buffer significativamente minore del suo valore medio, che può essere dovuto ad un calo improvviso del throughput. La disuguaglianza deve essere soddisfatta per più campioni consecutivi per evitare migrazioni non necessarie dovute a svuotamenti temporanei del buffer, che possono essere dovuti sia a picchi di richiesta da parte del decoder, o cali solo momentanei del throughput di rete.
Rispetto al metodo di fault detection basato sul timeout di lettura da buffer, per questo meccanismo di fault detection, è più difficile elaborare una tempistica, e per la sua valutazione si rimanda ai test.
Fault recovery: migrazione su server di backup
Una volta che i meccanismi di fault detection implementati sul client rilevano un fault, che non è recuperabile dalla rete, deve essere portata a compimento la fase di fault recovery, vale a dire la migrazione verso il server di backup. La fase di failure notification non è richiesta perchè sia la fase di detection che quella di recovery sono effettuate dal client. La procedura di migrazione viene gestita dal client secondo i seguenti passaggi (vedi Figura 3-6):
1. Chiusura della connessione TCP e del socket di rete con il server primario: il socket di
rete con il server primario viene chiuso e abbandonato. A livello TCP viene inviato al
server primario un messaggio di TCP FIN (chiusura della connessione).
2. Apertura della connessione TCP/HTTP con il server di backup: viene aperto un nuovo socket di rete. A livello TCP si procede alla connessione con il server di backup attraverso
i messaggi TCP SYN (3-way handshake). A livello HTTP si procede con un messaggio HTTP GET in cui si richiede lo streaming del file MPEG a partire dal primo byte che non è ancora stato letto dal socket di rete primario (campo Range).
3. Nuovo tentativo di lettura dal socket di rete secondario: se la connessione con il server
secondario è andata a buon fine si procede ad una nuova lettura dal nuovo socket di rete. Poiché la request HTTP prevede l’inoltro del file a partire dal primo byte non letto dal
socket primario, il modulo di accesso alla rete può trasferire direttamente i dati dal socket
di rete secondario al buffer dell’applicazione senza soluzione di continuità.
In Figura 3-6 si possono riconoscere la procedura di connessione TCP e i messaggi di
request/reply a livello HTTP. Le specifiche del protocollo TCP non prevedono la possibilità
di trasportare alcun contenuto di livello superiore nel payload del messaggio TCP SYN all’apertura della connessione, così che è possibile inviare il messaggio di HTTP GET sol o dopo aver ricevuto riscontro dal server di backup, o trasmettendolo immediatamente dopo l’ultimo messaggio della 3-way handshake (TCP ACK) o direttamente incapsulato in esso.
Figura 3-6: Fault recovery
Durata della procedura di migrazione
Si può notare come in questo modo la procedura di migrazione impieghi per completarsi un tempo pari a
Tmigr-rec = 2 RTTC-SB
dove RTTC-SB è il Round Trip Time sperimentato tra client e server di Backup e il tempo che
intercorre tra fault e fault detection, e dove la durata della procedura di migrazione (Tmigrazione)
si intende l’intervallo di tempo che va dall’istante in cui si verifica il fault, a quando è possibile leggere dati dal nuovo socket di rete verso il server di backup.
Si evidenzia come l’intera procedura, dalla rilevazione del malfunzionamento, alla migrazione del server vera e propria possa avvenire in maniera del tutto trasparente ai livelli superiori dell’applicativo, in particolare all’ utente: se infatti la procedura di migrazione e il trasferimento dei dati dal server di backup si completa in un tempo sufficientemente breve ad evitare l’ underflow del video buffer, questo può continuare a produrre l’uscita audio/video con continuità.
E’ quind i necessario che
Tmigrazione < Tbuffer
Dove Tbuffer è la durata temporale del contenuto multimediale memorizzato nel playout buffer
(buffer del decoder + video buffer). Questo giustifica ulteriormente la presenza del buffer dell’applicazione la cui lung hezza può essere fissata arbitrariamente.
Chiusura della connessione con il server primario
Si fa notare come la chiusura della connessione con il server primario non sia da dare per scontata: un guasto di rete potrebbe impedire al messaggio di TCP FIN inviato dal client di raggiungere il Server. In questo caso quest’ultimo potrebbe continuare ad inviare inutilmente dati sulla rete. Nel caso che il messaggio di TCP FIN non raggiunga tempestivamente il
server primario, altri meccanismi contemplati dal protocollo TCP intervengono in breve
tempo prima ad interrompere la trasmissione dati, poi a chiudere definitivamente la connessione:
1. Esaurimento finestra di trasmissione TCP (tipicamente in meno di un secondo): dopo
la chiusura del socket primario il client non invia più i TCP ACK al Server. In mancanza dei riscontri una volta esaurita la finestra di trasmissione il Server primario non può inviare altri dati. Pur rimanendo aperta la connessione, il client interrompe lo streaming, evitando la trasmissione di dati inutili.
2. TCP FIN/RESET dal client: il protocollo TCP prevede che il client, una volta chiusa la
connessione debba continuare ad inviare periodicamente messaggi TCP FIN finchè non venga ricevuta conferma analoga dal Server.
3. Time-out connessione TCP (tipicamente in qualche secondo): nel caso che il guasto di
rete si protragga per più di alcuni secondi, e non sia possibile lo scambio dei messaggi TCP FIN, il protocollo TCP prevede che qualora client e server non ricevano nessun messaggio per un certo intervallo temporale fissato dal parametro TCP TIME-OUT la connessione debba essere considerata comunque chiusa.
Valutazione sperimentale
Al fine di valutare il funzionamento dei meccanismi proposti, nonché di dare una dimostrazione tangibile del funzionamento, si riportano di seguito i risultati di alcuni test.
Architettura di rete
Abbiamo visto in precedenza come una rete che debba provvedere al trasporto dati per applicazioni multimediali on-demand, come ad esempio uno streaming video, debba in sostanza poter fornire dinamicamente connessioni a banda minima garantita. In seguito si andrà a presentare una applicazione di MPLS Diff-Serv che è stata utilizzata in fase di test per garantire la QoS al traffico multimediale.
Si considera un dominio di rete in cui si vuole implementare due distinte classi di traffico: classe di traffico best-effort e classe di traffico a banda massima garantita. La prima non impone alcuna restrizione al traffico che è possibile inviare alla rete, di contro non offre alcuna garanzia di QoS. Tale classe di servizio è fruibile dalle normali applicazioni dati asincrone. L’altra prevede la possibilità di instaurare dinamicamente una connessione con banda massima garantita end-to-end, che può essere sfruttata dal servizio di streaming on-
demand.
L’applicazione proposta richiede l’implementazione di un dominio di rete composto da router con le seguenti caratteristiche:
• Capacità di effettuare indistintamente forwarding IP e MPLS
• Supporto completo di MPLS-TE, quindi dei protocolli OSPF con estensioni traffic
engineering e RSVP con estensioni Explicit Routing, allo scopo di stabilire LSP CSPF-routed.
• Supporto di meccanismi di forwarding DiffServ sulle interfacce di uscita, nonché di
traffic classification e dropping sulle interfacce di ingresso.
Sotto tali condizioni il traffico appartenente alla classe di servizio best-effort viene instradata attraverso la rete mediante il normale routing/forwarding IP senza alcuna limitazione.
La connessione garantita viene invece instaurata attraverso un LSP CSPF-routed stabilito tra due edge router di cui l’ ingress è costituito dal router di default del server, mentre l’egress è sempre il router di default del client host. Il parametro di banda del LSP viene impostato pari al rate dello streaming.
Il calcolo del path mediante algoritmo CSPF consente di instradare il LSP a banda garantita
lungo percorsi che evitino l’insorgere della congestione (vedi Capitolo 1 – Traffic
engineering).
Sull’ ingress router deve essere implementato un filtro avente una duplice funzione (si veda
Capitolo 1 - Ingresso nel dominio MPLS-DiffServ):
• Implementare politiche di dropping del traffico out-profile, vale a dire che ecceda il parametro di banda richiesto, al fine di evitare fenomeni di congestione nei link attraversati dal LSP.
La presenza del traffico best-effort non limitato darebbe luogo comunque a congestione se questo venisse trattato in fase di forwarding alla stregua del traffico garantito. Allora sulle interfacce di uscita dei router è stata implementata la modalità di forwarding mostrata in Figura 3-7, derivata dall’architettura DiffServ.
Figura 3-7: Struttura funzionale di un router nell'applicazione di MPLS-DiffServ proposta
Lo switching fabric provvede ad instradare ciascun pacchetto verso l’interfaccia di uscita appropriata, sia esso MPLS o IP: nel primo caso il forwarding è basato sulla MPLS Label che identifica il LSP sul quale il pacchetto è instradato; nel caso di traffico IP best effort il pacchetto è inviato all’interfaccia di uscita associata alla IP destination, secondo le tabelle di
forwarding IP.
Una volta nell’interfaccia di usc ita un classificatore provvede a inviare il traffico MPLS garantito su una coda di uscita, il traffico IP best effort sull’altra; lo scheduler utilizza un criterio di scheduling che provvede a riservare ai traffici a banda garantita tutta la banda del
link in uscita di cui hanno necessità, lasciando la banda residua al traffico best-effort.
I meccanismi di MPLS-TE garantiscono che su ciascun link sia disponibile banda sufficiente per servire tutti i LSP che lo attraversano, evitando così l’insorgere della c ongestione per i flussi di traffico a banda garantita. Al contrario il traffico IP best effort si trova limitato ad utilizzare le risorse lasciate inutilizzate dal primo, con la possibilità quindi di incontrare risorse insufficienti su un particolare link.
Il testbed
Il testbed utilizzato in tutte le esperienze utilizza le seguenti apparecchiature:
• 2 router Juniper M10© [22], che per mezzo della suddivisione in router virtuali possono
emulare fino a 8 router diversi.
• un generatore/analizzatore di traffico Agilent RouterTester© [23]
• 3 PC Linux, uno utilizzato come video client, gli altri come video server, uno come video
server primario, l’altro come server di backup. Il video client è provvisto del sofware
VLC con le modifiche sopra descritte, mentre i due video server utilizzano il web server
Apache versione 2.03 per erogare lo streaming.
Le interfacce assegante a ciascun router, nonchè le loro interconnessioni sono illustrate in Figura 3-8.
Figura 3-8: topologia del testbed
I router Juniper supportando tutte le funzionalità richieste e sono stati configurati in modo da implementare l’applicazione di MPLS -DiffServ illustrata nel paragrafo precedente; la configurazione completa è stata riportata e commentata in appendice B.
I due video server nonchè il vlient host sono connessi ciascuno ad uno degli edge router attraverso interfacce Fast-ethernet 100 Mb/s. Il generatore/analizzatore di traffico è stato
utilizzato per simulare il traffico di rete che nel corso delle prove interagisce con lo stream video: il generatore provvede a inviare all’analizzatore vari flussi di traffico IP.
Lo stream video utilizzato in tutti i test è un file in formato MPEG-2 ad alta qualità (DVD) della durata complessiva di 20 secondi, di dimesione 26 MByte, con un rate medio di circa 10 Mbit/s. Il VLC è stato impostato con parametri di migrazione (vedi fault detection) mostrati in Tabella 3-1.
Lunghezza del Video Buffer 5 s
Time-out lettura socket 1 s
N 5
k 0.05
c 30 %
Tabella 3-1: Parametri di migrazione impostati su VLC
Durante i test sono stati utilizzati alcuni flussi di traffico di disturbo, originati dal generatore di traffico. In uscita al generatore di traffico si è sempre avuto flussi di traffico IP ciascuno a bit rate costante. Nel corso delle esperienze si è fatto utilizzo di LSP a banda garantita per proteggere sia lo stream video, sia i flussi di disturbo; in particolare per lo stream video sono stati utilizzati due LSP, uno dal server primario, l’altro dal server di backup; le impostazioni sono riportate in Tabella 3-2.
LSP Stream primario LSP Stream secondario
Parametro di banda 10 Mb/s 10 Mb/s
ingress router Edge1 Edge2
Egress Router Egde3 Egde3
Setup / Hold Priority 4 / 4 4 / 4
Tabella 3-2: Impostazione dei LSP Stream
Disturb1 Disturb2
Parametro di banda 95 Mb/s 95 Mb/s
ingress router Edge1 Edge1
Egress Router Edge3 Core2
Setup / Hold Priority 0 / 0 0 / 0
Altri LSP sono stati utilizzati per proteggere I flussi di traffico di disturbo, in particolare i LSP Disturb1 e Disturb2, le cui impostazioni sono riportate in Tabella 3-3. I due LSP
Disturb1 e Disturb2, avendo un parametro di priorità più stringente, possono sottrarre risorse
al LSP Stream ed eventualmente causarne il rerouting o l’abbattimento.
Test 1: Congestione di un link con video stream protetto da un LSP a banda garantita
L’obiettivo di questo test è quello di dimostare come il traffico inoltarto attraverso un LSP abbia banda garantita. La Tabella 3-4 e la Figura 3-9 riassumono lo svolgimento del test.
Figura 3-9: configurazione del test 1
Flussi utilizzati: IPF1 LSP: Stream
Condizioni iniziali (t = 0 s) IPF1 attivo @ 95 Mb/s
LSP Stream attivo
Timeline del test: 6 s Inizio video stream
26 s Fine video stream Tabella 3-4: configurazione e svolgimento del test 1
Lo stream video è trasportato sul LSP stream da E1 a E3 attraverso C1. Poichè il flusso di traffico IP Best Effort IPF1 è inoltarto attraverso E1-C1-E3 il link C1-E3 è soggetto a congestione. Tuttavia finchè lo stream video non è attivo, il flusso IPF1 è libero di sfruttare tutta la banda, e non è quindi soggetto a perdite. Non appena lo streaming ha inizio (t = 6s) il
link C1-E3 si congestiona, ma poichè il flusso video è trasportato su un LSP a banda protetta
viene ricevuto al client senza perdite (Figura 3-11), mentre il flusso IPF1 è soggeto a perdita ed a una riduzione del thrughput complessivo da 95 a 85 Mb/s (Figura 3-10). Solo al termine dello streaming (t=26 s) il flusso IPF1 Ovviamente data la garanzia della rete, la migrazione del server non è necessaria.
Figura 3-10: Flussi di traffico di disturbo
Test 2: Migrazione dovuta alla congestione (approcccio IP puro)
Il test 2 mira a verificare la funzionalità di migrazione innescata dalla congestione di rete qualora lo stream video non sia garantito dalla rete, cioè quando lo stream non è trasportato su un LSP a banda garantita ma è inoltrato come normale traffico IP best effeort: in tal caso è possibile l’insorgere della congestione. La Figura 3-12 e la Tabella 3-5 descrivono la configurazione e lo svolgimento del test.
Figura 3-12: configurazione e svolgimento del test 2
Flussi utilizzati: IPF1 LSP -
Condizioni iniziali (t = 0 s) IPF1 attivo @ 85 Mb/s
Timeline del test: 6 s Inizio stream video da Primary Server
18 s IPF1 incrementato @ 95 Mb/s 26 s Fine video stream da Backup Server Tabella 3-5: configurazione e svolgimento del test 2
Sia lo stream video che il flusso IPF1 sono inoltati come normale traffico IP lungo il percorso EDGE1-CORE1-EDGE3, con il link a 100Mb/s link tra CORE1 e EDGE3 a rappresentare il collo di bottiglia. Fino a che il flusso IPF1 si mantiene sotto i 90 Mb/s, il link CORE1-EDGE3
Primary video Server, mentre IPF1 non sperimenta perdite. Quando IPF1 viene incrementato a 95 Mb/s (t=18s), si ha l’insorgere della congestione con perdita di thrughput su entrambi I flussi IPF1 e video. Lo stream dal video server non è più in grado di garantire la continuità della visualizzazione the application decoding rate. Questo porta il VLC a innescare la migrazione del sever in seguito a l’underflow del playout buffer. Poichè il flusso video dal
Backup Server non sperimenta congestione la migrazione consente di preservare la continuità
del servizio senza alcuna perdita di frame al Video client. Agli effetti del flusso IPF1, la migrazione libera risorse sul link congestionato, in quanto lo stream da Primary server si arresta, consentendo in tal modo di evitare ulteriori perdite e di recuperaare velocemente il pieno throughput (95 Mb/s).
Figura 3-13: stream rate ricevuto al client Video
Test 3: LSP rerouting in seguito a preemption
Il test 3 intende verificare l’affidabilità del meccanismo di Dynamic Path Recovery (vedi capitolo 2), nel caso che il LSP a banda garantita che trasporta lo streaming video venga abbattuto da uno nuovo a priorità più alta (preemption) e che di conseguenza la rete debba provvedere a riabilitare il LSP su un cammino alternativo, il tutto in modo trasparente rispetto all’applicazione, al fine di evitare il ricorso alla migrazione del server. La configurazione del test e il suo svolgimento sono descritti nella Figura 3-15 e nella Figura 3-16 nonchè nella Tabella 3-6
Flussi utilizzati: IPF1, IPF2, IPF3 LSP Stream, Disturb1 Condizioni iniziali (t = 0 s) IPF1 attivo @ 95 Mb/s
IPF2 attivo @ 95Mb/s IPF3 attivo @ 20 Mb/s LSP Stream attivo
Timeline del test: 7 s Inizio video stream
18 s Attivato LSP Disturb1 (alta priorità) 27 s Fine stream video
Tabella 3-6: configurazione e svolgimento del test 3
Figura 3-16: configurazione del test 3 dopo il rerouting del LSP Stream (t = 18s)
Inizialmente, prima dell’inizio dello stream video, I flussi di traffico IP best effort IP1 e IP3 vanno a congestionare il link C2-E3, dando luogo a perdite su entrambi I flussi (Figura 3-18, Packet Loss). Dopo l’attivazione dello stream video(t=7s) lo stream protetto dal LSP Stream limita I flussi IPF1 e IPF3, a causa della congestione del link C1-E3.
Nell’istante t=18s viene stabilito il LSP Disturb1 tra E1 ed E3. La banda richiesta dal LSP
Disturb1 (95 Mb/s) non può essere garantita lungo C1-E3 se non dopo la preemption del LSP Stream, che però può essere reinstradato attraverso il router C2 (Figura 3-16). Tutto questo
porta da una parte al throughput pieno da parte del flusso IPF1, ora garantito da LSP
Disturb1, mentre il flusso IPF2 viene limitato dal LSP Stream a causa della congestione del link C1-C2 (Figura 3-18, RX throughput). Per ciò che riguarda lo streaming video, il LSP
rerouting porta ad un’interuzione dello streaming al client (Figura 3-17) della durata di circa 200 ms; tuttavia tale interuzione non pregiudica la continuità del servizio e diffatti non comporta il ricorso alla migrazione.
Figura 3-17: stream rate ricevuto al client
Figura 3-18: comportamento dei flussi di traffico nel test 3
Test 4: Migrazione dopo la preemption del LSP Stream
In questa esperienza si valuta una situazione in cui la migrazone del server risulta necessaria: questa situazione si può verificare qualora la connessionessione protetta che trasporta il flusso video venga abbattuta per liberare risorse ad una nuova connessione a più alta priorità (preemption), mentre la rete non è in grado di ristabilire la connessione su un percorso alternativo. La configurazione del testbed e il suo svolgimento sono illustarti dalla Tabella 3-1 e dalle Figura 3-19 e Figura 3-20.
Flussi utilizzati: IPF1, IPF2
LSP Stream, Disturb1, Disturb2 Condizioni iniziali
(t = 0 s)
LSP Stream attivo LSP Disturb2 attivo
IPF2 flow attivo @ 95 Mb/s trasportato dal LSP Disturb2 Timeline del test: • 7 s Inizio dello stream video
• 18 s LSP Disturb1 attivato, IPF1 attivato @ 95 Mb/s trasportato da LSP
Disturb 1
• 27 s Fine dello strema video
Tabella 3-7: configurazione e svolgimento del test 4
Figura 3-19: configurazione iniziale del test 4
Il test ha una impostazione similie al precedente, tuttavia è stabilito il nuovo LSP ad alta priorità con banda 95 Mb/s lungo il percorso E1-C1-C2, che impedisce l’eventuale re routing del LSP stream, in quanto il link C1-C2 è già attraversato dal LSP Disturb2 e non è in grado di supportare anche il LSP Stream.
Inizialmente il flusso di traffico IPF2 è trasportato come traffico protetto dal LSP Disturb2, pertanto viene ricevuto all’analizzatore senza perdite e con throughput pieno. Lo stream video viene anch’esso inoltrato dal server primario verso il client attraverso il LSP Stream, che come già dimostarto dal test 1 è in grado di sostenere lo stream fintanto che è attivo,
Figura 3-20: configurazione del test 4 dopo l’abbattimento del LSP Stream (t = 18s)
A t = 17 s il LSP Disturb1 viene stabilito, con la conseguenza che il LSP Stream deve essere abbattuto per liberare una banda sufficiente sul link C1-E3, mentre lo stream video deve continuare a raggiunge il client come traffico IP Best effort (Figura 3-20). Non appena il LSP
Disturb1 è attivo il flusso IP1 a 95 Mb/s può essere fatto partire per esservene inoltrato:
questo traffico garantito va a limitare la porzione di banda disponibile allo stream video sul
link C1-E3 che viene congestionato, mentre il throughput utile si riduce a meno di 5 Mb/s
(Figura 3-21). Ciò porta inevitabilmente ad un underflowing del playout buffer al client, che fa scattare la migrazione verso il server di backup. La continuità del servizio è garantita allora dal server di backup che può proseguire lo streaming inoltrandolo al client attraverso il LSP di backup.
Figura 3-22: comportamento dei flussi di traffico nel test 4
Test 5: Migrazione dopo la preemption del LSP Stream (congestione pesante)
Il test 5 è del tutto simile al precedente, con l’aggiunta del fluss o di traffico best effort IPF3, il quale va ad aggravare la situazione di congestione sul link C1-E3. La configurazione e lo svolgimento del test sono illustarti nella Tabella 3-8 nonchè dalla Figura 3-23 e Figura 3-24.
Flussi utilizzati: IPF1, IPF2, IPF3
LSP Stream, Disturb1, Disturb2 Condizioni iniziali (t
= 0 s)
LSP Stream attivo LSP Disturb2 attivo
IPF2 attivo @ 95 Mb/s trasportato dal LSP Disturb2 IPF3 attivo @ 20 Mb/s (traffico IP best effort) Timeline del test: • 7 s Inizio dello stream video
• 16 s LSP Disturb1 attivato, IPF1 attivato @ 95 Mb/s trasportato da LSP
Disturb 1
• 27 s Fine dello strema video
Figura 3-23: configurazione iniziale del test 5
Figura 3-24: configurazione del test 5 dopo l’abbattimento del LSP Stream (t = 16s)
Dopo l’attivazione del flusso IPF1 protetto dal LSP Disturb1, il LSP Stream al pari del test precedente subisce la preemption e viene abbattuto (Figura 3-24). A differenza della situazione precedente, in cui il flusso IPF3 non era attivo, sul link C1-E3 I flussi di stream e IPF3 (per un totale di 30 Mb/s) si trovano a contendersi una banda inferiore a 10 Mb/s. Ciò porta ad una situazione di congestione pesante che blocca del tutto lo stream, il quale non
guasto di link con conseguenza. L’interruzione dello stream al client provoca dopo 1 s la migrazione sul server di backup, che consente, al pari del test precedente, la continuità del servizio senza perdite di frame in fase di visualizzazione.
Figura 3-25: stream rate ricevuto al client nel corso del test 5
Figura 3-26: comportamento dei flussi di traffico nel test 5
Commenti ai test
I test dimostarno la bontà e la funzionalità dei meccanismi di fault detection che innescano la migrazione. In particolare:
• Il test 3 dimosta che qualora, in seguito a preemption, la rete sia in grado di ricorrere a meccanismi di dynamic path recovery, e sia possibile effettuare il rerouting della
connessione protetta in tempi ragionevoli (inferiori al secondo), la migrazione non interviene.
• Il test 2 e 4 dimostano invece che in caso di perdita della garanzia del servizio, sul quale la rete non è in grado di intervenire, lo schema di migrazione proposto è in grado di completare il recupero in un tempo vicino al secondo.
Si può concludere che lo schema proposto è consistente con i criteri di coordinazione proposti, e sufficientemente affidabile e veloce a garantire il ripristino del servizio; inoltre la limitata durata complessiva della migrazione consente di utilizzare un video buffer al lato
client di lunghezza inferiore a 10 secondi, limitando l’utilizzo di memoria al client host.
Tuttavia non si può fare a meno di mettere in luce alcuni aspetti non ottimali:
• Spreco di risorse: Una connessione di backup costantemente attiva, in un ottica di recupero statica, presenta il vantaggio di offrire tempi di recupero ristretti, inoltre non impedisce al traffico best-effort di utilizzare tutta la banda ad esso riservata finchè il LSP non viene utilizzata dallo streaming in caso di migrazione; d’altra parte è ovvio che rappresenta quantomeno un utilizzo non ottimale delle risorse di rete, in quanto occupa risorse di banda che potrebbero venire utilizzate per l’instaurazione di altri LSP.
• Contesa di risorse: si deve considerare che poiché le due connessioni condividono il medesimo egress router (router del client), il loro path tende a convergere negli ultimi
link. E’ probabile allora che non sia possibile stabilire contemporaneamente due LSP, uno working e uno di backup, per mancanza di risorse necessarie sui link che devono essere
attraversati da entrambi.
Nel capitolo successivo si è implementato uno sviluppo dei meccanismi di ripristino qui presentati, che grazie ad una maggiore integrazione tra il livello di rete e quello di applicazione, riesce a far fronte alle problematiche appena elencate.
