domenica 6 novembre 2016

Banda e Throughput: un po' di chiarezza

Tutti noi stiamo assistendo da anni alla "corsa alla banda". Nelle reti fisse si è passati dalla "banda larga" all'ultrabroadband, nelle reti mobili dal 3G, al 4G (LTE) e già si parla di 5G. Tutte queste tecnologie promettono una banda disponibile sempre maggiore, addirittura fino 1 Gbit/s. Sembra quasi la promessa del nirvana !!!

Ma è proprio così ? O meglio, è proprio vero che tutta questa banda sia necessaria ? O è la solita trovata dei nostri amici del Marketing, che pur di vendere un servizio si inventano numeri ad effetto ?

Facciamo un po' di chiarezza. Intanto, quanto promesso NON è una banda garantita end-to-end, ma solo la banda disponibile sul rilegamento di accesso. Mi spiego meglio. Io ho fatto da qualche mese un upgrade del mio abbonamento di servizi di telecomunicazione, a un pacchetto che tra le altre cose, mi da 100/20 di banda downlink/uplink, o meglio, questo dice la pubblicità del servizio. 

Il mio collegamento è parte in rame e parte in fibra ottica. La parte in rame, che poi sarebbe il caro vecchio classico doppino telefonico, collega il mio router di casa a un armadio distante, per mia fortuna, circa 30 metri. In questo armadio c'è una ONU (Optical Network Unit), che poi è un banale switch Ethernet, con 192 porte di accesso a 100 Mbit/s e con due uplink da 1+1 Gbit/s in fibra ottica, che terminano in un apparato di centrale (spero affasciati in un LAG, ma io sono ottimista e quindi supporrò di si). Questo è quanto mi ha garantito il tecnico che mi ha installato il servizio, alla mia domanda sulla storia del LAG mi ha candidamente risposto che non sapeva nemmeno cosa fosse, ma sorvoliamo su questo aspetto, ripeto, sono un ottimista per natura

E quindi già qui cominciano male. Se ancora un po' di aritmetica la ricordo, siamo in presenza di una concentrazione del traffico downlink, di 1:9,6. Morale della favola, solo "narcotizzando" 172 Clienti attestati al mio stesso switch posso avere la certezza matematica di avere 100 Mbit/s tra apparato di centrale (che si chiama OLT, Optical Line Termination) e il mio router (quindi non end-to-end, badate bene). Se tutti i 192 utenti fossero attivi, al massimo quello che possiamo avere è poco più di 10 Mbit/s a testa. 

Ma si sa, il traffico dati è soggetto alle leggi della statistica e non a leggi deterministiche. E poi spesso e volentieri il traffico è di tipo burst (basti pensare alla classica navigazione web), per cui anche una concentrazione 1:9,6 potrebbe essere soddisfacente, ma non garantisce certo 100 Mbit/s.

Ma supponiamo di vivere in un mondo ideale, dove il nostro "mega-provider" ci garantisce realmente 1 Gbit/s end-to-end. A questo 1 Gbit/s, corrisponde nella realtà un throughput di pari livello ? Ricordo che il throughput è la quantità di traffico che arriva realmente a destinazione nell'unità di tempo, al netto di perdite sulla rete, del funzionamento dei protocolli, ecc. . Dal throughput dipende quella che in gergo viene chiamata la Quality of Experience (QoE, da non confondersi con la QoS, che invece è la qualità del servizio), ossia la qualità percepita dall'utilizzatore finale (es. il video si vede bene ?, il download di una pagina web avviene con velocità sufficiente ?, l'audio si sente bene ?, e così via).

Bene, a me hanno insegnato che il 90 % del traffico smaltito dalle reti IP utilizza come protocollo di trasporto il TCP. Questo perché la stragrande maggioranza delle applicazioni che utilizziamo, es. HTTP, HTTPS, SMTP, FTP, ecc. si poggia sulla coppia TCP/IP (NOTA: faccio presente che il traffico HTTP/HTTPS include tutto il traffico da/verso i maggiori OTT (Over The Top), come Google, Facebook, Instagram, Netflix, e chi più ne ha più ne metta). 

A me hanno anche insegnato che il TCP ha un funzionamento molto complesso, che lo rende un protocollo "educato", nel senso che se si dovesse accorgere che da qualche parte della rete c'è congestione, abbassa notevolmente il suo bit-rate fino a riportarlo lentamente al valore precedente (con meccanismi noti come slow start e congestion avoidance). Inoltre, come arcinoto, il TCP utilizza un meccanismo a finestra (windowing) per non sovraccaricare il terminale destinazione del traffico (TCP Flow Control).

Sono proprio questi meccanismi che potrebbero ridurre notevolmente il throughput complessivo delle applicazioni TCP (che ripeto, sono la stragrande maggioranza), indipendentemente da quale è la banda che il nostro ipotetico "mega-provider" ci garantisce. Prima vediamo il perché, e quindi in seguito illustrerò qualche soluzione per ovviare al problema.

THROUGHPUT MASSIMO DI UNA SESSIONE TCP
Partiamo dal meccanismo della finestra. Vi faccio un esempio che a prima vista vi sembrerà surreale, ma assolutamente corretto. Supponiamo di avere una classica configurazione Client-Server, come nella figura seguente e che la distanza fisica tra i due dispositivi sia di 1.000 Km. Il nostro ipotetico "mega-provider" ci garantisce, mettendolo per iscritto con uno SLA capestro (per lui), una banda end-to-end di 1 Gbit/s. L'obiettivo è scaricare da un server FTP un file molto grande, diciamo da 4 Gbyte (= 32 Gbit). 




Intuitivamente viene da pensare che ci vogliano più o meno 32 secondi per il download del file (32 Gbit a una velocità di 1 Gbit/s). Purtroppo così non è, il tempo di download è notevolmente superiore. Vediamo perché. 

Il meccanismo di Flow Control del TCP, basato su un meccanismo a finestra, impone che al massimo il Server possa spedire, prima di ricevere un riscontro, una quantità di byte pari al valore della finestra. Il valore della finestra è comunicato dal ricevitore al trasmettitore, tramite il campo Window presente nell'intestazione TCP. Questo campo esprime il valore numerico dell'ampiezza della finestra espresso in byte, e poiché ha lunghezza di 16 bit, il valore massimo che può assumere è 65.535. Ciò significa che al massimo il trasmettitore potrà inviare, senza attendere alcun ACK dal ricevitore, 65.535 byte. 

NOTA: la finestra di cui sto parlando è la finestra di ricezione, così detta poiché il valore della finestra è stabilito dal ricevitore, sulla base alle risorse disponibili. Il TCP ha anche una seconda finestra, utilizzata nel meccanismo di Congestion Avoidance, che però è stabilita dal trasmettitore.

Ora, considerando il valore tipico di ritardo fisico di 5 microsecondi/Km, e trascurando altri ritardi introdotti dagli apparati di rete (che per la verità non sono assolutamente trascurabili, ma mi voglio mettere in una condizione ideale), questi 65.535 byte impiegano circa 5 millisecondi per arrivare al ricevitore (distante 1.000 Km). Gli ACK inviati dal ricevitore, impiegano lo stesso tempo per arrivare trasmettitore. Quindi quest'ultimo riceve gli ACK dopo 10 millisecondi, dopodiché può iniziare a tramettere altri byte. Il tempo che intercorre tra la trasmissione dei byte da parte del trasmettitore e la ricezione dell'ACK è noto come Round Trip Time (RTT) (= 10 millisecondi).

Ricapitolando, il trasmettitore in condizioni ideali può tramettere un massimo di 65.535 byte ogni 10 millisecondi, che corrisponde a un throughput di: (65.535*8)/(10 ms) = 52,428 Mbit/s !!! La formula generale è:

TH = (RW*8)/RTT  

dove TH = THroughput e RW = valore della finestra di ricezione (in byte).

Un semplice conto mostra che per scaricare il nostro file da 4 Gbyte si impiegano circa 610 secondi, ossia poco più di 10 minuti !!! E non 32 secondi come ci avrebbe detto il nostro amico del marketing.

Il fenomeno è tanto più evidente quanto maggiore è il valore di RTT. Questo è un problema ben noto da tempo, quando si è iniziato a inviare traffico TCP sui collegamenti via satellite, dove il RTT assume valori dell'ordine delle centinaia di millisecondi. 

Un parametro chiave è il BPD (Bandwidth-Delay Product), ossia il prodotto tra "Banda fisica" e RTT. Ad esempio, per lo scenario Client-Server descritto sopra questo valore è :

1 Gbit/s x 10 ms = 10 Mbit = 1,25 Mbyte

Ma cosa rappresenta il BDP ? Semplice, il valore che dovrebbe assumere la finestra di ricezione per sfruttare tutta la banda fisica disponibile. Maggiore è il valore di RTT, maggiore il valore di BDP. Reti con valori di BDP molto grandi, come ad esempio le reti via satellite, sono note come "long fat networks". Quando il valore di RW supera il valore di BPD, il throughput è limitato dal valore della banda fisica del collegamento, viceversa è limitato dalla formula descritta sopra, che quindi andrebbe modificata nel seguente modo:

TH = [min(BPDRW)*8]/RTT

Il problema è che in collegamenti ad alta velocità, con RTT anche relativamente basso, per sfruttare tutta la banda disponibile, il valore della finestra dovrebbe essere ben maggiore dei 65.535 byte consentiti dal TCP. Per questo nel lontano Maggio 1992 fu introdotta una opzione del TCP, nota come "TCP Window Scale Option", che con un trucchetto semplice ma quantomai diabolico, consente di ampliare di molto la finestra del TCP, fino ad arrivare a un valore massimo di poco superiore a 1 Gbyte (per i dettagli potete leggervi la RFC 1323, oppure dare un'occhiata a questo post). Attenzione però che l'opzione potrebbe non essere supportata da uno degli estremi della connessione (e in questo caso non viene abilitata), oppure disabilitata da apparati intermedi come firewall o load balancer.

In conclusione, in assenza di perdita di pacchetti, il throughput di una sessione TCP dipende in modo essenziale dal valore di RTT e dall'ampiezza della finestra di ricezione, e non dalla banda fisica disponibile !

Ma la storia non finisce qui, perché non ho ancora considerato un altro parametro che influenza il throughput ...

LA FORMULA DI MATHIS
Le considerazioni fatte nella sezione precedente valgono nel caso puramente teorico di perdita nulla dei pacchetti. Nelle applicazioni pratiche la perdita dei pacchetti non è mai nulla e quindi è lecito chiedersi quale sia l'influenza della perdita dei pacchetti sul throughput TCP. 

Come arcinoto, il TCP reagisce alla perdita di un segmento mediante il meccanismo di Congestion Avoidance, il cui scopo è quello di reagire a una congestione di rete nel verso Trasmettitore --> Ricevitore, regolando il flusso di segmenti TCP che un host invia in rete. Il meccanismo è descritto nella RFC 5681 (che è una revisione della vecchia RFC 2581), ed esistono varie diverse implementazioni (Tahoe, Reno, New Reno, Cubic, tanto per citare le più note). 

NOTA: il TCP considera la perdita di un segmento come un segnale di congestione sulla rete. In realtà questo non è sempre vero poiché il segmento potrebbe andare perso per altri motivi (es. errori di trasmissione). Ma il TCP, non avendo altri strumenti disponibili, interpreta sempre la perdita di un segmento come un segnale di congestione. Un modo (non l'unico) per rilevare la perdita di un segmento è la scadenza del Retransmission Time-Out (RTO), che come tale quindi deve essere leggermente superiore al RTT. Le implementazione TCP più attuali stimano in tempo reale il RTT con algoritmi di exponential smoothing e quindi utilizzano la formula RTO = RTT(stimato) + delta, dove delta è un valore prefissato. In realtà, poiché attendere il RTO fa perdere troppo tempo, vengono utilizzati meccanismi di fast retransmit (es. TCP Tahoe).

La regolazione si basa sull'utilizzo di una finestra di trasmissione cnwd, che è espressa in numeri interi, dove ciascun numero è il permesso di inviare un segmento TCP di lunghezza MSS (Maximum Segment Size, es. 1460 byte). Semplificando di molto, il meccanismo una volta rilevata la perdita di un segmento TCP entra in fase detta Slow Start (che poi tanto “slow” non è poiché ha una progressione geometrica) durante la quale il valore cnwd viene posto a 1, e quindi aumentato di uno ogniqualvolta viene ricevuto un ACK (non fatevi ingannare, il valore cnwd è vero che aumenta di 1, ma il valore della finestra viene effettivamente raddoppiato; la prova è lasciata al lettore come esercizio). Solo per curiosità, nella figura seguente, tratta da Wikipedia, è riportato l'andamento del valore di cnwd nel tempo (i pallini rappresentano gli istanti di arrivo degli ACK).




L'utilizzo del meccanismo di Congestion Avoidance fa sorgere spontanea una domanda: quale relazione esiste tra throughput e perdita ? Vi è una vasta letteratura che ha trattato questo argomento, utilizzando modelli matematici più o meno sofisticati. La relazione base è stata trovata da Matthew Mathis, Jerey Semke e Jamshid Mahdavi in un articolo del Luglio 1997 "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm" (scaricabile a questo link), ed è nota in letteratura come formula di Mathis.

La formula di Mathis è la seguente: 









dove TH(p) indica il ThroughputMSS il Maximum Segment Size, negoziato dai due peers della connessione durante il three-way-handshake (ossia, durante la fase iniziale di apertura della connessione TCP) e p è la probabilità di perdita (in valore assoluto) di un segmento TCP.  La costante C varia in funzione della modalità con cui vengono inviati gli ACK; ad esempio, nel caso venga utilizzato un algoritmo di tipo Delayed ACK, la costante assume valori leggermente inferiori a 1. Nel lavoro originale di Mathis, Semke e Mahdavi, C = SQRT(3/2), circa 1,22. 

In sostanza, la formula dice che il throughput varia in funzione dell'inverso della radice della probabilità di perdita di un segmento TCP. In realtà però, a causa delle semplificazioni modellistiche utilizzate per la sua derivazione, la formula va più vista come un limite superiore al throughput piuttosto che per la determinazione di un valore puntuale. Ma questo non ne svilisce l'importanza.

Come va utilizzata la formula di Mathis ? Ad esempio, nel caso di MSS = 1.460 byte (= 11.680 bit), RTT = 10 ms e p=0,0001, ipotizzando una costante C = 1, si ha che TH = 116,8 Mbit/s. Ma poiché abbiamo visto sopra che il TH in assenza di perdita, con una RW massima (senza window scaling) di 65.535 è pari a 52,428 Mbit/s, l'upper bound fornito dalla formula di Mathis non è in questa situazione significativo. Con gli stessi valori, ma ipotizzando invece p = 0,01, la formula di Mathis da un upper bound per TH di 11,68 Mbit/s, inferiore al valore in assenza di perdita. Quindi, ricapitolando, la formula complessiva che fornisce un upper bound per il Throughput TCP è la seguente:

TH <= min[MSS*C/SQRT(p), RW]/RTT  = min[<cnwd>*MSSRW]/RTT

dove <cnwd> = TH(p)*RTT/MSS = C/SQRT(p) è una stima della finestra media di congestione. 

In altre parole, la formula di Mathis ci dice che per piccoli valori di perdita il Throughput è limitato dall'upper bound RW/RTT, mentre per valori di perdita consistenti dal valore <cnwd>*MSS/RTT.

SOLUZIONI TECNICHE CHE CONSENTONO DI AUMENTARE IL THROUGHPUT TCP
Riassumendo quanto visto fin qui:

  • Il Throughput è in genere inferiore alla banda disponibile (spesso molto inferiore !).
  • Per aumentare il Throughput è necessario agire su RTT e perdita dei pacchetti, riducendoli entrambi.
  • L'aumento della sola banda, anche fosse end-to-end, non è sufficiente a garantire livelli adeguati di Throughput.

E dal Throughput dipende la QoE, ossia la soddisfazione del Cliente finale nell'utilizzo delle applicazioni.

Cosa fare allora per aumentare il Throughput e quindi aumentare la QoE ? L'idea è semplice, la realizzazione un po' meno: si tratta di avvicinare il più possibile i contenuti al Cliente finale. Questo comporta una diminuzione del RTT (meno strada da fare per accedere ai contenuti e riceverli) e anche della perdita poiché diminuisce il numero di apparati da attraversare.

Queste problematiche sono state affrontate in passato con vari strumenti, il più noto dei quali sono le Content Delivery Network (CDN). Una CDN può essere vista come un insieme di server, gestito da terze parti (un esempio celebre è Akamai) o direttamente dal fornitore di contenuti (es. Google), posizionato ai bordi o all'interno di una rete di un ISP. Nei server della CDN sono memorizzati i contenuti richiesti dagli utenti finali. Non tutti ovviamente, ma solo quelli di chi paga il gestore della CDN per ospitarli nei propri server. Nel caso degli OTT, considerata la loro forza economica, le CDN sono gestite in proprio.

Il difetto delle CDN è che in un certo senso sono "stupide", nel senso che avvicinano agli utenti dei contenuti predefiniti, che sono quelli di chi paga il gestore della CDN. E questo indipendentemente dell'interesse del Cliente per questi contenuti.

Negli ultimi anni si è fatta strada una evoluzione "intelligente" delle CDN, le Transparent Cache. Diversamente dalle CDN, i cui server hanno all'interno i contenuti definiti sulla base di accordi commerciali, le Transparent Cache utilizzano algoritmi "intelligenti"  per decidere quali contenuti memorizzare. Collocandole in modo strategico sulla rete dell'ISP, consentono di avvicinare i contenuti più popolari agli utenti finali, aumentando di conseguenza la QoE, e riducendo il traffico in transito sulla rete.

Per il momento mi fermo qui. In un prossimo post tratterò gli aspetti essenziali del Transparent Caching, i trade-off da valutare per la loro introduzione in rete, cercando di quantificare i vantaggi (molti) e svantaggi (pochi) che si ottengono dal loro inserimento in rete.

CDN e Transparent Caching non sono gli unici strumenti a disposizione per migliorare la QoE. Altri strumenti come TCP accelerator e Front End Optimization non sembrano godere degli stessi vantaggi, per cui non li tratterò.

CONCLUSIONI
Spesso e volentieri il concetto di banda inganna. Intuitivamente, l'equazione "maggiore banda = maggiore qualità" sembra vera. Ma spesso e volentieri non è così. In questo post ho cercato di mettere in evidenza il problema. Per carità, tutta roba che ogni networker ha nel suo bagaglio culturale (magari non la formula di Mathis, sconosciuta ai più), ma spesso si cade nel tranello.

Al di la di questo, mi premeva mettere in evidenza la necessità di dotare le reti di strumenti che consentano di migliorare la Quality of Experience. Le Transparent Cache sembrano al momento lo strumento più promettente e mi riprometto di tornarci con maggiori dettagli in un prossimo post.

RINGRAZIAMENTI: un particolare grazie al mio amico Gianfranco Ciccarella, ex-Top Manager Telecom, ora in pensione (virtuale), per le fruttuose illuminanti discussioni e scambi di idee sull'argomento trattato in questo post.

  









13 commenti:

  1. Questo articolo dovrebbe essere letto da tutti coloro che si occupano di reti e di QOE dei clienti

    RispondiElimina
    Risposte
    1. Grazie per il commento. L'argomento è spesso trascurato ma secondo me di grande importanza. In un prossimo post illustrerò l'importanza delle piattaforme di Transparent Caching, uno dei metodi più promettenti per aumentare la QoE.

      Elimina
  2. Complimenti! Nel prossimo articolo credo sia importante far chiarezza sui benefici delle cache non solo come copia di contenuti vicino all'accesso (che funziona solo se per accessi multipli agli stessi media), ma proprio come acceleratore TCP spezzando la connessione end2end in loop più corti. Avanti così!

    RispondiElimina
  3. Grande post, la competenza non passa mai di moda !

    RispondiElimina
  4. Carissimo, complimenti per l'articolo, a quanto scritto bisognerebbe aggiungere il Throughput di livello 2 di una lan ethernet, pari a 97,4%.
    L'header ethernet è infatti pari a 38 byte, oltre ai 18 canonici vanno aggiunti 7 byte di preambolo
    1 byte del campo start frame delimiter e 12 byte del "non campo" Interpacket gap.
    A liv. 3/4 il Throughput massimo di una lan scende al 94,8%, l'overhead dei prorocolli sale a 78 byte,
    20 byte header ip + 20 byte header tcp.
    Il Throughput del 94,8% è calcolato in condizioni ideali, trascurando i tempi di propagazione,
    l'eventuale perdita di pacchetti e i pacchetti pieni a 1500 byte.
    Su un collegamento geografico PPPoE, limitatamente al tragitto router/nas, i tempi
    di propagazione e la perdita di pacchetti non sono più trascurabili, ma oltre a questo va aggiunto
    l'overhead del PPPoE pari a 8 byte (6 byte del PPPoE + 2 byte del PPP) ed il Throughput scende ulteriormente.

    Un salutone

    Riccardo

    RispondiElimina
  5. << Ma cosa rappresenta il BDP ? Semplice, il valore che dovrebbe assumere la finestra di ricezione per sfruttare tutta la banda fisica disponibile. Maggiore è il valore di RTT, maggiore il valore di BDP >>
    in teoria maggiore è il valore di RTT minore è il valore del BDP :|

    RispondiElimina
    Risposte
    1. Non proprio. Se il BDP è il prodotto Banda*RTT, all'aumentare di RTT, a parità di banda disponibile. non può che aumentare ...

      Elimina
  6. Buongiorno Ammiraglio! Anzitutto grazie per la condivisione degli articoli, sempre fonte di ispirazione, di importanti nozioni ma soprattutto che spiegano nel concetti che molte volte sono un pò ostici da affrontare solo da un punto di vista teorico...vedi TCP/IP illustrated :) Ciò detto mi domandavo: usando un software lato client che sfrutta sessioni TCP (socket) multipli si può arrivare ad utilizzare effettivamente il Gbps? Uso spesso downthmeall (plugin browser) piùttosto che filezilla nel caso di FTP che sfruttano la banda disponibile appunto creando più socket.. in quanto, se non erro, il windows size è un parametro globale sullo stack TCP/IP del device ma è per socket. Corretto? Grazie e buona giornata!

    RispondiElimina
  7. Buongiorno Ammiraglio, utilizzando software per testare il troughput di un link e appurato che una connessione TCP quasi sempre non raggiunge il valore di Banda;Effettuando un test con sessione UDP è possibile raggiungere valori di Througput uguali o vicini alla banda disponibile?
    Se tramite sessioni UDP il troughput raggiunge valori vicinissimi alla banda disponibile si può confermare che la banda assegnata da un service provider è compliant con quanto viene venduto?
    Si può confermare la bontà di un circuito con sessioni UDP?
    Naturalmente parlo di link non residenziali con connettività fibra e tecnologia DWDM.

    RispondiElimina
  8. Ottimo articolo. Grazie mille

    RispondiElimina
  9. "Bene, a me hanno insegnato che il 90 % del traffico smaltito dalle reti IP utilizza come protocollo di trasporto il TCP."

    Not more TCP...

    ref.: new protocols used by internet clients:

    HTTP/2 -> RFC 7540 https://tools.ietf.org/html/rfc7540
    ESNI -> https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ https://www.cloudflare.com/ssl/encrypted-sni/
    DoH (DNS over https) -> RFC 8484 https://tools.ietf.org/html/rfc8484
    HTTP-over-QUIC -> renamed to HTTP/3 in November 2018 (plan RFC by July 2019) https://daniel.haxx.se/blog/2018/11/26/http3-explained/

    @rtaccon

    RispondiElimina
  10. Grande TiTo! Riesci a farti capire anche da me!
    Un abbraccio.
    Antonello

    RispondiElimina