TEST BED PER LA VALUTAZIONE DELLA QUALITÀ DEL

Transcript

__________________________________________________________________
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 0.357. Le tre porte costituenti lo switch sono indicate nello schema
con le lettere A, B e C.
B
A
C
Porta di controllo
Figura 0.357 : 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
__________________________________________________________________
Tensione del
segnale di
controllo
≤3V
≤ 4,5 V ≥3V
≥ 4,5V
comportamento
Il disposito opera nel primo
Il segnale ottico transita tra
stato.
AeB
Il dispositivo non cambia stato Il percorso ottico non
cambia
Il dispositvo opera nel
Il segnale ottico transita tra
secondo stato.
AeC
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.
4.3.2 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
__________________________________________________________________
(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.
4.3.2.1 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 0.368 : 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
__________________________________________________________________
♦
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, 18-25 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 0x378.
125
__________________________________________________________________
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 0.379. 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 0.379 : Schema circuitale dell'amplificatore di corrente implementato
126
__________________________________________________________________
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
__________________________________________________________________
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
__________________________________________________________________
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%
Conversational
voice and video
0%
Zero
loss
100 msec
Command
/ control
(eg Telnet,
Interactive
games)
Voice/video
messaging
1 sec
Streaming
audio/video
10 sec
Transactions
(eg E-commerce,
Web-browsing, Email access)
Messaging,
Downloads
(eg FTP,
still image)
Delay
Fax
100 sec
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
__________________________________________________________________
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 throughput14 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
__________________________________________________________________
Netmeeting (protocollo RTP) dalla macchina di indirizzo 192.168.6.28 alla
macchina di indirizzo 192.168.7.11 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 (6.28Æ7.11) script Netmeeting 10Mbps)
Throughtput (Mbps)
One way delay (ms) Loss Data (%) Jitter (ms)
9,86
2
0
10
9,83
1
0,001
10
9,84
1
0,001
11
9,9
1
0
7
Di cui si mostra il grafico dei valor medi:
Valori Medi
10
9
8
7
6
Valori Medi
5
4
3
2
1
0
Valori Medi
Throughtput (Mbps)
One way delay (ms)
Loss Data (%)
Jitter (ms)
9,8575
1,25
0,0005
9,5
131
__________________________________________________________________
Prova 2 (7.11Æ6.28) 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,001
3
9,96
1
0
3
9,84
1
0,01
11
9,97
1
0
3
Di cui si graficano dei valori medi:
10Mbps 7.11--->6.28
10
9
8
7
6
5
Valori Medi 7.11--->6.28
4
3
2
1
0
Valori Medi 7.11--->6.28
Throughtput(Mbps)
One way Delay (ms)
Loss Data (%)
Jitter (ms)
9,9275
1
0,00275
5
Questo tipo di prova veniva ripetuto per valori di throughput sempre maggiori, su
più macchine al variare delle schede di rete.
132
__________________________________________________________________
5.2 CONFIGURAZIONE DEI ROUTER
5.2.1 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 EF15 è stato generato dal server Chariot ed in queste condizione è stato
valutato il comportamento di due diversi Drop Profile16 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 [ 0 10 15 20 25 30 ];
drop-probability [ 0 20 50 75 100 ];
}
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
Letteralmente “profilo di scarto” detta il comportamento che deve avere il router quando si
carica una cosa in termini di scarto dei pacchetti.
16
133
__________________________________________________________________
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:
1
2
3
4
5
6
7
8
9
10
PERDITE (%)
0,12
0,06
0,04
0,004
0,04
0,009
0,058
0,03
0,005
0,1
JITTER MAX (ms)
11
10
11
11
11
10
10
10
12
11
ONE-WAY DELAY MAX (ms)
2
1
1
1
1
1
1
1
1
2
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 BE17 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:
1
2
3
4
5
6
7
8
9
10
PERDITE (%)
0,068
0,023
0,009
0,048
0,009
0,94
0,121
0,004
0,112
0,066
JITTER MAX (ms)
11
11
9
10
11
16
9
11
12
11
5
4
3
3
3
5
5
3
4
3
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
__________________________________________________________________
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:
1
2
3
4
5
6
7
8
9
10
PERDITE (%)
EF
BE
0,01
24,8
0,05
25
0,065
24,9
0,004
24,8
0,035
25,1
0,1
24,9
0,006
24,8
0,11
24,7
0,07
24,8
0,08
24,8
JITTER MAX (ms)
EF
BE
11
9
11
15
11
15
10
13
10
17
13
12
10
18
13
24
11
25
11
16
EF
BE
4
50
4
50
3
50
4
50
4
50
4
50
4
50
5
50
4
50
3
49
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:
admin@lab1#
interpolate {
fill-level [ 0 50 75 100 ];
drop-probability [ 0 1 50 100 ];
}
Figura 5.7: Configurazione drop_profile_2 della coda Exedited Forwarding
135
__________________________________________________________________
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.
1
2
3
4
5
6
7
8
9
10
PERDITE (%)
0,042
0,005
0,007
0,004
0,06
0,044
0,066
0,007
0,025
0,09
JITTER MAX (ms)
11
10
11
11
12
11
13
11
9
13
4
3
4
3
3
3
4
4
4
4
Figura 5.8: 5 flussi Netmeeting EF su rete scarica con drop_profile_2
1
2
3
4
5
6
7
8
9
10
PERDITE (%)
0,05
0,004
0,0023
0,008
0,11
0,037
0,076
0,027
0,1
0,02
JITTER MAX (ms)
11
10
12
10
12
13
12
10
20
12
3
3
3
3
5
4
4
3
5
3
Figura 5.9: 5 flussi Netmeeting EF su rete carica con traffico BE con drop_profile_2
136
__________________________________________________________________
1
2
3
4
5
6
7
8
9
10
PERDITE (%)
EF
BE
0,06
24,9
0,07
25
0,05
24,8
0,07
24,9
0,08
24,7
0,15
25
0,005
24,7
0,07
24,9
0,19
24,8
0,02
24,7
JITTER MAX (ms)
EF
BE
11
15
10
18
10
13
11
17
12
21
11
24
10
21
11
16
11
18
11
16
EF
BE
4
50
3
50
3
49
4
50
4
50
4
49
3
50
4
50
5
51
4
50
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
__________________________________________________________________
one way delay max in ms
ONE WAY DELAY MAX
60
50
40
traffico con drop
profile_2
30
traffico con drop
profile_1
20
10
0
1
2
3
4
5
6
7
8
9
10
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
__________________________________________________________________
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.
5.2.2 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 AF18 riportate di seguito:
admin@lab1#
assured-forwarding {
interpolate {
fill-level [ 0 10 25 30 40 50 ];
drop-probability [ 0 1 25 60 80 100 ];
}
Figura 5.12: Configurazione del drop profile 3 della coda Assured Forwarding
18
Assured Forwarding
139
__________________________________________________________________
admin@lab1#
interpolate {
fill-level [ 0 10 20 30 40 50 60 70 80 100 ];
drop-probability [ 0 1 2 3 5 20 40 80 100 ];
}
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 rate19
ed il buffer size20 dello scheduler map21 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
__________________________________________________________________
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.
1
2
3
4
5
6
7
8
9
10
PERDITE (%)
EF
AF
0,05
0,08
0,14
0,11
0,072
0,064
0,056
0,022
0,13
0,1
0,08
0,1
0,08
0,08
0,06
0,02
0,075
0,07
0,071
0,094
JITTER MAX (ms)
EF
AF
10
10
11
10
11
10
10
9
11
10
11
11
11
12
10
10
10
10
10
11
EF
AF
6
8
6
9
7
9
7
10
7
10
8
11
8
11
8
11
9
11
10
12
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
__________________________________________________________________
percentuale pacchetti persi
LOST DATA
0,16
0,14
0,12
0,1
traffico EF
0,08
0,06
0,04
traffico AF
0,02
0
1
2
3
4
5
6
7
8
9
10
valori di jitter max in msec
JITTER MAX
14
12
10
8
traffico EF
6
traffico AF
4
2
0
1
2
3
4
5
6
7
8
9
10
ONE WAY DELAY M AX
one way delay in msec
14
12
10
8
traffico EF
6
traffico AF
4
2
0
1
2
3
4
5
6
7
8
9
10
Figura 5. 15: Tabella e grafici della sessione di misure eseguita sul traffico AF
142
__________________________________________________________________
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.
TRANSMISSION
RATE
8%
9%
78%
5%
TRAFFICO
EF
AF
BE
NC22
BUFFER SIZE
Figura 5.39: Seconda configurazione dello Scheduler
22
NC non classificato
143
7%
9%
79%
5%
__________________________________________________________________
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.
1
2
3
4
5
6
7
8
9
10
PERDITE (%)
EF
AF
0,12
5,4
0,1
5,3
0,012
5,28
0,081
5,11
0,1
5,64
0,016
5,2
0,013
5,36
0,06
5,54
0,007
5,31
0,14
5,34
JITTER MAX (ms)
EF
AF
11
11
11
12
11
11
11
11
10
10
11
12
10
11
10
11
10
10
17
9
144
EF
AF
5
28
5
29
6
29
6
29
7
29
7
30
8
31
7
31
8
31
9
32
__________________________________________________________________
LOST DATA
6
5
4
traffico EF
3
traffico AF
2
1
0
1
2
3
4
5
6
7
8
9
10
JITTER MAX
18
16
14
12
10
8
6
4
2
0
traf fico EF
traf fico AF
1
2
3
4
5
6
7
8
9
10
ONE WAY DELAY M AX
35
30
25
20
traffico EF
15
traffico AF
10
5
0
1
2
3
4
5
6
7
8
9
10
Figura 5.18: Tabella e grafici della sessione di misure del traffico AF
145
__________________________________________________________________
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
EF
AF
BE
NC
TRANSMISSION
RATE
8%
10%
78%
5%
BUFFER SIZE
7%
8%
80%
5%
Figura 5.20: Configurazione definitiva dello Scheduler
146
__________________________________________________________________
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.
1
2
3
4
5
6
7
8
9
10
PERDITE (%)
EF
AF
0,13
1,43
0,04
1,48
0,14
1,49
0,066
1,51
0,005
1,43
0,025
1,49
0,134
1,496
0,004
1,452
0,077
1,448
0,012
1,452
ONE-WAY DELAY MAX
JITTER MAX (ms) (ms)
EF
AF
EF
AF
11
11
3
36
10
10
3
36
11
9
3
33
9
10
3
36
10
10
4
36
10
10
3
38
12
10
3
36
8
10
3
35
10
10
3
36
10
10
3
36
147
__________________________________________________________________
LOST DATA
1,6
1,4
1,2
1
traffico EF
0,8
0,6
0,4
traffico AF
0,2
0
1
2
3
4
5
6
7
8
9
10
JITTER MAX
14
12
10
8
traf fico EF
6
traf fico AF
4
2
0
1
2
3
4
5
6
7
8
9
10
ONE WAY DELAY M AX
40
35
30
25
traffico EF
20
15
traffico AF
10
5
0
1
2
3
4
5
6
7
8
9
10
Figura 5.41: Tabella e grafici sessione misure traffico AF
148
__________________________________________________________________
Figura 5.22: Confronto tra il througput del traffico EF e del traffico AF
5.2.3 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
__________________________________________________________________
5.3 TEST SUI SERVIZI
5.3.1 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
__________________________________________________________________
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
__________________________________________________________________
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
__________________________________________________________________
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
__________________________________________________________________
Figura 5. 458: Lost Data Caso Generico
Figura 5.469: One-Way Delay Caso Generico
154
__________________________________________________________________
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
__________________________________________________________________
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
__________________________________________________________________
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.
5.3.3 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
__________________________________________________________________
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
__________________________________________________________________
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
0.037 Mbit/s e quasi impercettibile sul grafico.
5.3.4 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
__________________________________________________________________
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
__________________________________________________________________
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
__________________________________________________________________
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
CLIENT
VLC LAN
Link di collegamento FastEthernet
SERVER CHARIOT
HUB
conv e/o
Laboratorio valutazione della QoS multimediale – Ufficio IV ISCOM
1,25 GBE
ANELLO OTTICO
ROMA-POMEZIA
Fibra ottica mmf
Fibra ottica smf
1550
Laboratorio trasmissivo reti ottiche
-ISCOM-
conv e/o
fe
fe
1,25 GBE
1,25 GBE
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
__________________________________________________________________
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 Lan23. VLC è stato installato su un PC del laboratorio di reti
ottiche dinamiche del piano 1S24 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 192.168.6.0/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 è
www.videolan.org
24
1S: primo sotterraneo
163
__________________________________________________________________
family inet {
filter MF {
term a {
from {
source-address {
192.168.6.20/32;
}
}
then forwarding-class
expedited-forwarding;
}
term b {
from {
source-address {
192.168.6.22/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
__________________________________________________________________
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 550-11,
relativa alla qualità della televisione radio trasmessa, e adattata al sistema sotto
test.
6.2.1 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 500-11, il materiale audio-video
deve essere di alta qualità (ITU-R BT 601 4:2:2) e contenere “scene critiche”25
25
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
__________________________________________________________________
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-Fi26, 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
__________________________________________________________________
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
__________________________________________________________________
Figura 6.55: fotogramma tratto dalla sequenza di automobilismo.
Figura 6.56: fotogramma tratto dalla sequenza tennis.
168
__________________________________________________________________
Figura 6.57: fotogramma tratto dalla sequenza nuoto sincronizzato.
Figura 6.58: fotogramma tratto dalla sequenza ciclismo.
169
__________________________________________________________________
Figura 6.59: fotogramma tratto dalla sequenza musica
Figura 6.60: fotogramma tratto dal film Pearl Harbor
170
__________________________________________________________________
6.2.2 Registrazione delle sequenze
Per avere il controllo assoluto del segnale sorgente la Raccomandazione 550-11
consiglia la registrazione delle sequenze su memorie digitali.
La prima fase ha previsto la registrazione direttamente dal segnale satellitare delle
sequenze di musica, ciclismo, nuoto sincronizzato, automobilismo e tennis in
formato MPEG-2, e l’estrazione della sequenza Pearl Harbor da supporto DVD
ancora codificato in MPEG-2 con rate fisso di 8 Mbit/s. I sei file audio-video
MPEG ottenuti sono stati divisi in due file complessivi: il primo della durata di tre
minuti contenente la sequenza tratta dal film, il secondo della durata di due minuti
e mezzo poiché somma delle cinque sequenze tratte da satellite ognuna della
durata di 30 secondi.
Una volta preparato il materiale di test è stato configurato il generatore di traffico
per la saturazione della rete.
Il traffico sotto test di queste prove, 8 Mbit/s per ogni classe di servizio, è minore
di quello utilizzato nelle misure oggettive e dunque si è reso
necessario
aumentare il traffico di saturazione per stressare la rete; in particolare è stato
aumentato il traffico EF ed AF generato dall’MD1230A in modo che il traffico
complessivo presente nella rete potesse essere lo stesso delle prove oggettive.
Fissate le condizioni di saturazione della rete il file MPEG presente nel CD di
back up è stato trasmesso, su protocollo RTP, tramite il programma VLC LAN dal
laboratorio delle reti ottiche dinamiche del piano 1S al laboratorio per la
valutazione della qualità del servizio multimediale del sesto piano attraverso
l’anello ottico Roma-Pomezia.
Nel laboratorio della QoS la parte video dello streaming viene registrata frame per
frame in formato yuv8 non compresso, YUV 4:4:4, su hard disk ad alta capacità,
mentre la parte audio viene acquisita in formato wave su un secondo PC.
Il segnale video viene inizialmente codificato in formato RGB; tramite un
semplice algoritmo si passa dalle componenti Red Green Blue alle componenti
Y-luminanza e U,V-crominanza, attraverso le quali è possibile effettuare la
compressione video. Il formato YUV 4.4:4 non introduce perdite di informazione
rispetto
al formato RGB in quanto per ogni pixel vengono considerate le
171
__________________________________________________________________
componenti Y-U-V, passando ad esempio ad altri formati come YUV 4:2:2
vengono perse informazioni sulla crominanza alla quale l’occhio umano risulta
essere poco sensibile.
Le operazioni di registrazione nel laboratorio della QoS multimediale vengono
svolte una volta per ogni classe di servizio ad eccezione della classe Assured
Forwarding per la quale vengono svolte due registrazioni corrispondenti a due
diversi valori del traffico di saturazione. I file audio e video ottenuti sono
rappresentativi del comportamento della rete riguardo ad ogni classe di servizio,
dai file vengono poi separate di nuovo le singole sequenze da 30 secondi per la
preparazione delle prove soggettive.
Poiché ogni sequenza è stata registrata frame per frame in formato abekas27 per
renderle tutte visibili all’utente portandole in formato avi 28 sono necessarie delle
conversioni intermedie operate da riga di comando. Nel caso delle prove
soggettive si lavora in DOS poiché le macchine a disposizione hanno sistema
operativo Windows XP.
Di seguito vengono riportati i passaggi per la creazione dei file avi.:
1. Si crea un file unico yuv per ogni sequenza concatenando i frame
2. I file ottenuti dal punto 1 in formato yuv 4:4:4 vengono convertiti in
formato 4:2:2
3. Dal formato 4:2:2 si passa al 4:2:0 utilizzato per le codifiche MPEG-1,
MPEG-2, MPEG-4 ed AVI.
4. Dal formato 4:2:0 si crea un file avi per ogni sequenza.
5. Tramite il software multimediale ULEAD si sincronizzano i file video avi
con i rispettivi file audio wave e si memorizza tutto in un unico file avi.
Dopo queste operazioni, per ogni classe di servizio, si hanno a disposizione 5
sequenze da 30 secondi e 1 da 3 minuti per un totale di 22 minuti di prove
valutabili. Prima di procedere alle prove soggettive è stata operata una nuova
cernita delle sequenze da sottoporre ai valutatori, infatti tutte le sequenze che
passano nella rete etichettate Best Effort dalla firewall risultano indecifrabili ed è
27
28
Formato yuv8.
Formato non compresso.
172
__________________________________________________________________
dunque di poco interesse procedere ad una valutazione. La scelta operata è stata
quella di eliminare tutte le sequenze della classe di servizio BE ottenendo come
vantaggio collaterale quello di tenere i valutatori impegnati per un tempo minore.
Per il ricevuto dal client VLC tramite l’access point oltre al traffico BE è stato
sottratto alla valutazione anche il traffico Assured Forwarding di tipo medium
quality poiché è risultato altrettanto indecifrabile e dunque di poco interesse per la
valutazione.
Figura 6.61: Laboratorio di registrazione sequenze.
173
__________________________________________________________________
6.2.3 Scelta del metodo di valutazione e preparazione della
camera afonica
I metodi descritti nella Raccomandazione BT 500-11 adatti a questo tipo di prove
sono:
Nel
•
SDSCE ( Double Stimulus for Continuos Evaluation)
•
SSCQE ( Single Stimulus for Continuos Quality Evaluation)
metodo
SDSCE
agli
osservatori
vengono
presentati
due
stimoli
contemporaneamente, uno di riferimento ad alta qualità ed un altro degradato dal
sistema sotto test, ad esempio per compressione del filmato, e viene valutata la
differenza di qualità fra i due stimoli. Nel metodo SSCQE agli osservatori viene
proposto un solo stimolo alla volta cioè sequenze di qualità variabile che sono
chiamati a valutare senza aver alcun riferimento.
Nel caso di queste prove il compito degli osservatori è stato quello di valutare la
presenza o meno di disturbi, blocco immagini e pacchettizzazione non la qualità
assoluta delle immagini; per questi test è stato ritenuto più idoneo il metodo
SSCQE.
Per questo metodo è prevista la partecipazione di almeno 15 valutatori, non
esperti di queste attività, di età compresa tra i 18 ed i 35 anni.
Effettuata la scelta del metodo si è proceduto all’allestimento della camera silente.
Figura 6.62: Camera afonica
174
__________________________________________________________________
Per le valutazioni SSCQE il laboratorio per la valutazione della QoS multimediale
ha a disposizione il sistema software/hardware IQ++. La parte hardware è
composta da un dispositivo a cui vengono collegati, tramite cavo di rete, i
potenziometri , sliders, dotati di una scala a 5 livelli; il segnale proveniente dai
potenziometri viene campionato ogni 0,5 secondi ed alla posizione del cursore
viene associato un valore tra 0 e 255 rispettivamente cattiva qualità e qualità
eccellente. Durante i primi 5 secondi di ogni sequenza il software IQ++ non
registra alcun voto, poiché si suppone che questo lasso di tempo costituisca una
fase di training per i valutatori.
Seguendo la normativa BT 500-11 sono state disposte quattro postazioni
all’interno della camera silente in modo che la loro distanza fosse pari a 4 volte
l’altezza dello schermo e l’angolo di visuale maggiore di 30° rispetto al centro
dello schermo stesso.
6.3 LA SESSIONE DI TEST
6.3.1 Preparazione delle sequenze
Affinché venga rispettata la Raccomandazione 500-11 è stato preparato uno script
in formato .txt in cui le sequenze sono ordinate in modo casuale. Nello
svolgimento delle prove sono stati impiegati due PC diversi, uno per la gestione
del sistema e l’altro per la gestione del proiettore nella camera afonica. Il software
IQ++ memorizza le votazioni secondo un ordine fisso delle sequenze presentate e
dunque lo stesso ordine deve essere rispettato durante la proiezione affinché i
risultati siano validi.
Gli osservatori prima dall’inizio delle prove hanno compilato una liberatoria per
la tutela della privacy e si sono sottoposti ad un esame visivo di idoneità.
175
__________________________________________________________________
Figura 6.63: Scheda sottoposta ai valutatori
Prima del test la Raccomandazione BT 500-11 consiglia un addestramento
preliminare dei valutatori. In questa fase un esperto del laboratorio per la
valutazione della QoS multimediale spiega agli osservatori seduti nella camera
silente cosa vedranno durante il test, cosa saranno chiamati a valutare ed in che
modo dovranno usare il cursore messo loro a disposizione per le valutazioni.
176
__________________________________________________________________
Figura 6.64: l’esperto spiga come usare il cursore
Figura 6.65: Fase di training dei valutatori.
177
__________________________________________________________________
6.3.2 Fase di elaborazione dei dati.
Per ognuna delle due sessioni (prove via cavo e prove Wi-Fi) e per ogni valutatore
il software IQ++ ha creato un file contenente i voti relativi al test, cioè il software
ha raccolto i voti su tutti i 7,5 minuti delle prove via cavo della prima sessione e
sui 6 minuti della prova Wi-Fi.
Il sistema come descritto al paragrafo precedente registra la posizione del cursore
ogni 0,5 secondi creando un vettore dei voti molto esteso, per questo motivo, per
l’elaborazione dei risultati è stato impiegato il software MATLAB.
La prima sessione di 7,5 minuti comprende le 15 sequenze totali da trenta secondi
ognuna da valutare; in particolare ogni sequenza originale è stata trasmessa tre
volte, una per ogni classe di servizio, ed è per questo che dalle cinque sequenze
originali alla fine se ne estraggono 15. Lo stesso procedimento è applicato per le
prove Wi-Fi, sessione 2,a partire dalla sequenza originale di 3 minuti se ne sono
ottenute tre per un totale di nove minuti, come già osservato alla fine i valutatori
sono stati chiamati a valutare solo sei minuti di filmato su nove corrispondenti a
due sole classi di servizio.
Le 15 sequenze via cavo da valutare vengono mescolate in ordine casuale in modo
che non si ripetano di seguito le stesse sequenze seppure appartenenti a classi di
servizio diverse.
Lo stesso è stato fatto per il Wi-Fi, anche se in questo caso non è stato necessario
generare un ordinamento casuale delle sequenze poiché quelle sottoposte a
valutazione erano soltanto due.
Di seguito si riportano dei fotogrammi di stesse sequenze tratte dalle tre differenti
classi di servizio sotto test con lo scopo di rendere visibile il deterioramento che
sperimentano le stesse sequenze quando trattate con classi di servizio differenti.
.
178
__________________________________________________________________
Figura 6.66: Fotogrammi presi dalle sequenza AUTOMOBILISMO oggetto di valutazione
nelle classi di servizio: EF la prima dall’alto AF high la seconda ed AF medium l’ultima.
179
__________________________________________________________________
Figura 6.67: Fotogrammi presi dalle sequenza TENNIS oggetto di valutazione nelle classi di
servizio: EF la prima dall’alto AF high la seconda ed AF medium l’ultima.
180
__________________________________________________________________
Figura 6.68: Fotogrammi presi dalle sequenza NUOTO SINCRONIZZATO oggetto di
valutazione nelle classi di servizio: EF la prima dall’alto AF high la seconda ed AF medium
l’ultima.
181
__________________________________________________________________
Figura 6.69: Fotogrammi presi dalle sequenza CICLISMO oggetto di valutazione nelle classi
di servizio: EF la prima dall’alto AF high la seconda ed AF medium l’ultima.
182
__________________________________________________________________
Figura 6.70: Fotogrammi presi dalle sequenza tratta dal film Pearl Harbor oggetto di
valutazione nelle classi di servizio: EF la prima dall’alto AF high la seconda.
183
__________________________________________________________________
Per procedere allo studio dei parametri di rete in corrispondenza degli andamenti
dei voti dei valutatori si è utilizzato una “sniffer”29 di rete, in particolare è stato
fatto uso del programma ETHEREAL, lanciandolo sul PC sorgente e su quello
destinazione e salvando i dati per poi studiarli in un secondo momento. Per
“allineare” i pacchetti si è proceduto in questa maniera: in primo luogo tramite il
comando net time di DOS si è provveduto a sincronizzare gli orologi dei due PC,
in modo tale che, tramite una funzione di ETHEREAL che permette di marcare i
pacchetti al tempo corrente si avesse la medesima scala temporale di riferimento;
in secondo luogo per riconoscere che sia in trasmissione sia in ricezione si
trattasse dello stesso pacchetto si è passati all’analisi del campo del pacchetti IP
Identification
registrato dal programma nell’area INTERNET PROTOCOL.
Tramite ACCESS sono stati estrapolati tutti questi dati dal file di ETHEREAL
esportato in formato testo e messi per colonne; a questo punto il ritardo è stato
ottenuto per differenza dei tempi dei relativi pacchetti, il jitter è stato direttamente
fornito,così come il throughput.
Di seguito si riportano per via grafica i dati ottenuti dallo studio delle singole
sequenze per ogni singola classe di servizio.
I grafici vengono riportati in questa maniera: per ogni sequenza si riportano gli
andamenti dei valutatori, il throughtput ed il jitter per tutte e tre le classi di
servizio. Le sequenze hanno durata 30 secondi, ma il programma di elaborazione
delle valutazione non prende in considerazione l’intera sequenza temporale, ma
scarta i primi cinque secondi e gli ultimi due per motivi di training.
Per questa ragione i grafici che seguono relativamente all’andamento nel tempo
delle valutazioni hanno scala delle ascisse che va da 5 a 28 mentre quelli del
throughput e del jitter rappresentano anche loro un intervallo in ascisse di 23
secondi ma conservano il tempo originale della sequenza all’interno del file unico
(“provacavo “)
dal quale sono state registrate. In ordinate i grafici delle
valutazioni hanno valori da 0 a 255. Nei grafici comparati verranno poi
normalizzati da 0 a 100.
29
Sniffer: dispositivo hardware o programma software in grado di catturare ed immagazzinare
tutto il traffico indirizzato alla propria scheda di rete. Questa procedura detta sniffing può essere
adoperata anche in modo promiscuo sulla LAN, in questo modo si memorizza tutto il traffico
della sottorete che la propria scheda può ascoltare e che non è necessariamente indirizzato al
proprio MAC.
184
__________________________________________________________________
6.4 RISULTATI OTTENUTI
Per una analisi sistematica del gran numero di grafici ottenuti dallo svolgimento
delle prove di valutazione della qualità percepita si procede come segue:
prima si fa uno studio globale delle sequenze valutate cercando delle correlazioni
con i parametri percepiti, la stessa cosa si fa con le sequenze Wi-Fi.
Fatta una analisi globale si scende nel dettaglio di ogni singola sequenza
approfondendone lo studio.
6.4.1 Analisi globale delle sequenze via cavo.
Lo studio della qualità percepita mediamente non ha disilluso quanto ci aspettava
dopo lo svolgimento delle prove soggettive. Quello che appare evidente infatti è
che le tra classi di servizio vengano valutate in maniera differente e l’andamento
dei giudizi
rispecchia la differenza della priorità. Nella figura che segue si
riportano gli andamenti globali dei giudizi forniti dai valutatori sulle cinque
sequenze “via cavo”.
ANDAMENTO COMPLESSIVO DIVISO PER SEQUENZE
100
90
80
70
VOTAZIONI
60
50
40
30
20
Expedited
Assured HQ
10
Assured MQ
0
0,0
20,0
40,0
60,0
80,0
100,0
120,0
140,0
TEMPO [s]
Figura 6.71: Andamento delle valtazioni si tutte le sequenze.
Nella figura appaiono delle aree separate, queste rappresentano le cinque sequenze
diverse che in seguito verranno studiate nel dettaglio. La separazione delle aree
185
__________________________________________________________________
avviene ad opera del software di acquisizione dei voti che sulle sequenze della
durata di 30 secondi scarta i primi cinque e gli ultimi due sfruttando come dati di
training i campioni contenuti in quasti secondi. Ciò che si deduce dal grafico è che
la classe di servizio Assured Forwarding High Quality si comporta mediamente
molto bene, con una media di 90/100 si tutti i tipi di sequenze disponibili. La
classe
Expedited Forwarding risulta ottima, l’andamento della valutazione è
mediamente 100/100, in pratica non degrada le immagini originali. La classe
Assured Forwarding Medium Quality rappresenta l’Assured Forwarding in
condizione di rete molto congestionata e sperimenta da parte dei valutatori una
votazione media di 65/100.
DISTRIBUZIONE DEI VOTI
1,0000
0,9000
Expedited
0,8000
Assured HQ
Assured MQ
0,7000
0,6000
0,5000
0,4000
0,3000
0,2000
0,1000
0,0000
0
10
20
30
40
50
60
70
80
90
100
VOTAZIONI
Figura 6.72: Distribuzione normalizzata dell’andamento delle votazioni.
Passando all’analisi dei parametri oggettivi che hanno caratterizzato le sequenze
giudicate dai valutatori in primo luogo si deve far riferimento al throughput.
Di seguito viene riportato un grafico che mostra l’andamento del throughput delle
tre differenti classi di servizio per tutte le sequenze.
186
__________________________________________________________________
CONFRONTO DEI THROUGHPUT
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
10000000
9500000
Mbps
9000000
8500000
8000000
7500000
7000000
0
20
40
60
80
100
120
140
TEMPI [s]
Figura 6.73: Grafico dell’ andamento dei Throughput nelle tre diverse classi di servizio EF, AF
HQ, AF MQ
Come ci si aspettava i valori medi della classe EF e della classe AF HQ sono
molto simili e si discostano di poco, ciò e dovuto al fatto che il traffico AF HQ è
stato inviato su rete mediamente congestionata dunque in una situazione da
considerarsi non al limite e per questo il throughput non deteriora; per quanto
concerne l’AF MQ invece è questi stato inviato su una rete molto congestionata
ed è evidente dal grafico come il througput sia più basso dei primi due
mediamente di 1 Mbit/s.
DISTRIBUZIONE DEL THROUGHPUT
100
90
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
80
70
60
50
40
30
20
10
0
0
2000000
4000000
6000000
8000000
10000000
12000000
Figura 6.74: Distruinuzione normalizzata del throughput nelle tre diverse classi di servizio EF,
AF HQ ed AF MQ.
187
__________________________________________________________________
Si può dedurre anche per ispezione visiva del grafico che le perdite della classe di
servizio Assured Forwardin Medium Quality superano di gran lunga l’1 %
imposto dalla normativa ITU-T G 1010 questa violazione è stata accettata proprio
per investigare come degradasse la qualità percepita e capire un po’ meglio se poi
è proprio necessario avere dei parametri di rete ed end-user così stringenti o se è
lecito rilassare alcuni vincoli.
Altro parametro preso in considerazione è stato il jitter, ma dallo studio di questo
non si è giunti a considerazioni diverse d quelle fatte per il throughput; la cosa da
osservare è che è bassissimo per tutte e tre le classi di sevizio anche se differente.
CONFRONTO JITTER
0,005
0,0045
Expedited
0,004
Ass_hq_OFF_e
Ass_OFF_mq_e
SECONDI
0,0035
0,003
0,0025
0,002
0,0015
0,001
0,0005
0
0
20
40
60
80
100
120
140
TEMPO [s]
Figura 6.75: Confronto del jitter per tutte le sequenze visionate per le classi EF, AF HQ ed AF
MQ.
188
__________________________________________________________________
DISTRIBUZIONE JITTER NORMALIZZATA
100
90
80
70
60
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
50
40
30
20
10
0
0
0,002
0,004
0,006
0,008
0,01
0,012
0,014
0,016
0,018
0,02
Figura 6.76: Distribuzione del Jitter per le tre classi di servizio, le classi Ef ed AF HQ sono
praticamente sovrapposte.
Di seguito si è proceduto ad uno studio di relazione fra i voti forniti dati valutatori
ed i parametri oggettivi di cui sopra cioè throughput e jitter. Al termine si è
ritenuto opportuno creare due grafici a dispersione che mettessero in relazione: 1)
il trhoughput e l’andamento dei voti,2) il jitter e l’andamento dei voti in modo da
delimitare delle aree entro le quali confinare la qualità percepita.
GRAFICO A DISPERSIONE DEL THROUGHPUT
100,0
VOTAZIONE NORMALIZZATA
90,0
Expedited
Assured HQ
80,0
Assured MQ
70,0
60,0
50,0
40,0
30,0
20,0
10,0
0,0
7
7,5
8
8,5
9
9,5
10
Milioni
THROUGHPUT
Figura 6.77: Grafico che evidenza le aree occupate dalle tre classi di servizio in relazione con il
throughput e l’andamento dei voti.
189
__________________________________________________________________
GRAFICO A DISPERSIONE DEL JITTER
VOTAZIONE NORMALIZZATA
100,0
90,0
80,0
70,0
60,0
50,0
40,0
Expedited
Assured HQ
30,0
Assured MQ
20,0
10,0
0,0
0,001
0,0011
0,0012
0,0013
0,0014
0,0015
0,0016
0,0017
0,0018
0,0019
0,002
MILLISECONDI
Figura 6.78: Grafico che evidenza le aree occupate dalle tre classi di servizio in relazione con il
jitter e l’andamento dei voti.
Ciò che emerge da questo studio comparato dei valori forniti dai valutatori e dai
parametri di rete sono due fatti fondamentali:
•
il primo è che il test-bed si comporta secondo le aspettative e cioè la tre
classi implementate tramite l’approccio DiffServ raccolgono dei giudizi
proporzionali alla loro importanza.
•
Il secondo è che i valutatori hanno ritenuto buono anche il traffico AF HQ
che ha un costo di gestione molto minore dell’EF e che per rete
mediamente congestiona, come nel nostro caso e del resto come nel caso
della rete nazionale, ha un decadimento delle prestazioni meno che lineare
col costo di implementazione.
6.5 ANALISI DELLE SEQUENZE “VIA CAVO”
In questo paragrafo si procede ad una accurata analisi di ogni singola sequenza per
capire come le varie tipologie di immagine reagiscano al degrado della rete e
soprattutto come vengano percepite dall’utente finale.
190
__________________________________________________________________
6.5.1 Automobilismo
La prima sequenza ad essere analizzata è l’automobilismo; questa tipologia di
immagini è stata giudicata come molto critica per la rete in quanto è costituita da
soggetti relativamente fermi all’interno dell’inquadratura (le automobili) e da
sfondi continuamente in movimento che richiedono molti bit di informazione.
Ciò che è vero per la rete, tipologia di immagine critica, non lo è per il valutatore.
Chi giudica infatti focalizza la propria attenzione sul soggetto e non sullo sfondo,
percependo poco eventuali effetti mosaico che si presentano al contorno
dell’inquadratura.
Nelle figura che segue è riportato il grafico dell’andamento delle valutazioni della
sequenza automobilismo per le tre tipologie di qualità del servizio.
Figura 6.79: Andamento delle valutazioni della sequenza AUTOMOBILISMO la linea rossa è
la classe EF, la blu la classe AF HQ e la fucsia la classe AF MQ.
191
__________________________________________________________________
Dall’andamento delle valutazioni è abbastanza chiaro che le tre classi di servizio
proposto siano state percepite in modo diverso; l’EF va sempre bene tranne due
piccoli picchi imputabili a dei cambi di scena animati che molto probabilmente i
valutatori avevano cominciato a percepire come errore.
La classe AF HQ varia tra l’80% ed il 100%, le votazioni basse corrispondono
alle inquadrature dall’alto dove le macchine perdevano la loro centralità
all’interno dell’inquadratura ed il contorno risultava più visibile.
L’ AF MQ ricalca grossomodo lo stesso andamento dell’AF HQ solo che i difetti
delle immagini sono stati percepiti in maniera maggiore.
La differenza dell’andamento delle valutazioni tra EF ed AF HQ è dovuta alla
seppure minima variazione di throughput; infatti la classe AF HQ sperimenta
delle perdite intorno al punto percentuale dovute al tipo di “drop profile “
configurato sui router. In pratica per la classe AF si ammette che dopo il 50% di
riempimento della coda corrispondente si comincino a scartare i pacchetti; se tra
questi c’è un i-frame del codec MPEG-2, questi si ripercuote in maniera pesante
sul filmato, in particolare il degrado può ripercuotersi fino all’ i-frame successivo.
192
__________________________________________________________________
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
10000000
9500000
Mbps
9000000
8500000
8000000
7500000
7000000
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
TEMPI [s]
Figura 6.80: Confronto dei throughput per la sequenza AUTOMOBILISMO
Circa il Jitter non ci sono grosse considerazioni da fare, è molto basso e costante
senza grosse fluttazioni.
CONFRONTO JITTER
0,002
0,0019
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
0,0018
SECONDI
0,0017
0,0016
0,0015
0,0014
0,0013
0,0012
0,0011
0,001
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
TEMPO [s]
Figura 6.81: Confronto dei Jitter per la sequenza AUTOMOBILISMO
193
56
57
58
__________________________________________________________________
6.5.2 Tennis
La seconda sequenza considerata è stata quella del tennis; la scelta è motivata per
caratteristiche di questo sport.
Nel tennis infatti lo sfondo è fisso e gli scambi sono molto veloci, questi danno
luogo a dei picchi di traffico molto elevati ed imprevedibili che posso degradare
con facilità nella rete.
Figura 6.82: Andamento delle valutazioni della sequenza TENNIS la linea rossa è la classe EF,
la blu la classe AF HQ e la fucsia la classe AF MQ.
Come è possibile osservare in figura la qualità percepita del traffico AF MQ
assume un andamento mediamente del 60 % e con forti oscillazioni. In pratica
quello che viene fuori dall’osservazione di questa sequenza e che ciò che non è
mediamente critico per la rete lo è per qualità percepita.
Il traffico AF MQ che rappresenta il traffico AF in condizioni di rete molto
congestionata, ci si aspetta vada meglio rispetto alla sequenza automobilismo,
quello che riscontra invece è che le perdite di pacchetto che si iscontrano durante
194
__________________________________________________________________
li scambi veloci del gioco si ripercuotono su tutta la sequenza degradando la
qualità percepita.
Circa le altre due classi dove le perdite di pacchetto sono molto imitate si
riscontrano valutazioni eccellenti (EF) e molto buone (AF HQ). Quello che
emerge dallo studio di questa sequenza è che una stesso valore di perdita dei
pacchetti ha una rilevanza maggiore rispetto ad altri tipi di immagini come ad
esempio la sequenza automobilismo.
Di seguito si riportano i grafici dei valori di throughput e jitter per le tre classi di
servizio considerate.
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
10000000
9500000
Mbps
9000000
8500000
8000000
7500000
7000000
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
TEMPI [s]
Figura 6.83: Confronto dei throughput per la sequenza TENNIS
CONFRONTO JITTER
0,002
0,0019
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
0,0018
SECONDI
0,0017
0,0016
0,0015
0,0014
0,0013
0,0012
0,0011
0,001
95
100
105
110
TEMPO [s]
Figura 6.84: Confronto dei Jitter per la sequenza TENNIS
195
115
116
117
118
__________________________________________________________________
Il throughput si presenta molto variabile per le tre classi e ciò è dovuto ai picchi di
traffico dovuti ai repentini cambi d’immagine, lo stesso vale per il jitter che in
alcuni casi risulta minore per la classe AF MQ rispetto alla classe HQ. La
mutevolezza dei valori del jitter è indice della mutevolezza dei valori del ritardo,
questo è dovuto ai buffer delle code del router ottimizzate per traffici
genericamente costanti. I picchi infatti saturano il buffer della cosa corrispondente
generando nel migliore di casi pacchetti ritardati e nel peggiore dei casi perdite.
6.5.3 Nuoto Sincronizzato
La terza sequenza analizzata è stato il nuoto sincronizzato, il nuoto è stato scelto
perché lo sfondo è costante (la piscina) ed i movimenti delle atlete non
particolarmente veloci; la sequenza è da considerarsi non critica ne per la rete ne
per i giudizi che danno i valutatori.
Figura 6.85: Andamento delle valutazioni della sequenza NUOTO SINCRONIZZATO la linea
rossa è la classe EF, la blu la classe AF HQ e la fucsia la classe AF MQ.
196
__________________________________________________________________
La parte interessante di questa immagine è la reazione che hanno i valutatori alle
increspature delle onde data la buona luminosità delle immagini, infatti in queste
condizioni anche piccoli errori vengono certamente percepiti.
Il giudizio dato dai vantatori è mediamente superiore a quello che hanno fornito
sulle sequenze già descritte; la classe EF ha un comportamento eccellente, quello
della classe AF HQ ottimo e quello della classe AF MQ molto buono.
Quello della sequenza nuoto è un tipico caso in cui al gestore converrebbe
stipulare un contratto AF col cliente per il servizio IP-TV.
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
10000000
9500000
Mbps
9000000
8500000
8000000
7500000
7000000
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
TEMPI [s]
Figura 6.86: Confronto dei throughput per la sequenza NUOTO SINCRONIZZATO
In queste condizioni di immagini i throughput sono mediamente più alti e dunque
le perdite basse; le code non saturano mai i ritardi sono costanti e di conseguenza
lo sono anche i Jitter per le tre classi di servizio.
197
__________________________________________________________________
CONFRONTO JITTER
0,002
0,0019
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
0,0018
SECONDI
0,0017
0,0016
0,0015
0,0014
0,0013
0,0012
0,0011
0,001
65
70
75
80
85
TEMPO [s]
Figura 6.87: Confronto dei Jitter per la sequenza NUOTO SINCRONIZZATO
6.5.4 Ciclismo
La sequenza sul ciclismo non è stata scelta per caratteristiche particolare ma per le
varietà delle immagini presenti nel particolare filmato. Le immagini infatti
contemplano tutte le casistiche di interesse; ci sono riprese dall’alto dei corridori
su uno sfondo boschivo dove diventa poco percepibile da parte del valutatore
l’effetto mosaico ed immagini molto luminose dove l’occhio è più sensibile ad
eventuali errori.
198
__________________________________________________________________
Figura 6.88: Andamento delle valutazioni della sequenza CICLISMO la linea rossa è la classe
EF, la blu la classe AF HQ e la fucsia la classe AF MQ.
L’ andamento delle tre tipologie di traffico è: eccellente per EF, molto buono per
AF HQ e discreto per AF MQ. Ciò che si osserva per la classe AF MQ da uno
studio comparato col throughput è che stessi valori di questo parametro
sperimentano giudizi differenti; buoni quando lo sfondo è colorato e l’iimagine è
presa dall’alto, meno buoni quando ci sono primi piani sui corridori e la
luminosità è alta. Con questa particolare sequenza si può osservare che la qualità
percepita dipende dal tipo di immagine a parità di condizioni di rete.
199
__________________________________________________________________
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
10000000
9500000
Mbps
9000000
8500000
8000000
7500000
7000000
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
TEMPI [s]
Figura 6.89: Confronto dei throughput per la sequenza CICLISMO
Per quanto concerne i valori del one way delay e lecito dire che rimango costanti
per tutta la durata della sequenza per tutte le classi di servizio. Il jitter di
conseguenza non varia.
CONFRONTO JITTER
0,002
0,0019
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
0,0018
SECONDI
0,0017
0,0016
0,0015
0,0014
0,0013
0,0012
0,0011
0,001
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
TEMPO [s]
Figura 6.90: Confronto dei Jitter per la sequenza CICLISMO
200
24
25
26
27
28
__________________________________________________________________
6.5.5 Musica
La sequenza tratta da un video clip è stata scelta con l’intento di studiare la
degradazione dell’audio, e come questo possa influire circa la qualità percepita.
Quello che si osserva è la una buona componente audio favorisce la qualità
percepita; uno stesso filmato che si sente bene ma si vede male mediamente è
giudicato meglio di un filmato che si vede bene ma si sene male. In questa
sequenza infatti i valutatori sono stati maggiormente attratti da quello che
sentivano piuttosto che da ciò che ascoltavano.
Figura 6.91: Andamento delle valutazioni della sequenza MUSICA la linea rossa è la classe EF,
la blu la classe AF HQ e la fucsia la classe AF MQ.
Comparando la valutazione con le immagini giudicate si è osserva che il giudizio
sale quando l’audio va bene anche in presenza di pesanti disturbi, ed il giudizio
cade pesantemente quando il sonoro degrada.
201
__________________________________________________________________
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
10000000
9500000
Mbps
9000000
8500000
8000000
7500000
7000000
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
TEMPI [s]
Figura 6.92: Confronto dei throughput per la sequenza MUSICA
Il throughput grossomodo ricalca quello della sequenza ciclismo, ciò nonostante i
giudizi osservati risultano mediamente più bassi proprio questa particolare
attenzione posta dai valutatori su quello che ascoltavano. In pratica è un po’ come
se avessero livellato in alta le soglie di giudizio. Lo stesso avviene per il jitter di
cui si riporta il grafico di seguito.
CONFRONTO JITTER
0,002
0,0019
Expedited
Ass_hq_OFF_e
Ass_OFF_mq_e
0,0018
SECONDI
0,0017
0,0016
0,0015
0,0014
0,0013
0,0012
0,0011
0,001
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
TEMPO [s]
Figura 6.93: Confronto dei Jitter per la sequenza MUSICA
202
144
145
146
147
148
__________________________________________________________________
6.6
ANALISI DELLE SEQUENZE Wi-Fi
Figura 6.94: Test-be sperimentale per le prove Wi-Fi
Le prove fatte su Wi-Fi sono state effettuate su una sola sequenza della durata di
tre minuto proposta ai valutatori per sole due classi di servizio: Exedited
forwarding ed Assured Forwarding High Quality. La scelta di proporre solo due
delle classi di servizio rispetto alle tre proposte nella prova via cavo consta nel
fatto che la classe AF con rete molto congestionata (AF MQ) risultava
completamente degradata e dunque di poco interesse ai fini della valutazione.
La sequenza è stata scelta lunga per vedere come eventuali errori si propagassero
nel tempo all’interno della sequenza.
Evidentemente il supporto Wi-Fi non supporta la QoS e dunque i valori dei
throughput che giungevano alla macchina client erano praticamente identici per le
due classi.
203
__________________________________________________________________
Wi-Fi CONFRONTO THROUGHPUT
10000000
9000000
EXP_wifi_e
Ass_Hq_wifi_e
8000000
Mbps
7000000
6000000
5000000
4000000
3000000
2000000
1000000
0
0
20
40
60
80
100
120
140
160
180
TEMPO [s]
Figura 6.95: Confronto tra i valori dei throughput della sequenza Wi-Fi per la classe di servizio
EF linea rossa, ed AF HQ linea blu.
La sovrapponibilità dei valori dei throughput è ancora più evidente nel grafico
della distribuzione di seguito.
DISTRIBUZIONE DEL THROUGHPUT
100
90
EXP_wifi_e
Ass_Hq_wifi_e
80
70
60
50
40
30
20
10
0
0
2000000
4000000
6000000
8000000
10000000
12000000
Figura 6.96: Distribuzione del throughput delle due sequenze Wi-Fi, EF linea rossa ed AF HQ
linea blu
204
__________________________________________________________________
La sovrapponibilità del throughput è indice che le due C.o.S vengano trattate alla
stessa maniera dunque che non ci siano garanzie di Q.o.S. I jitter delle due classi
di servizio non sono molto alti ma mediamente sovrapponibili.
Wi-Fi CONFRONTO DEI JITTER
0,01
0,009
EXP_wifi_e
Ass_Hq_wifi_e
0,008
SECONDI
0,007
0,006
0,005
0,004
0,003
0,002
0,001
0
0
20
40
60
80
100
120
140
160
180
TEMPO [s]
Figura 6.97: Confronto tra la classe EF line rossa, e la classe AF HQ linea blu
DISTRIBUZIONE NORMALIZZATA DEL JITTER PER Wi-Fi
100
90
80
70
EXP_wifi_e
Ass_Hq_wifi_e
60
50
40
30
20
10
0
0
0,002
0,004
0,006
0,008
0,01
0,012
0,014
0,016
0,018
Figura 6.98: Distribuzione del jitter per le classi EF linea rossa ed AF HQ linea blu
205
0,02
__________________________________________________________________
I valori di throughput e di Jitter sono in pratica gli stessi, nonostante questo i
valori dei giudizi espressi dai valutatori sono differenti.
Figura 6.99: Andamento delle valutazioni per la sequenza Wi-Fi per le classi EF linea rossa ed
AF linea blu.
La notevole differenza della qualità percepita dipende dalla variazione sui ritardi
che i due flussi sperimentano nella rete; nel flusso EF i ritardi sono contenuti entro
I cinque millisecondi, mentre per il flusso AF HQ i ritardi si attestano mediamente
sui venti millisecondi. Nonostante il valore medio del ritardo AF HQ sia al disotto
di quanto specificato e dalla normativa ITU-T G1010 e dalla normativa Y1541 per
il supporto Wi-Fi questi valori si dimostrano insufficienti per una discreta qualità
percepita che nei fatti si rivela essere Bassa con valori medi di 40/100.
In conclusione quella wireless è una tecnologia ancora non matura per il supporto
efficiente di servizi di tipo real-time.
206
__________________________________________________________________
Capitolo 7
MISURE OGETTIVE DEL TEMPO DI RIPRISTINO
7.1 INTRODUZIONE
In questo capitolo verranno presentati i risultati più significativi ottenuti dalle
misure riguardanti il tempo di ripristino del servizio ottenuto utilizzando il sistema
di protezione proposto in questo lavoro.
In particolare verranno mostrati i seguenti risultati:
♦
Tempo di interruzione fisica del collegamento
♦
Tempo di detection del guasto da parte dei router Juniper M10
♦
Tempo di interruzione relativo a servizi real time simulati
♦
Tempo di interruzione relativo a servizi non-real time
Infine verranno indicati i tempi che si otterrebbero se il ripristino del servizio
fosse compiuto esclusivamente dall’algoritmo di routing OSPF senza beneficiare
dell’intervento del sistema di protezione.
7.2 TEMPO DI INTERRUZIONE DEL COLLEGAMENTO
Tra tutti i risultati ottenuti dall’analisi delle prestazioni del sistema questo è
sicuramente il più significativo. E’ infatti di fondamentale importanza capire per
quanto tempo il collegamento fisico tra i due apparati terminali risulti fuori
servizio in seguito ad un guasto improvviso. Questo tempo rappresenta il periodo
nel quale le interfacce ottiche dei router relative al link sotto test presentino uno
stato di down. Per ottenere la misura esatta di questo tempo è stato utilizzato un
207
__________________________________________________________________
oscilloscopio a campionamento continuo, la cui descrizione è riportata nel
capitolo precedente, e di uno splitter di potenza 90:10.
Tramite lo splitter di potenza è stato possibile spillare il 10% della potenza ottica
presente nelle immediate vicinanze di una delle interfacce dei due router
terminali. Tale potenza è stata inviata verso l’oscilloscopio mediante un
convertitore opto-elettrico affinché il segnale fosse conforme alle caratteristiche
dello strumento di misura utilizzato. In questo modo è stato possibile monitorare
costantemente l’andamento della potenza ottica in ingresso/uscita dalle interfacce
dei router. Nella Errore. L'origine riferimento non è stata trovata. viene
mostrato lo scenario appena descritto.
OSCILLOSCOPIO
Convertitore
Opto-Elettrico
ROUTER 1
10%
90%
LINEA DI SERVIZIO
PXC
ROUTER 2
LINEA DI BACKUP
LINUX BOX
Traffico dati
LINUX BOX
Collegamenti Fast Ethernet
Collegamento ottico Gbe primario
Collegamento ottico Gbe Secondario
CLIENT B
Figura 7.1 : Banco di misura del tempo di interruzione fisica del collegamento
Una volta allestito il banco di misura come in figura si è proceduto a simulare un
guasto improvviso del link di working. Il tempo di ripristino del sistema di
protezione misurato è risultato essere pari a 20 ms. Questo tempo è il risultato
della somma dei seguenti fattori:
208
__________________________________________________________________
♦
Tempo di invio del segnale di allarme da parte dei router
♦
Tempo di elaborazione del PC di controllo
♦
Tempo di commutazione degli switch ottici
♦
Tempi di propagazione dei segnali tra i vari apparati interessati
Il tempo appena descritto è mostrato nella Errore. L'origine riferimento non è
stata trovata. direttamente fornita dallo strumento di misura utilizzato (Le Croy).
Figura 7.2 : Immagine del tempo di fuori servizio fornita dall' oscilloscopio
Questo risultato evidenzia una considerevole efficienza, in termini di velocità di
ripristino della situazione precedente al guasto, del sistema da me proposto.
7.3 TEMPO DI REAZIONE DEL ROUTER AL GUASTO
Tutto quello che è stato illustrato nel paragrafo precedente riguarda
esclusivamente lo strato fisico della rete. E’ necessario ora approfondire il
comportamento del sistema ai livelli superiori al primo, per capire le effettive
conseguenze di un guasto e di un relativo ripristino relativamente ai possibili
servizi disponibili oggi nella rete .
209
__________________________________________________________________
Come già detto, il testbed di rete considerato consiste in due router IP/MPLS
connessi tramite un collegamento GbE (1000BaseLX) punto-punto su fibra ottica
monomodale.
E’ di centrale importanza capire qual è il tempo impiegato dal router per la
rilevazione del guasto al livello software su connessioni punto-punto GbE.
Un’ analisi di questo tipo è stata svolta dalla Scuola Superiore Sant’ Anna di Pisa
nel Laboratorio Nazionale di Reti Fotoniche di Pisa, proprio sui router Juniper
M10.
Secondo quanto affermato dai suddetti centri di ricerca, i router Juniper M10
presentano dei tempi di reazione al guasto che oscillano tra 40ms e circa 1 sec. Il
tempo medio misurato è di 0.573 s, la deviazione standard 0.275 s, il tempo
minimo 42 ms, il massimo 1.091 s. Fig. 2 mostra i risultati ottenuti in termini di
distribuzione dei tempi suddetti.
Figura 7.3 : Tempo di reazione al guasto dei rouetr Juniper (misurato dalla S.S.S.A.)
Confrontando quindi questi risultati con i risultati descritti nel precedente
paragrafo è possibile misurare il ritardo introdotto dal router per il definitivo
ripristino del servizio.
Si nota quindi che la distribuzione dei valori risulta piuttosto uniforme fra 0.1 s e
1 s, tale quindi da far presupporre una verifica dello stato delle interfacce da parte
del router solo di una volta al secondo. Ciò quindi determina tempi di ripristino
del guasto decisamente maggiori rispetto al tempo potenzialmente offerto dal
sistema di protezione proposto in questo lavoro.
210
__________________________________________________________________
Intervallo di reazione al guasto
da parte dei router
0
20
Tmin 40
Tempo di ripristino
fisico del collegamento
~500
Tmax 1000
T [ms]
Tempo medio di
reazione del router al
guasto
Figura 7.4 : Schematizzazione dei tempi di ripristino
Infatti qualsiasi metodo di ripristino della connettività attivato dal router su questo
tipo di connessione, ad esempio MPLS Fast Reroute su un percorso alternativo,
risulta pesantemente influenzato dal tempo di reazione al guasto.
L’evoluzione dei router commerciali dovrà quindi necessariamente tenere conto di
questi aspetti e integrare meccanismi più efficienti per la reazione al guasto.
La reazione del router, nel nostro sistema, si articola nelle seguenti fasi:
♦
In seguito al guasto, il router invia l’allarme considerando l’interfaccia
non attiva (down)
♦
il sistema di protezione fornisce un collegamento alternativo dopo 20ms
facendo tornare le interfacce in uno stato attivo (up)
♦
il router interroga l’interfaccia e trovandola attiva instrada di nuovo il
traffico sul link disponibile
Nel laboratorio di reti ottiche dinamiche ho svolto delle misure relative a questo
tempo che hanno confermato quanto offerto dalla letteratura suddetta. Tali misure
sono state realizzate utilizzando il generatore/analizzatore di traffico ANRITSU
MD1230A. Tramite questo dispositivo, collegato direttamente con il router 1, è
stato possibile generare un traffico IP a 30 Mb/s su protocollo ICMP ed
indirizzare tale traffico verso un PC collegato direttamente con il router 2. In
questo modo il traffico generato, dopo aver percorso il link sotto test, è stato
ricevuto sul PC tramite l’ analizzatore di protocollo ETHEREAL. Nella figura che
segue è riportato schematicamente quanto detto.
211
__________________________________________________________________
ROUTER 1
PXC
LINEA DI SERVIZIO
PXC
ROUTER 2
LINEA DI BACKUP
LINUX BOX
ANRITSU 1230MD
LINUX BOX
Traffico dati
Collegamenti Fast Ethernet
Collegamento ottico Gbe primario
Collegamento ottico Gbe Secondario
PC-SNIFFER
Figura 7.5 : Configurazione utilizzata per misurare il tempo di reazione al guasto dei router
Di seguito vengono riportate le immagini fornite dal software utilizzato dove
vengono evidenziati i tempi di reazione significativi misurati. Più precisamente la
Figura 7.6 mostra il tempo minimo di reazione ottenuto pari a 40ms, mentre la
mostra un tempo medio alto di reazione ottenuto pari a 600ms. Viene mostrato sia
il report dei pacchetti IP ricevuti dallo sniffer che l’andamento del throughput
fornito dal software nei due casi.
212
__________________________________________________________________
Figura 7.6 : Interruzione minima del traffico (40ms)
Figura 7.7: Interruzione medio alta del traffico (600ms)
213
__________________________________________________________________
7.4 TEST SUI SERVIZI
Affinché fosse possibile stabilire l’effettiva applicabilità di questo sistema di
protezione ad un contesto reale si è proceduto a misurarne le prestazioni
relativamente ai diversi servizi disponibili attualmente nella rete.
Ciò è stato possibile grazie all’impiego del software Chariot NetIQ generalmente
utilizzato per misure oggettive della QoS. Le prestazioni del sistema sono state
valutate su diversi tipi di traffico e su tre diverse classi di servizio. Il test bed
infatti è stato configurato in accordo con l’approccio Diffserv over MPLS. In
assenza di guasti simulati sono stati configurati i router facendo riferimento ad
opportune metriche che stabiliscono i requisiti minimi di QoS da rispettare per
alcuni tipi di servizi indipendentemente dalle condizioni di traffico nella rete. Le
metriche sono riportate nella Tabella 7.1.
Tabella 7.1: Requisiti minimi per alcuni servizi multimediali
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 Figura 7.8:
Packet Loss
5%
Conversational
voice and video
0%
Zero
loss
100 msec
Command
/ control
(eg Telnet,
Interactive
games)
Voice/video
messaging
1 sec
Transactions
(eg E-commerce,
W eb-browsing, Email access)
Streaming
audio/video
10 sec
Messaging,
Downloads
(eg FTP,
still image)
Delay
Fax
100 sec
Background
(eg Usenet)
Figura 7.8 : User-centric Delay and Packet Loss requirements – ITU G.1010*
214
__________________________________________________________________
7.5 TEST BED UTILIZZATO PER LE MISURE CON IL
SOFTWARE CHARIOT
Passiamo ora a descrivere le modalità in cui sono state svolte le misure con il
software chariot.
Lo schema utilizzato per questo tipo di prove è rappresentato nella Figura 7.9.
MULTIMEDIA SERVER
SERVER
CHARIOT
Laboratorio valutazione della QoS multimediale – Ufficio IV ISCOM
Hub
ANELLO OTTICO ROMA-POMEZIA Fibra ottica smf 1550 1,25 GBE
Convertitore
Opto-elettrico
Linea di servizio
Laboratorio reti ottiche
trasmissive -ISCOM-
Linea di backup
PXC
Fibra ottica
MMF
PXC
Convertitore
Elettro-ottico
GENERATORE
ANALIZZATORE
DI TRAFFICO
CLIENT-1 CHARIOT
Fe
1,25 GBE
1,25 GBE
Laboratorio reti ottiche dinamiche – Ufficio III ISCOM
Fe
CLIENT-2 CHARIOT
Figura 7.9 : Test bed utilizzato per le misure con il software chariot
Nell’ anello ottico, che collega i due router Juniper, è stato inserito il generatore
analizzatore di traffico Anritsu MD1230A presente nel “laboratorio reti ottiche
dinamiche”. Tramite questo strumento, descritto dettagliatamente nel capitolo
precedente, è stato possibile saturare il link ottico sotto test fino al suo limite (1,25
Gbit/s), ottenendo così la possibilità di effettuare delle misure in ogni condizione
di carico della rete.
Le interfacce dei router sono state utilizzate nel seguente modo:
215
__________________________________________________________________
♦
2 Fast Ethernet ed 1 Gigabit Ethernet (TX/RX) sono state collegate al
generatore/analizzatore di traffico Anritsu, per congestionare la rete ed al
fine di metterci nelle probabili condizioni in cui può trovarsi una rete di
trasporto metropolitana.
♦
2 Fast Ethernet sono state collegate ai Client Chariot
♦
1 Gigabit Ethernet è stata utilizzata per collegare i due router con
l’anello Roma-Pomezia (ge-0/0/0).
Per quanto concerne la quarta porta Fast Ethernet disponibile, nel primo router è
stata collegata ad un convertitore elettro-ottico per permettere il collegamento tra
il laboratorio di reti ottiche dinamiche ed il laboratorio di valutazione della QoS.
Il traffico di saturazione può essere etichettato in accordo con l’approccio
DiffServ.
Nel laboratorio della Qos multimediale è presente un server di dati realizzato
mediante l’istallazione del software Chariot prodotto dalla NetIQ. La versione
client di questo programma è stata istallata sui PC del laboratorio di reti ottiche
dinamiche. Mediante l’interazione tra queste tre macchine (server più due client) è
stato possibile effettuare uno scambio di traffico dati tra i client collegati ai due
diversi router (dunque alle estremità dell’anello),
e misurarne i parametri
significativi di interesse. I dati scambiati posso essere di diverso tipo, ad esempio
video conferenza realizzata mediante sessione Netmeeting, “download” di dati di
tipo FTP (File Transfer Protocol), sessioni di VoIP (Voice over IP) etc; inoltre
tramite il server Chariot è possibile decidere il rate del traffico inviato e marcare il
campo DSCP dei pacchetti IPv4 in accordo con l’approccio DiffServ30.
Quando i flussi etichettati dal Chariot giungono ad uno dei due router viene subito
esaminato il campo DSCP, questo determina il trattamento che subirà il pacchetto.
In seguito il pacchetto viene inoltrato sull’interfaccia GigabitEthernet di uscita
verso l’interfaccia GigabitEthernet di ingresso dell’altro router il quale, in seguito
ad un ulteriore studio del campo DSCP, adotterà una opportuna politica di QoS ed
instraderà i flussi verso una sua interfaccia di uscita che in questo caso è una
FastEthernet.
30
DiffServ: politica di gestione della QoS, nel nostro caso realizzata utilizzando i tre bit
sperimentali della Shim header MPLS
216
__________________________________________________________________
Circa la descrizione del test-bed in esame va osservato che la totalità del traffico
che entra ed esce dalle interfacce dei router Juniper, ovvero il traffico di
saturazione dell’Anritsu e quello di test del Chariot, è traffico etichettato; i due
router non svolgono alcuna operazione sui pacchetti ma applicano semplicemente
il PHB (Per Hop Behaviour) relativamente alla classe di servizio cui
appartengono. I due router Juniper sono quindi configurati come Core Router.
Affinché fossero rispettati i requisiti minimi imposti dalla normativa sono stati
configurati sui router i drop profile31 relativi alle tre diverse classi di servizio
implementate: Expedited Forwarding , Assured Forwarding e Best Effort.
Il Drop Profile utilizzato per la classe di servizio Expedited Forwarding è
riportato in Figura 7.10:
admin@lab1#
interpolate {
fill-level [ 0 10 15 20 25 30 ];
drop-probability [ 0 20 50 75 100 ];
}
Figura 7.10 : Drop Profile della coda Expedited Forwarding
Al 30% di riempimento della coda del traffico EF il Drop Profile 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 è
stato pensato per garantire valori di jitter e di one-way-delay molto bassi anche
se a scapito di una perdita di pacchetti alta.
Anche in condizione di rete carica tutti i paramertri di rete considerati, througput
one-way delay jitter e loss data, sono risultati al di sotto di quelli riportati nella
tabella di riferimento di Tabella 7.1. Questo comportamento ricalca in pieno le
caratteristiche cui mira l’approccio DiffServ che riserva ai flussi EF un
trattamento privilegiato.
31
Drop Profile: Descrive la probabilità di scarto dei pacchetti all’interno di una coda, in relazione
al grado di occupazione della stessa
217
__________________________________________________________________
Il Drop Profile utilizzato per la classe di servizio Assured Forwarding è riportato
nella Figura 7.11.
admin@lab1#
interpolate {
fill-level [ 0 10 20 30 40 50 60 70 80 100 ];
drop-probability [ 0 1 2 3 5 20 40 80 100 ];
}
Figura 7.11 : Configurazione del drop profile della coda Assured Forwarding
In seguito all’osservazione dei risultati ottenuti dalle misure, è stato possibile
osservare come le perdite di dati ed i valori di one-way-delay del traffico AF siano
molto basse e praticamente comparabili con quelle del traffico EF.
Infine il buffer size ed il trasmission rate configurati sui router sono riportati nella
Figura 7.12.
TRAFFICO
EF
AF
BE
NC32
TRANSMISSION
RATE
8%
9%
78%
5%
BUFFER SIZE
7%
9%
79%
5%
Figura 7.12: Configurazione dello Scheduler
Grazie a questa configurazione è stato possibile rispettare i limiti imposti dalla
normativa di riferimento, in assenza di guasti simulati nella rete.
32
NC non classificato
218
__________________________________________________________________
7.5.1 Test sui servizi simulati
Le misure che seguiranno sono state realizzate per testare il tempo necessario per
il ripristino software del traffico in seguito ad un link faiulre del collegamento di
esercizio. Di conseguenza non verranno considerati i limiti imposti dalla
normativa in termini di Lost Data, Jitter, Throughput medio e one-way delay, in
quanto i parametri misurati vengono decisamente alterati dal guasto della risorsa
primaria volutamente realizzato.
Il traffico di saturazione totale, prodotto dal generatore MD1230A, presente in
rete al momento dello svolgimento delle misure è stato il seguente:
♦
Expedited Forwarding: 32 Mbit/s
♦
Assured Forwarding: 80 Mbit/s
♦
Best Effort: 800 Mbit/s
7.5.2 Test di ripristino su servizi di video conferenza
A dimostrazione del corretto funzionamento della QoS differenziata ottenuta
mediante il server Chariot su rete carica in assenza di guasti simulati viene
riportata una sessione di misure effettuata su servizio Netmeeting. In particolare
dal server Chariot sono stati inviati 6 flussi Netmeeting cosi ripartiti:
♦
2 flussi EF da 10 Mbit/s
♦
1 flusso BE da 10 Mbit/s
♦
3 flussi AF da 10 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.
219
__________________________________________________________________
Figura 7.13 : Throughput delle tre classi di servizio
La scelta di questo particolare grafico sviluppato su una sessione di cinque minuti
è dovuto alla particolare resa cromatica che per contrasto rende immediatamente
evidente la 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 (rosso - rosa), quelli più
privilegiati hanno throughput poco variabile e praticamente uguale a quello
nominale, il flusso BE (celeste) come ci si aspettava ha perdite notevoli e
inaccettabili ed è altamente variabile. I tre flussi AF(verde e grigio) 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 7.14: Lost Data delle tre classi di servizio
220
__________________________________________________________________
In Figura 7.14 è mostrato l’andamento delle perdite dei pacchetti. Come è ben
visibile i flussi EF (rosso-rosa) hanno perdite nulle tanto che il Chariot non le
grafica, il flusso BE (celeste) ha perdite inaccettabili ed i flussi AF ( verde e
grigio) hanno perdite mediamente intorno al 4% cioè al limite dei valori imposti
per la classe Assured Forwarding.
Figura 7.15: One-Way-Delay delle tre classi di servizio
In Figura 7.15 relativa al caso limite AF è mostrato il one-way delay massimo
sperimentato dai pacchetti. Per tutte le classi di servizio i valori di one-way-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.
221
__________________________________________________________________
Figura 7.16 : Jitter massimo delle tre classi di servizio
Nella Figura 7.16 è rappresentato il jitter massimo sperimentato dai pacchetti in
rete, si può notare come i flussi EF abbiano valori molto bassi, mentre per le altre
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.
Dopo aver dimostrato il corretto funzionamento del test bed in relazione alla QoS
passiamo a mostrare i risultati ottenuti dalle misure relative al sistema di
protezione proposto in questo lavoro.
Le prime due serie di misure sono state effettuate sul servizio Netmeeting. Il
servizio di video conferenza è un servizio di tipo real time che usa il protocollo
RTP per il trasferimento dei dati. Si riportano di seguito i casi più significativi:
♦
simulazione di un guasto singolo all’interno della sessione di prove
♦
simulazione di guasti multipli all’interno di una sessione di prove
Guasto singolo:
Dal server Chariot sono stati inviati 12 flussi Netmeeting cosi ripartiti:
♦
4 flusso EF da 10 Mbit/s ognuno
♦
4 flusso BE da 10 Mbit/s ognuno
♦
4 flussi AF da 10 Mbit/s ognuno
222
__________________________________________________________________
per un totale di 120 Mbit/s. Ricordo che al traffico prodotto dal Chariot va sempre
sommato il traffico di background prodotto dall’Anritsu descritto all’inizio del
paragrafo.
Figura 7.17 : Andamento del throughput in caso di guasto singolo per servizio Netmeeting
Il grafico di Figura 7.17, sviluppato su una sessione di 30 secondi, mostra il
trattamento differenziato delle tre tipologie di traffico, EF, AF e BE, anche in
presenza di una interruzione fisica. Tale interruzione è stata realizzata agendo
manualmente direttamente sulla fibra di esercizio. Come si deduce da una
semplice analisi del grafico, il traffico subisce una momentanea interruzione per
poi venire completamente ripristinato dopo un tempo pari a circa 400ms. Si può
notare come il guasto nella rete, non degrada le prestazioni che i flussi a parità di
bit-rate nominale sperimentano in base alla classe di servizio di appartenenza.
223
__________________________________________________________________
Figura 7.18 : Andamento del Lost Data in caso di guasto singolo per servizio Netmeeting
Nella Figura 7.18 è riportato l’andamento del lost data relativo alle tre classi di
servizio implementate. Il grafico evidenzia le conseguenze, in termini di pacchetti
persi, in seguito alla momentanea caduta del servizio.
Guasti multipli:
In questa sessione di prove sono stati simulati cinque guasti consecutivi del
collegamento primario, opportunamente distanziati nel tempo. Come è stato già
detto in precedenza il sistema di protezione sotto test è in grado di sopperire
solamente a guasti singoli, infatti le seguenti prove sono state effettuate
interrompendo il collegamento primario solo dopo aver, ogni volta, ripristinato la
situazione iniziale.
Questo è stato fatto sostanzialmente per due motivi:
♦
Evidenziare un comportamento coerente nel tempo del sistema sotto test
♦
Evidenziare la totale trasparenza al traffico del passaggio dal
collegamento di back up al collegamento di esercizio effettuato per
predisporre il sistema a reagire ai guasti successivi al primo.
Dal server Chariot sono stati inviati 12 flussi Netmeeting tutti da 10 Mbit/s,
ripartiti nel seguente modo:
♦
4 flusso EF da 10 Mbit/s ognuno
♦
4 flusso BE da 10 Mbit/s ognuno
♦
4 flussi AF da 10 Mbit/s ognuno
224
__________________________________________________________________
Osservando la figura si nota inoltre che, le relative protezioni, effettuate per
ripristinare il traffico, non alterano, anche in questo caso, il comportamento delle
tre diverse classi di servizio.
Figura 7.19 : Andamento del throughput in caso di guasti multipli per servizio Netmeeting
Figura 7.20 : Andamento del Lost Data in caso di guasti multipli per servizio Netmeeting
In Figura 7.20 sono riportate le perdite di dati riscontrate nel corso dell’intera
sessione di prova. Da questo e dal precedente grafico si può notare che le perdite
relative alle diverse interruzioni sono decisamente diverse. La terza e la quarta
simulazione di guasto hanno causato un’interruzione del servizio pari a circa 300
ms ottenendo quindi una bassissima perdita di pacchetti; al contrario le altre
interruzioni offrono tempi di fuori servizio leggermente più lunghi e delle perdite
di dati ovviamente maggiori. Questa variabilità di risultati è dovuta al tempo di
reazione dei router descritto nei precedenti paragrafi.
225
__________________________________________________________________
7.5.3 Commutazione volontaria del mezzo trasmissivo
Le interruzioni, relative al caso appena descritto, sono state realizzate volutamente
a distanza di 30 secondi l’una dall’altra, mentre il passaggio inverso, dalla fibra di
back up alla fibra di esercizio, è stato effettuato nei 4 secondi successivi ad ogni
simulazione di guasto. Risulta evidente, da una rapida ispezione di entrambi i
grafici, che il ritorno alla situazione precedente al guasto non genera alcuna
conseguenza sul traffico dati in questione. Essendo la video conferenza un traffico
di tipo real time interattivo, e quindi il traffico più critico in termini di Lost Data,
si può affermare che un eventuale azione volontaria riguardo la commutazione del
mezzo trasmissivo ( per ragioni legate a manutenzione o a riconfigurazione della
rete) non infici sulle prestazioni relative a nessun tipo di servizio disponibile oggi
nella rete.
Questa affermazione è stata confermata dai risultati ottenuti da tutte le misure
effettuate su questo sistema su tutti i tipi di servizio real-time e non real-time.
E’ opportuno inoltre osservare che, in corrispondenza di una commutazione
volontaria del mezzo trasmissivo, l’interfaccia del router dovrebbe percepire una
mancanza di potenza ottica per il tempo che gli switch ottici richiedono per
effettuare lo scambio (3ms). In realtà il router, in questo caso, non invia nessun
allarme il che significa che il LOL viene inviato solamente quando la mancanza di
luce persiste per un tempo maggiore a 3ms. Questo risultato è da sottolineare in
vista di un inserimento futuro di dispositivi ottici all’interno della rete, ad esempio
convertitori di lunghezza d’onda. E’ infatti utile rimarcare che qualora l’intervento
su tali dispositivi occupi un tempo minore o uguale a 3ms, il router non viene in
nessun modo coinvolto e il traffico da esso instradato non subisce alcuna
degradazione.
7.5.4 Test di ripristino su servizio VoIP (Voice over IP)
Il servizio Voice over IP analogamente al servizio Netmeeting è un servizio di
tipo real-time, quindi richiede parametri di QoS molto stringenti. Come per il caso
226
__________________________________________________________________
generico Netmeeting, dalle misure effettuate in assenza di guasti simulati, non è
evidente la differenza di prestazioni tra i flussi EF e AF.
La configurazione del traffico inviato dal Server Chariot, utilizzata per le misure,
è stata:
♦
15 flussi VoIP Expedited Forwarding
♦
15 flussi VoIP Assured Forwarding
♦
15 flussi VoIP Best Effort
per un totale di 45 flussi.
Anche per questo servizio si sono effettuate alcune misure su guasto singolo ed
alcune misure su guasti multipli consecutivi. Tutte le prove riguardanti questo
servizio sono state realizzate sullo standard G.711.
Guasto singolo:
Nella Figura 7.21 viene graficata, tramite l’andamento del throughput,
l’interruzione del servizio dovuta ad un guasto singolo all’interno di una sessione
di prova della durata di 2 minuti. Da una rapida ispezione dl grafico è possibile
notare che prima del guasto del link di esercizio i flussi appartenenti alla classe di
servizio Best Effort presentano un
throughput mediamente minore ed un
andamento molto più variabile rispetto alle CoS AF ed EF. In seguito al ripristino
del servizio le tre CoS offrono, per un tempo limitato, prestazioni identiche in
termini di throughput medio. Questo accade poichè il traffico di background
presente in rete è il medesimo di quello utilizzato per le prove sul servizio di
video conferenza, ma in questo caso l’occupazione di banda del servizio sotto test
è decisamente inferiore. Questo comporta che in seguito all’interruzione, le code
dei router si svuotano quasi totalmente e, data la limitata occupazione di banda del
servizio, tutte le code dei router potranno essere servite con una frequenza tale da
non generare perdite.
Dopo un determinato lasso di tempo le priorità imposte sulle code dei router per le
tre diverse CoS causano il riempimento della coda dedicata al BE che torna a
presentare le medesime prestazioni precedenti al guasto.
227
__________________________________________________________________
Figura 7.21 : Andamento del throughput in caso di guasto singolo per servizio VoiP
Quanto appena descritto dall’analisi
dell’andamento del throughput medio è
confermato dal grafico che descrive l’andamento delle perdite nella Figura 7.22.
L’interruzione del servizio sperimentata dalla misura appena descritta è stata di
circa 900ms.
Figura 7.22 : Andamento del Lost Data in caso di guasto singolo per servizio VoiP
Guasti multipli:
Analogamente a quanto visto per il servizio Netmeeting le misure relative ad
interruzioni multiple del link di servizio sono state realizzate per evidenziare due
aspetti:
♦
un comportamento coerente nel tempo del sistema sotto test
228
__________________________________________________________________
♦
la totale trasparenza al traffico del passaggio dal collegamento di back
up al collegamento di esercizio effettuato per predisporre il sistema a
reagire ai guasti successivi al primo.
In questo caso sono stati simulati due guasti a distanza di 1minuto e 20 secondi, in
una sessione di prova della durata complessiva di 3 minuti.
Figura 7.23 : Andamento del throughput in caso di guasti multipli per servizio VoiP
Figura 7.24 : Andamento del Lost Data in caso di guasti multipli per servizio VoiP
E’ evidente che i risultati ottenuti sono completamente in linea con quanto detto in
precedenza per il caso di singolo guasto, ed è importante sottolineare che anche
per questo servizio la commutazione tra il link di back up ed il link di working
non genera alcuna conseguenza parametri di rete misurati.
229
__________________________________________________________________
La classe di servizio EF, per come è configurata sui router, può supportare una
grande quantità di traffico real-time senza compromettere la qualità del servizio.
Nelle misure che seguiranno verranno presi in considerazione servizi di tipo non
real-time che viaggiano su protocolli tipo TCP . Il parametro che si considererà di
qui in seguito è il throughput medio.
7.5.5 Test di ripristino su servizi audio-video non real time
Per osservare il comportamento del sistema di protezione riguardo a questo tipo di
servizi si è utilizzato il generatore/analizzatore di traffico Anritsu MD1230A in
modalità ‘passante’. Il dispositivo in questione offre infatti la possibilità di essere
utilizzato per graficare il throughput del traffico che lo attraversa. Per fare ciò si
sono utilizzate quattro interfacce Fast Ethernet nella modalità descritta in Figura
7.25.
ROUTER 1
PXC
LINEA DI SERVIZIO
PXC
ROUTER 2
LINEA DI BACKUP
LINUX BOX
Generatore/Analizzatore di traffico LINUX BOX
ANRITSU
CLIENT
SERVER MULTIMEDIALE
Figura 7.25 : Configurazione del Test bed per misure su streaming non real-time
Lo streaming media è composto principalmente da quattro elementi:
230
__________________________________________________________________
1) Encoder: digitalizza il contenuto in un formato compresso con una speciale
sequenza di trasmissione. Il flusso di dati può essere codificato per differenti
bitrate33, in modo da consentire agli utenti una fruizione ottimizzata secondo il
loro metodo di accesso.
2) Streaming Server: computer appositamente configurato per la gestione di file
multimediali. Fornisce l’accesso ai contenuti agli utenti che lo richiedono.
3) Rete di distribuzione: Internet o Virtual Private Network (VPN).
4) Client: applicazione che gira su un terminale e consente di vedere il contenuto
dello streaming.
Il processo di streaming può essere così sintetizzato (Figura 7.26):
♦
Un evento viene registrato
♦
Il contenuto è sottoposto a editing e digitalizzato
♦
Il contenuto digitale audio/video viene codificato per lo streaming.
♦
Il media file viene memorizzato su un apposito server.
♦
Il file invia lo streaming all’utente che lo richiede.
♦
L’utente visualizza il contenuto grazie a una utility come Windows
Media Player, Real Player o QuickTime.
Figura 7.26 : Componenti dello streaming
33
Prodotto tra la frequenza di campionamento e il numero di bit utilizzati durante il processo di
quantizzazione. A un bitrate elevato corrispondono una migliore qualità del video, ma anche
maggiori dimensioni
231
__________________________________________________________________
I pacchetti che giungono al destinatario sono prima inseriti in un buffer e poi
decompressi in successione dal player; il contenuto viene riprodotto mentre si
continuano a ricevere i pacchetti dello stesso flusso.
Il vantaggio principale dello streaming sta proprio nel fatto che non bisogna
scaricare completamente il file prima di utilizzarlo. Supponiamo ad esempio di
voler vedere un filmato con un bitrate compatibile con la velocità della nostra
connessione. Se la dimensione del file fosse molto grande, il download potrebbe
durare anche parecchi minuti. Grazie allo streaming invece possiamo iniziare la
visione dopo appena pochi secondi.
Inoltre ogni singolo pacchetto, dopo essere stato utilizzato, può essere scartato.
Ciò consente di non occupare spazio su disco e di non dare il possesso del file
all’utente.
Abbiamo visto che lo strato IP non offre alcun tipo di qualità di servizio e le unità
informative possono essere perse, duplicate, ritardate o consegnate fuori sequenza.
Per garantire un trasporto affidabile si usa normalmente il protocollo TCP, ma le
ritrasmissioni e il controllo di flusso/congestione causano dei ritardi inaccettabili
per una comunicazione in real-time.
Per le trasmissioni multimediali si utilizza allora il protocollo UDP (User
Datagram Protocol), che fornisce un servizio senza connessione, non affidabile,
senza controllo di flusso e congestione. Lo streaming multimediale si basa su
diversi tipi di protocolli:
♦
RTP (Real-time Transport Protocol): gestisce l’effettivo trasferimento
dei dati.
♦
RTCP (Real-time Control Protocol): consente di ottenere informazioni
sulla qualità della trasmissione.
♦
RTSP (Real-time Streaming Protocol): consente di controllare il flusso
di informazioni trasmesse.
♦
RDT (Real Data Transport): protocollo proprietario della Real Networks
per la comunicazione tra RealServer e RealPlayer.
♦
PNM (Progressive Networks Media): protocollo proprietario della Real
Networks per lo streaming audio.
232
__________________________________________________________________
♦
SDP (Session Description Protocol): ha lo scopo di fornire informazioni
sulla sessione multimediale (nome, indirizzi IP, porte, formati...)
♦
MMS (Microsoft Media Server): protocollo proprietario della Microsoft,
usato con le architetture Windows Media Technologies.
♦
HTTP (Hyper Text Transfer Protocol): adoperato nello streaming on
demand.
Figura 7.27 : Protocolli utilizzati per lo streaming
Per realizzare uno streaming non real time è possibile utilizzare protocolli che si
appoggiano su TCP come HTTP o RTCP. In questo modo nel momento in cui si
verifica una perdita di pacchetti il protocollo può richiedere una ritrasmissione
degli stessi garantendo una continuità del flusso di immagini all’utente. Questo è
possibile data la natura non interattiva del servizio.
Nel caso di queste misure si è simulata la situazione nella quale un client richiede
un servizio di video on demand ad un server remoto. La trasmissione dei dati
avviene avvalendosi del supporto del protocollo TCP.
Nel laboratorio di reti ottiche dinamiche è presente un server multimediale che è
stato utilizzato come sorgente di traffico. Nella Figura 7.28 viene mostrato
l’andamento del throughput relativo a due stream codificati in MPEG-2 ad 8
Mbps etichettati diversamente in assenza di simulazioni di guasto. Per rendere più
evidente la differenza di prestazioni dei due flussi sono state considerate solo la
CoS EF e la CoS BE. Il traffico di background è il medesimo di quello utilizzato
nelle prove precedenti.
233
__________________________________________________________________
Figura 7.28 : Throughput di due streaming appartenenti a due CoS ( blu-EF, verde-BE)
La linea verde rappresenta i throughput relativo al flusso BE che risulta
decisamente minore del throughput relativo al flusso EF rappresentato dalla linea
blu.
Nella Figura 7.29 è invece graficata l’interruzione del sevizio relativa al guasto
della risorsa primaria. E’ evidente, dal grafico, che in seguito all’interruzione, il
traffico EF viene ripristinato prima del traffico BE grazie alla maggiore priorità
riservata alla coda EF nei router rispetto alle code relative alle altre CoS. Subito
dopo viene ripristinato anche il flusso BE che per un tempo finito successivo al
ripristino presenta un throughput medio più alto dell’EF. Questo è imputabile al
fatto che nell’attesa che la coda dell’EF venga servita la coda BE accumula dati
che dovranno essere tramessi con un rate più elevato nel momento in cui la coda
BE viene servita, al fine di garantire una continuità del flusso video lato cliente.
Inoltre è da sottolineare che il guasto e il relativo ripristino risultano totalmente
trasparenti all’utente grazie alla bufferizzazione preventiva del video ed al
contributo offerto dal TCP nel ritrasmettere i dati persi.
234
__________________________________________________________________
Figura 7.29 : Andamento del througput di due streming video non real time in caso di guasto
7.5.6 Test di ripristino su servizio di trasferimento dati
In questa sessione di test, analogamente alla precedente, si è fatto uso del
generatore/analizzatore di traffico Anritsu MD 1230A al fine di monitorare il
comportamento del sistema su questo tipo di servizo.
Il servizio di trasferimento dati è stato realizzato trasmettendo dei dati da un
server ad un client in seguito ad una richiesta dello stesso.
La Figura 7.30 mostra l’andamento del throughput relativo ai due flussi
diversamente etichettati ( BE – verde ; EF – blu ) in seguito ad una simulazione di
guasto.
Come si può osservare l’andamento ricalca quanto visto nel paragrafo precedente
per il servizio audio-viedo non real time.
Queste analogie fra i due servizi sono dovute al fatto che anche il servizio FTP
(File Transer Protocol) è non real-time ed al fatto che anche questo tipo di servizio
235
__________________________________________________________________
utilizza il protocollo TCP. Anche in questo caso si può notare che il flusso EF
viene ripristinato prima del flusso BE e che, successivamente al ripristino, è
presente un momentaneo aumento di throughput per il flusso BE.
Infine è importante sottolineare che anche in questo caso il guasto, ed il relativo
ripristino, avviene in maniera totalmente trasparente all’utente.
Figura 7.30 : Andamento del throughput di due flussi FTP in caso di guasto
7.6 RISPRISTINO DEL SERVIZIO MEDIANTE
PROTOCOLLO OSPF
In questo paragrafo verranno riportati i risultati ottenuti dalle misure del tempo di
ripristino del servizio, ottenuto utilizzando il protocollo di routing OSPF in luogo
del sistema di protezione oggetto di questo lavoro. Più precisamente si è voluto
misurare il tempo in cui il protocollo OSPF riesce riconoscere un cambiamento
improvviso della topologia della rete ed a reagire di conseguenza ripristinando il
corretto flusso di dati.
236
__________________________________________________________________
A tal proposito si è utilizzato il terzo router presente nel labotorio di reti ottiche
dinamiche affinché fosse disponibile una via alternativa tra i due client interessati
alla comunicazione. La situazione appena descritta è rappresentata in Figura 7.31.
Router 3
Router 1
Router 2
CLIENT A
CLIENT B
Figura 7.31 : Ripristino del servizio mediane protocollo di routing OSPF
Dalle misure effettuate è stato possibile constatare che il tempo di ripristino del
servizio con queste modalità è mediamente pari a 8 secondi. Infatti, una volta
riconosciuto il link failure il protocollo OSPF deve cancellare il ramo relativo dal
grafo originario, e procedere ad un calcolo di tutte le strade alternative per
raggiungere la destinazione, scegliendo fra queste la via più convenientee stilando
quindi la nuova tabella di instradamento. E facile osservare che nel nostro caso la
via alternativa è una sola e che, in una situazione di rete reale, nella quale
aumentano decisamente il numero di nodi ( router ) e di rami, il tempo di calcolo
relativo ad una riconfigurazione dinamica della rete crescerebbe notevolmente.
Infatti il tempo di calcolo di una nuova tabella di instradamento da parte
dell’algoritmo di dijkstra (algoritmo utilizzato dal protocollo OSPF per il calcolo
delle tabelle di instradamento e dei relativi percorsi) è pari a N*log L dove N è il
numero di rami ed L è il numero di nodi.
237
__________________________________________________________________
Questo processo è estremamente costoso in termini temporali e può durare anche
40 o 50 secondi. Tali tempi non sono accettabili per un servizio real-time a
pagamento come IP-TV, Netmeeting etc.
Sempre in collaborazione con il laboratorio della QoS e grazie all’utilizzo del
server Chariot si è potuto misurare il tempo di fuori servizio della rete registrato
su un traffico Netmeeting. E’ stato scelto questo servizio perché, essendo
interattivo, è decisamente il più sensibile a quelle situazioni capaci di causare
rilevanti perdite di dati, quale è il caso di un guasto improvviso nella rete.
Nella Figura 7.32 è riportato l’andamento del throughput in caso di guasto
singolo del link d’esercizio.
Figura 7.32 : Andamento del throughput in caso di guasto gestito dall'OSPF su servizio
Netmeeting
Anche se, come già detto, si sta considerando il caso di singolo guasto, sono ben
visibili due interruzioni del servizio ognuna delle quali pari a circa 9 secondi. Il
motivo della seconda interruzione è dovuto ad un ritorno alla situazione
precedente al guasto. E’ infatti importante notare che nel momento in cui il link
guasto viene ripristinato, il protocollo di routing percepisce la presenza di un
nuovo ramo e quindi un’altra possibile via per raggiungere il nodo. Viene quindi
intrapreso il medesimo procedimento seguito dopo il guasto del link di esercizio,
ovvero viene ricalcolata nuovamente la tabella di instradamento.
Nella Figura 7.33 è visibile l’andamento delle perdite nella situazione appena
descritta ed è un ulteriore conferma che per applicazioni di tipo real time non è
238
__________________________________________________________________
ammissibile che la protezione del traffico venga demandata solamente ad un
algoritmo di routing dinamico quale è l’OSPF.
Figura 7.33 : Andamento del Lost Data in caso di guasto gestito dall'OSPF su servizio
Netmeeting
239
Capitolo 8
PROVE SOGGETTIVE E QUALITA’ PERCEPITA
DALL’UTENTE FINALE
8.1 ELEMENTI NORMATIVI PER LA VALUTAZIONE
SOGGETTIVA DELLA QUALITA’ DEL SERVIZIO
In questo capitolo viene illustrata una rassegna di normative e metodi per la
valutazione della qualità del servizio percepita dall’utente finale per servizi di tipo
real-time quale ad esempio l’IP-TV, più una breve descrizione degli enti
normativi stessi. Verranno inoltre descritti nel dettaglio le modalità di
svolgimento delle prove per la qualità percepita dall’utente finale ed i risultati
ottenuti in termini di valutazione.
Lo studio dei risultati sotto questo punto di vista ha il solo scopo di evidenziare la
correlazione esistente tra il tempo di fuori servizio misurato oggettivamente e
l’effettiva percezione dell’utente di tale situazione.
8.2 NORMATIVE ITU-T ED ITU-R
8.2.1 Enti per la valutazione delle QoS
La Qualità del servizio consiste di due aspetti fonadamentali:
♦ QoS di rete: controllo della correttezza del flusso informativo e delle
prestazioni di rete.
♦ QoS del contenuto: controllo della correttezza del contenuto del
flusso informativo in relazione alla percezione dell’utente del servizio.
La valutazione della QoS è da qualche anno in fase di standardizzazione; gli enti
che se ne stanno occupando sono:
__________________________________________________________________
♦ E.T.S.I.
(European
Telecomunications
Standard
Institut):
è
un’organizzazione indipendente e no-profit il cui obiettivo è quello di
produrre standards per le telecomunicazioni del presente e del futuro.
L’ ETSI è ufficialmente responsabile delle standardizzazioni della
ICT ( Information & Communication Technologies ) in Europa.
♦ A.N.S.I.
(American
National
Standards
Institute):
è
un’organizzazione privata e no-profit che amministra e coordina il
sistema di standardizzazione e valutazione di conformità di sistemi di
telecomunicazione negli Stati Uniti. L’obiettivo di questo istituto è
quello di migliorare sia la competitività globale del commercio degli
Stati Uniti sia la qualità della vita degli statunitensi promuovendo e
facilitando i campioni di consenso ed i sistemi volontari di valutazione
di conformità a salvaguardia della loro integrità.
♦ I.T.U. (International Telecomunication Union): è un organismo
internazionale per la standardizzazione delle specifiche tecniche
riguardanti vari campi delle telecomunicazioni. L’ ITU ha tra i suoi
obiettivi di massima quello di mantenere ed estendere la cooperazione
internazionale per il miglioramento delle telecomunicazioni, quello di
offrire l’assistenza tecnica ai Paesi in via di sviluppo e quello di
promuovere a livello internazionale l’adozione di un approccio più
generale alle questioni riguardanti le telecomunicazioni, tutto ciò in
vista
della
globalizzazione
dell’economia
e
della
società
dell’informazione.
L’ ITU è costituita da tre settori:
♦ ITU-T Telecomunication Standardization: ha come obiettivo la
produzione efficiente e veloce di standard di alta qualità
(Reccomendations)
che
riguardano
tutti
i
campi
delle
telecomunicazioni.
♦ ITU-R
Radiocomunications :
è il settore che riguarda le
radiocomunicazioni e gioca un ruolo fondamentale nella gestione
dello spettro delle radio-frequenze e delle orbite satellitari.
241
__________________________________________________________________
♦ ITU-D : è il settore dello sviluppo ed è nato di recente con l’intento di
favorire lo sviluppo armonico delle telecomunicazioni nei Paesi in via
di sviluppo fornendo loro l’assistenza necessaria.
8.2.2 QoS della rete
Per la valutazione della QoS di rete la ITU-T ha pubblicato quattro normative:
•
G 1010- Categorie della QoS multimediale END-USER
Questa Raccomandazione definisce un modello di riferimento per le categorie
della QoS multimediale realizzato tenendo conto del punto di vista dell’utente
finale. In considerazione delle aspettative di qualità di un utente finale riguardo
alle applicazioni multimediali sono state create 8 categorie basate sui valori di
perdita delle informazioni e ritardo dei pacchetti. Lo scopo della G 1010 è quello
di stabilire i fattori chiave che influenzano la Qualità del Servizio percepita
dall’utente finale.
Fattori che influenzano la QoS End-USER:
1. Delay: è dato dalla somma di molti termini tra cui il tempo necessario per
stabilire un particolare servizio una volta richiesto dall’utente. Il ritardo ha
un impatto notevole sulla soddisfazione dell’utente soprattutto per
applicazioni multimediali interattive .
2. Jitter: il jitter è definito come la variazione del ritardo end-to-end ed è
causato principalmente dalla variazione del cammino e dal differente
ritardo di accodamento all’interno dei router dei pacchetti IP. Per le
applicazioni più sensibili al jitter è prevista una bufferizzazione aggiuntiva
(buffer di play-out) lato user che diminuisce o elimina il jitter.
3. Perdita di informazione: ha un effetto diretto sulla qualità del servizio e
non riguarda solo la perdita dei pacchetti all’interno della rete o errori di
trasmissione ma anche la degradazione dovuta alla compressione del
segnale sorgente.
242

TEST BED PER LA VALUTAZIONE DELLA QUALITÀ DEL

Transcript

Documenti analoghi

Gestione totale per 40 anni all`Aeroporto Internazionale di Napoli

Configurazione Router Sitecom WL 118 e WL 119

[campania - x] eci_sud/10 10/05/10

Senza titolo

ADSL2+ router 54G Turbo ADSL2+ router MiMoXR

fmea severity

La presente guida e il progetto TAI sono nati da

[torino - 38] stampa/cronaca/02 06/10/04

WWF Italia - No TAV Brennero

Impostazione di base per IP CAMERA