QoS a Livello Network
1 like729 views
Il documento fornisce una panoramica sulla qualità del servizio (QoS) nelle reti, spiegando come il protocollo IP operi su base 'best effort' e la necessità di gestire flussi di traffico diversificati con requisiti specifici. Viene discussa la differenziazione dei servizi tramite approcci come Integrated Services e Differentiated Services, con un focus sulle politiche di gestione della congestione e sul ruolo degli algoritmi di admission control. Infine, il documento affronta le sfide legate all'implementazione della QoS nelle reti mobili e l'importanza della gestione interdominio.
![QoS: definizione
La qualitá del servizio (QoS) é la capacitá di una
infrastruttura di differenziare il servizio fornito a piú flussi di
traffico concorrentemente presenti sulla rete. [RFC 2990]
Non si puó infatti contare sul fatto che la banda disponibile
sia sempre sufficientemente elevata né risulta economico
sovradimensionare le risorse di rete (overprovisioning)
– p.](https://image.slidesharecdn.com/qos-rete-100108100317-phpapp01/85/QoS-a-Livello-Network-4-320.jpg)
![Flussi (2)
Maximum packet size M: dimensione massima dei
pacchetti (idem)
Il meccanismo di funzionamento é sostanzialmente il
seguente: nel bucket arrivano b gettoni al secondo, e
quando viene ricevuto un pacchetto di lunghezza N ne
vengono tolti N. Se non ci sono abbastanza gettoni da
togliere, si aspetta che ne arrivino altri. Quando i pacchetti
hanno pagato il numero di gettoni dovuto vengono
processati (smooth).
I token bucket possono essere ostili al TCP [RFC 2990].
– p. 1](https://image.slidesharecdn.com/qos-rete-100108100317-phpapp01/85/QoS-a-Livello-Network-10-320.jpg)
![Integrated Services (1)
É una emulazione di circuito su reti IP [RFC 1633], quindi si
allontana molto dal tradizionale approccio best effort. Si
basa su un protocollo di prenotazione (Resource
Reservation Protocol, RSVP [RFC 2205]) ed opera su
singoli flussi.
– p. 1](https://image.slidesharecdn.com/qos-rete-100108100317-phpapp01/85/QoS-a-Livello-Network-12-320.jpg)
QoS a Livello Network
- 1. QoS a livello Network Paolo Campegiani paolo@paolocampegiani.it http://www.paolocampegiani.it – p.
- 2. IP: un protocollo best effort Il protocollo IP é un protocollo best effort: non c’é garanzia che i pacchetti spediti raggiungano la destinazione i tempi per la consegna possono grandemente variare alcuni pacchetti possono andare persi e devono essere ritrasmessi Questo modus operandi permette di costruire reti IP grandemente scalabili e robuste, ma cosa succede a livello applicativo? – p.
- 3. Le richieste del livello applicativo Esistono piú tipi di traffico, che hanno esigenze diverse: FTP, e-mail: scarsamente interattivi Web: da interattivo a molto interattivo giochi online: molto interattivo streaming audio/video: molto interattivo, con vincoli sulla varianza nel ritardo dei pacchetti (jitter ) e sulla quantità di dati persi Un gestione efficiente del livello Network dovrebbe dare più risorse al traffico con vincoli temporali piú stringenti. – p.
- 4. QoS: definizione La qualitá del servizio (QoS) é la capacitá di una infrastruttura di differenziare il servizio fornito a piú flussi di traffico concorrentemente presenti sulla rete. [RFC 2990] Non si puó infatti contare sul fatto che la banda disponibile sia sempre sufficientemente elevata né risulta economico sovradimensionare le risorse di rete (overprovisioning) – p.
- 5. Come si definisce la QoS (1) Qualitá: Insieme di elementi concreti che definiscono la natura di qualcosa, e ne permettono la valutazione (Zingarelli). Esistono metriche diverse per la qualitá, a seconda di quanto occorre al livello applicativo. Le metriche possono essere di tipo assoluto o relativo. Esempi di metriche assolute: “L’applicazione puó inviare 200 kbps sostenuti” (banda) “Il 99% dei pacchetti arriva a destinazione entro 300 ms” (delay) “Nel 98% dei casi i pacchetti arrivano tra 90 e 98 ms” (jitter) – p.
- 6. Come si definisce la QoS (2) Nelle metriche relative si differenziano i flussi in categorie (tenendo conto di aspetti applicativi, tariffe pagate dagli utenti, servizio richiesto...) e si stabilisce che i pacchetti in categorie migliori sono sempre trattati “meglio” dei pacchetti appartenenti a categorie peggiori. Per appartenere ad una categoria migliore in genere occorre pagare di piú per l’uso delle risorse di rete. – p.
- 7. Come si definisce la QoS (3) Si puó pensare che l’utilizzatore di una rete sia disposto a corrispondere una certa tariffa in base al ritardo che impiegano i suoi dati a viaggiare nella rete. guadagno Y D D’ tempo Quindi lo scopo di una architettura QoS diviene quello di massimizzare il totale dei guadagni ottenuti. – p.
- 8. Obiettivi di una QoS Controllare la rete in modo che i tempi di risposta siano predicibili Permettere di stabilire in anticipo il livello di servizio che si otterrá dalla rete Arbitrare l’accesso alla rete in modo tale che alcuni servizi siano privilegiati Fornire un accesso “equo” alle risorse Massimizzare l’uso della rete Tutto questo con un coinvolgimento attivo del network (che attualmente é un componente passivo, lasciando alcuni di questi compiti a TCP). – p.
- 9. Flussi (1) Con flow si intende un unico e mono-direzionale flusso di dati tra un destinatario ed un ricevente. I flussi sono usati per specificare i requisiti di banda per QoS a livello network. Traffic Specification (TSPec, RFC 2215) é un modello token-bucket: Token rate r: massimo service rate Bucket depth d: extra data rate per brevi periodi di tempo (burst data rate) Peak rate p: massimo tasso di invio (se noto, altrimenti infinito) Minimum policed size m: dimensione minima dei pacchetti (tutti i pacchetti piú piccoli di m sono considerati grandi m). – p.
- 10. Flussi (2) Maximum packet size M: dimensione massima dei pacchetti (idem) Il meccanismo di funzionamento é sostanzialmente il seguente: nel bucket arrivano b gettoni al secondo, e quando viene ricevuto un pacchetto di lunghezza N ne vengono tolti N. Se non ci sono abbastanza gettoni da togliere, si aspetta che ne arrivino altri. Quando i pacchetti hanno pagato il numero di gettoni dovuto vengono processati (smooth). I token bucket possono essere ostili al TCP [RFC 2990]. – p. 1
- 11. SLA Un Service Level Agreement é un contratto tra un cliente ed un fornitore di connettivitá Internet che disciplina il servizio che i dati del cliente riceveranno, quindi quali parametri misurare, come misurarli (attivamente o passivamente), le modalitá di rimborso in caso di non rispetto. Si tratta quindi della visione ad alto livello e contrattuale di un sistema con QoS. – p. 1
- 12. Integrated Services (1) É una emulazione di circuito su reti IP [RFC 1633], quindi si allontana molto dal tradizionale approccio best effort. Si basa su un protocollo di prenotazione (Resource Reservation Protocol, RSVP [RFC 2205]) ed opera su singoli flussi. – p. 1
- 13. Integrated Services (2) Nella prima fase del protocollo, viene memorizzato tutto il percorso che collega la sorgente del flusso con il destinatario: 1. La sorgente del flusso determina il TSpec del flusso e invia un messaggio PATH al destinatario 2. Quando un router riceve un pacchetto PATH memorizza nel pacchetto stesso l’indirizzo del router precedente e lo inoltra poi verso la destinazione 3. Il destinatario riceve il pacchetto PATH – p. 1
- 14. Integrated Services (3) A questo punto il destinatario conosce il percorso che seguiranno i dati del mittente, e su questo percorso invia un pacchetto RESV. Quando un router riceve un pacchetto RESV decide (con un admission control) se puó fornire le risorse richieste (banda e memoria) per processare i pacchetti del flusso. In caso affermativo inoltra il pacchetto RESV al router successivo. Altrimenti comunica al destinatario il rifiuto. – p. 1
- 15. Integrated Services (4) Se la sorgente riceve il pacchetto RESV vuol dire che il circuito virtuale é stato creato, e puó cominciare ad inviare pacchetti. Quando il flusso non serve piú invia ai router del percorso una notifica di chiusura. C’é un approccio soft-state: il mittente deve reinviare periodicamente un pacchetto PATH altrimenti i router rilasciano le risorse associate al flusso. – p. 1
- 16. Integrated Services (5) Sono possibili due livelli di servizio: Guaranteed Service l’emulazione di circuito Controlled Load Service é un best effort Il problema di questo protocollo é la scalabilitá: i router devono tener conto di molte informazioni ed hanno uno stato! – p. 1
- 17. Differentiated Services (1) In questa soluzione architetturale il traffico viene ripartito in grandi flussi aggregati. Questo viene fatto utilizzando il campo TOS (Type Of Service) di IPv4 che viene ridefinito come DSCP (DiffServ Code Point). Il DSCP si mappa in un PHB (Per Hop Behaviour) che specifica come ogni router deve gestire il pacchetto, ad esempio con politiche a prioritá per il dropping e lo scheduling. – p. 1
- 18. Differentiated Services (2) Il DSCP viene impostato dal mittente (o dal primo router), e a paritá di DSCP il trattamento é lo stesso: in questo modo i router devono distinguere solo tra poche classi di traffico. Sono presenti due modelli di servizio: Premium Service simile al Guaranteed Service di IntServ Assured Service diviso in 4 classi. L’applicazione che imposta il DSCP non effettua una negoziazione esplicita, quindi le sue richieste di QoS potrebbero essere onorate o meno. – p. 1
- 19. Confronti tra IntServ e DiffServ Proprieta’ Integrated Services Differentiated Services Granularita’ Flusso Aggregati Informazioni di stato Flusso Aggregato Classificazione pacchetti Quintupla (TSpec) Byte DS di IP Tipo di differenziazione Determ/Statistica Assoluta/relativa Admission Control Necessario Nec. per diff. ass. Protocollo di segnalazione RSVP Solo per diff. ass. Coordinamento End to End Per Hop Scalabilita’ No Si’ Network accounting In base al flusso In base alla classe Organizzazione Network Circuiti Virtuali Datagrammi Accordi per interdominio Multilaterali Bilaterali Livello Applicazione Trasporto – p. 1
- 20. IntServ e DiffServ RSVP e DiffServ possono essere impiegati insieme, avendo ambiti di applicazione ottimali diversi e complementandosi a vicenda. Sui router centrali di Internet si usa DiffServ, poiché questi router gestiscono centinaia di migliaia di flussi. Sui router periferici (dove la congestione é piú alta) si usa IntServ (ad esempio per gestire flussi multimediali in una Intranet). Vengono definite delle mappe tra i flussi di RSVP e i valori di DSCP. Le applicazioni richiedono esplicitamente di avere QoS e hanno notifica quando non é possibile – p. 2
- 21. QoS routing Sia IntServ che DiffServ usano il percorso individuato per best effort (con SPF) ma non c’é garanzia che questo sia il miglior percorso per fare QoS. In una comunicazione TCP sono presenti due flussi, e il routing non garantisce la simmetria dei flussi. QoS routing: cercare non un percorso best effort ma un percorso capace di QoS (traffic engineering: MPLS?). – p. 2
- 22. Router e QoS I router sono la componente di rete essenziale per avere QoS. out profile Dropper Pacchetti in profile Classifier Marker Meter out profile Shaper out profile – p. 2
- 23. Componenti di un router Classifier riceve i pacchetti e determina il flusso/aggregato al quale appartengono (DSCP, Flow Label di IPv6...) Marker etichetta se serve i pacchetti (ad es. aggiungendo DSCP) Meter elabora statistiche sui pacchetti e determina se sono in profilo o fuori profilo (rispettano lo SLA o meno) Dropper scarta i pacchetti fuori profilo Shaper riceve pacchetti fuori profilo e prova a ritardarli per riportarli in profilo Dopo questa fase i pacchetti vengono accodati. – p. 2
- 24. Gestione della coda La causa tipica di perdita dei pacchetti é la congestione TCP ha meccanismi propri di gestione della congestione non tutto il traffico é TCP una gestione efficace della congestione puó essere fatta sui router con una opportuna politica di dropping e scheduling – p. 2
- 25. Politiche di dropping (1) Politiche elementari di dropping: drop tail (del vino): se la coda é piena si scarta l’ultimo pacchetto arrivato drop front (del latte): se la coda é piena si scarta il primo pacchetto in coda Nessuna di queste politiche é migliore in assoluto, dipende dal tipo di traffico su cui opera (ovvero dalla presenza o meno di meccanismi di livello superiore di gestione della congestione). – p. 2
- 26. Politiche di dropping (2) Politiche evolute di dropping: Random Early Detection (RED) considera la lunghezza L della coda per decidere come operare: L < minth accetta tutti i pacchetti minth < L < maxth con probabilitá P crescente con L scarta un pacchetto a caso tra tutti i presenti L > maxth scarta con certezza un pacchetto a caso tra tutti i presenti La scelta di un pacchetto in modo casuale evita fenomeni di sincronizzazione globale. – p. 2
- 27. Politiche di dropping (3) RIO (Red with In/Out bits): discrimina tra pacchetti in profilo e fuori profilo, calcolando Lin per i pacchetti in profilo e Ltot per tutti. minout < minin quindi pacchetti out sono scartati per primi La probabilitá di drop per i pacchetti out é maggiore di quella per i pacchetti in maxout < maxin quindi scarta ogni pacchetto out prima – p. 2
- 28. Politiche di dropping (4) Il risultato di queste scelte é che i pacchetti in profile vengono scartati solo come extrema ratio, tentando di rimuovere quelli out profile quando si comincia ad avvertire la congestione. 1 1 P(drop out) P(drop in) P_max_out P_max_in min_in max_in L_in min_out max_out L_total – p. 2
- 29. Politiche di scheduling FCFS (FIFO) usa una sola coda Priority Scheduling ogni classe ha una propria coda e vengono svuotate prima le code delle classi a prioritá maggiore. Permette differenziazione relativa tra le classi Weighted Fair Queueing (WFQ) ogni classe riceve una quantitá di servizio proporzionale alla sua prioritá, quindi ogni tanto vengono prelevati pacchetti anche dalle classi meno privilegiate Earliest Deadline First (EDF) ogni pacchetto deve essere spedito entro un certo tempo, e EDF cerca di massimizzare il numero di volte che il vincolo viene soddisfatto – p. 2
- 30. QoS interdominio Nel caso generale, una comunicazione tra due entità coinvolge più di un Autonomous System, quindi occorrono meccanismi di gestione della QoS che possano essere interdominio. Questo include meccanismi di autenticazione, autorizzazione ed accounting (AAA), ma non c’è ancora accordo su meccanismi condivisi. – p. 3
- 31. Algoritmi di Admission Control (1) Il ruolo di un algoritmo di admission control é quello di garantire che l’accesso di un nuovo flusso ad una risorsa di rete limitata non violi i livelli di servizio per i flussi che giá usano quella risorsa, cercando inoltre di massimizzarne il profitto derivante dall’uso. – p. 3
- 32. Algoritmi di Admission Control (2) Per operare un algoritmo di admission control tiene conto delle risorse richieste per il flusso che si deve ammettere, e questo puó essere fatto in due modi: stima a priori stima dinamica con uno stimatore In generale sono possibili più classi di servizio, per ognuna delle quali si puó definire una probabilitá di call-blocking, ovvero la probabilitá che una richiesta di quella classe non sia ammessa. – p. 3
- 33. Algoritmi di Admission Control (3) I requisiti di QoS possono essere definiti in vari modi: rapporti esistenti tra le probabilitá di call-blocking per richieste di classi diverse deviazione dal livello di servizio pattuito profitto complessivamente ottenuto (considerando guadagni per richieste onorate e perdite per richieste rifiutate) In generale un problema di admission control é un problema complicato, e si puó risolvere solo in modo approssimato. – p. 3
- 34. QoS e reti mobili Nelle reti mobili la QoS é essenziale: maggiore variabilitá delle condizioni della rete costi maggiori della rete contenuti multimediali (VoIP) Le architetture di QoS attualmente presenti non sono state pensate per nodi mobili (ad esempio RSVP crea un circuito virtuale ma il nodo puó spostarsi e occorre “spostare” il circuito virtuale). – p. 3
- 35. Algoritmi di Call Admission Control Sono algoritmi di admission control specializzati per reti mobili. In queste reti un flusso puó essere accettato nell’ambito della rete di una cella, poi puó avvenire un handoff verso una nuova cella e occorre una nuova decisione di admission control, che deve tuttavia tenere conto del fatto che il flusso era giá stato accettato nella vecchia cella, e quindi privilegiarlo (per quanto possibile), in modo da non sprecare il lavoro fatto. – p. 3
- 36. Riferimenti N. Vasiliou, “Reading Course Paper: Overview of QoS and Web Server QoS”, Dept. of Computer Science University of Western Ontario, Canada. RFC 2990 “Next Steps for QoS Architecture” – p. 3