QoS e QoE

Le reti basate sull’Internet Protocol originariamente offrivano una sola classe di servizio denominata best-effort e modellata sul comportamento base delle code interne degli apparati di rete chiamato FIFO (First-In, First-Out). Successivamente è stato definito un modello in grado di fornire QoS (Quality of Service) differenziata a flussi di traffico preferenziali classificati secondo regole legate a decisioni dell’amministratore della rete. Il modello Diff-serv [9] è anch’esso definito sulla base delle opzioni di comportamento delle code interne ai nodi; qui è possibile scartare alcuni pacchetti dati, modificarne l’ordine di trasmissione, gestire la cadenza di invio dei pacchetti in modo da non eccedere un limite di velocità e così via. Il comportamento sui flussi di traffico viene tradotto in parametri quali la probabilità di perdita di pacchetti, la latenza dovuta al percorso che i pacchetti devono compiere, la variazione di latenza o jitter.
Tra i limiti di questo modello vale la pena segnalare il fatto che la sua azione è efficace solo in caso di congestione di uno dei tratti di rete attraversati dalla comunicazione; in condizioni operative “normali”, cioè in assenza di congestione, fornire un trattamento preferenziale ad un flusso di traffico non significa affatto rendere più bassa la probabilità di perdita di pacchetti o rendere più veloce il trasferimento dell’informazione. Inoltre tradurre parametri come la probabilità di perdita o la latenza di rete in parametri che rappresentino la qualità percepita dal cliente finale (QoE, Quality of Experience) può risultare alquanto complesso. Si pensi al tempo di caricamento e visualizzazione di una pagina web: certamente la latenza di rete contribuisce, ma contributi maggiori si ottengono dalla sequenzialità di download dovuta alla struttura ad oggetti della pagina stessa, dal tempo di costruzione della visualizzazione da parte dei terminali, dal DNS e da molto altro ancora.
Molti elementi da cui dipende la qualità percepita sono legati al terminale e alle applicazioni client-server o peer-2-peer. Sfruttando queste dipendenze, i Content Provider hanno progressivamente adottato soluzioni che permettono non solo di introdurre il controllo a livello applicativo, ma addirittura di rendere inefficaci o controproducenti alcuni meccanismi di tipo Diff-serv introdotti dagli ISP. Per applicazioni Video, il traffico relativo ad uno stesso filmato può essere suddiviso tra varie connessioni; il controllo di flusso viene operato dal client (e non dal server) e a livello http (e non più TCP); al jitter si ovvia con un buffering iniziale che viene adattato alle condizioni della rete; la risoluzione è adattativa, e regolata automaticamente, in quanto l’applicazione tende a sfruttare in best-effort tutta la banda disponibile e a saltare ad una risoluzione più alta o più bassa nel caso si verifichino perdite o strozzature improvvise o si renda disponibile una banda più elevata. Quest’ultima caratteristica, ad esempio, potrebbe determinare oscillazioni anomale tra due livelli di risoluzione diversi (con effetti finali decisamente sgradevoli) in presenza di configurazioni di scarto selettivo in rete che prevedano la tolleranza di elevati valori di burst size (treni lunghi di pacchetti): questi ultimi venivano preferiti in passato per proteggere le applicazioni stesse in condizioni di jitter elevato nei collegamenti a lunga distanza, senza rinunciare a differenziare l’offerta in termini di banda disponibile.
I Content Provider effettuano precise misurazioni della banda disponibile end-to-end tra i propri server (o i server delle Content Delivery Network che distribuiscono i loro contenuti) e i terminali degli utenti finali, cercando anche di discriminare tra gli artefatti introdotti dalle reti e gli artefatti introdotti dai terminali. Oltre a questo misurano parametri significativi per la percezione di utente, quali il tempo di attesa per l’avvio della riproduzione video, il numero di interruzioni della riproduzione, la maggiore o minore risoluzione video e il numero di cambiamenti di risoluzione.
In questo contesto anche i Telco/ISP non possono rimanere ancorati ai classici parametri di QoS e devono dotarsi di strumenti per il controllo e la misura della QoE. Tra i parametri di QoE, quello dell’effettiva banda che si rende disponibile a livello applicativo è il parametro che maggiormente dipende dalle prestazioni della rete ed è anche quello su cui gli OTT valutano gli ISP [7,10].
I principali strumenti per il miglioramento della QoE sono quelli che consentono di avvicinare i contenuti ai loro “consumatori” (Content Delivery Network, Transparent Internet Caching), di ottimizzare il contenuto trasmesso sulla base del terminale a cui è destinato o ancora accelerare la transazione a livello applicativo ( i più importanti di questi sono presentati in [6]).
Per migliorare la QoE, l’importanza dell’avvicinamento dei contenuti all’end-user è illustrata nella Figura A. Sull’asse verticale sono riportati il “Throughput” (l’effettiva velocità di trasferimento delle informazioni quando l’utente finale utilizza un’applicazione o accede ad un contenuto sul WEB), ovvero il “bit rate” (la velocità di trasferimento dati che viene misurata ad esempio con strumenti quali speed–test).
La figura mostra come per la stragrande maggioranza del traffico che fa uso del protocollo TCP (Transport Control Protocol), il throughput dipende significativamente dal Round Trip Time – RTT (la misura del tempo impiegato da un pacchetto dati per arrivare dal terminale dell’ end-user al server di rete e tornare indietro) e dalla perdita di pacchetti (percentuale di pacchetti persi durante il percorso). Le linee decrescenti in figura riportano i valori teorici calcolati con il modello presentato in [10] al variare dei valori di perdita di pacchetti e RTT per una singola sessione TCP: l’area ombreggiata delimita le condizioni operative osservate all’interno delle reti dei Service Provider. Questi valori sono coerenti con le misure di throughput a livello applicativo provenienti da varie fonti e realizzate secondo diverse metodologie che sono riportate nella stessa figura come linee orizzontali tratteggiate.
Le soluzioni/piattaforme per il miglioramento della QoE rappresentano un’importante opportunità per i Telco/ISP per migliorare i servizi offerti ai propri clienti e per ottenere un riconoscimento economico della qualità di distribuzione dei contenuti che sono in grado di offrire.
In questa prospettiva, anche il modello Diff-serv e gli strumenti di controllo della QoS possono mantenere comunque un ruolo importante: quello di rendere stabili nel tempo le prestazioni di QoE, andando ad agire nelle temporanee situazioni di congestione che si possono verificare a seguito di picchi inattesi di traffico o di alcuni tipi di guasti. In questo senso possono essere considerati utili complementi per la realizzazione di offerte a QoE differenziata.

 

Figura A - Bit Rate and Throughput v.s. RTT e Packet Loss

 

Torna all'articolo