197 lines
9.1 KiB
Markdown
197 lines
9.1 KiB
Markdown
# 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 di `beta*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`, con `b < 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**.
|