9.1 KiB
Sistema di controllo in tempo continuo - TCP (continua)
(vedi slides)
Modellando un sistema in cui un mittente che invia un pacchetto tramite router AQM con probabilita' di perdita p(t), si puo' analizzare lo scenario singolo collo di bottiglia, in cui supponiamo:
- singolo link congestionato di capacita' C
- N flussi TCP infiniti che attraversano il link (seguendo un path punto-punto)
(slides per formule RTT e throughput B)
Router RED
Se il router congestinato e' gestito con RED, possiamo collegare la probabilita' di perdita con la lunghezza della coda. RED infatti scarta i pacchetti in arrivo in base alla lunghezza attuale della coda, calcolata con media mobile esponenziale.
Ignorando timeouts e slow start: Possiamo quindi scrivere un'ODE che descriva la dimensione della finestra del router congestionato, di modo da ottenere un sistema di ODE che descriva la lunghezza istantanea della coda. (slides per formule)
Due ODE: una per la window size, una per la lughezza della coda.
Window size
Le equazioni sono costruite sommando le componenti di additive increase e multiplicative decrease. Abbiamo due rate: uno che descrive la ricezione di ACKs (e quindi pacchetti non persi) che implicano additive increase, mentre il secondo rate e' dipendente da p(t) e indica i pacchetti persi (multiplicative decrease).
Ignorando i feedback delay, possiamo semplificare ulteriormente la ODE. (vedi slides)
Lunghezza istantanea della coda
Come per la window size, anche la lughezza della coda e' pilotata da due componenti: traffico in ingresso e traffico in uscita. Il traffico in ingresso e' ottenuto aggregando i flussi che mandano pacchetti su una stessa coda.
Risoluzione Equilibrio (comportamento a regime)
Il sistema di ODE e' pensato per studiare l'evoluzione nel tempo, ma e' molto utile studiare la soluzione di equilibrio (derivata == 0). Cosi' facendo, ci riconduciamo alla sqare root formula.
Risoluzione transitorio
Non calcolata a mano ma con un risolutore, di seguito la descrizione del sistema ottenuto.
Evoluzione della media mobile esponenziale
(vedi slides)
Evoluzione della probabilita di perdita
(vedi slides) Si utilizza la chain rule, dove dp/dx e' il profilo di RED.
Equazioni accoppiate
Ottenute tutte le equazioni di interesse, si ottengono N+2 equazioni accoppiate, che possono essere messe a sistema, per ottenere la lughezza istantanea e mediata della coda, da cui posso ottenere la probabilita' di perdita.
Multipli colli di bottiglia
E' possibile studiare una rete fatta da multipli colli di bottiglia, creando sistemi di equazioni che descrivano i singoli router. Si puo' quindi calcolare la probabilita di perdita totale su un percorso e il RTT totale. (vedi slides per formule)
Accuratezza del modello
L'accuratezza del modello proposto e' studiata supponendo:
- Una serie di link non congestionati di capacita' elevata
- Un link congestionato con capacita' ridotta, alimentato dai link
- Simulando flussi tcp, dopo un certo tempo (30 sec) si introduce un guasto della rete in cui i flussi dimezzano. Questo permette di studiare il transitorio dell'oggetto (router RED) a seconda delle variazioni di carico.
- Plottando il modello fluido calcolato e il modello simulato, si nota un accordo evidente tra i risultati misurati e quelli calcolati.
Il risultato e':
- Il modello cattura la dimensione della finestra media con un accuratezza molto elevata, supponendo una popolazione omogenea di flussi.
Proprieta' di scalamento del modello
(nota: OC-12 rappresenta una banda fisica, OC-48 = OC-12 x 4
Immaginando di moltiplicare la quantita' di flussi e le capacita' per una costante j, possiamo simulare una situazione di scalamento, la finestra media dei flussi rimane invariata:
Wk(t) = Wj,k(t) W = window size
Qv(t) = Qj,v(t)/j q = lunghezza coda
Questo permette di garantire lo stesso throughput sotto ipotesi di scalabilita', il che e' molto utile nel caso di sistemi troppo grandi da essere simulati. Posso quindi simulare un sistema scalato verso il basso, perche' so che scalando mantengo il throughput.
Nota: se il router e' RED, e' necessario scalare anche il profilo RED.
Altre applicazioni
- Il modello e' estendibile al caso di code drop tail.
- Il modello e' utile prettamente per studiare la stabilita' e la taratura di RED.
- Il modello e' usato anche per studiare il fenomeno della congestione dal punto di vista controllistico.
Semplificazione del sistema di ODE
Utile in futuro.
dW/dt = W/R (1/W - p*W/2)
TCP CUBIC
Implementazione di default in Linux.
-
E' caratterizzato da un fattore di decrease multiplicativo
beta, che ad ogni perdita diminuisce la dimensione della finestra dibeta*W. -
In assenza di perdite, TCP CUBIC utilizza un polinomio di terzo grado per predire l'evoluzione della finestra:
W = C(t - K)^3 + Wmax
Dove:
t = tempo misurato dall'ultima perdita
K = cubicroot(Wmax*beta/C)
C = parametro limitato dalla curva cubica, dove consideriamo un decrease di beta*W ottenendo:
Wmax*(1-beta) = -C*K^3 + Wmax
=> beta*Wmax = C*K^3
Da cui si puo' ottenere C e K
L'unico parametro libero e' dato da dopo quanto tempo il valore della finestra torna a quello iniziale.
(slides per plot)
L'implementazione di TCP CUBIC e' migliore del modello classico a dente di sega perche', mentre nel modello classico il tempo di ritorno al valore precedente e' dipendente da W e RTT, in TCP CUBIC e' un parametro libero.
Problematiche di TCP standard: scenario ad alte prestazioni
Considerando una singola connessione TCP standard con un throughput atteso altissimo (x Gbps), (vedi slides) scopriamo che TCP standard richiede una finestra media di congestione di 83333 segmenti.
Dato che la durata del dente di sega dipende dalla finestra media, otteniamo (applicando la square root formula) che la durata del dente di sega e' ~ di 1 ora e 40 minuti, a cui poi segue una nuova perdita (e quindi il ciclo ricomincia).
La quantita richiesta di tempo e' troppa per uno scenario ad alte prestazioni, perche' una grande quantita' di tempo e' passata con una window size sottodimensionata.
Il tempo T tra due segnali di congestione e' infatti proporzionale al throughput e RTT:
T = B*R^2 / c^2
Quindi: throughput alto, tempo maggiore per la crescita della finestra, rallentando le dinamiche di TCP.
TCP non scala in scenari di altissimo throughput.
(vedi slides per calcoli, quella scritta a mano definita back-of-the-envelope computations)
Soluzione al problema
C'e' un ampio spettro di soluzioni:
- Apertura di N connessioni TCP in parallelo, ma richiede un middleware di divisione / riassemblaggio dei dati complicatissimo
- Uso di MulTCP, una singola connessione che ottiene un comportamento simile a multiple connessioni TCP virtuali. Questo implica una decrescita di
b*W, conb < 1/2. L'idea e' di rendere TCP piu' aggressivo, limitando la decrescita del dente di sega.
Per migliorare la decrescita, si puo' calcolare la W partendo dalla ODE semplificata vista in precedenza. (vedi slides)
Altre soluzioni:
Soluzioni a basso costo implementativo (cambiamenti marginali)
Highspeed TCP (TCP con parametri modificati)
Utilizza un additive increase, multiplicative decrease ma gli incrementi e i decrementi dipendono dalla window size. I cambiamenti sono segnati come parametri di una tabella, inclusa nell'implementazione di TCP.
Plottando il sending rate sul loss rate, vediamo che Highspeed TCP utilizza una pendenza modificata (0.15/p^0.82) rispetto alla pendenza di standard TCP ( 1.22/p^0.5)
Scalable TCP (slides) e CUBIC TCP utilizzano una pendenza ancora migliore (vedi plot).
Scalable TCP (TCP con multiplicative increase)
L'utilizzo di multiplicative increase, multiplicative decrease:
W = W+a // per ogni ACK -> crescita geometrica se si considerano i RTT
W = W-b*W // per finestra di cui si rileva la perdita
Si nota che questo multiplicative increase, il tempo tra due segnali di perdita (aka durata del dente di sega) non dipende piu' dal throughput:
B = a/(R*b*p) => T = (b*R) / a
Questo risultato e' ottenuto a partire dall'ODE semplificata, ponendo la soluzione di equilibrio (quindi con la derivata nulla).
(vedi slides per grafici di prestazioni di STCP)
Scalable TCP e' stato creato nei primi 2000 ma non ha avuto una grossa considerazione. In compenso, TCP CUBIC ha utilizzato il suo stesso concetto di scalabilita'.
TCP CUBIC: scalabilita'
Utilizzando una curva cubica, TCP CUBIC e' in grado di migliorare Scalable TCP (che invece sale esponenzialmente al punto di congestione), mantenendo comunque un throughput proporzionale a 1/p.
Il miglioramento di Scalable TCP e' dovuto proprio alla stabilita' di una curva cubica (migliore fairness, migliore scalabilita') rispetto a una curva esponenziale, che si rivela molto piu' aggressiva.
Altre soluzioni
- Protocolli di congestione delay-based, studiando il RTT posso regolare la finestra (TCP FAST, TCP VEGAS).
- Controllo di congestione supportato dai router: XCP.