Capitolo 1...pag. 5 La Qualita del Servizio

Transcript

1 Indice Capitolo pag. 5 La Qualita del Servizio 1.1 Parametri di QoS Throughput Delay Delay Variation Loss o Error Rate 1.2 Multimedia Application Requirements Applicazioni Interattive e Non-Interattive Tolleranza e Intolleranza Caratteristiche Adattative e Non-adattative Application Criticality Rappresentazione degli Application Requirements Espressione Quantitativa Espressione Qualitativa Esempi di Applications Requirements Voce Interattiva Applicazioni Video 1.3 I Servizi QoS Servizi Quantitativi (Garantiti) Servizi Qualitativi (Differenziati) Servizi Best Effort Servizi Per-Flow Servizi Per-Class 1

2 Capitolo pag. 22 Meccanismi per la Qualita del Servizio 2.1 Classification Data Link Layer Classification Network Layer Classification Classificazione del Livello di Trasporto Application o User Classification 2.2 Meccanismi di Accesso al Canale Collision-Based Channel Access Collision-Free Channel Access Polling TDMA (Time Division Multiple Access) 2.3 Meccanismi di Schedulazione dei Pacchetti First In First Out (FIFO) Strict Priority Weight Fair Queue (WFQ) Osservazioni su Channel Access e Packet Scheduling 2.4 Traffic Policing Mechanism Leaky Bucket Token Bucket 2.5 Resource Reservation Signaling (RSVP) 2.6 Admission Control 2.7 Architettura di QoS Architettura di QoS per Infrastructure Wireless Network Architettura di QoS per Ad Hoc Wireless Network Capitolo 3...pag. 47 La Qualita del Servizio nelle Wireless LAN IEEE

3 3.1.1 Architettura di Rete Topologie di Rete Ad Hoc Network Rete Wireless Infrastrutturata Stack Protocollare Livello Fisico (Physical Layer) Media Access Control (MAC) Distributed Coordination Function (DCF) Point Coordination Function (PCF) Physical Layer Convergence Protocol (PLCP) Qualita del Servizio in IEEE QoS in DCF QoS in PCF 3.2 L Estensione di per QoS: e Classificazione del Traffico Access Category (AC) Traffic Stream (TS) Accesso al Canale e Scheduling dei Pacchetti EDCF QoS in EDCF HCF QoS in HCF Capitolo 4...pag. 74 Network Code in Linux Kernel: QDISC e Host-AP 4.1 Networking Code in Linux Kernel 4.2 Processo di Ricezione di un Pacchetto 4.3 Processo di Trasmissione di un Pacchetto 4.4 Tecniche di Controllo del Traffico 4.5 Un esempio di Traffic Control 3

4 4.6 Il Driver Host-AP Capitolo 5...pag. 95 La QoS in Legacy con Host-AP e QDISC Studio Sperimentale Scenari e Admission Control 5.1 Scenario Reale 5.2 Obiettivi Sperimentali Problema del NIC buffer: accodamento dei pacchetti Scenario Sperimentale Admission Control per VoIP VoIP Ammissibili : Calcolo Teorico VoIP Ammissibili : Verifica Sperimentale Risultati Sperimentali Capitolo 6....pag. 119 La QoS in Legacy con Host-AP e QDISC Studio Sperimentale Rate Limiter, PRIO e CBQ QDISC Rate Limiter, PRIO e CBQ QDISC 6.1 Schedulazione con PRIO QDISC 6.2 Rate Limiter con CBQ QDISC Misure Sperimentali Misure con 5 VoIP Misure con 9 VoIP 6.3 Conclusioni Finali 4

5 Capitolo 1 La Qualita del Servizio Il concetto di Qualita del Servizio o QoS si riferisce all insieme delle caratteristiche qualitative e quantitative (es., throughput, dimensione del pacchetto, delay, priorita, tipo,..) che descrivono un flusso di traffico prodotto da una specifica applicazione. La Qualita del Servizio e un parametro sensibile in special modo a tutte quelle applicazioni multimediali, come streaming video, Voice over IP, videoconferenza, file sharing, web surfing, le quali richiedono un supporto endto-end con diversi livelli di qualita del servizio in termini di banda, di ritardo e di delay jitter. End-to-end vuol dire che i meccanismi di QoS devono essere previsti non solo nelle sottoreti di collegamento che sono il cuore di Internet, ma anche all interno delle LAN dove si trovano gli host utilizzatori delle suddette applicazioni. Il concetto di QoS si presta a molteplici definizioni: dal lato Network esso si riferisce al livello del servizio o alla qualita del servizio che la rete puo offrire alle applicazioni o agli utenti in termini di una serie di parametri come per esempio la latenza, l affidabilita nella trasmissione dei pacchetti, il throughput. Dal lato delle applicazioni e dell utente invece, QoS generalmente si riferisce alla qualita percepita in uno streaming video e/o audio, in un applicativo di videoconferenza, in una telefonata che usi VoIP. Un modello semplificato che include queste due prospettive puo essere per esempio quello della figura

6 Fig. 1.1: Modello QoS Gli Applications/Users si aspettano uno specifico livello di QoS in termini di qualita percepita e di servizio ininterrotto; questi QoS Requirements sono trasmessi alla rete implicitamente o esplicitamente, e le Networks sono responsabili di soddisfare le suddette richieste. L utente non sa come la rete gestisce le sue risorse o quali meccanismi sono coinvolti e richiesti per assicurare la qualita dei servizi offerti, ma inferisce la qualita del servizio stesso valutando la qualita percepita delle applicazioni. La rete, invece, ha come obiettivo quello di fornire QoS agli utenti e lo fa analizzando gli Applications Requirements, gestendo le risorse di rete, e utilizzando opportuni meccanismi di QoS. Sebbene il modello presentato ha una struttura semplice, ci sono molti punti che devono essere considerati: - Quali sono i parametri di QoS? - Che tipo di informazione e contenuta negli Applications Requirements, e quali sono i criteri per mapparla in termini di parametri di QoS che possono essere gestiti dalla rete? - Che livello di servizio di QoS puo essere fornito dalla rete, e qual e la relazione tra i servizi di QoS e gli Applications Requirements? Nei paragrafi che seguono si da una risposta a questi interrogativi. 6

7 1.1 Parametri di QoS I QoS parameters che sono rilevanti per le applicazioni multimediali sono i seguenti: - Throughput o larghezza di banda - Delay o latenza - Variazione del ritardo (Delay Jitter) - Packet Loss o Error Rate Throughput Il Throughput rappresenta la risorsa di rete piu importante e che meglio bisogna gestire e allocare alle applicazioni. Esso si riferisce al data rate generato da un applicazione ed e infatti misurato in bit per secondo; qualche volta e anche chiamato bit rate o bandwidth. Il throughput richiesto da un applicazione dipende dalle caratteristiche di questa: per esempio in uno streaming video diverse proprieta come frame size, frame rate, compressione, profondita di colore generano diversi livelli di throughput. Quindi in generale la bandwidth richiesta e legata al tipo di processo di generazione del traffico; questo puo essere di tre tipi: - Constant Bit Rate o CBR - Variable Bit Rate o VBR - Burstiness o traffico dati a raffica Vediamo meglio i casi CBR e VBR. CBR applications sono per esempio VoIP con codec G.711 dove si ha appunto un flusso di dati costante a 64Kbps, oppure streaming video in download da un server. La maggior parte delle applicazioni con bit rate costante sono sensibili al delay e richiedono una allocazione di banda minima al di sotto della quale si ha un 7

8 cattivo funzionamento come mostrato nella fig. 1.2; allocare piu banda sopra quella richiesta non aumenta l User Satisfaction. Fig. 1.1: User Satisfaction in funzione della banda allocata per traffico CBR VBR applications si hanno per esempio nel caso di Web Surfing, o di video digitale compresso come accade con la codifica Mpeg4; le applicazioni con bit rate variabile richiedono anch esse un minimo garantito di banda, e piu ne viene allocata meglio funzionano anche se dopo una certa soglia non si hanno piu sensibili miglioramenti come si puo vedere dalla fig Fig. 1.3: User Satisfaction in funzione della banda allocata per traffico VBR Delay Il Delay ha un grosso impatto soprattutto sulle applicazioni real-time che richiedono la consegna delle informazioni entro un certo tempo. 8

9 Infatti lunghi ritardi possono causare la perdita di fedelta in un video o l impossibilita a sostenere un comunicazione VoIP. Il delay e dovuto a tutti quei componenti del sistema di comunicazione che interconnette la sorgente con la destinazione; si puo fare la seguente classificazione: - Source processing delay: e dovuto alla digitalizzazione e alla pacchettizzazione dei dati presso la sorgente; dipende in generale dalla configurazione hardware del source host (RAM, CPU, ) e dal carico ( e.g., il numero delle applicazioni che girano contemporaneamente e le risorse hardware impegnate). - Transmission delay: il tempo di trasmissione di un pacchetto e funzione della dimensione di questo e della velocita di trasmissione. - Network delay: - Propagation delay: e un ritardo dovuto alla distanza fisica tra source e destination; - Protocol delay: questo delay e causato dai protocolli di comunicazione eseguiti nei diversi componenti di rete come routers, gateway, schede di rete. Esso dipende dai protocolli, dal carico della rete e dalla configurazione hardware che esegue tali protocolli; - Output queuing delay: e dovuto al tempo che un pacchetto passa nella coda di trasmissione di un componente di rete. Il ritardo qui e legato alla congestione della rete, al tipo di hardware del nodo, al velocita di trasmissione del link. - Destination processing delay: questo ritardo e introdotto dal processing richiesto alla destinazione: per esempio esso puo aversi nel processo di ricostruzione del pacchetto. E un delay simile a quello di source processing e quindi e legato all hardware e al carico dell host destinazione. La figura che segue illustra come sono legati tra loro tutti questi suddetti ritardi. 9

10 Fig. 1.4: Diagramma del ritardo end-to-end Delay Variation Il Delay Jitter e una metrica di QoS che si riferisce appunto alla variazione del ritardo introdotta dai componenti di rete lungo il path di comunicazione. Ogni pacchetto puo viaggiare attraverso diversi percorsi della Network e quindi siccome ogni path puo essere caratterizzato da diverse condizioni di congestione, di carico, di velocita di trasmissione, accade che il delay end-toend varia. Cio puo dare dei problemi come nel caso delle CBR applications dove il delay jitter causa la perdita di sincronizzazione nel traffico originale della sorgente (fig. 1.5). 10

11 Fig. 1.5: Delay Jitter e sue soluzioni Esistono varie tecniche per far fronte a questo problema: - nel caso A (fig. 1.5A) il receiver non fa nulla di particolare e si limita a trasmettere ai livelli protocollari superiori il pacchetto subito appena questo arriva; cio causa la perdita del punto di playback del segnale (e.g., video o audio); - nel caso B (fig. 1.5B) il receiver fa il playback del segnale basandosi sulla sequenza di tempo originale, e se un pacchetto perde il playback point esso viene scartato; - la tecnica C (fig. 1.5C) prevede l uso di un de-jittered buffer dove tutti i pacchetti ricevuti vengono immagazzinati per un certo tempo (offset delay) prima di essere poi processati dal receiver secondo la sequenza temporale di origine. Buffer grandi permettono di gestire grosse variazioni nei ritardi, ma introducono anche una maggiore latenza che puo superare il limite dell application delay requirement. Si deve allora fare un ragionevole compromesso tra le suddette cose. 11

12 1.1.4 Loss o Error Rate La perdita dei pacchetti condiziona direttamente la qualita percepita dall applicazione; puo compromettere l integrita dell informazione fino a distruggere il servizio. A livello di rete il packet loss puo essere causato da congestione che appunto comporta generalmente la perdita dei pacchetti. Un altra causa e quella di un canale rumoroso come quello wireless (e.g., ) che provoca errori nei bits e quindi lo scarto del pacchetto ricevuto. Esistono anche qui delle tecniche che permettono entro certi limiti di cancellare o compensare le perdite: correzione dell errore a livello fisico, o uso di codec a livello applicativo. Esse pero comportano sempre un aumento dell overhead e quindi una diminuzione del throughput. 1.2 Multimedia Application Requirements Differenti applicazioni multimediali hanno differenti QoS requirements espressi in termini dei parametri di qualita del servizio, precedentemente descritti: throughput, delay, delay variation, loss. In molti casi gli users possono determinare il livello di queste richieste di QoS valutando direttamente i fattori che influenzano la qualita dell applicazione: per esempio, sperimentalmente si osserva che il one-way delay requirement per la voce interattiva (VoIP) deve essere minore di 250msec, pena una inaccettabile qualita del servizio. Questo e un ritardo, come gia visto, somma dei ritardi introdotti da tutti i componenti del communication path: source delay, transmission delay, network delay e destination delay. 12

13 Nel caso wireless gli application requirements sono condizionati dal tipo di supporto fisico usato soprattutto in termini di delay e di throughput, essendo proprio questi dei colli di bottiglia per la limitata bandwidth e per la natura rumorosa del canale di una wireless lan. Prima di vedere nello specifico per ciascun tipo di applicazione il livello ed il tipo di QoS richiesto, diamo un occhiata ai fattori che influenzano gli application requirements. Essi sono: - Application interactivity level: relativo ad applicazioni interattive e non interattive; - User/Application characteristics: caratteristiche di tolleranza o no al ritardo, di adattivita o di non adattivita ; - Application criticality: applicazioni di tipo mission-critical o non-missioncritical. Segue una descrizione dei suddetti Applicazioni Interattive e Non-Interattive Un applicazione interattiva coinvolge una qualche forma di interattivita (azione-reazione, richiesta-risposta, o scambio di informazioni) tra due parti (persona-persona, persona-macchina, macchina-macchina). Ecco alcuni esempi di interactive applications: - persona-persona: telefonia su IP, videoconferenza, voce/video interattivi; - persona-macchina: video-on-demand (VOD), streaming video/audio, realta virtuale; - macchina-macchina: controllo automatico di macchina. In questo tipo di applicazioni e importante il delay che dipende direttamente dal grado di interattivita. Le applicazioni real time di voce interattiva sono le piu stringenti in termini di delay requirement (nell ordine dei millisecondi). 13

14 Lo streaming video, invece, ha minore interattivita (i.e., si ha solo durante le azioni di stop, play, pause, forward e reverse) per cui non richiede risposte in real time e il ritardo puo essere dell ordine dei secondi. In generale un limitato delay requirement comporta anche uno stretto delay jitter requirement; per limitare la variazione del ritardo si puo usare, per esempio, un buffer di ricezione (vedi prima), stando pero attenti a non aumentare troppo il delay complessivo e quindi a non danneggiare, anziche migliorare, il livello di interattivita dell applicazione Tolleranza e Intolleranza La tolleranza e l intolleranza descrivono la sensibilita dell utente nei confronti dei cambiamenti nel valore dei parametri di qualita del servizio. Consideriamo in particolare la tolleranza dell user alla latenza e alla distorsione: - Latency tolerance e intolerance: questa caratteristica determina il grado di rigorosita del delay requirement; per esempio uno streaming video e piu tollerante in termini di ritardo che un applicazione multimediale interattiva. Il livello di delay tolerance dipende dall user satisfaction, da cio che si aspetta l utente e dall urgenza dell applicazione (i.e., un controllo di macchina in remoto in una linea di produzione e intollerante alla latenza); - Distorsion tolerance e intolerance: la tolleranza alla fedelta della qualita dell applicazione dipende da fattori come user satisfaction, user expectation, e il tipo di applicazione multimediale; per esempio gli utenti sono piu tolleranti alla distorsione video che non audio, e quindi la rete deve cercare di mantenere la qualita audio piu di quella video. 14

15 1.1.3 Caratteristiche Adattative e Non-adattative L adattivita o meno descrive la capacita di un applicazione di adattarsi alla degradazione di QoS tramite opportuni meccanismi come rate e delay adaptation: - le rate adaptative applications possono variare il data rate del traffico spedito nella Network; durante una congestione di rete l applicazione puo quindi ridurre il data rate perdendo alcuni pacchetti, aumentando la compressione del codec, o cambiando le sue proprieta multimediali. In questo modo anche se si ha una degradazione della qualita percepita, questa sara comunque mantenuta entro un certo livello; - le delay-tolerant adaptive applications tollerano un certo grado di delay jitter tramite l uso di un de-jittered buffer o con l impiego di tecniche di playback adattative (fig. 1.5). Da aggiungere che l adattivita deve essere gestita dalla rete o dall end user tramite segnali di feedback esplicito o implicito Application Criticality Gli aspetti mission-critical o non-mission-critical riflettono l importanza dell uso di un applicazione, e quindi la rigorosita dei QoS requirements. E il caso della telemedicina o delle applicazioni di chirurgia controllate in remoto dove sono in gioco le condizioni di salute dei pazienti Rappresentazione degli Application Requirements Ci sono due modi per esprimere gli Application Requirements: - in modo quantitativo, - in modo qualitativo. 15

16 Espressione Quantitativa In questo caso gli Application Requirements sono espressi in termini di QoS parameters con valori quantificabili che possono essere determinati dalle specifiche tecniche dell applicazione (i.e., video codec - MPEG1, MPEG2, MPEG4, HDTV) o da prove sperimentali: - Throughput: in generale e espresso come il data rate medio dell applicazione: - HDTV non compresso: 1.5 Gbps - MPEG4: 5 Kbps 4 Mbps - ITU-T G.711: 64 Kbps Nel caso delle VBR applications sono importanti pure altri valori significativi come average rate, peak rate, maximum burst size; - Delay e Jitter: sono forniti in termini di valori limite (e.g, in VoIP il ritardo end-to-end deve essere massimo di 250msec e il delay jitter minore di 40msec); questi limiti sono rigorosi nelle applicazioni di tipo mission-critical o intolleranti al delay, sono invece valori medi negli altri casi; - Loss: viene espresso piu che altro come un valore statistico (e.g., in VoIP la percentuale massima dei pacchetti persi puo essere al massimo del 3%) Espressione Qualitativa I QoS requirements si possono esprimere anche in modo qualitativo:.. avere piu banda che si puo,.. avere un delay basso,.. avere un ritardo minore per questa che non per quell altra applicazione. Il motivo per cui si usa la forma qualitativa anziche quella quantitativa e che alle volte si desidera solo che delle applicazioni (web browsing, remote login) abbiano un servizio migliore che altre, oppure che per alcune applicazioni non e possibile o e troppo costoso quantificare i relativi QoS requirements. 16

17 1.1.6 Esempi di Applications Requirements Voce Interattiva I requirements per le voice applications come Voice over IP si possono riassumere in quanto segue: - Bandwidth: VoIP richiede poca banda (i.e., 64 Kbps per G.711), il traffico voce e relativamente costante e viene pacchettizzato in unita dati ci circa bytes con, quindi, bassi tempi di trasmissione. Siccome le conversazioni vocali possono contenere fino al 60% di silenzio, opportuni algoritmi di codifica della voce permettono requisiti di bandwidth minori con un livello della qualita ancora accettabile. La tabella 1.1 mostra le codifiche standard attualmente in uso. Tabella 1.1: Codifiche Voce Standard - Delay: quando VoIP riguarda la conversazione tra persone, bisogna tenere conto della sensibilta dell orecchio umano alla qualita del suono e ai tempi di risposta nella conversazione. La tabella seguente da delle linee guida in questo senso: Tabella 1.2: Delay guidelines per VoIP 17

18 - Delay Jitter: una grande varianza nel ritardo (tabella 1.3) peggiora la qualita della voce. Tabella 1.3: Delay Jitter guidelines per VoIP - Packet loss: la perdita di pochi pacchetti viene risolta dai codec che riescono a cancellare o a compensare le perdite; cio e vero pero entro certi limiti (i.e., l error rate deve mantenersi in genere sotto il 3 4 %) Applicazioni Video Le applicazioni video possono essere classificate in due gruppi: video interattivo (e.g., videoconferenza, telechirurgia, lezioni a distanza) e streaming video (e.g., RealVideo, QuickTime, Video on Demand, HDTV). La tabella 1.4 mostra i requisiti di banda in relazione al codec usato: Tabella 1.5: Video Codec Bandwidth Requirements 18

19 - Interactive video applications: richiedono bassi valori di end-to-end delay e di delay jitter, specie nel caso mission-critical come nella telechirurgia; - Streaming video applications: lo streaming video e una comunicazione del tipo one-way e cioe dal video server all utente; le uniche interazioni si hanno con i comandi stop, play, reverse, forward, e quindi il delay non e il problema piu grosso. Cosi non e invece per il delay jitter dato che questo puo causare la perdita del playback point e quindi video distorsione. 1.3 I Servizi QoS Le reti ricevono dalle applicazioni (implicitamente o esplicitamente) le richieste (qualitative o quantitative) di qualita del servizio, e rispondono fornendo dei servizi di QoS ottenuti usando opportuni meccanismi. Nel prossimo capitolo vengono analizzati proprio questi meccanismi di qualita del servizio, mentre qui approfondiamo l aspetto dei QoS Services. Essi si possono categorizzare nel modo seguente: - servizi quantitativi, servizi qualitativi, servizi best effort: cioe relativi al tipo di servizio fornito alle applicazioni multimediali; - servizi per-flow, servizi per-class: a seconda dell entita (individuale o gruppo/classe) a cui la rete fornisce il servizio. Le networks possono usare una combinazione di QoS services (i.e., per-flow e quantitativi, per-class e quantitativi), e ne possono pure includere di tipi multipli in modo da dare supporto ad un ampio gruppo di applicazioni. Ecco degli esempi: - Guaranteed Integrated Services (IntServ), che sono di tipo per-flow e quantitativi; - Controlled Load Integrated Services, cioe per-class e qualitativi; - Differentiated Services (DiffServ), servizi per-class e qualitativi. Vediamoli nel dettaglio. 19

20 1.3.1 Servizi Quantitativi (Garantiti) Sono quelli che permettono il piu alto grado di qualita del servizio (hard QoS), garantendo il supporto di application requirements quantitativi per le applicazioni di tipo interattivo o mission-critical. I servizi quantitativi garantiscono la network perfomance (bandwidth, delay, delay jitter) in termini deterministici o statistici (e.g., la rete garantisce il minimo throughput necessario ad un applicazione oppure il ritardo end-to-end e limitato ad un certo valore). Per far funzionare i suddetti servizi sono necessari un gran numero di meccanismi di QoS (Capitolo 2 ) Servizi Qualitativi (Differenziati) Sono quelli che provvedono un supporto di tipo relativo alle applicazioni secondo livelli di priorita, come quando succede per esempio quando si puo assicurare un delay minore ad una certa classe di applicazioni che non ad un altra. Quindi i servizi differenziati forniscono qualita del servizio prima alle classi di piu alta priorita e poi a quelle a priorita piu bassa Servizi Best Effort I servizi best effort non garantiscono nessun supporto QoS: tutto il traffico dati e trattato allo stesso modo senza nessuna distinzione. Vanno bene per applicazioni che non richiedono un minimo di banda o insensibili al ritardo (e.g., FTP, , pagine web). 20

21 1.3.4 Servizi Per-Flow Assicurano un supporto a flussi individuali e cioe alla singola applicazione, in modo quantitativo o qualitativo; per esempio il video interattivo ha un delay requirement piu rigoroso che non lo streaming video per cui la Network deve fornire servizi differenti ai due tipi di applicazione in relazione ai rispettivi bisogni individuali. Il meccanismo base per un servizio per-flow e la QoS classification (Capitolo 2 ) Servizi Per-Class Le applicazioni multimediali possono essere categorizzate in diversi gruppi o classi sulla base di differenti criteri: QoS requirements, organizzazione, tipo di applicazione, famiglia di protocolli). I per-class services permettono il supporto qualitativo o quantitativo ai singoli gruppi con un certo tipo di QoS uguale per tutte le applicazioni della medesima classe. Come per i servizi per-flow, sono necessari dei meccanismi di classificazione per implementare i suddetti servizi (Capitolo 2 ). 21

22 Capitolo 2 Meccanismi per la Qualita del Servizio Nel capitolo precedente sono stati introdotti i concetti fondamentali della qualita del servizio; ora invece analizziamo i meccanismi chiave che permettono la realizzazione dei servizi di QoS. Questi meccanismi possono essere classificati in due categorie a seconda di come viene trattato il traffico dati delle applicazioni (per esempio vedi fig. 2.1 per il caso wireless) : 1) traffic handling mechanisms, 2) bandwidth management mechanisms. Fig. 2.1 : Meccanismi di QoS in una rete wireless I traffic handling mechanisms, chiamati pure in-traffic mechanisms, sono quelli che classificano, gestiscono, e monitorano il traffico dei pacchetti che transitano nella rete. I piu importanti sono : classification, accesso al canale, packet scheduling, traffic policing. I bandwidth management mechanisms, chiamati pure out-of-traffic mechanisms, sono invece quelli che gestiscono le risorse di rete (e.g., 22

23 bandwidth) mediante la configurazione e la coordinazione dei traffic handling mechanisms dei network devices (i.e., hosts, access point). I piu importanti sono : resource reservation signaling (RSVP), admission control. 2.1 Classification Il livello piu basso di servizio che una rete puo fornire e il best effort, dove non si ha QoS e in cui il traffico e trattato tutto allo stesso modo indipendemente dall applicazione o dall host che lo ha generato. Si e visto pero (capitolo 1 ) che per varie applicazioni multimediali e necessario un supporto alla qualita del servizo, migliore del best effort come nel caso dei servizi differenziati o garantiti. Perche una rete possa fornire servizi selettivi a certe applicazioni, prima di tutto e richiesto un meccanismo di classificazione che permetta una differenziazione : il classification mechanism identifica e separa traffici differenti in flussi o gruppi di flussi (flows o classi) in modo che ognuno di essi possa essere trattato in modo selettivo. Il meccanismo di classificazione puo essere implementato in diversi network devices : host, router, switch, access point. La figura 2.2 mostra uno schema semplificato di classification in un end host e in un intermediate device : Fig. 2.2 : Classificazione 23

24 Il traffico dati generato da un applicazione (end host) o proveniente da altri hosts (intermediate device) e identificato dal meccanismo di classificazione e passato alle appropriate code di servizio da altri meccanismi come quello di schedulazione o Packet Scheduler. Il livello di granularita della classificazione puo essere per-user, per-flow, o perclass a seconda del tipo di qualita del servizio fornito; per esempio un QoS perflow service richiede per-flow classification, mentre un QoS per-class service richiede per-class classfication. Ovviamente per identificare e classificare il data traffic, il meccanismo di classificazione abbisogna di una qualche forma di tagging o di marking dei pacchetti. Sono possibili diversi approcci, anche a seconda dell OSI layer dove viene implementata la classificazione (fig. 2.3). Fig. 2.3 : Esempi di Classificazioni per ogni OSI Layer Data Link Layer Classification Il livello Data Link, o livello 2, permette la classificazione dei pacchetti tramite un opportuno tag presente nell header. 24

25 Un esempio e lo standard IEEE 802.1Q, ideato per le VLAN (Virtual LAN), in cui e definito il campo user priority (802.1p) di 3 bits : si hanno 8 livelli di priorita per la differenziazione del traffico dati a livello DL. Vedi fig. seguente. Fig. 2.4 : Tag 802.1Q e 802.1p Un end host o uno switch (che e un dispositivo di livello 2) possono taggare un opportuno livello di priorita dell header del pacchetto a seconda dell applicazione che lo ha generato e del livello di servizio richiesto. IEEE raccomanda un mapping tra valori di user priority e di servizio cosi come mostrato nella tabella 2.1 : Tabella 2.1 : Associazione priorita /traffico raccomandata dall IEEE 25

26 Il traffico dati taggato che attraversa uno switch viene allora classificato tramite un meccanismo che identifica i vari livelli di priorita esaminando il campo 802.1p e, quindi, instradato a differenti code di trasmissione relative a diversi valori di user priority. Lo switch deve allora possedere da almeno 2 ad un massimo di 8 code di trasmissione; anche qui lo standard 802.1p raccomanda la seguente aggregazione : Tabella 2.2 : Relazione tra numero di code e di tipo di traffico La tabella 2.2 mostra come i vari tipi di traffico possono essere suddivisi in code diverse in base al numero di code di cui uno switch dispone. Questa suddivisione presuppone che le code sia gestite con priorita fissa (fixed priority) : il commutatore trasmette tutti i pacchetti contenuti nella coda a massima priorita e, solo quando questa e vuota, trasmette i pacchetti nella coda con priorita immediatamente inferiore, e cosi via. Commutatori piu evoluti possono utilizzare algoritmi di gestione (queuing algotithms) delle code a priorita variabile come round robin, weighted round robin, o weighted fair queuing, in cui il pacchetto da trasmettere viene prelevato da una delle code in base a criteri (anche parecchio sofisticati) che mirano a far si che ogni tipo di traffico ottenga il servizio voluto senza danneggiare gli altri. 26

27 Gli apparati commerciali forniscono comandi di configurazione tramite i quali associare i valori di priorita alle code e determinare le politiche di servizio delle code Network Layer Classification A livello di Rete o livello 3, gli standard Ipv4 e Ipv6 definiscono un campo nell header IP per la priorita del pacchetto che puo essere usato per la Layer 3 classification. La RFC 1349 definisce nell header Ipv4 l ottetto (8 bits) IPTOS o IP Type of Service : come si puo vedere dalla figura 2.5, esso consiste di un sottocampo di 3 bits per la precedenza, segue il sottocampo TOS di 4 bits, mentre l ultimo bit non e usato e vale 0. Il sottocampo di 4 bits TOS permette, ovviamente, 16 livelli di classe di servizio. Fig. 2.5 : Campo IPTOS e DSCP nell header Ipv4 Nell header Ipv6, invece, e presente un campo per la classe di servizio fatto da 8 bits (vedi fig. 2.6). 27

28 Ultimamente la Internet Engineering Task Force (IETF) ha ridefinito il byte IPTOS dell Ipv4 con il campo Differential Service Code Point (DSCP) dove i primi 6 bits permettono 64 classi di servizio (fig. 2.5). Fig. 2.6 : Ipv6 Header e relativo campo di priorita Classificazione del Livello di Trasporto L insieme dei campi nell header IP source IP, destination IP, source port, destination port, e protocol IP puo essere usato per una classificazione di livello 3 o livello di Trasporto. La suddetta quintupla dell header IP puo, infatti, identificare univocamente il flusso dati di una data applicazione, e da quindi un supporto ad un QoS service di tipo per-flow. Purtroppo la Transport Layer classification ha pero dei limiti : - va bene per le edge networks ma per le core networks, che trasportano grossi quantitativi di traffico dati, mantenere una coda per ogni flusso non e possibile; - se i pacchetti passano attraverso un firewall che usa NAT (Network Address Translation), l indirizzo IP reale (i.e., l IP address della sorgente del traffico) e nascosto alle reti al di la del firewall le quali, allora, non potrebbero risalire alla source application se usassero una classificazione di livello 3. 28

29 2.1.4 Application o User Classification Un applicazione o un generico utente possono venire identificati usando un identificatore (ID) che puo essere statico (i.e., contratto o policy), o dinamico (i.e., segnalazione di connessione). Nel caso della connection signaling, nella rete e presente un entita (e.g., una stazione centrale) che e responsabile di decidere se permettere o no una nuova sessione : prima, l applicazione o l utente inviano una richiesta di connessione alla central station; poi, se la nuova connessione e ammessa le sara assegnato un numero ID unico che la identifica. In questo modo i pacchetti generati dall applicazione saranno associati con il relativo ID, e quindi classificati a livello superiore a quello IP. 2.2 Meccanismi di Accesso al Canale Nelle reti locali la trasmissione dei pacchetti originati dalle varie stazioni avviene su un unico mezzo condiviso, che nel caso wireless e l etere. Quindi, quando a provare a trasmettere sono piu hosts, si possono avere delle collisioni tra i pacchetti; si deve allora munire le reti di un channel access mechanism che controlli l accesso al canale condiviso. Ci sono due tipologie di meccanismi di accesso al canale : 1) channel access basato sulle collisioni, 2) channel access esente da collisioni. I meccanismi 1) e 2), come mostrato nel seguito, possono fornire differenti servizi di QoS Collision-Based Channel Access E un metodo di accesso al canale di tipo distribuito : implementa in ogni host della lan dei meccanismi per evitare le collisioni, per risolvere le contese 29

30 nella trasmissione quando queste si verificano, e permette la ritrasmissione dei pacchetti quando questi collidono e sono corrotti. Un classico meccanismo di accesso al canale basato sulle collisioni e il CSMA/CD (Carrier Sense Multiple Access with Collision Detection) che e usato in Ethernet e in generale nelle lan In ambiente wireless, invece, un esempio e il CSMA/CA usato nella DCF delle IEEE , dove CA sta per Collision Avoidance. Nelle reti con collision-based channel access il numero delle collisioni dipende dal carico, e cioe dal numero di utenti attivi che hanno pacchetti da trasmettere nella rete. Al crescere del carico, allora, aumentano le collisioni e le ritrasmissioni, e di conseguenza crescono pure i ritardi. Gli accessi al canale condiviso sono aleatori e quindi la trasmissione dei pacchetti non e prevedibile, cosi come non lo e il delay. Il servizio offerto e dunque di tipo best effort : tutti gli hosts nella rete ricevono uguale banda e il ritardo end-to-end non ha un limite superiore. Un modo per avere qualita del servizio puo essere quello di aggiungere ulteriori meccanismi per la priorita come, per esempio, usare backoff windows di dimensione diversa per differenti classi di priorita. Questo e cio che si propone di fare il gruppo di lavoro e ( e sta per enhancemed), come illustrato meglio nel 3 capitolo Collision-Free Channel Access Con il collission-free channel access mechanism il canale e arbitrato in modo che le collisioni non possano mai avvenire : solo ad un solo host per volta e concesso di trasmettere in e per un certo periodo di tempo. Esempi delle suddette tecniche sono il Polling e il TDMA (Time Division Multiple Access). 30

31 Polling In una rete wireless si uo fare in modo che l Access Point o AP si comporti come poller, e cioe che controlli l accesso al wireless channel da parte delle altre stazioni. Queste non possono trasmettere data traffic sino a che non vengano autorizzate a farlo tramite la ricezione di un opportuno pacchetto di polling inviato dall AP. In questo modo, si capisce, le collisioni non avvengono mai; inoltre alcuni hosts possono ricevere il poll piu volte di altri, e quindi la frequenza di polling riflette l allocazione di bandwidth assegnata. Ovviamente l access point puo variare dinamicamente la banda concessa alle stazioni variando appunto la polling frequency TDMA (Time Division Multiple Access) Uno schema TDMA divide il channel access opportunity in frames e ciascuno di essi e a sua volta suddiviso in time slots (TS). Ad ogni host e permesso di trasmettere i pacchetti in un predefinito time slot, come mostrato in figura 2.7. Fig. 2.7 : Schema Time Division Multiple Access 31

32 Il numero di slots temporali associato ad una stazione riflette la banda allocata alla stessa. Anche questa tecnica richiede un entita di tipo master che gestisca l assegnazione dei time slots per tutti gli hosts della rete, che determini quanti TS assegnare a ciascun host, e che lo notifichi alla stazione tramite un qualche meccanismo di segnalazione. Ci sono diverse filosofie a riguardo : - static time slot assignment :ciascuna STA (stazione) riceve un numero fisso di TS notificati durante il connection setup; - dynamic time slot assignment : l assegnazione dei time slots cambia dinamicamente in funzione del carico di traffico, degli application QoS requirements, e delle condizioni del canale. Con questa policy si ha piu flessibilita e pure una migliore utilizzazione del canale, anche se pero aumenta l overhead dovuto alla segnalazione necessaria per comunicare gli assignment changes alle STAs. Per concludere, gli collision-free channel access schemes permettono un rigoroso controllo per l accesso al canale condiviso, e possono quindi fornire delay piu limitati nella trasmissione dei pacchetti. Vanno bene, allora, la dove sono richiesti requirements di qualita del servizio piu rigorosi. 2.3 Meccanismi di Schedulazione dei Pacchetti Il Packet Scheduling e il meccanismo che seleziona un pacchetto per la trasmissione dalle code che si formano con la classificazione dei pacchetti; decide che pacchetto (da quale coda o queue) e quale stazione schedulare per la trasmissione in un certo periodo di tempo : in questo modo lo scheduling controlla la bandwidth allocata alle stazioni, alle classi, alle applicazioni. Come mostrato in fig. 2.7, ci sono due livelli di meccanismi di schedulazione dei pacchetti : 32

33 1) Intrastation packet scheduling : cioe schedulazione tra le queues all interno di uno stesso host; 2) Interstation packet scheduling : meccanismo di scheduling che sceglie un pacchetto tra le code di differenti hosts. Fig. 2.7 : Schema Time Division Multiple Access La schedulazione puo essere implementata usando un approccio di tipo gerarchico o di tipo orizzontale (flat) : - packet scheduling gerarchico : un meccanismo (una policy o un entita ) di interstation scheduling assegna ad ogni stazione un certo quantitativo di banda, e cioe permette che ciascuna STA possa trasmettere per un determinato periodo di tempo. Quando poi una stazione riceve l opportunita di trasmettere, il meccanismo di intrastation packet scheduling decidera quale pacchetto scegliere per la trasmissione. Questo approccio e quindi scalabile dato che la schedulazione tra stazioni si preoccupa solo di allocare ad esse in modo opportuno tutta la bandwidth disponibile. E invece ogni STA che, poi, gestisce in proprio la porzione di banda assegnata, distribuendola alle varie applicazioni o classi di applicazioni tramite il meccanismo di intrastation scheduling. - flat packet scheduling : e quello che si basa su tutte le code di tutte le stazioni; ogni queue di ogni STA riceve, dunque, un servizio individuale dalla rete. 33

34 Il packet scheduling mechanism lavora, quindi, in modo simile ad un meccanismo di accodamento o queuing : recupera pacchetti dalle code per permetterne la trasmissione sul canale. Pero bisogna notare delle differenze. L intrastation scheduling, dato che all interno di una stazione si conosce lo stato di ciascuna coda, e virtualmente identico ad un queuing mechanism. L interstation scheduling, invece, e leggermente differente da un meccanismo di queuing perche non sa come le code sono distribuite tra le varie STAs, e quindi abbisogna di un qualche altro meccanismo di segnalazione per coordinare la schedulazione tra gli hosts. Proprio per questa similarita tra meccanismi di packet scheduling e di queuing, segue la descrizione di alcuni tra i piu importanti schemi elementari di accodamento che sono alla base per la costruzione di altri piu sofisticati : FIFO (First In First Out), Strict Priority, e Weight Fair Queue (WFQ) First In First Out (FIFO) E il piu semplice queuing mechanism : tutti i pacchetti sono accodati in un unica coda e vengono schedulati nell ordine di arrivo (fig. 2.8). Fig. 2.8 : FIFO Packet Scheduling 34

35 FIFO fornisce servizio best effort, dato che non prevede nessuna differenziazione dei packets. In questo modo un applicazione che genera un flusso di traffico piu grande di quello di un altra, ottiene una porzione di banda maggiore. In generale tutti i flussi sono caratterizzati dallo stesso delay medio; se pero un packet flow aumenta aggressivamente la sua portata, i flussi dati delle altre applicazioni si ritrovano una diminuzione della banda e si ha pure un aumento del ritardo medio. Si puo qui, allora, fornire un supporto QoS tramite traffic policing (per limitare il rate di ciascun flow) e admission control (vedi poi) Strict Priority Alle code e assegnato un ordine di priorita ; lo scheduler strict priority processa i pacchetti secondo quest ordine. Quindi i pacchetti nelle code a piu alta precedenza sono trasmessi sempre prima di quelli nelle queues a priorita minore, che invece possono essere trasmessi solo quando non ci sono packets in attesa nelle code di priorita maggiore. La figura 2.9 illustra graficamente il meccanismo di strict priority packet scheduling. Fig. 2.8 : Strict Priority Packet Scheduling 35

36 Strict priority fornisce servizi differenziati in termini sia di banda che di delay : le code a priorita alta ottengono la maggior parte della bandwidth (sino a prenderla tutta), mentre le lower priority queues ricevono la rimanente. Ovviamente, priorita piu alta comporta pure delay piu bassi. Anche qui se un packet flow, accodato in una coda a priorita alta, aumenta aggressivamente la sua portata, i flussi dati nelle altre code (con minore precedenza) possono morire di fame (starving). Si puo quindi fornire un ulteriore supporto di QoS con l impiego di traffic policing (per limitare il rate di ciascun flow) e di admission control (vedi poi) Weight Fair Queue (WFQ) La tecnica WFQ schedula il traffico dei pacchetti sulla base del weight ratio di ogni coda. Un peso w i e assegnato a ciascuna coda i secondo la network policy. w1 w2 w3 Per esempio (fig. 2.9), siano date 3 code A, B, C con pesi,, rispettivamente. A, B, C riceveranno le seguenti quantita di banda : coda A : w 1 /( w1 + w2 + w3 ) coda B : w 2 /( w1 + w2 + w3 ) coda C : w 3 /( w1 + w2 + w3 ) Fig. 2.9 : Weight Fair Queue Packet Scheduling 36

37 Questa volta un uso eccessivo di banda da parte di una specifica coda non avra effetto sulle altre : WFQ fornisce al massimo la bandwidth assegnata tramite il relativo peso w i. La delay perfomance e inoltre direttamente legata alla banda allocata : una coda con alta bandwidth allocation (grande valore di un basso valore di ritardo nella trasmissione dei pacchetti. w i ) sara caratterizzata da Da notare che pero, alle volte, certe applicazioni abbisognano di low band e di low delay, oppure di high band e di high delay; in questo caso WFQ scheduling puo sempre e solo fornire una grossa banda (quindi piccolo ritardo), sprecando l uno o l altro attributo (bandwidth o delay) che non rientra tra i requirements dei suddetti tipi di applicazione. Comunque in generale WFQ e usato per la schedulazione di pacchetti relativi a gruppi di flows o a classi, e non a flussi individuali; in questo caso si mira a dare piu importanza al throughput che non al delay Osservazioni su Channel Access e Packet Scheduling Prima di continuare con la descrizione su altri meccanismi di QoS, e doveroso osservare che non sempre le tecniche di Channel Access e di Packet Scheduling sono mutualmente esclusive. Infatti ci sono delle coincidenze e delle somiglianze, tanto che i due discussi meccanismi possono alle volte essere fusi in una unica soluzione di qualita del servizio. 37

38 2.4 Traffic Policing Mechanism Il meccanismo di Traffic Policing e quello che si occupa di monitorare il traffico dati che lo attraversa in modo che questo sia conforme a prefissati parametri di QoS. Quando si verifica una violazione (e.g., e inviato piu traffico di quanto inizialmente concordato all apertura della sessione), il suddetto meccanismo si comporta da shaper in modo da limitare il traffico eccessivo, riportandolo ai valori prestabiliti. Il traffic policing puo essere applicato ai singoli flussi di pacchetti delle applicazioni multimediali. Si basa su valori quantitativi e conosciuti che, appunto, sono i parametri di QoS per il traffico dati. Dato che le applicazioni real-time come video e voce usano codec che forniscono una certa conoscenza dei parametri di traffico, esse sono sempre compatibili con la policy. Cosi non e, invece, per il non-real-time traffic che generalmente chiede tanta banda quanto piu ne e possibile. Il traffic policing si applica proprio a questo tipo di traffico per il quale si preoccupa di limitarne la banda secondo la network policy adottata. Il meccanismo di policing si puo implementare su end hosts o su intermediate hosts; esempi di traffic policing sono i meccanismi noti con i nomi di leaky bucket (secchio bucato) e di token bucket Leaky Bucket E un meccanismo di smoothing per il traffico che agisce limitando il traffic rate e il massimo burst size; ha il nome di leaky bucket perche si sfrutta l analogia con un secchio bucato per descriverne il funzionamento. 38

39 I parametri del secchio (i.e., la dimensione e la misura del buco) sono, infatti, analoghi ai parametri di policy come il maximum burst size e il maximum rate (rispettivamente). Il leaky bucket fa lo shaping del traffico limitandone il rate fino ad un massimo pari al valore del bucket rate; Il bucket size determina il massimo burst size prima che il secchio cominci a perdere i pacchetti. Il meccanismo, allora, lavora nel seguente modo (segui esempio in fig. 2.10). I pacchetti in arrivo sono inseriti in cima al secchio; sul fondo del bucket c e un buco attraverso cui il traffico puo uscire con un rate massimo pari a r bytes per secondo. La dimensione del secchio e di b bytes (i.e., ne puo contenere al piu b bytes). Fig : Meccanismo del Leaky Bucket - Fig (A) : Inizialmente il secchio e vuoto; dei pacchetti cominciano ad arrivare con rate pari a R, minore del bucket rate r. In questo caso il traffico in uscita avra un data rate pari a R, mentre il burstiness dell incoming traffic e lo stesso di quello dell outgoing traffic (almeno fino a quando R < r). - Fig (B) : Stavolta, il traffico dei pacchetti in ingresso e R > r; l outgoing traffic rate e uguale a r. - Fig (C) : Come in (B) ma il secchio e pieno. Il traffico in eccesso viene perso (dropped) o inviato come best effort. 39

40 2.4.1 Token Bucket Il Token Bucket mechanism e simile a quello del Leaky Bucket tranne per il fatto di preservare l aspetto burstiness del traffico. Questa volta r (bytes per secondo) e il rate dei gettoni che finiscono nel secchio, la cui dimensione e pari a b bytes. Quando arriva un pacchetto, questo prende un token (se ne e disponibile almeno uno) e, quindi, viene trasmesso in uscita. Fino a quando ci sono gettoni nel secchio, il rate del traffico in uscita sara uguale a quello dell incoming traffic. Se il tocken bucket e vuoto, i pacchetti in arrivo devono aspettare sino a che non ci siano di nuovo gettoni disponibili nel secchio : solo allora saranno autorizzati ad uscire. La figura seguente e un esempio del meccanismo token bucket : Fig : Meccanismo del Token Bucket 40

41 - Fig (A) : L incoming traffic rate (R) e minore di quello di arrivo dei tokens (r). Quindi il traffico in uscita e pari a quello in ingresso. - Fig (B) : Questa volta R e piu grande del rate dei gettoni; fino a quando ci sono tokens nel secchio, i pacchetti all ingresso vanno tutti in uscita. - Fig (C) : Se il rate R del traffico in ingresso continua ad essere maggiore di r (e.g., lungo burst di traffico), prima o poi finiranno i gettoni disponibili nel bucket. In questo caso i pacchetti dovranno attendere l arrivo di nuovi tokens perche ad essi sia permesso di transitare fuori. Quindi l outgoing traffic viene limitato al token arrival rate. La tecnica del token bucket permette, allora, di conservare il burst del data traffic : i pacchetti che escono mantengono un rate medio massimo pari al token rate r, quindi il secchio a gettoni puo venire usato per controllare l average rate del traffico dati. Generalmente le due tecniche di traffic policing (token bucket e leaky bucket) sono combinate insieme (prima token, poi leaky) : il secchio a gettoni fa si che il data rate medio sia limitato a quello dei tokens, mentre il leaky bucket limita il peak data rate a quello del secchio bucato. 2.5 Resource Reservation Signaling (RSVP) I meccanismi per la gestione del traffico descritti prima (classificazione, accesso al canale, schedulazione dei pacchetti, traffic policing) permettono la qualita del servizio in ogni dispositivo di rete. Cio pero non basta a fare QoS di tipo end-to-end perche e necessaria anche una coordinazione tra i vari end host e ogni nodo intermedio. Il meccanismo di Resource Reservation Signaling si occupa, quindi, di informare (usando le risorse della rete) ciascuna entita sui QoS requirements delle applicazioni multimediali che hanno luogo. Questa informazione viene elaborata da ciascun dispositivo perche usi i meccanismi di gestione del traffico cosi da controllare le sue risorse, come per esempio la banda, in modo da soddisfare tali application requirements. 41