Qualità di servizio
Da Wikipedia, l'enciclopedia libera.
Nel campo delle reti di telecomunicazioni, il termine Qualità di servizio o più semplicemente QoS (dall'inglese Quality of Service) è usato per indicare i parametri usati per caratterizzare la qualità del servizio offerto dalla rete (ad esempio perdita di pacchetti, ritardo), o gli strumenti per ottenere una qualità di servizio desiderata.
La qualità del servizio è in normalmente correlata negativamente con il traffico offerto alla rete, e positivamente con le risorse impegnate per realizzare e gestire la rete.
Il traffico offerto alla rete e l'intervento di malfunzionamenti sono processi stocastici, di conseguenza i parametri usati per caratterizzare la qualità del servizio sono variabili casuali.
Quando un contratto di servizio prevede dei parametri di qualità del servizio, con relative penali nel caso questi parametri non vengano rispettati, si parla di SLA o Service Level Agreement (accordo sul livello del servizio).
Indice |
[modifica] Telefonia
Nel campo della telefonia, e in generale della commutazione di circuito la qualità di servizio prevede parametri come:
- livello di rumore sul circuito
- livello sonoro
- probabilità di trovare una linea libera per iniziare una comunicazione
- probabilità di interruzione indesiderata di una comunicazione
- disponibilità del servizio
- durata media e massima dei disservizi
[modifica] Reti a pacchetto
In una rete a pacchetto, un pacchetto ricevuto da un commutatore può trovare la porta su cui dovrebbe essere trasmesso impegnata da un altro pacchetto in trasmissione. In questo caso, viene memorizzato in una coda, e subisce per questo un ritardo. Nel caso la coda sia piena, il pacchetto viene scartato.
I parametri tipicamente considerati per una rete a pacchetto sono:
- perdita di pacchetti o dropped packets: viene considerata la percentuale di pacchetti che la rete nel suo complesso non riesce a consegnare a destinazione. La perdita di un pacchetto viene gestita in modi diversi dai protocolli di trasporto, anche se questo esula dalla definizione della qualità di servizio della rete: in un protocollo senza riscontro, si avrebbe la mancata trasmissione dell'informazione, in un protocollo con riscontro come TCP, il ricevente, dopo aver atteso un tempo ragionevole, deve chiedere che l'informazione venga ritrasmessa, causando anche gravi ritardi (delay) nella trasmissione complessiva.
- ritardo (delay) subito da un pacchetto dalla sua immissione nella rete alla consegna al destinatario. Vengono considerate caratteristiche come il ritardo medio ("i pacchetti in media impiegano 10 ms ad attraversare la rete"), e i suoi percentili ("il 99% dei pacchetti viene consegnato entro 20 ms"). Viene anche considerato il jitter, ovvero la variazione del ritardo tra pacchetti inviati in sequenza da un nodo ad un altro.
- consegna fuori ordine o out-of-order – su alcune reti, è possibile che una sequenza di pacchetti inviati da un nodo ad un'altro venga consegnata in un ordine diverso da quello originale. Questo accade tipicamente perché i pacchetti vengono instradati su percorsi diversi. Questo problema rende necessario che i protocolli di trasporto riordinino i pacchetti fuori ordine una volta che sono giunti a destinazione, e comporta ulteriori ritardi nella ricostruzione del flusso di dati a livello applicativo. Viene considerata la probabilità che un pacchetto arrivi fuori ordine.
- errore di trasmissione: un pacchetto può essere consegnato a destinazione, ma non essere identico a quello inviato. Molte reti riconoscono la gran parte degli errori di trasmissione, e alcune sono anche in grado di correggere tali errori. Si considera la percentuale di pacchetti errati. Normalmente i protocolli di trasporto riconoscono un pacchetto errato e ne richiedono la ritrasmissione come se questo fosse stato perso, ma è anche possibile che l'errore raggiunga l'applicazione finale.
[modifica] Applicazioni che richiedono QoS
Il modello di QoS originale di Internet, ovvero nessuna QoS, è adatto ad applicazioni elastiche, che possono funzionare anche su reti con prestazioni molto degradate, e viceversa usare tutta la banda a disposizione se questa è abbondante.
Altri tipi di servizio sono invece chiamati inelastici, ovvero richiedono un certo livello di banda per funzionare – se ne ottengono di più non la sfruttano e se ne ottengono di meno non funzionano affatto. Sono queste applicazioni che rendono necessaria l'adozione di misure per garantire una certa QoS.
- multimedia streaming: può richiedere un throughput garantito
- telefonia VoIP può richiedere vincoli molto stretti sul ritardo
- emulazione di collegamenti dedicati richiede sia un throughput garantito che un ritardo massimo limitato
- un'applicazione critica per la sicurezza, come la chirurgia remota, può richiedere una livello garantito di disponibilità, ciò è chiamato anche hard QoS.
In contesti lavorativi, può accadere che vengano definiti dei requisiti di QoS anche per applicazioni che non sono intrinsecamente elastiche, per garantire livelli adeguati di produttività. Ad esempio, "il terminale dell'agenzia di viaggi deve riuscire a completare la transazione entro 10 s nel 98% dei casi". Spesso però un requisito di questo tipo richiede di intervenire sia sulla rete che sul sistema informativo che eroga il servizio (ad esempio, allestire un numero adeguato di server).
[modifica] Ottenere QoS in Internet
Quando è stata creata Internet, non era stata percepita la necessità di QoS per le applicazioni. Infatti l'intera Internet segue la filosofia del best effort, cioè il sistema garantisce di fare tutto il possibile per portare a termine un'operazione, ma non garantisce affatto che l'operazione verrà compiuta, né in che modo. Il protocollo IP prevede 4 bit per il tipo di servizio (type of service) e 3 per la precedenza di ciascun pacchetto, questi bit sono largamente inutilizzati.
Ci sono fondamentalmente due modi per fornire garanzie sulla Qualità di servizio.
[modifica] Overprovisioning
Il primo metodo, detto overprovisioning, consiste nel fornire risorse in abbondanza, abbastanza da soddisfare la domanda di picco attesa, con un sostanziale margine di sicurezza. Una soluzione semplice, ma alcuni credono che in pratica sia troppo costosa, e non è applicabile se la domanda di picco cresce più velocemente di quando predetto: disporre nuove risorse richiede tempo.
[modifica] Priorità
L'alternativa è amministrare la banda disponibile, facendo in modo che i pacchetti a cui deve essere garantita una certa QoS ottengano un trattamento privilegiato. Per ottenere questo, bisogna risolvere due problemi:
- identificare i pacchetti che devono ricevere un trattamento privilegiato.
- Applicare a questi pacchetti una disciplina di coda che garantisca le prestazioni necessarie, applicata sulle porte di uscita dei router.
[modifica] Classificazione
I metodi strutturati per identificare il traffico da privilegiare sono:
- integrated services, basato sulle prenotazioni: prima di iniziare una sessione che ha dei requisiti di QoS, l'applicazione deve "chiedere" alla rete se può garantire le prestazioni necessarie. La rete valuta se dispone delle risorse adeguate, e in caso positivo accetta la prenotazione.
- differentiated services, prevede che gli utenti della rete stipulino a priori un contratto che definisce la quantità massima di traffico "privilegiato" che possono generare, e marchino il traffico a cui dare priorità utilizzando il campo Type of Service dell'header IP. Le prenotazioni quindi sono "statiche".
Soprattutto nelle reti di piccole dimensioni, è possibile utilizzare metodi più semplici, che prevedono di identificare manualmente sui router il traffico a cui dare priorità, tipicamente usando delle ACL.
[modifica] Discipline di coda
In un router che non applichi politiche di qualità di servizio, i pacchetti vengono trasmessi sulle porte in uscita nell'ordine in cui sono arrivati. Una disciplina di coda consiste essenzialmente nel gestire per ciascuna porta diverse code in uscita, in cui i pacchetti vengono classificati. La disciplina di coda stabilisce in quale ordine verranno prelevati i pacchetti dalle varie code.
Esempi di disciplina di coda:
- priorità stretta: le code sono ordinate per priorità. Ogni volta che si deve trasmettere un pacchetto, lo si preleva dalla coda a priorità più alta che ha un pacchetto pronto. In questo modo, una applicazione di priorità superiore può monopolizzare l'intera banda disponibile, a danno di quelle di priorità inferiore (starving).
- weighted round robin: viene prelevato a turno un pacchetto da ciascuna coda. In questo modo, si garantisce che tutte le classi di applicazioni potranno trasmettere. Il "weighted" significa che a ciascuna coda può essere attribuito un peso, ovvero una frazione della banda disponibile, e i pacchetti vengono prelevati in modo da garantire questa banda disponibile. Se una classe di traffico in un certo momento non utilizza la banda allocata, questa è utilizzabile dalle altre (bandwidth borrowing).
- Discipline di coda più avanzate, come Hierarchical Packet Fair Queueing (H-PFQ) e Hierarchical Fair Service Curve (H-FSC), permettono di esprimere per ciascuna coda sia un requisito sulla banda che uno sul ritardo. Al momento, sono disponibili solo su router software, basati su BSD o linux. Si veda a proposito [1].
Altri strumenti utilizzati per amministrare la banda disponibile:
- RED: quando si approssima la congestione, la rete scarta arbitrariamente una piccola percentuale del traffico. Questo viene interpretato da TCP come una indicazione di congestione, abbassando la quantità di traffico inviata. Un caso particolare di questa tecnica chiamato WRED (Weighted Random Early Detection) permette di distinguere il flusso di traffico dal quale iniziare a scartare i pacchetti in presenza di congestione. Con il WRED è possibile definire delle soglie di utilizzo del link che, una volta raggiunte provocano lo scarto di pacchetti appartenenti a specifiche classi di traffico. Così al raggiungimento della prima soglia verranno scartati solo pacchetti di flussi poco importanti, mentre al raggiungimento di soglie di utilizzo via via più alte verranno scartati anche pacchetti appartenenti a flussi di traffico più importanti. Il "weighted" significa che la classe di traffico che sperimenterà il maggior numero di pacchetti droppati sarà quella associata alla soglia più bassa. La definizione delle soglie di utilizzo e dei diversi flussi di traffico è fatta su base configurazione.
- rate limiting: una classe di traffico può essere limitata in modo che non utilizzi più di una certa banda.
[modifica] Discussione
Il mercato non ha ancora favorito la nascita di servizi QoS. Alcuni credono che una rete stupida che offra sufficiente banda per la maggior parte delle applicazioni e per la maggior parte del tempo, sia già economicamente la migliore soluzione possibile, mostrando poco interesse a supportare applicazioni non-standard capaci di QoS.
La rete internet ha già accordi complessi tra i provider, e sembra che ci sia poco entusiasmo nel supportare il QoS attraverso connessioni che interessano reti appartenenti a provider diversi, o sugli accordi circa le politiche che dovrebbero essere sostenute al fine di poterle supportare.
Gli scettici sul QoS indicano che se si scartano troppi pacchetti su una connessione elastica a basso QoS, si è già pericolosamente vicini al punto di una congestione per le applicazioni inelastiche ad elevato QoS, non essendoci più modo di scartare ulteriori pacchetti senza violare i contratti sul traffico.
[modifica] Problemi del QoS con alcune tecnologie
Le seguenti proprietà possono essere usare solo sulle porte finali, ma non sui server, backbone o altre porte, che mediano molti flussi concorrenti.
- half duplex - collisioni sul collegamento possono far variare i ritardi (jitter), perché i pacchetti sono ritardati da ogni collisione con un tempo di backoff.
- Porte con buffer a coda IEEE 802.3x (controllo di flusso).
Il controllo di flusso dell'IEEE 802.3x non è un reale controllo di flusso, ma piuttosto un controllo di coda. Un esempio di problemi dell'IEEE 802.3x sono i blocchi head of Line. Molti degli switch odierni usano l'IEEE 802.3x di default - anche sulla porta di uplink/backbone.
Citazione da: Network World, 09/13/99, 'Flow control feedback': "...Hewlett-Packard points out that quality of service is a better way to handle potential congestion, and Cabletron and Nortel note that QoS features can't operate properly if a switch sends [IEEE 802.3x] pause frames...."
Questa citazione suggerisce che QoS e IEEE 802.3x sono tra loro incompatibili.
[modifica] Collegamenti esterni
- IEEE 802.1 P,Q - QoS on the MAC level, 24.4.1999, Niclas Ek
- IEEE 802.1 LAN/MAN Bridging & Management
- "Good old days" IP QoS: Type of Service in the Internet Protocol Suite
- On the Effects of the IEEE 802.3x Flow Control in Full-Duplex Ethernet LANs, Oliver Feuser, Andre Wenzel, University of Bonn
- sslug.dk: Hyggemøde tirsdag den 11. juni 2002: Båndbreddebegrænsning
- sslug.dk: Hyggemøde tirsdag den 11. juni 2002: Båndbreddebegrænsning. Eksempler
- Linux Advanced Routing & Traffic Control
- Linux Advanced Routing & Traffic Control, HowTo
- lartc.org: The Wonder Shaper
- Packeteer PacketShaper 2500: Traffic Control on Autopilot, September 4, 2000, By David Newman
- Packeteer PacketShaper
- Traffic Shaping application for Windows (has free version)
- ALTQ:] Alternate Queueing for BSD UNIX]