Progetto di reti locali/Qualità del servizio nelle LAN IEEE 802

La qualità del servizio nell'inoltro del traffico è richiesta quando c'è una limitata quantità di risorse tale che il traffico offerto eccede la capacità di smaltimento dei dati creando delle congestioni.

Di solito le LAN sono sovrabbondanti, in quanto è molto più economico espandere la rete che imporre la qualità del servizio → nel caso peggiore, l'occupazione del canale è pari al 30-40% della banda disponibile → apparentemente non c'è alcun bisogno della qualità del servizio perché non ci sono congestioni.

In alcuni scenari possibili si potrebbero avere dei problemi:

• 
  Backbone non ben dimensionato.
• 
  Trasferimento dati da diversi client a un singolo server.
• 
  Trasferimento dati da un server veloce a un client lento.

• backbone non ben dimensionato: un bridge dotato di buffer troppo piccoli nel backbone può portare a micro-congestioni sugli uplink, le quali non sono persistenti ma sono tante e di breve durata (micro) perché il traffico dei client è estremamente bursty;
• trasferimento dati da diversi client a un singolo server: un bridge dotato di buffer troppo piccoli come singolo punto di accesso a un server può portare a congestioni persistenti dovute alla concorrenza di tanti client collegati al server allo stesso tempo;
• trasferimento dati da un server veloce a un client lento: un client lento (in termini di velocità del link, capacità della CPU, ecc.) può portare a congestioni temporanee sul client stesso perché non riesce a smaltire il traffico proveniente da un server veloce.

La qualità del servizio è potenzialmente una bella funzionalità, ma presenta delle controindicazioni che ne rendono non così forte la necessità: la qualità del servizio è solo uno dei problemi da risolvere per rendere la rete efficiente, e i miglioramenti che essa porta spesso non sono percepiti dall'utente finale.

IEEE 802.1p

Lo standard IEEE 802.1p definisce 8 classi di servizio, chiamate livelli di priorità, e a ognuna di esse è assegnata una diversa coda (logica).

Una trama può essere contrassegnato con una specifica classe di servizio nel campo "Priority Code Point" (PCP) del tag VLAN: Virtual LAN#Tagging delle trame. Lo standard offre anche la possibilità di selezionare l'algoritmo di scheduling a priorità desiderato: round robin, weighted round robin, weighted fair queuing.

Sarebbe meglio lasciare che la sorgente, a livello applicazione, effettui la marcatura perché solo la sorgente conosce esattamente il tipo di traffico (traffico voce o traffico dati), ma quasi tutti gli utenti dichiarerebbero tutti i pacchetti come ad alta priorità perché non sarebbero onesti → la marcatura va eseguita dai bridge di accesso che sono sotto il controllo del provider. Tuttavia il riconoscimento del tipo di traffico è molto difficile per i bridge e li rende molto costosi, perché richiede di salire al livello applicazione e può non funzionare con il traffico criptato → si può semplificare la distinzione per i bridge in due modi:

• marcatura per porta: il PC è connesso a una porta e il telefono a un'altra porta, così il bridge può marcare il traffico in base alla porta di ingresso;
• marcatura per dispositivo edge: il PC è connesso al telefono e il telefono al bridge → tutto il traffico del PC passa per il telefono, che semplicemente lo marca come traffico dati, mentre marca il suo traffico come traffico voce.

Lo standard suggerisce a quale tipo di traffico è destinato ogni livello di priorità (ad es. 6 = traffico voce), ma lascia la libertà di cambiare queste associazioni → possono sorgere dei problemi di interoperabilità tra fornitori diversi.

IEEE 802.3x

Lo standard 802.3x implementa un controllo di flusso a livello Ethernet, in aggiunta al controllo di flusso esistente a livello TCP: dato un link, se il nodo (bridge o host) a valle ha i buffer pieni può inviare al nodo a monte all'altra estremità del link un pacchetto PAUSE chiedendo ad esso di interrompere la trasmissione dei dati su quel link per una certa quantità di tempo, detta tempo di pausa che è espresso in "quanti di pausa" (1 quanto = tempo per trasmettere 512 bit). Il nodo a monte quindi memorizza i pacchetti che arrivano durante il tempo di pausa nel suo buffer di uscita, e li invierà quando il buffer di ingresso del nodo a valle sarà pronto a ricevere altri pacchetti → i pacchetti non vanno più persi per colpa della congestione dei buffer.

Esistono due modalità di controllo di flusso:

• modalità asimmetrica: solo un nodo invia il pacchetto PAUSE, l'altro si limita a ricevere il pacchetto e a interrompere la trasmissione;
• modalità simmetrica: entrambi i nodi alle estremità del link possono trasmettere e ricevere pacchetti PAUSE.

Su ogni nodo si può configurare la modalità di controllo di flusso, ma la fase di autonegoziazione deve determinare l'effettiva configurazione in modo che la modalità scelta sia coerente su entrambi i nodi alle estremità del link.

L'invio di pacchetti PAUSE può essere problematico nel backbone.

L'invio di pacchetti PAUSE può essere problematico nel backbone: un bridge con i buffer pieni è in grado di far interrompere il traffico solo sul link a cui è direttamente collegato ma, se i bridge intermedi nel percorso di upstream non sentono la necessità di mandare a loro volta dei pacchetti PAUSE perché dotati di buffer più grandi, non è in grado di "zittire" l'host che sta inviando troppi pacchetti → finché il bridge di accesso non invierà a sua volta un pacchetto PAUSE all'host interessato, la rete appare bloccata anche a tutti gli altri host che non sono responsabili del problema → i pacchetti PAUSE inviati da bridge non di accesso non hanno la capacità di selezionare il traffico in eccesso per rallentare l'host responsabile, ma hanno effetto sul traffico di tutti gli host.

Per questo motivo, è consigliabile disabilitare il controllo di flusso nel backbone e utilizzare i pacchetti PAUSE solo tra i bridge di accesso e gli host. Spesso viene scelta la modalità di controllo di flusso asimmetrica, dove solo gli host possono mandare i pacchetti PAUSE: in genere i buffer dei bridge di accesso sono sufficientemente grandi, e diversi bridge commerciali accettano pacchetti PAUSE dagli host, bloccando la trasmissione dati sulla porta interessata, ma non possono inviarli.

Tuttavia l'invio dei pacchetti PAUSE può essere problematico anche per gli host, in quanto può scatenare un livelock nel kernel del sistema operativo: la CPU dell'host lento è così impegnata ad elaborare i pacchetti in arrivo sull'interfaccia NIC che non riesce a trovare un momento per mandare un pacchetto PAUSE → i pacchetti si accumulano in RAM portandola alla saturazione.