QoS a livello Network

QoS a livello Network
Paolo Campegiani
[email protected]
http://www.ce.uniroma2.it
– p.1
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.2
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.3
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.4
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.5
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.6
Come si definisce la QoS (3)
Y
guadagno
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.
D
D’
tempo
Quindi lo scopo di una architettura QoS diviene quello di
massimizzare il totale dei guadagni ottenuti.
– p.7
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.8
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.9
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.10
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.11
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.12
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.13
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.14
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.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 router devono tener conto di molte informazioni ed hanno uno stato!
– p.16
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.17
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.18
Confronti tra IntServ e DiffServ
Proprieta’
Integrated Services
Granularita’
Flusso
Aggregati
Flusso
Aggregato
Informazioni
di
stato
Differentiated Services
Classificazione pacchetti
Quintupla (TSpec)
Tipo di differenziazione
Determ/Statistica
Assoluta/relativa
Admission
Necessario
Nec. per diff. ass.
Protocollo di segnalazione
RSVP
Solo per diff. ass.
Coordinamento
End
Scalabilita’
No
Network
Control
accounting
to
End
Byte DS di IP
Per Hop
Si’
In base al flusso
Virtuali
In base alla classe
Organizzazione Network
Circuiti
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 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.20
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.21
Router e QoS
I router sono la componente di rete essenziale per avere
QoS.
out profile
Pacchetti
Classifier
Marker
Meter
Dropper
in profile
out profile
Shaper
out profile
– p.22
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.23
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.24
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.25
Politiche di dropping (2)
Politiche evolute di dropping:
Random Early Detection (RED) considera la
lunghezza della coda per decidere come operare:
accetta tutti i pacchetti
con probabilitá crescente con
scarta un pacchetto a caso tra tutti i presenti
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.26
Politiche di dropping (3)
RIO (Red with In/Out bits): discrimina tra pacchetti in
per i pacchetti in
profilo e fuori profilo, calcolando
per tutti.
profilo e
quindi pacchetti out sono scartati per
primi
La probabilitá di drop per i pacchetti out é maggiore
di quella per i pacchetti in
quindi scarta ogni pacchetto out
prima
– p.27
Politiche di dropping (4)
1
1
P(drop in)
P(drop out)
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.
P_max_in
min_in max_in L_in
P_max_out
min_out
max_out L_total
– p.28
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.29
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.30
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.31
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.32
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.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 state
pensate per nodi mobili (ad esempio RSVP crea un circuito virtuale ma il nodo puó spostarsi e occorre “spostare” il
circuito virtuale).
– p.34
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.35
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.36