qos a livello network
DESCRIPTION
TRANSCRIPT
IP: un protocollo best effort
Il protocollo IP é un protocollo best effort:
non c’é garanzia che i pacchetti spediti raggiungano ladestinazione
i tempi per la consegna possono grandemente variare
alcuni pacchetti possono andare persi e devono essereritrasmessi
Questo modus operandi permette di costruire reti IPgrandemente scalabili e robuste, ma cosa succede a livelloapplicativo?
– p.
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 vincolisulla varianza nel ritardo dei pacchetti (jitter ) e sullaquantità di dati persi
Un gestione efficiente del livello Network dovrebbe dare piùrisorse al traffico con vincoli temporali piú stringenti.
– p.
QoS: definizione
La qualitá del servizio (QoS) é la capacitá di unainfrastruttura di differenziare il servizio fornito a piú flussi ditraffico concorrentemente presenti sulla rete. [RFC 2990]Non si puó infatti contare sul fatto che la banda disponibilesia sempre sufficientemente elevata né risulta economicosovradimensionare le risorse di rete (overprovisioning)
– p.
Come si definisce la QoS (1)
Qualitá : Insieme di elementi concreti che definiscono lanatura di qualcosa, e ne permettono la valutazione(Zingarelli).
Esistono metriche diverse per la qualitá, a seconda diquanto occorre al livello applicativo. Le metriche possonoessere 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 300ms” (delay)
“Nel 98% dei casi i pacchetti arrivano tra 90 e 98 ms”(jitter)
– p.
Come si definisce la QoS (2)
Nelle metriche relative si differenziano i flussi in categorie(tenendo conto di aspetti applicativi, tariffe pagate dagliutenti, servizio richiesto...) e si stabilisce che i pacchetti incategorie migliori sono sempre trattati “meglio” deipacchetti appartenenti a categorie peggiori.
Per appartenere ad una categoria migliore in genereoccorre pagare di piú per l’uso delle risorse di rete.
– p.
Come si definisce la QoS (3)
Si puó pensare che l’utilizzatore di una rete sia disposto acorrispondere una certa tariffa in base al ritardo cheimpiegano i suoi dati a viaggiare nella rete.
Y
tempo
guad
agno
D D’
Quindi lo scopo di una architettura QoS diviene quello dimassimizzare il totale dei guadagni ottenuti.
– p.
Obiettivi di una QoS
Controllare la rete in modo che i tempi di risposta sianopredicibili
Permettere di stabilire in anticipo il livello di servizio chesi otterrá dalla rete
Arbitrare l’accesso alla rete in modo tale che alcuniservizi siano privilegiati
Fornire un accesso “equo” alle risorse
Massimizzare l’uso della rete
Tutto questo con un coinvolgimento attivo del network (cheattualmente é un componente passivo, lasciando alcuni diquesti compiti a TCP).
– p.
Flussi (1)
Con flow si intende un unico e mono-direzionale flusso didati tra un destinatario ed un ricevente. I flussi sono usatiper specificare i requisiti di banda per QoS a livello network.Traffic Specification (TSPec, RFC 2215) é un modellotoken-bucket:
Token rate r : massimo service rate
Bucket depth d : extra data rate per brevi periodi ditempo (burst data rate)
Peak rate p : massimo tasso di invio (se noto, altrimentiinfinito)
Minimum policed size m : dimensione minima deipacchetti (tutti i pacchetti piú piccoli di m sonoconsiderati grandi m).
– p.
Flussi (2)
Maximum packet size M : dimensione massima deipacchetti (idem)
Il meccanismo di funzionamento é sostanzialmente ilseguente: nel bucket arrivano b gettoni al secondo, equando viene ricevuto un pacchetto di lunghezza N nevengono tolti N. Se non ci sono abbastanza gettoni datogliere, si aspetta che ne arrivino altri. Quando i pacchettihanno pagato il numero di gettoni dovuto vengonoprocessati (smooth).I token bucket possono essere ostili al TCP [RFC 2990].
– p. 10
SLA
Un Service Level Agreement é un contratto tra un cliente edun fornitore di connettivitá Internet che disciplina il servizioche i dati del cliente riceveranno, quindi quali parametrimisurare, come misurarli (attivamente o passivamente), lemodalitá di rimborso in caso di non rispetto.
Si tratta quindi della visione ad alto livello e contrattuale diun sistema con QoS.
– p. 11
Integrated Services (1)
É una emulazione di circuito su reti IP [RFC 1633], quindi siallontana molto dal tradizionale approccio best effort. Sibasa su un protocollo di prenotazione (ResourceReservation Protocol, RSVP [RFC 2205]) ed opera susingoli flussi.
– p. 12
Integrated Services (2)
Nella prima fase del protocollo, viene memorizzato tutto ilpercorso che collega la sorgente del flusso con ildestinatario:
1. La sorgente del flusso determina il TSpec del flusso einvia un messaggio PATH al destinatario
2. Quando un router riceve un pacchetto PATH memorizzanel pacchetto stesso l’indirizzo del router precedente elo inoltra poi verso la destinazione
3. Il destinatario riceve il pacchetto PATH
– p. 13
Integrated Services (3)
A questo punto il destinatario conosce il percorso cheseguiranno i dati del mittente, e su questo percorso invia unpacchetto RESV.
Quando un router riceve un pacchetto RESV decide (con unadmission control) se puó fornire le risorse richieste (bandae memoria) per processare i pacchetti del flusso. In casoaffermativo inoltra il pacchetto RESV al router successivo.Altrimenti comunica al destinatario il rifiuto.
– p. 14
Integrated Services (4)
Se la sorgente riceve il pacchetto RESV vuol dire che ilcircuito virtuale é stato creato, e puó cominciare ad inviarepacchetti. Quando il flusso non serve piú invia ai router delpercorso una notifica di chiusura.
C’é un approccio soft-state: il mittente deve reinviareperiodicamente un pacchetto PATH altrimenti i routerrilasciano le risorse associate al flusso.
– p. 15
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 routerdevono tener conto di molte informazioni ed hanno unostato!
– p. 16
Differentiated Services (1)
In questa soluzione architetturale il traffico viene ripartito ingrandi flussi aggregati. Questo viene fatto utilizzando ilcampo TOS (Type Of Service) di IPv4 che viene ridefinitocome DSCP (DiffServ Code Point).
Il DSCP si mappa in un PHB (Per Hop Behaviour) chespecifica come ogni router deve gestire il pacchetto, adesempio con politiche a prioritá per il dropping e loscheduling.
– p. 17
Differentiated Services (2)
Il DSCP viene impostato dal mittente (o dal primo router), ea paritá di DSCP il trattamento é lo stesso: in questo modoi router devono distinguere solo tra poche classi di traffico.Sono presenti due modelli di servizio:
Premium Service simile al Guaranteed Service diIntServ
Assured Service diviso in 4 classi.
L’applicazione che imposta il DSCP non effettua unanegoziazione esplicita, quindi le sue richieste di QoSpotrebbero essere onorate o meno.
– p. 18
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/rel ativa
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. 19
IntServ e DiffServ
RSVP e DiffServ possono essere impiegati insieme,avendo ambiti di applicazione ottimali diversi ecomplementandosi 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) siusa IntServ (ad esempio per gestire flussi multimedialiin una Intranet).
Vengono definite delle mappe tra i flussi di RSVP e ivalori di DSCP.
Le applicazioni richiedono esplicitamente di avere QoSe hanno notifica quando non é possibile
– p. 20
QoS routing
Sia IntServ che DiffServ usano il percorso individuato perbest effort (con SPF) ma non c’é garanzia che questo sia ilmiglior percorso per fare QoS.In una comunicazione TCP sono presenti due flussi, e ilrouting non garantisce la simmetria dei flussi.
QoS routing: cercare non un percorso best effort ma unpercorso capace di QoS (traffic engineering: MPLS?).
– p. 21
Router e QoS
I router sono la componente di rete essenziale per avereQoS.
MarkerClassifier Meter
Shaperout profile
out profile
Dropperout profile
in profilePacchetti
– p. 22
Componenti di un router
Classifier riceve i pacchetti e determina ilflusso/aggregato al quale appartengono (DSCP, FlowLabel di IPv6...)
Marker etichetta se serve i pacchetti (ad es.aggiungendo DSCP)
Meter elabora statistiche sui pacchetti e determina sesono in profilo o fuori profilo (rispettano lo SLA o meno)
Dropper scarta i pacchetti fuori profilo
Shaper riceve pacchetti fuori profilo e prova a ritardarliper riportarli in profilo
Dopo questa fase i pacchetti vengono accodati.
– p. 23
Gestione della coda
La causa tipica di perdita dei pacchetti é la congestione
TCP ha meccanismi propri di gestione dellacongestione
non tutto il traffico é TCP
una gestione efficace della congestione puó esserefatta sui router con una opportuna politica di dropping escheduling
– p. 24
Politiche di dropping (1)
Politiche elementari di dropping:
drop tail (del vino) : se la coda é piena si scartal’ultimo pacchetto arrivato
drop front (del latte) : se la coda é piena si scarta ilprimo pacchetto in coda
Nessuna di queste politiche é migliore in assoluto, dipendedal tipo di traffico su cui opera (ovvero dalla presenza omeno di meccanismi di livello superiore di gestione dellacongestione).
– p. 25
Politiche di dropping (2)
Politiche evolute di dropping:
Random Early Detection (RED) considera lalunghezza L della coda per decidere come operare:
L < minth accetta tutti i pacchettiminth < L < maxth con probabilitá P crescente conL scarta un pacchetto a caso tra tutti i presentiL > maxth scarta con certezza un pacchetto a casotra tutti i presenti
La scelta di un pacchetto in modo casuale evita fenomeni disincronizzazione globale.
– p. 26
Politiche di dropping (3)
RIO (Red with In/Out bits) : discrimina tra pacchetti inprofilo e fuori profilo, calcolando Lin per i pacchetti inprofilo e Ltot per tutti.
minout < minin quindi pacchetti out sono scartati perprimiLa probabilitá di drop per i pacchetti out é maggioredi quella per i pacchetti inmaxout < maxin quindi scarta ogni pacchetto outprima
– p. 27
Politiche di dropping (4)
Il risultato di queste scelte é che i pacchetti in profilevengono scartati solo come extrema ratio, tentando dirimuovere quelli out profile quando si comincia ad avvertirela congestione.
min_in max_in
1
P(dr
op in
)
P_max_out
P_max_in P(dr
op o
ut)
1
L_totalL_in min_out max_out
– p. 28
Politiche di scheduling
FCFS (FIFO) usa una sola coda
Priority Scheduling ogni classe ha una propria coda evengono svuotate prima le code delle classi a prioritámaggiore. Permette differenziazione relativa tra leclassi
Weighted Fair Queueing (WFQ) ogni classe riceveuna quantitá di servizio proporzionale alla sua prioritá,quindi ogni tanto vengono prelevati pacchetti anchedalle classi meno privilegiate
Earliest Deadline First (EDF) ogni pacchetto deveessere spedito entro un certo tempo, e EDF cerca dimassimizzare il numero di volte che il vincolo vienesoddisfatto
– p. 29
QoS interdominio
Nel caso generale, una comunicazione tra due entitàcoinvolge più di un Autonomous System, quindi occorronomeccanismi di gestione della QoS che possano essereinterdominio.Questo include meccanismi di autenticazione,autorizzazione ed accounting (AAA), ma non c’è ancoraaccordo su meccanismi condivisi.
– p. 30
Algoritmi di Admission Control (1)
Il ruolo di un algoritmo di admission control é quello digarantire che l’accesso di un nuovo flusso ad una risorsa direte limitata non violi i livelli di servizio per i flussi che giáusano quella risorsa, cercando inoltre di massimizzarne ilprofitto derivante dall’uso.
– p. 31
Algoritmi di Admission Control (2)
Per operare un algoritmo di admission control tiene contodelle risorse richieste per il flusso che si deve ammettere, equesto puó essere fatto in due modi:
stima a priori
stima dinamica con uno stimatore
In generale sono possibili più classi di servizio, per ognunadelle quali si puó definire una probabilitá di call-blocking,ovvero la probabilitá che una richiesta di quella classe nonsia ammessa.
– p. 32
Algoritmi di Admission Control (3)
I requisiti di QoS possono essere definiti in vari modi:
rapporti esistenti tra le probabilitá di call-blocking perrichieste di classi diverse
deviazione dal livello di servizio pattuito
profitto complessivamente ottenuto (considerandoguadagni per richieste onorate e perdite per richiesterifiutate)
In generale un problema di admission control é un problemacomplicato, e si puó risolvere solo in modo approssimato.
– p. 33
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 statepensate per nodi mobili (ad esempio RSVP crea un circuitovirtuale ma il nodo puó spostarsi e occorre “spostare” ilcircuito virtuale).
– p. 34
Algoritmi di Call Admission Control
Sono algoritmi di admission control specializzati per retimobili. In queste reti un flusso puó essere accettatonell’ambito della rete di una cella, poi puó avvenire unhandoff verso una nuova cella e occorre una nuovadecisione di admission control, che deve tuttavia tenereconto del fatto che il flusso era giá stato accettato nellavecchia cella, e quindi privilegiarlo (per quanto possibile), inmodo da non sprecare il lavoro fatto.
– p. 35
Riferimenti
N. Vasiliou, “Reading Course Paper: Overview of QoSand Web Server QoS”, Dept. of Computer ScienceUniversity of Western Ontario, Canada.
RFC 2990 “Next Steps for QoS Architecture”
– p. 36