Qualità del servizio

Nel campo delle reti di telecomunicazioni, il termine qualità del servizio o più semplicemente QoS (dall'inglese Quality of Service) è utilizzato per indicare i parametri usati per caratterizzare la qualità del servizio offerto dalla rete (ad esempio perdita di pacchetti, ritardo), o gli strumenti o tecniche per ottenere una qualità di servizio desiderata.

La qualità del servizio è 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 usualmente modellati come processi stocastici: di conseguenza, i parametri usati per caratterizzare la qualità del servizio sono comunemente 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).

Descrizione

Telefonia

Nel campo della telefonia, e in generale della commutazione di circuito la qualità del servizio prevede parametri come:

• disponibilità del servizio;
• livello di rumore sul circuito;
• livello sonoro;
• probabilità di trovare una linea libera per iniziare una comunicazione;
• probabilità di interruzione indesiderata di una comunicazione;
• durata media e massima dei disservizi.

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 di un buffer, e subisce per questo un ritardo di accodamento. Nel caso la coda sia piena, il pacchetto viene scartato o perso.

I parametri tipicamente considerati per una rete a pacchetto sono:

• 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 per via della commutazione di pacchetto. 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. Dal punto di vista quantitativo 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. Dal punto di vista quantitativo 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.
• ritardo (delay) subìto 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.
• perdita di pacchetti o dropped packets (packet loss): 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à del 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.
• throughput: ai precedenti parametri si aggiunge generalmente la banda il cui valore massimo consentito dipende dal contratto stipulato dall'utente con il fornitore del servizio.

Per applicazioni o servizi non real-time come il file transfer o il video sharing, alcuni di questi parametri (ad eccezione del ritardo e del throughput) vengono soddisfatti dal protocollo di rete TCP che si occupa proprio di richiesta di riordino e recupero di errore sui pacchetti pervenuti e di ritrasmissione dei pacchetti persi ovvero non pervenuti a prezzo di un certo tempo di elaborazione. Il ritardo e la sua variabilità per tali applicazioni non è considerato un parametro critico in quanto tollerato dall'utente come tempo necessario a soddisfare la sua richiesta di acquisizione dei dati. Se il tempo di trasmissione è eccessivo l'utente tipicamente tende a richiedere un throughput maggiore che però è soddisfacibile dal fornitore solo attraverso una maggiore banda.

Per applicazioni real-time, come la fonia su IP (VOIP) e lo streaming audio-video in diretta diventano invece sensibili i parametri di ritardo, variabilità di ritardo e perdita di pacchetti che implicano rispettivamente tempi di latenza troppo elevati, jitter che dà luogo a consegna fuori sequenza e conseguente necessità di reordering con ritardo aggiuntivo di elaborazione, ed infine richieste di ritrasmissione da parte di TCP con ulteriore ritardo aggiuntivo. In tali applicazioni quindi si preferisce evitare l'uso del protocollo TCP in favore dell'altro protocollo di trasporto UDP che non fa controllo di trasmissione ovvero non esplica le funzionalità di cui sopra, al prezzo di qualche perdita di dati.

In aggiunta a ciò spesso si rende necessaria una garanzia maggiore sui cosiddetti parametri di qualità del servizio (QoS) nel caso di comunicazioni real-time come la fonia e la diffusione di contenuti multimediali audio-video real-time in situazioni di congestione sui nodi interni di commutazione.

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.

Applicazioni che richiedono una QoS sono ad esempio le seguenti:

• multimedia streaming: può richiedere un throughput garantito;
• telefonia VoIP può richiedere vincoli molto stretti sul ritardo e sulla variabilità del ritardo (jitter);
• 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 un 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).

Meccanismi di 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. Anche se 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. Al crescere del numero e tipologie di servizi e del traffico offerto rispetto alle capacità della rete il problema della qualità del servizio ha cominciato a divenire importante e sempre più considerato.

Ci sono fondamentalmente due modi per fornire garanzie sulla Qualità del servizio.

Overprovisioning

Il primo metodo, detto overprovisioning (sovradimensionamento), consiste nel fornire risorse di rete (di trasmissione, memorizzazione ed elaborazione) 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 sia applicabile se la domanda di picco cresce più velocemente di quando predetto: disporre nuove risorse richiede infatti sempre tempo.

Priorità

L'alternativa è amministrare la banda disponibile, facendo in modo che i pacchetti che giungono ad un nodo di rete (router) subiscano un trattamento differenziato ovvero quelli a cui deve essere garantita una certa QoS ricevano in particolar modo un trattamento privilegiato. Per ottenere questo, bisogna risolvere due problemi:

• Identificare i pacchetti che devono ricevere un trattamento privilegiato (classificazione o discriminazione del traffico).
• Applicare a questi pacchetti identificati una disciplina di coda (queue discipline) che garantisca le prestazioni necessarie da applicare poi sulle porte o interfacce di uscita dei router.

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 questa può garantire le prestazioni necessarie (admission control): la rete valuta se dispone delle risorse adeguate e in caso positivo accetta la prenotazione concedendo il servizio richiesto.
• Differentiated services, prevede che gli utenti della rete stipulino a priori un contratto che definisca la quantità massima di traffico "privilegiato" che essi possono generare e marchino tale traffico utilizzando il campo Type of Service (TOS) dell'header IP. In questo caso quindi le prenotazioni sono rigidamente "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 liste di controllo degli accessi (ACL).

Discipline di coda

In un router che non applichi politiche di qualità del servizio, i pacchetti vengono trasmessi sulle porte in uscita nell'ordine in cui sono arrivati. Una disciplina di coda, o scheduling dei pacchetti, 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 Hierarchical Fair Service Curve Scheduler..

Altri strumenti utilizzati per amministrare la banda disponibile:

• RED (Random Early Detection o Rilevazione casuale anticipata): 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.

Discussione

Il mercato non ha ancora favorito la nascita di servizi QoS end-to-end, ovvero in grado di garantire vincoli sulla QoS di un flusso di dati scambiati tra utenti remoti. Alcuni credono che una rete stupida cioè sovradimensionata, che offra cioè 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.

È inoltre importante sottolineare come la gestione della QoS nelle reti di accesso wireless di tipo LTE e WiMAX sia un tema di primaria rilevanza da affrontare per la diffusione di tali tecnologie. Infatti, gli enti preposti al rilascio delle specifiche di LTE e WiMAX hanno già incorporato i meccanismi standard necessari a gestire la QoS offerta ai terminali.

In termini generali, come evidenzia Kotler, poiché le aziende trovano più difficile differenziare i loro prodotti fisici, si rivolgono alla differenziazione del servizio, sia che ciò significhi consegne puntuali, risposte migliori e più rapide alle richieste o risoluzione più rapida dei reclami. I migliori fornitori di servizi conoscono bene questi vantaggi e sanno anche come creare esperienze memorabili per i clienti.

Problemi del QoS con alcune tecnologie

Le seguenti proprietà possono essere usate 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'. URL consultato il 3 aprile 2018 (archiviato dall'url originale il 10 marzo 2005).: "...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.

Bibliografia

• M. Menth, R. Martin, and J. Charzinski “Capacity Overprovisioning for Networks with resilience Requirements". In Proc. of ACM Sigcomm 2006.

Voci correlate

• Neutralità della rete
• Qualità dell'esperienza
• MPLS

Altri progetti

Altri progetti

• Wikizionario
• Wikimedia Commons

• Wikizionario contiene il lemma di dizionario «QoS»
• Wikimedia Commons contiene immagini o altri file sulla qualità di servizio

Collegamenti esterni

• (EN) Denis Howe, quality of service, in Free On-line Dictionary of Computing. Disponibile con licenza GFDL
• IEEE 802.1 P,Q - QoS on the MAC level, 24.4.1999, Niclas Ek, su tml.hut.fi. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 31 maggio 2005).
• IEEE 802.1 LAN/MAN Bridging & Management, su standards.ieee.org.
• "Good old days" IP QoS: Type of Service in the Internet Protocol Suite, su sunsite.dk. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 2 dicembre 2001).
• On the Effects of the IEEE 802.3x Flow Control in Full-Duplex Ethernet LANs, Oliver Feuser, Andre Wenzel, University of Bonn, su computer.org. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 12 ottobre 2004).
• sslug.dk: Hyggemøde tirsdag den 11. juni 2002: Båndbreddebegrænsning, su sslug.dk. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 13 marzo 2005).
• sslug.dk: Hyggemøde tirsdag den 11. juni 2002: Båndbreddebegrænsning. Eksempler (TXT), su sslug.dk. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 18 febbraio 2005).
• Linux Advanced Routing & Traffic Control, su lartc.org. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 15 ottobre 2011).
• Linux Advanced Routing & Traffic Control, HowTo, su lartc.org. URL consultato il 17 novembre 2022 (archiviato dall'url originale l'11 ottobre 2007).
• lartc.org: The Wonder Shaper, su lartc.org. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 31 maggio 2005).
• Packeteer PacketShaper 2500: Traffic Control on Autopilot, September 4, 2000, By David Newman, su networkcomputing.com. URL consultato il giugno 19, 2005 (archiviato dall'url originale il 21 aprile 2003).
• Packeteer PacketShaper, su packeteer.com. URL consultato il 19 giugno 2005 (archiviato dall'url originale il 19 ottobre 2005).
• Traffic Shaping application for Windows (has free version), su inetshaper.com.
• ALTQ: Alternate Queueing for BSD UNIX (archiviato dall'url originale il 27 settembre 2007).