Figura 0.34 : Foto di uno degli switch ottici utilizzati. Porta di controllo. Figura : Schema di principio degli switch ottici utilizzati

Transcript

1 4.3.1 Switch Ottico Figura 0.34 : Foto di uno degli switch ottici utilizzati Gli switch ottici utilizzati sono dei dispositivi a tre porte il cui schema è riportato nella Figura Le tre porte costituenti lo switch sono indicate nello schema con le lettere A, B e C. A B C Porta di controllo Figura : Schema di principio degli switch ottici utilizzati Tramite un segnale elettrico di controllo si può cambiare lo stato del dispositivo agendo sul circuito ottico al suo interno. Nello stato di riposo (stato 1), l apparato collega le porte A e B, mentre variando opportunamente il segnale di controllo si può chiudere il circuito ottico al fine di collegare le porte A e C (secondo stato). Agendo dunque sulla tensione di controllo del dispositivo è possibile commutare il flusso ottico dalla fibra di esercizio alla fibra di backup. La commutazione dallo stato 1 allo stato 2, avviene nel momento in cui si presenta una differenza di potenziale maggiore o uguale a 4.5V sulla porta di controllo dello switch. I livelli di tensione relativi alle possibili variazioni di stato del dispositivo sono riportati nella tabella che segue. 122

2 Tensione del segnale di controllo 3 V comportamento Il disposito opera nel primo stato. Il segnale ottico transita tra A e B 4,5 V 3V Il dispositivo non cambia stato Il percorso ottico non cambia 4,5V Il dispositvo opera nel secondo stato. Il segnale ottico transita tra A e C Tabella 0.1: Tabella dei livelli di tensione ai quali avvengono i cambiamenti di stato delgli switch ottici Oltre alla differenza di potenziale appena descritta, affinché possa avvenire la commutazione dallo stato 1 allo stato 2, sono inoltre necessari almeno 40mA. Proprio per questo motivo è stato realizzato un circuito in logica TTL, capace di amplificare la corrente pari a 4mA disponibile all uscita della porta parallela del PC di management. Il tempo di commutazione del dispositivo è pari a circa 3 ms La Porta parallela L'interfaccia parallela del calcolatore, nella sua forma più utilizzata, è la periferica più semplice che si possa immaginare. Non mi riferisco qui ai nuovi standard, tipo EPP, ma al protocollo originale della parallela, che è supportato da tutti i PC, dall'8088 in poi. In pratica, sul connettore a 25 piedini si trovano direttamente i segnali corrispondenti ad alcuni bit di I/O, in logica TTL (con segnali a 0V e 5V). Con "direttamente" intendo dire che i bit che vengono scritti dal processore sulle porte di output appaiono sui piedini del connettore, e i bit della porta di ingresso vengono letti dal segnale di tensione sul connettore. Il connettore parallelo presenta 12 bit di output e 5 bit di input, più 8 segnali di terra. L'interfaccia software si compone quindi di due porte di output ed una porta di input. Alcuni bit subiscono una inversione tra quello che appare sul connettore e quello che viene visto dal processore. I segnali elletrici utilizzati sono appartenenti alla famiglia logcia TTL (Transistor-Transistor Logic) molto utilizzata, almeno in passato, che presenta specifiche di ingresso/uscita non simmetriche: mentre un'uscita bassa 123

3 (0V) può assorbire una corrente significativa, un'uscita alta (5V nominali) non è in grado di erogare più di 4 ma di corrente. E consigliabile l'uso di fotoaccoppiatori per proteggere il calcolatore L'intefaccia software Ogni porta parallela del sistema viene vista tramite tre indirizzi di I/O consecutivi: "base", "base+1", "base+2". Il registro "base+1" è un registro di input, e viene usato per leggere i 5 segnali di ingresso del connettore, "base" e "base+2", invece, sono registri di output, e quando vengono letti restituiscono l'ultimo valore scritto (cioè lo stato attuale dei segnali al connettore). L'effettiva mappatura tra i bit nei registri e i piedini del connettore è spiegata nella figura che segue. Figura : Descrizione dell interfaccia parallela L'indirizzo base della porta parallela (detto ``BASE'' nel seguito) è 0x3bc per /dev/lp0, 0x378 per /dev/lp1 e 0x278 per /dev/lp2. La porta base+0, o semplicemente, (porta dati) controlla i segnali dei dati della porta (da D0 a D7 per i bit da 0 a 7, rispettivamente; stati: 0 = basso (0 V), 1 = alto (5 V)). Una scrittura in tale porta fissa i dati sui pin. Una lettura restituisce i dati che sono stati scritti per ultimi. La porta base+1 (porta di Stato) è di sola lettura e restituisce lo stato dei seguenti segnali d'ingresso: 124

4 Bit 0 e 1, sono riservati. Bit 2 stato dell'irq Bit 3 ERROR (1 = alto) Bit 4 SLCT (1 = alto) Bit 5 PE (1 = alto) Bit 6 ACK (1 = alto) Bit 7 -BUSY (0 = alto) La porta base+2 (porta di Controllo) è di sola scrittura (una lettura restituisce gli ultimi dati scritti) e controlla i seguenti segnali di stato: Bit 0 -STROBE (0 = alto) Bit 1 AUTO_FD_XT (1 = alto) Bit 2 -INIT (0 = alto) Bit 3 SLCT_IN (1 = alto) Bit 4, quando impostato ad 1, abilita l'irq della porta parallela (che si verifica nella transizione da basso ad alto di ACK) Bit 5 controlla la direzione del modo esteso (0 = scrittura, 1 = lettura) ed è assolutamente di sola scrittura (una lettura di questo bit non restituisce nulla di utile). Bit 6 e 7, sono riservati. Configurazione dei pin (connettore a "D" femmina a 25-pin) (i = input, ingresso; o = output, uscita): 1io -STROBE, 2io D0, 3io D1, 4io D2, 5io D3, 6io D4, 7io D5, 8io D6, 9io D7, 10i ACK, 11i -BUSY, 12i PE, 13i SLCT, 14o AUTO_FD_XT, 15i ERROR, 16o -INIT, 17o SLCT_IN, Ground (Massa) I pin da me collegati alla porta di controllo degli switch sono stati i PIN 2 e 3 della sezione base avente come indirizzo di memoria utilizzato dal processore 0x

5 4.3.3 Amplificatore di corrente Le uscite della LPT1 forniscono,come appena detto, tensioni 0-5V erogando una corrente, in corrispondenza dei 5 V, pari a circa 4mA. Lo switch ottico da me utilizzato, affinché commuti il suo stato necessita di una tensione pari a 5V e di una corrente pari a 40mA. Per queste ragioni ho realizzato un amplificatore di corrente capace di amplificare la corrente in uscita dalla LPT1 di un fattore 10. Tale amplificatore è stato realizzato utilizzando l integrato 74AC541 secondo il circuito mostrato in Figura Tramite questo integrato si è potuto ottenere un buffer digitale ovvero un circuito che mantiene inalterato il livello logico dall ingresso all uscita ma che in corrispondenza di esso presenta due intensità di corrente diverse. In sostanza si rende disponibile su ciascuna uscita una corrente maggiore di quella fornita in ingresso; in questo modo il componente si comporta da interfaccia tra la porta di controllo (LPT1) e la periferica controllata (switch ottico). Figura : Schema circuitale dell'amplificatore di corrente implementato 126

6 All interno dell integrato sono presenti 8 buffer digitali disposti come in figura: Figura 0.20 : Schema circuitale dell'integrato 74AC541 Sono state utilizzate due delle 8 uscite disponibili corrispondenti a due ingressi collegati entrambi all uscita della LPT1. Un uscita è stata utilizzata per gestire lo switch ottico, mentre all altra è stato collegato un LED luminoso utilizzato per evidenziare lo stato effettivo dello switch ottico: Switch stato 1 led spento Switch stato 2 led acceso 127

7 Capitolo 5 CONFIGURAZIONE DELLA RETE E PROVE OGGETTIVE Nel capitolo vengono riportate la descrizione completa delle prove effettuate ed i risultati ottenuti, sono dapprima descritti i criteri con i quali si è scelto il setup del test-bed, i tipi di servizi sotto test e le modalità con le quali si interviene sul settaggio dei router. 5.1 TIPOLOGIE DI PROVE E NORMATIVE DI RIFERIMENTO. Nel corso dei test, per la valutazione dei risultati, è stato fatto riferimento ad opportune metriche che stabiliscono i requisiti minimi di QoS da rispettare per alcuni tipi di servizi indipendentemente dalle condizioni di traffico. Le metriche sono riportate nella tabella seguente: Figura 5.1: Tabella requisiti minimi per alcuni servizi multimediali 128

8 La tabella si riferisce ad un traffico DiffServ (RFC 2474,RFC 2475) consigliato ed è stata a sua volta ricavata dalla normativa ITU-T G1010 riportata in figura: Packet Loss 5% Zero loss 0% Conversational voice and video Command / control (eg Telnet, Interactive games) Voice/video messaging Streaming audio/video Delay 100 msec 1 sec 10 sec Fax 100 sec Transactions (eg E-commerce, Web-browsing, E- mail access) Messaging, Downloads (eg FTP, still image) Background (eg Usenet) Figura 5.2: User-centric Delay and Packet Loss requirements ITU G.1010* Una prima prova di misure è stata effettuata con lo scopo di testare i limiti hardware dei PC utilizzati come client, ed i limiti del software Chariot utilizzato per simulare le sessioni di scambio dei dati. Dalle misure effettuate è risultata una differenza di prestazioni tra i due client sia in termini di perdita dei pacchetti sia in termini di jitter. Questo comportamento è stato registrato in completa assenza di traffico di saturazione, quindi la differenza di prestazioni, che inoltre differiscono anche a seconda del verso di trasmissione, è stata imputata alle schede di rete dei due PC diverse sia per modello che per configurazione. Le differenze sperimentate di cui si parla in realtà sono minime ma differenze di prestazioni anche piccole su traffici molto grandi, quali quelli che si trattano nella rete, impongono di non trascurare i dettagli e di cercare per quanto possibile le soluzioni migliori ottenibili. Si è reso dunque necessario un settaggio delle schede di rete nella ricerca di trovare le condizioni ottime a partire dai materiali a disposizione. 129

9 5.1.1 Settaggio delle schede di rete A causa delle differenti prestazioni sperimentate col Chariot si è proceduto per esclusione a capire quali potessero essere le cause che generavano queste differenze, seppure lievi. In primo luogo si è pensato di mandare come flussi di test dei flussi di tipo Netmeeting aumentandone gradualmente il throughput 14 e tenendo nota dei valori riscontrati a seconda della macchina e della scheda di rete della macchina stessa. Un primo tentativo è stato quello di capire se i valori differenti che si riscontravano cambiando i PC dipendessero dalla frequenza del clock dei processori o dalle schede di rete. La vasta disponibilità di macchine presenti nel laboratorio di reti ottiche dinamiche ha reso possibile questo tipo di prove. Per prima cosa si è proceduto con una misura dei vari parametri: Throughput, One-Way-delay, Lost Data, Jitter con flussi via via crescenti lasciando ogni scheda di rete montata sul suo PC di origine. Quello che si riscontrava è che si ottenevano parametri più buoni da macchine con processori meno potenti di altre, Questo dato ha chiaramente evidenziato che le prestazioni differivano per la diversità dei modelli delle schede di rete, per questo motivo su due PC diversi sono state montate due schede di rete uguali, ma questo non ha portato ad un miglioramento della situazione. Dunque le prestazioni dipendono in maniera congiunta dalle schede di rete ed anche dal PC su cui sono montate. In seguito a questa considerazione sono state montate tutte le schede di rete a dispostone su tutti i PC a disposizione indistintamente fino a trovare le coppie ottime PC-scheda per potere iniziare le prove. Naturalmente per ognuna delle prove sono state create delle tabelle che non vengono riportate in primo luogo per il numero elevato, in secondo luogo perché non costituiscono delle informazioni importanti ai fini dell indagine sulla qualità del servizio. Si riporta comunque per completezza un esempio di come questa prove siano state effettuate, in questo caso specifico si presenta l andamento di un flusso 14 Portata 130

10 Netmeeting (protocollo RTP) dalla macchina di indirizzo alla macchina di indirizzo ripetendo la prova 5 volte, in seguito si inverte il flusso e si ripetono altre prove; al termine delle prove i dati vengono mediati e sulla base delle medie si traggono conclusioni su quali macchine e schede adoperare. Prova 1 ( ) script Netmeeting 10Mbps) Throughtput (Mbps) One way delay (ms) Loss Data (%) Jitter (ms) 9, ,83 1 0, ,84 1 0, , Di cui si mostra il grafico dei valor medi: Valori Medi Valori Medi Throughtput (Mbps) One way delay (ms) Loss Data (%) Jitter (ms) Valori Medi 9,8575 1,25 0,0005 9,5 131

11 Prova 2 ( ) script Netmeeting a 10Mbps L obbiettivo consiste nel decidere in quale verso mandare il flusso, valutando le caratteristiche di test. Throughtput(Mbps) One way Delay (ms) Loss Data (%) Jitter (ms) 9,94 1 0, , ,84 1 0, , Di cui si graficano dei valori medi: 10Mbps > Valori Medi > Throughtput(Mbps) One way Delay (ms) Loss Data (%) Jitter (ms) Valori Medi >6.28 9, , Questo tipo di prova veniva ripetuto per valori di throughput sempre maggiori, su più macchine al variare delle schede di rete. 132

12 5.2 CONFIGURAZIONE DEI ROUTER Misure per il dimensionamento dell Expedited Forwarding Trovata la configurazione ottima per il settaggio delle schede di rete che corrisponde a quella descritta nel paragrafo dei dispositivi utilizzati, circa le prestazioni del server Chariot è stato deciso di instaurare delle sessioni con al massimo 60 Mbit/s. Questa decisione è stata presa al fine di non stressare eccessivamente le schede di rete dei client e la capacità computazionale dei PC stessi. La prima serie di misure finalizzata alla configurazione di una piattaforma di servizi gestiti in maniera DiffServ è stata realizzata su rete scarica; il traffico presente i rete, costituito da 5 flussi di videoconferenza (Netmeeting) da 10Mbit/s etichettato EF 15 è stato generato dal server Chariot ed in queste condizione è stato valutato il comportamento di due diversi Drop Profile 16 in termini di Throughput, perdita dei pacchetti, Jitter massimo e One-Way-Delay massimo. Il primo Drop Profile di seguito indicato come drop_profile_1 è riportato di seguito in figura: [edit class-of-service drop-profiles] admin@lab1# expedited-forwarding { interpolate { fill-level [ ]; drop-probability [ ]; } Figura 5.3: Drop Profile 1 della coda Expedited Forwarding Al 30% di riempimento della coda del traffico EF drop_profile_1 presenta una probabilità di drop (scarto) pari al 100%. Questo profilo è molto restrittivo poiché la coda della forwarding class EF non viene mai riempita completamente, ed è 15 Expedited Forwarding 16 Letteralmente profilo di scarto detta il comportamento che deve avere il router quando si carica una cosa in termini di scarto dei pacchetti. 133

13 stato pensato per garantire valori di jitter e di one-way-delay molto bassi anche se a scapito di una perdita di pacchetti alta. Nella tabella che segue sono riportati i risultati dei test riportati su 10 prove: PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) 1 0, , , , , , , , , , Figura 5.4: Flussi Netmeeting EF su rete scarica con drop_profile_1 Per confrontare la tenuta del Drop Profile con situazioni più realistiche, lo stesso traffico EF è stato invito su rete carica. Il traffico di saturazione è di tipo BE 17 ed è stato generato da quattro porte FastEthernet, con rate generato variabile tra 10 e 100 Mbit/s, e due porte GigabitEthernet con rate fisso di 800Mbit/s nei due versi trasmissivi. Sono riportati in tabella i risultati del comportamento del drop_profile_1 in termini di perdita dei pacchetti, jitter massimo e one-way-delay massimo: PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) 1 0, , , , , , , , , , Figura 5.5: Flussi Netmeeting EF su rete carica con traffico BE, drop_profile_1 Anche in condizione di rete carica tutti i valori sono al di sotto di quelli riportati nella tabella di riferimento di figura 11, ed inoltre sono comparabili con quelli 17 Best Effort 134

14 registrati nel caso di rete scarica. Questo comportamento ricalca in pieno le caratteristiche cui mira l approccio DiffServ che riserva ai flussi EF un trattamento privilegiato. A dimostrazione del corretto funzionamento della QoS differenziata mediante il server Chariot su rete carica nelle medesime condizioni sono stati mandati: 4 flussi Netmeeting da 10 Mbit/s etichettati EF ed un flusso Netmeeting da 10 Mbit/s etichettato BE, è stato quindi possibile confrontare le modalità di trattamento delle due diverse tipologie di traffico. Nella tabella che segue sono riportati i risultati dei test: PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) EF BE EF BE EF BE 1 0,01 24, , ,065 24, ,004 24, ,035 25, ,1 24, ,006 24, ,11 24, ,07 24, ,08 24, Figura 5.6: 4 flussi Netmeeting EF, un flusso Netmeeting BE su rete carica con traffico BE, drop_profile_1 per EF Le stesse misure sono state effettuate utilizzando un secondo Drop profile per il traffico EF nel seguito indicato come drop_profile_2 ed illustrato in figura: [edit class-of-service drop-profiles] admin@lab1# expedited-forwarding { interpolate { fill-level [ ]; drop-probability [ ]; } Figura 5.7: Configurazione drop_profile_2 della coda Exedited Forwarding 135

15 Questo Drop Profile prevede una probabilità di drop del 100% solo dopo aver raggiunto il 100% di riempimento della coda ed è meno aggressivo del drop_profile_1 che prevedeva uno svuotamento della coda a partire dal 30% di riempimento della stessa. Come previsto in questo caso diminuisce la perdità dei pacchetti, ma aumentano in maniera sensibile sia il jitter massimo che il one-waydelay massimo a causa del maggior tempo che i pacchetti passano all interno della coda. Di seguito vengono riportati i valori dei test ottenuti col drop_profile_2 nelle stessa condizioni del drop_profile_1. PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) 1 0, , , , , , , , , , Figura 5.8: 5 flussi Netmeeting EF su rete scarica con drop_profile_2 PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) 1 0, , , , , , , , , , Figura 5.9: 5 flussi Netmeeting EF su rete carica con traffico BE con drop_profile_2 136

16 PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) EF BE EF BE EF BE 1 0,06 24, , ,05 24, ,07 24, ,08 24, , ,005 24, ,07 24, ,19 24, ,02 24, Figura 5.10: 4 flussi Netmeeting EF, un flusso Netmeeting BE su rete carica con traffico BE, drop_profile_2 per EF Una nuova serie di misure è stata realizzando trasmettendo con il server Chariot 5 flussi Netmeeting EF con traffico di saturazione di tipo EF in modo da congestionare completamente la coda EF e porci nella condizione limite per questa tipologia di traffico. Da questo test è possibile confrontare i due Drop Profile in maniera più netta, e dalle misure risulta che il parametro che subisce i cambiamenti più rilevanti passando da un profilo all altro è solo il one-waydelay, gli altri parametri presentano infatti variazioni poco apprezzabili fra di loro a seconda del profilo. Di seguito si riporta una tabella di confronto tra i due one-way-delay sperimentati con i due Drop Profile differenti: 137

17 ONE WAY DELAY MAX one way delay max in ms traffico con drop profile_2 traffico con drop profile_1 Figura 5.11: Confronto tra one-way-delay massimi per i due Drop Profile Dalle misure effettuate si è accertato che pur variando le dimensioni del buffer, il Drop Profile o il Trasmission Rate associato alle code EF le perdite dei pacchetti sono estremamente basse. Il motivo per cui pur avendo un Drop Profile molto aggressivo si sperimentano basse perdite dei pacchetti è da imputare alla configurazione dei router Juniper M10, infatti circa lo scheduling dei pacchetti è possibile settare tre livelli di priorità: Bassa Alta Molto alta Per il traffico Best Effort è stata scelta la prima, per il traffico Assured Forwarding la seconda ed infine la terza per il traffico Expedited Forwarding; quest ultimo infatti deve essere più cautelato rispetto alle altre tipologie. Le differenze che sussistono tra le tre classi sono le seguenti: la classe con priorità alta, fintanto che si ha disponibilità di banda, viene servita prima di quella con priorità bassa, la classe molto alta ha precedenza su tutte le altre e la coda associata a questa classe è servita finché ci sono pacchetti da spedire indipendentemente dalla banda disponibile. A causa di questo motivo le 138

18 perdite dell EF sono sempre trascurabili, a parte il caso limite in cui la rete viene caricata esclusivamente con traffico EF. Per garantire la banda alle classi con priorità bassa ed alta viene allocata alla classe con priorità molto alta una quantità di banda pari al traffico che fa fluire nella rete; questo significa che per ottimizzare le risorse e configurare i router in modo che tutti i servizi rispettino le metriche di QoS bisogna conoscere prima la quantità ed il tipo di traffico dati presenti in rete Misure per il dimensionamento dell Assured Forwarding. La successiva serie di misure è stata realizzata al fine di dimensionare opportunamente le risorse di rete per gestire il traffico Assured Forwarding. Anche in qusto caso durante le prove sono stati implementati due diversi Drop Profile per il traffico AF 18 riportate di seguito: [edit class-of-service drop-profiles] admin@lab1# assured-forwarding { interpolate { fill-level [ ]; drop-probability [ ]; } Figura 5.12: Configurazione del drop profile 3 della coda Assured Forwarding 18 Assured Forwarding 139

19 [edit class-of-service drop-profiles] assured-forwarding { interpolate { fill-level [ ]; drop-probability [ ]; } Figura 5.13: Configurazione del drop profile 4 della coda Assured Forwarding Il drop_profile_3 è più stringente del drop_profile_4, il secondo infatti prevede il 100% di probabilità di scarto dei pacchetti al 100% di riempimento del buffer della coda, il primo invece presenta una probabilità di drop del 100% al 50% di riempimento della coda. Durante la prova sono stati generati mediante il server Chariot due flussi AF e tre flussi EF, ciascuno costituito da streaming Netmeeting da 10 Mbit/s, il traffico di saturazione inviato dall analizzatore generatore di traffico Anritsu MD1230A è stato suddiviso come segue: due porte GigabitEthernet inviano sul link sotto test traffico di tipo BE, due porte FastEthernet inviano traffico AF ed altre due porte FastEthernet inviano traffico EF. Il traffico totale presente in rete è dunque il seguente: EF: 32 Mbit/s (MD1230A) + 30 Mbit/s (server Chariot: 3 EF sotto test) AF: 80 Mbit/s (MD1230A) + 20 Mbit/s (server Chariot: 2 AF sotto test) BE: 800 Mbit/s (MD1230A) In una prima sessione di misure per il traffico EF è stato impiegato il drop_profile_1, per il traffico AF il drop_profile_2 ed infine il trasmission rate 19 ed il buffer size 20 dello scheduler map 21 sono stati dimensionati in questo modo: 19 Trasmission rate control determina le effettive condizioni di traffico provenienti da ogni forwarding class configurata. Il rate è specificato in bit/s, ed è possibile limitare la banda 140

20 TRAFFICO TRANSMISSION RATE BUFFER SIZE EF 10% 7% AF 10% 9% BE 73% 79% NC 5% 5% Figura 5.14: Configurazione dello Scheduler I risultati ottenuti dalle misure sono riportati nelle tabelle e nei grafici che seguono. Per completezza sono stati riportati anche i risultati del traffico EF pur non essendo sotto analisi. PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) EF AF EF AF EF AF 1 0,05 0, ,14 0, ,072 0, ,056 0, ,13 0, ,08 0, ,08 0, ,06 0, ,075 0, ,071 0, trasmessa all esatto valore configurato, o lasciare che il traffico in eccesso ricada su altre code laddove sia possibile 20 Buffer Size, si utilizza per avere un controllo sulla congestione di rete, prevede ad assorbire i pacchetti derivanti da picchi di traffico, quando il buffer si riempie i pacchetti in ecceso vengono scartati. 21 Vedi appendice 141

21 LOST DATA percentuale pacchetti persi 0,16 0,14 0,12 0,1 0,08 0,06 0,04 0, traffico EF traffico AF JITTER MAX valori di jitter max in msec traffico EF traffico AF ONE WAY DELAY MAX one way delay in msec traffico EF traffico AF Figura 5. 15: Tabella e grafici della sessione di misure eseguita sul traffico AF 142

22 Figura 5.386: Confronto tra il throughput del traffico EF e del traffico AF Dai valori riportati nelle tabelle e nei grafici si può notare come le perdite ed i valori di one-way-delay del traffico AF siano molto basse e praticamente comparabili con quelle del traffico EF. Si osservi inoltre che i valori riportati dal traffico AF sono molto al sotto dei QoS requirements previsti dalla normativa ITU-T G1010 di cui la tabella in figura 11. Poiché ci si trova molto al di sotto dei valori previsti dalla normativa e dunque si ha un discreto margine, sono stati variati il Drop Profile, il buffer size ed il trasmission rate con lo scopo di ottimizzare le risorse di rete ed allineare il traffico AF alle metriche di QoS. Nella sessione di misure che segue il traffico di saturazione generato dal Chariot è rimasto lo stesso, il buffer size ed il trasmission rate sono stati modificati come si nota in tabella e, per il traffico AF è stato utilizzato il drop_profile_1. TRAFFICO TRANSMISSION RATE BUFFER SIZE EF 8% 7% AF 9% 9% BE 78% 79% NC 22 5% 5% Figura 5.39: Seconda configurazione dello Scheduler 22 NC non classificato 143

23 I risultati ottenuti sono riportati nelle tabelle e nei grafici che seguono; come prima sono stati riportati per completezza anche i risultati dei valori del traffico EF. PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) EF AF EF AF EF AF 1 0,12 5, ,1 5, ,012 5, ,081 5, ,1 5, ,016 5, ,013 5, ,06 5, ,007 5, ,14 5,

24 LOST DATA percentuale pacchetti persi traffico EF traffico AF JITTER MAX valori di jitter max in msec traffico EF traffico AF ONE WAY DELAY MAX one way delay in msec traffico EF traffico AF Figura 5.18: Tabella e grafici della sessione di misure del traffico AF 145

25 Figura 5.40: Confronto del throughput del traffico EF e del traffico AF Dai valori delle tabelle e dai grafici si nota come le perdite di pacchetti ed i valori del one-way-delay siano aumentate rispetto al caso precedente, in particolare le perdite percentuali dell AF superano i limiti imposti dalle metriche di QoS, dunque le configurazioni del buffer size, del trasmission rate ed il Drop Profile sono state nuovamente modificate passando ad una nuova sessione di prove. Dopo vari tentativi si è giunti ad una situazione ottimale che rispetta i limiti imposti dalla normativa e al contempo tende a distinguere i risultati ottenuti da traffico AF e da traffico EF. In questa nuova configurazione è risultato essere vincente il drop_profile_2 per il traffico AF con i valori di buffer size e di trasmission rate riportati in tabella. TRAFFICO TRANSMISSION RATE BUFFER SIZE EF 8% 7% AF 10% 8% BE 78% 80% NC 5% 5% Figura 5.20: Configurazione definitiva dello Scheduler 146

26 In questa nuova configurazione è stato possibile aumentare la quantità di traffico di analisi (Chariot). Il traffico presente in rete è stato suddiviso in questa maniera: EF: 32 Mbit/s (MD1230A) + 20 Mbit/s (Chariot 2 EF sotto test) AF: 80 Mbit/s (MD1230A) + 26 Mbit/s (Chariot 3 AF sotto test) BE: 800 Mbit/s (MD1230A) Ricordo che i flussi hanno un rate di 10Mbit/s ognuno ed il flusso AF generato dal Chariot di 26 Mbit/s è composto da due flussi da 10 Mbit/s ed uno da 6Mbit/s; è stato possibile introdurre quest ultimo flusso in seguito alle modifiche apportate alla configurazione. Il valore di 6 Mbit/s è stato ricavato per tentativi ed è da intendersi come valore limite, infatti per valori di AF maggiori di questo la rete, per come è stata dimensionata, non è più in grado di mantenersi sotto i limiti dettati dalle metriche di QoS. I risultati ottenuti sono riportati nelle tabelle e nei grafici che seguono e, come al solito, per completezza vengono riportati anche le statistiche sul traffico EF. PERDITE (%) JITTER MAX (ms) ONE-WAY DELAY MAX (ms) EF AF EF AF EF AF 1 0,13 1, ,04 1, ,14 1, ,066 1, ,005 1, ,025 1, ,134 1, ,004 1, ,077 1, ,012 1,

27 LOST DATA percentuale pacchetti persi 1,6 1,4 1,2 1 0,8 0,6 0,4 0, traffico EF traffico AF JITTER MAX valori di jitter max in msec traffico EF traffico AF ONE WAY DELAY MAX one way delay in msec traffico EF traffico AF Figura 5.41: Tabella e grafici sessione misure traffico AF 148

28 Figura 5.22: Confronto tra il througput del traffico EF e del traffico AF Configurazione definitiva. Al termine di tutte queste misure è stata scelta come configurazione definitiva la seguente: Traffico EF drop_profile_1 Traffico AF drop_profile_2 Scheduler come in figura 17. La configurazione completa e definitiva di entrambi i router per queste prove oggettive e per le prove soggettive che verranno descritte nel prossimo capitolo e riportata in appendice. Le misure che seguiranno sono state realizzata per testare l efficienza della gestione delle politiche di Qualità di Servizio. Sulla rete settata secondo l ultima configurazione descritta sono state effettuate una serie di misure al fine di mostrare la differenza di trattamento, in termini di perdite di pacchetto, one-way-delay e jitter, che uno stesso servizio riceve a seconda della sua etichettatura. 149

29 5.3 TEST SUI SERVIZI Test sui servizi di video conferenza. Le prime due serie di misure sono state effettuate sul servizio Netmeeting, lo stesso usato per il settaggio delle configurazioni e dei carichi, che è un servizio di tipo real time e richiede valori molto bassi per quanto riguarda i parametri di bitter, one-way-delay, e perdita dei pacchetti percentuale. Tra le varie configurazioni di traffico provate, si riportano di seguito i casi più significativi: Caso limite AF. Dal server Chariot sono stati inviati 6 flussi Netmeeting cosi ripartiti: 2 flusso EF da 10 Mbit/s 1 flusso BE da 10 Mbit/s 3 flussi AF per un totale di 30 Mbit/s Al traffico prodotto dal Chariot vanno sommati gli 80 Mbit/s AF e i 32 Mbit/s EF generati dalle FastEthernet dell Anritsu MD1230A, più gli 800 Mbit/s generati dalle interfacce GigabitEthernet dello stesso generatore. Figura 5.23: Throughput caso limite AF 150

30 Rispetto al carico dei settaggi in questa prova il traffico del Chariot è stato ulteriormente aumentato di 10 Mbit/s etichettati come traffico EF. La scelta di questo particolare grafico sviluppato su una sessione di cinque minuti anziché di uno è dovuto alla particolare resa cromatica che per contrasto rende immediatamente conto della differenza del trattamento delle tre tipologie: EF, AF e BE. Si può notare come i flussi a parità di bit-rate nominale sperimentino prestazioni diverse in base alla classe di servizio di appartenenza. I flussi EF, quelli più privilegiati hanno throughput poco variabile e praticamente uguale a quello nominale, il flusso BE (quello celeste) come ci si aspettava ha perdite notevoli e inaccettabili ed è altamente variabile. I tre flussi AF essendo in condizioni limite sperimentano throughput più bassi dell EF anche se comparabili, ma presentano una variabilità notevole. Nonostante queste osservazioni i flussi AF rimangono comunque nei limiti prestabiliti di QoS. Figura 5.42: Lost Data caso limite AF In questa figura è mostrato l andamento delle perdite dei pacchetti. Come è ben visibile i flussi EF (quelli rossi) hanno perdite nulle tanto che il Chariot non le grafica, il flusso BE (quello celeste) ha perdite inacettabili ed i flussi AF (quelli della zona verde e grigia) hanno perdite mediamnte intorno al 4% cioè al limite dei valori imposti per la classe Assured Forwarding. 151

31 Figura 5.43: One-Way-Delay caso limite AF In quest ultima figura relativa al caso limite AF è mostrato il ritardo ad una via massimo sperimentato dai pacchetti. Per tutte le classi di servizio i valori di oneway-delay sono bassi rispetto a quelli dettati dalla normativa di riferimento, ma risulta evidente la differenza tra i vari flussi: il traffico EF sperimenta un ritardo trascurabile rispetto agli altri due, mentre BE sperimenta il ritardo in assoluto più grande, ciò è dovuto alla sua maggiore bufferizzazione. Figura 5.26: Jitter massimo caso limite AF Nella figura sopra è rappresentato il jitter massimo sperimentato dai pacchetti in rete, si può notare come i flussi EF abbiano valori molto bassi, mentre per le altre 152

32 tipologie di traffico i valori sono ben più elevati, in particolare i valori del jitter del traffico AF sono elevati poiché ci troviamo in una situazione limite e si trovano risultati paragonabili a quelli della tipologia BE. Caso generico. Dal server Chariot sono stati inviati 5 flussi Netmeeting tutti da 10 Mbit/s, ripartiti nel seguente modo: 1 flusso EF 2 flussi BE 2 flussi AF. Diversamente dal caso precedente il traffico AF non è spinto al limite e dunque sperimenta prestazioni molto simili a quelle dell EF. Per quanto concerne i flussi BE si nota che rimangono molto alti i valori delle perdite di pacchetto e di oneway-delay massimo. Figura 5.447: Throughput Caso Generico 153

33 Figura : Lost Data Caso Generico Figura 5.469: One-Way Delay Caso Generico 154

34 5.3.2 Test su servizio VoIP (Voice over IP) Il servizio Voice over IP analogamente al Netmeeting è un servizio di tipo realtime. Richiede parametri di QoS molto stringenti e, come per il caso generico Netmeeting, dalle misure effettuate non è evidente la differenza di prestazioni tra i flussi EF e AF. Si rimane sempre al di sotto del limite di traffico AF che la rete può supportare. La configurazione del traffico inviato dal Server Chariot è la seguente: 5 flussi VoIP per ogni classe di servizio. Il motivo di così pochi flussi è dovuto alle limitazioni del software Chariot ed alle modalità di simulazione che non permettono l instaurazione di un numero maggiore di chiamate. Figura 5.30: Throughput flussi VoIP 155

35 Figura 5.47: Lost Data flussi VoIP Figura 5.48: One-Way Delay flussi VoIP Dai grafici ottenuti dal Chariot sviluppati su un minuto si nota come il traffico BE sperimenti perdite molto alte mentre i grafici AF ed EF abbiano entrambi perdite molto basse. Per quanto riguarda il one-way-delay, la differenza tra i flussi EF-AF ed i flussi BE è notevole, per i primi due inferiore ad 1 ms, per i flussi BE superiore a 90 ms. Tutte le misure che precedono riguardano servizi real-time è si mostra, dall evidenza delle prove, come il traffico BE non sia in grado di supportare 156

36 questo tipo di servizi. La differenza tra le due classi di servizio AF ed EF è risultata meno evidente ma va osservato che: Il traffico di tipo AF ha ottenuto risultati sempre sotto al limite massimo consentito dalla normativa ITU-T G1010 di riferimento. La classe di servizio EF, per come è configurata sui router, può supportare una grande quantità di traffico real-time senza compromettere al qualità del servizio. I limiti alle quantità di traffico presenti nella rete sono dovuti sia alle risorse hardware disponibili, sia ai parametri di QoS della classe AF. I parametri di QoS esaminati nelle misure effettuate fino ad ora sono validi esclusivamente per servizi real-time per i quali si passa sul protocollo RTP; nelle misure che seguiranno verranno verranno presi in considerazione servizi di tipo non real-time che viaggiano su protocolli tipo TCP per i quali non ha senso avere informazioni sul jitter, sulle perdite e sul ritardo. Il parametro che si considererà di qui in seguito è il throughput medio Servizio di trasferimento dati In questa sessione di test è stato impiegato per il Chariot uno script di simulazione di un servizio FTP. Si tratta di un trasferimento di dati su protocollo TCP. La configurazione dei flussi è la seguente: 1 flusso ftp EF 1 flusso ftp AF 1 flusso ftp EF 157

37 Figura 5.493: Throughput flussi ftp Il bit-rate dei singoli flussi non è settabile sul Chariot come costante, ma è un parametro variabile, dunque per analizzare il grafico non bisogna ragionare sui valori assoluti del throughput, ma per differenza sulle singole classi. Si nota dal grafico che mediamente il throughput del traffico EF e quello del traffico AF sono simili, mentre quello del traffico BE (zona in basso del grafico) è di un ordine di grandezza inferiore. I risultati leggibili nel file di report prodotto dal Chariot riportano un throughput medio del traffico EF di 1 Mbit/s, un throughput medio del traffico AF di 0,73 Mbit/s ed uno BE di 0,1 Mbit/s. Una successiva prova è stata effettuata con un nuovo script di tipo file-send con la seguente configurazione: 1 flusso file-send EF 1 flusso file-send AF 1 flusso file-send BE 158

38 Figura 5.504: Throughput flussi file-send I risultati di questo test mostrano in maniera più evidente la differenza di prestazioni che i differenti flussi sperimentano in rete. Come si nota in figura, il flusso EF (colore verde) ha un bit-rate molto maggiore degli altri con una media fornita dal Chariot di circa 28 Mbit/s, il flusso AF (quello rosso nella zona centrale del grafico) ha un throughput medio di circa 14 Mbit/s ed infine il traffico di tipo BE è il meno performante di tutti con un throughput medio di Mbit/s e quasi impercettibile sul grafico Servizi audio-video non real time In questa serie di misure vengono utilizzati degli script che simulano servizi di streaming audio-video non real time che utilizzano il protocollo UDP, i servizi testati sono Quick Time e Real Player. Il primo test effettuato su servizio Real Player è stato realizzato con la seguente configurazione: 1 flusso Real Player EF da 20 Mbit/s 1 flusso Real Player AF da 20 Mbit/s 1 flusso Real Player Be da 20 Mbit/s 159

39 Anche per questo tipo di traffico il parametro fondamentale è il throughput medio. Figura 5.515: Throughput flussi Real Player Come nel caso del VoIP e del Netmeeting, non c è molta differenza tra i flussi EF ed AF in termini di throughput che si aggira per entrambi intorno ai 19 Mbit/s quasi il valore del throughput nominale. Il flusso BE è fortemente penalizzato e presenta un throughput medio di 0,4 Mbit/s. Il secondo test è stato realizzato sull applicazione Quick Time. Durante la misura è stato generato un flusso dello stesso traffico per ogni classe di servizio. 160

40 Figura 5.526: Throughput flussi Quick Time I risultati di questa ultima misura sono molto simili alla precedente: i flussi EF ed AF hanno lo stesso throughput che ora è appena maggiore di 20 Mbit/s mentre il flusso BE ha una portata di 0,42 Mbit/s. Tutte le misure presentate hanno dunque convalidato la teoria DiffServ, quindi la rete realizzata è in grado di differenziare la gestione del traffico in funzione del servizio specificato e della sua classificazione. La funzione differenziazione dei servizi è stata implementata con successo nei router Juniper M10 che hanno dimostrato un comportamento ottimo nella gestione delle classi di servizio. In tutte le misure effettuate è evidente infatti come le due classi più privilegiate Expedited Forwarding e Assured Forwarding siano cautelate anche in condizioni di rete molto carica e dunque adatte a servizi particolarmente delicati come quelli real time. Circa la classe Best Effert invece viene fortemente penalizzata e le prestazioni del traffico sono basse qualunque sia il servizio considerato. 161

41 Capitolo 6 PROVE SOGGETTIVE E QUALITA PERCEPITA DALL UTENTE FINALE In questo capitolo vengono descritti nel dettaglio lo svolgimento delle prove per la qualità percepita dall utente finale ed i risultati ottenuti in termini di valutazione Nello studio dei risultati si tiene conto dei parametri oggettivi di rete i quali vengono comparati con i parametri soggettivi al fine di stabilirne una correlazione. 6.1 TEST-BED SPERIMENTALE PER LA VALUTAZIONE SOGGETTIVA DELLA QUALITA DEL SERVIZIO. Il test-bed utilizzato per le prove soggettive è lo stesso di quello utilizzato per le misure oggettive a meno di necessarie modifiche descritte nel seguito. Il test-bed è mostrato nella figura che segue: Link sotto test Link di collegamento fra laboratori in fibra ottica mmf Link di collegamento in fibra ottica smf Link di collegamento FastEthernet CLIENT VLC LAN SERVER CHARIOT HUB Laboratorio valutazione della QoS multimediale Ufficio IV ISCOM conv e/o 1,25 GBE Laboratorio trasmissivo reti ottiche -ISCOM- ANELLO OTTICO ROMA-POMEZIA Fibra ottica smf 1550 Fibra ottica mmf conv e/o fe 1,25 GBE 1,25 GBE fe SERVER MULTIMEDIALE (VLC LAN) GENERATORE-ANALIZZATORE DI laboratorio reti ottiche dinamiche Ufficio III ISCOM Figura 6.53: Test-bed sperimentale per le prove soggettive. 162

42 Per lo svolgimento di queste prove è stato necessario l impiego di un software che trasmettesse e ricevesse streaming audio-video, tra i vari disponibili è stato scelto il programma VLC Lan 23. VLC è stato installato su un PC del laboratorio di reti ottiche dinamiche del piano 1S 24 in modo che funzioni da server ed il PC è stato connesso direttamente al primo router; VLC è poi stato installato in un PC del laboratorio per la qualità del servizio multimediale, sito al sesto piano, in modo che funzionasse da client. I due laboratorio sono connessi in fibra ottica multimodale tramite convertitori opto-elettronici. Per consentire il funzionamento del test-bed sono state apportate delle modifiche alla configurazione dei router Juniper M10. Il traffico che proviene dal server VLC Lan non viene etichettato nel DSCP e per ovviare a questo problema nel router 1 è stata introdotta una firewall. Il sistema di gestione JUNOS offre diversi parametri con i quali filtrare il traffico entrante in una interfaccia: indirizzo di sorgente, di destinazione, il protocollo di trasporto utilizzato etc. nel caso del test-bed il parametro con il quale è stato filtrato il traffico è l indirizzo di sorgente. Tutto il traffico proveniente da un determinato indirizzo viene classificato come appartenente ad una specifica classe di servizio. La firewall è stata configurata in modo che un indirizzo appartenente agli indirizzi di tipo /24 fosse etichettato expedited forwarding, un altro assured forwarding e tutti gli altri disponibili vengono etichettati best effort. 23 Lettore multimediale Open Source e multipiattaforma per diversi formati audio e video; è anche server di streaming con possibilità di transcoding( UDP unicast e multicast, http etc.) ed è realizzato per reti a banda larga. Il sito di riferimento da cui è possibile scaricarlo è S: primo sotterraneo 163

43 family inet { filter MF { term a { from { source-address { /32; } } then forwarding-class expedited-forwarding; } term b { from { source-address { /32; } } then forwarding-class assured-forwarding; } term c { then forwarding-class best-effort; } } } Figura 6.54:Configurazione della firewall sul router 1 I pacchetti provenienti dall indirizzo indicato nel firewall vengono classificati in una CoS (Class of Service) e dunque memorizzati nella coda corrispondente, ma il campo DSCP non viene riscritto dunque la firewall anche se classifica è inutile ai fini del test-bed poiché i router sono configurati in modo da leggere il campo DSCP. Il problema è stato risolto introducendo nella configurazione del router 1 un altro campo: il rewrite rule. Mediante questa dichiarazione è possibile riscrivere il campo DSCP dei pacchetti in uscita da una interfaccia con un qualsiasi valore. Il router 1 poiché etichetta il campo DSCP perde il suo ruolo di Core Router circa l approccio DiffServ e diviene un Edge Router. Il router 2 mantiene la stessa configurazione delle prove oggettive. 164

44 6.2 PROVE SOGGETTIVE Le valutazioni soggettive della qualità del servizio sono di fondamentale importanza la buona riuscita del sistema sotto test è basata sul cliente. Quando si parla di qualità percepita è importante analizzare le prestazioni sperimentate dai pacchetti nella rete, ma è ancora più importante e necessario studiare le reazioni degli utenti in corrispondenza di queste prestazioni. L insieme delle misure, oggettive e soggettive, può offrire un valido supporto per stabilire se il sistema sotto test può garantire o meno la QoS richiesta per un particolare servizio e se può soddisfare quello che il cliente si aspetta. Le prove oggettive svolte in questo lavoro hanno riguardato la maggior parte dei servizi presenti oggi in rete, ma per le prove soggettive ci si limita a porre sotto test i servizi di tipo real-time per i quali è fondamentale lo studio della qualità percepita dall utente. Il servizi real-time sui quali è stata studiata la qualità sono: IP-TV, ovvero la trasmissione di immagini televisive e DVD su rete fissa. Per la valutazione soggettiva di un sistema che supporti questi servizi l ITU-T non ha ancora redatto nessuna Raccomandazione e, poiché il grosso dei test tratta di immagini televisive, come riferimento è stata presa la normativa ITU-R , relativa alla qualità della televisione radio trasmessa, e adattata al sistema sotto test Scelta delle immagini televisive. Il primo passo per svolgere le valutazioni soggettive consiste nella scelta accurata delle immagini che verranno proposte ai valutatori. Affinché i risultati siano significativi, come raccomandato dalla normativa , il materiale audio-video deve essere di alta qualità (ITU-R BT 601 4:2:2) e contenere scene critiche Per scene critiche si intende una serie di immagini scelte in modo da portare il sistema ai limiti del corretto funzionamento percepibile dall utente; ad esempio scene molto movimentate, veloci cambi di scene, contrasti forti possono stressare il sistema e generare dei fastidiosi effetti mosaico o addirittura rendere la visione inaccettabile. 165

45 per il sistema sotto test. Circa la qualità del segnale trasmesso dal server si è ritenuto opportuno utilizzare immagini compresse in formato MPEG-2 codificate a 8 Mbit/s. Tra il del materiale audio video disponibile è stato scelto: un DVD per le prove Wi-Fi 26, in particolare il film Pearl Harbor per la completezza della casistica delle immagini contenute, e tra le immagini televisive possibili quelli riguardanti la scelta è ricaduta sullo sport e su video musicali. Lo sport è stato privilegiato poiché le immagini sono molto dinamiche e dunque caratterizzate da contenuti informativi variabili con picchi molto elevati, i video clip sono stati considerati perché oltre ad impegnare il sistema dal punto di vista delle immagini lo testano sotto il profilo audio. Di seguito si riporta un elenco delle sequenze scelte, quattro di sport ed un video clip per le prove su cavo, una scena piuttosto lunga per le prove wireless. Cavo LAN: Gara di automobilismo Partita di tennis Nuoto sincronizzato Ciclismo Musica (video musicale) Access Point: DVD (sequenza dal film Pearl Harbor) Le immagini del nuoto sincronizzato hanno una criticità medio-bassa in quanto la presenza di una grossa porzione di piscina che fa da sfondo ai movimenti da luogo ad un bit rate piuttosto costante e non elevatissimo, quindi meno deteriorabile dai disturbi della rete, lo stesso può dirsi per il tennis dove lo sfondo è pressoché costante, il campo, ma a differenza del nuoto il movimento degli atleti quando colpiscono la pallina è rapidissimo, quindi durante il gioco il throughput subisce dei picchi violenti e non prevedibili. Il tennis offre le immagini ideali per vedere la reazione del sistema a burst di traffico elevati. 26 Sono state fatte anche delle misure in cui la connessione non avveniva via cavo ma tramite un access point, di queste si parlerà nel seguito del capitolo. 166

46 La gara di automobilismo è stata scelta perché in questo caso l immagine centrale cambia con una velocità molto minore dello sfondo, il quale varia rapidamente con lo spostarsi delle automobili. Questo contesto stressa molto il sistema in quanto i quadri sono in continuo mutamento e quindi è da considerarsi ad alta criticità. In ultima analisi sono state selezionate scene tratte dal ciclismo, in particolare da una tappa alpina del giro d Italia. La scelta è stata fatta per tre motivi particolari: il primo è che ci sono inquadrature dall alto con sfondi colorati ed è interessante considerare come viene valutato l effetto mosaico su immagini a bassissimo contrasto, il secondo per la variètà delle inquadrature quindi la possibilità di studiare come varia la percezione di uno stesso degrado al variare dello zoom dell immagine, il terzo consiste nel fatto che parte delle immagini sono riprese in pieno giorno con molto sole e la percezione dell utente è molto più sensibile al degrado offerto dalla rete. Il ciclismo per tutti questi motivi è da considerarsi di criticità medio alta. Per quanto concerne le misure svolte utilizzando l access point la sequenza scelta è molto lunga e contempla tutte le casistiche di criticità che si trovano immerse nei filmati scelti sopra. La prova è lunga perché i tempi di ripercussione del degrado della rete sull utente finale sono diversi rispetto ai tempi sperimentati con i collegamenti via cavo di rete. Di seguito si riportano dei fotogrammi estratti dalle varie sequenze scelte. 167