In reti dove sono presenti lunghi ritardi, si necessita di una politica di gestione della nestra molto più aggressiva per mantenere e controllare la congestione anche attraverso gli apparati di rete intermedi. In questo paragrafo cercheremo di capire come sono state utilizzate delle nuove euristiche per realizzare un protocollo che è conosciuto come Yet Another High-Speed TCP - YeAH; ulteriori informazioni possono essere esaminate su [BCV07]. Il protocollo TCP venne pensato ed implementato negli anni '80 [Pos81] e ad oggi continua ad essere molto performante, poiché sulle sue basi solide è riuscito a seguire il trend evolutivo delle reti, che hanno modi cato sostanzialmente la mole di dati trasportabile (per citare un esempio sui backbone si è passati da 64Kbps agli attuali 10Gbps). Raggiungere delle buone performance in queste condizioni non è sempre facile e come abbiamo visto sono state molte le proposte per cambiare il controllo di usso del protocollo di trasporto.
Svariati lavori attuali, per lo studio dei problemi di congestione nelle reti TCP/IP, fanno riferimento al Bandwidth Delay Product (BDP ) e classi cano gli algoritmi che vengono utilizzati sostanzialmente in quattro categorie operative, quali
Loss Based Delay based Mesh
Network's noti cations
Gli algoritmi che ricadono nella prima categoria considerano la perdita di pacchetto come con- dizione implicita di congestione della rete, nella seconda categoria viene considerato il ritardo come sintomo di congestione, e la modi ca alla nestra CongW in viene fatta in accordo con i tempi di round trip riscontrati. Nella terza categoria ci sono approcci misti e la nestra viene aggiornata utilizzando entrambe le tecniche e scegliendo nell'istante in cui ci si trova quale sia l'approccio migliore. L'ultima classe algoritmica, solitamente, non si considera molto poiché utilizza messaggi speci ci dalla rete e necessita quindi una sincronizzazione con i router e tutti gli apparati intermedi, cosa ovviamente quasi mai fattibile. Questi lavori, come ad esempio in [Bor07], hanno dimostrato che eettivamente non esiste un paradigma migliore di un altro sulle reti BDP ; infatti un algoritmo che si comporta in modo corretto da una parte può non essere uguale dall'altra.
Ad oggi la diusione dei controlli di congestione TCP preserva la rete da possibili e continui imbottigliamenti; tuttavia se l'algoritmo di controllo del usso non è ben disegnato si possono avere situazioni di instabilità e degrado trasmissivo. Il protocollo YeAH cerca di sopperire a queste mancanze soprattutto nelle reti con alto BDP , cercando di diagnosticare la congestione prima che questa si veri chi.
2.10.1 L'algoritmo
La progettazione dell'algoritmo che governa il protocollo YeAH, ha tenuto conto di importanti considerazioni che di seguito elenchiamo al ne di rendere più completa la nostra trattazione. In generale possiamo sostenere che
La capacità trasmissiva della rete deve essere valutata in maniera e ciente; questo obiettivo comune a tutti i protocolli deve essere raggiunto modi cando le politiche di aggiornamento della nestra di congestione. Come verrà descritto in seguito YeAH TCP sfrutta ogni regola di incremento proposta in altri algoritmi (STCP, H-TCP, etc.)
Lo stress introdotto sulla rete deve essere minore, oppure uguale, a quello introdotto da TCP Reno
E' necessario che la friendliness del nuovo protocollo con il tra co di TCP Reno sia corretta e l'allocazione di banda sia equa
L'algoritmo deve essere necessariamente fairly soprattutto per quello che riguarda la ges- tione degli RT T
Le performance non devono essere impari con condizioni di congestione randomiche; perdite di pacchetti casuali non possono dettare le regole all'interno di queste reti, nemmeno in presenza di backbone che lavorano con Gigabit
Piccoli buer non devono prevenire alte prestazioni. Non è utile disegnare dimensioni di buer uguali al prodotto BDP come richiesto dallo standard di controllo di congestione di TCP Reno. Questo obiettivo può essere raggiunto adottando una politica di decremento, in caso di perdita dei pacchetti, simile a quella che abbiamo incontrato con Westwood L'algoritmo costruito per YeAH TCP cerca di raggiungere gli obiettivi di cui sopra ed utilizza due modalità operative; una prima che chiamiamo Fast ed una denominata Slow. Se ci troviamo nel periodo Fast la nestra di congestione viene incrementata in accordo con una regola che lavora in modalità aggressiva (greedy); nel caso in cui ci trovassimo nella fase Slow le funzionalità sarebbero le stesse adottate nel protocollo TCP Reno. Lo stato ed il tempo di operatività viene deciso in accordo con il numero di pacchetti stimato nella coda del buer presente nell'apparato intermedio di rete.
Sia RT Tbase il minimo RT T misurato dal mittente e RT Tmin il minimo RT T stimato nella nestra di dati corrente CongW in. Il ritardo sulla coda previsto è dunque dato da RT Tqueue= RT Tmin − RT Tbase, da cui è possibile inferire il numero di pacchetti già accodati nel usso semplicemente, utilizzando la seguente formula
Q = RT TqueueG = RT Tqueue
CongW in RT Tmin
(2.56) dove G è detto goodput15. Il livello di congestione della rete è noto utilizzando RT Tqueue ed
il minimo degli RT T stimati dal mittente come L = RT Tqueue/RT Tbase. Se Q < Qmax e L < 1/ϕ, l'algoritmo è nella modalità Fast altrimenti si trova in modalità Slow. Qmax e ϕ sono due parametri con gurabili e rappresentano rispettivamente il massimo numero di pacchetti di un singolo usso che possono essere contenuti in un buer ed il massimo livello del buer di congestione in riferimento al valore BDP. Durante la fase Slow viene anche implementato un algoritmo di decongestione; questo stabilisce che ogni volta che Q > Qmax, la nestra di congestione viene diminuita di Q e sshtresh viene impostato a CongW in/2.
Consideriamo il caso in cui un singolo usso YeAH-TCP sia in competizione con un altro in un buer; qui Q rappresenta una stima dell'eccesso di pacchetti rispetto alla minima CongW in richiesta, per raggiungere la larghezza di banda disponibile.
15Nelle reti di computer, goodput è il throughput a livello di applicazione, cioè il numero di bit utili per unità
di tempo trasmesso dalla rete da un determinato indirizzo di origine a una certa destinazione, escludendo gli overhead di protocollo ed i pacchetti ritrasmessi.
Il numero di questi pacchetti può essere rimosso dall'attuale nestra di congestione, senza che si degradi il goodput. Quando il numero di ussi in competizione aumenta, ognuno cerca di riempire il buer con lo stesso numero di pacchetti (al massimo Qmax), indipendentemente dal round trip time percepito raggiungendo quindi una RT T fairness interna. L'algoritmo di decongestione è ottimo solo quando i ussi che lo implementano non sono tra di loro in compe- tizione e non operano in modalità aggressiva, come generalmente fa TCP Reno. Per evitare la competizione tra questi ussi YeAH-TCP implementa un meccanismo di ricerca.
Analizziamo il caso in cui ci sia competizione con un usso Reno, e non venga implemen- tato nessun meccanismo di decongestione. Quando Q > Qmax l'algoritmo cerca di rimuovere i pacchetti dalla coda, il ritardo si incrementa perchè i ussi Reno in modo greedy cercano di riempire gli spazi disponibili. In questo caso YeAH-TCP resterà quasi sempre nello stato Fast. Al contrario quando i ussi non sono greedy l'algoritmo YeAH-TCP passerà dallo stato Fast a quello Slow ogni volta che il contenuto dei buer raggiunge il valore di Qmax e quindi è nec- essaria una decongestione rapida. Utilizziamo due nuove variabili, rispettivamente countreno e countf ast e cerchiamo di capire quello che succede. La countf ast rappresenta il numero di RT T nella modalità Fast, mentre countreno è una stima del valore della nestra di congestione dei ussi competitivi di tipo TCP Reno. La decongestione avviene solo durante la fase Slow e se CongW in > countreno per evitare che la CongW in decresca al di sotto del valore stimato del usso TCP Reno. All'avvio della connessione countreno è inizializzato a CongW in/2 ed è incre- mentato di un MTU ogni RT T ; quando si veri ca una perdita di pacchetto questo valore viene dimezzato. Questa variabile viene resettata a CongW in/2 ogni volta che countf ast è maggiore del valore di treshold, indicando che il usso compete con quelli non greedy; nello stesso istante countf ast viene resettato a zero.
Come abbiamo visto il protocollo YeAH cerca in tutti i modi di prestare molta attenzione alle proprietà di fairness ed alla friendliness su ussi TCP concorrenti, garantendo costantemente un utilizzo di banda equo e paritario a tutti. Il suo approccio basato sulle code e sui ritardi nei buer potrebbe essere molto interessante in un canale wireless anche se tuttavia potrebbe non bastare per compensare anche gli eventi di perdita che come abbiamo visto sono del tutto casuali su link di questo tipo.