200 lines
10 KiB
Markdown
200 lines
10 KiB
Markdown
|
# TCP - relazione throughput / probabilita' di perdita
|
||
|
|
|
||
|
|
*(continua)*
|
||
|
|
Il modello idealizzato vede l'evoluzione di TCP come crescita lineare, dimezzamento, e cosi' via *(vedi slides)*. L'obbiettivo dell'analisi e' trovare il throughput in funzione di probabilita' di perdita e RTT.
|
||
|
|
|
||
|
|
Vogliamo sommare i pacchetti tra w/2 e w, per ottenere un modello approssimato che descriva i pacchetti persi.
|
||
|
|
|
||
|
|
#### Sommatoria particolare tra w/2 e w
|
||
|
|
|
||
|
|
```
|
||
|
|
sum of i ,i ranging from a to b = (a+b) * (b - a + 1) / 2
|
||
|
|
```
|
||
|
|
Questa sommatoria puo' essere utilizzata nel caso in cui:
|
||
|
|
```
|
||
|
|
a = w/2
|
||
|
|
b = w
|
||
|
|
```
|
||
|
|
Facendo si' che la sommatoria di i con i compreso tra w/2, w sia `= (3/2*w)*(w/2 + 1)/2` *(vedi slides)*
|
||
|
|
|
||
|
|
Nota: essendo che w e' supposto essere molto grande, il termine in `w^2` e' molto maggiore del termine in `w`, quindi possiamo considerare **solo il termine quadratico**.
|
||
|
|
|
||
|
|
*(vedi slides per risultato approssimato)*
|
||
|
|
|
||
|
|
A questo punto, dobbiamo considerare anche la **probabilita di perdita**:
|
||
|
|
|
||
|
|
```
|
||
|
|
ploss = 8 / (3*w^2) ovvero w = sqrt(8/(3*ploss))
|
||
|
|
```
|
||
|
|
Che quindi significa che **il throughput e' inversamente proporzionale a RTT e ploss**. Questo risultato e' comunque ottenuto ignorando slow start, timeouts, dimensione max della finestra.
|
||
|
|
Per tener conto anche di timeouts e finestra massima, possiamo usare un modello dettagliato *(pubblicato da kurose)* che ha il nome di **PFTK** (dal nome degli autori). *(vedi slides per formula e descrizione)*.
|
||
|
|
Questo e' il modello piu' utilizzato per il throughput di TCP.
|
||
|
|
|
||
|
|
## Modello PFTK
|
||
|
|
|
||
|
|
E' un'analisi di ciclo (come l'esempio simplificato precedente) che pero' comprende anche i timeouts (eventualmente consecutivi). Quindi:
|
||
|
|
|
||
|
|
```
|
||
|
|
throughput = #pacchetti mandati in un ciclo / durata ciclo
|
||
|
|
```
|
||
|
|
Si considera una probabilita' di perdita indipendente da RTT a RTT. Questo modello e' stato verificato sperimentalmente *(vedi slides)* utilizzando strumenti come *tcpdump* per misurare timeout e pacchetti ricevuti.
|
||
|
|
|
||
|
|
Utilizzando questo modello, costruendo un grafico in scala **logaritmica** (asse x = loss frequency (probabilita' di perdita), asse y = #packets sent (pacchetti inviati)) si e' visto che il legame tra i due dataset e' una retta (in scala logaritmica).
|
||
|
|
|
||
|
|
## Analisi ad anello aperto e ad anello chiuso
|
||
|
|
|
||
|
|
Le precedenti analisi si riferiscono a **singole connessioni TCP che hanno nota probabilita' di perdita e RTT**. Questa e' definita **analisi ad anello aperto**.
|
||
|
|
|
||
|
|
Interessante e' studiare l'**analisi ad anello chiuso**, che si riferisce all'** interazione di tanti flussi TCP in rete**.
|
||
|
|
|
||
|
|
### Analisi ad anello chiuso
|
||
|
|
|
||
|
|
*(vedi slides per ripasso di gestione della coda RED)*
|
||
|
|
|
||
|
|
In una coda RED:
|
||
|
|
* la probabilita' di perdita dei pacchetti dipende dalla lunghezza media della coda
|
||
|
|
|
||
|
|
Supponiamo che nella rete ci sia **un singolo link congestionato (quindi con pacchetti in coda).**
|
||
|
|
Supponiamo inoltre che i flussi siano lunghi (difficili da trasmettere), e che ogni flusso TCP che attraversa il link subisca la stessa probabilita' di perdita. La domanda e':
|
||
|
|
* **i flussi avranno lo stesso throughput?**
|
||
|
|
|
||
|
|
La risposta e' **NO** perche' avranno RTT diverso, e come si e' visto dai grafici dei modelli, RTT piu' lunghi sono penalizzati (subiscono piu' perdite).
|
||
|
|
|
||
|
|
La soluzione di equilibrio si trova con un metodo detto **punto fisso**, con cui si ottiene:
|
||
|
|
|
||
|
|
```
|
||
|
|
sum for i of (B[i] * (p,RTT[i])) = C
|
||
|
|
```
|
||
|
|
*(vedi slides)*.
|
||
|
|
|
||
|
|
#### Singolo collo di bottiglia: flussi infiniti
|
||
|
|
|
||
|
|
Si considerino N flussi TCP con infiniti pacchetti da trasmettere. Il modello *(vedi slides)* puo' essere descritto:
|
||
|
|
|
||
|
|
```
|
||
|
|
p = p(x) // p funzione nota
|
||
|
|
RTT[i] = A[i] + x/C // A[i] e' la componente costante di propagazione per il flusso i, mentre x/C e' la velocita' // con cui il link scarica una coda di lunghezza x. (C e' la velocita')
|
||
|
|
|
||
|
|
sum for i of (B[i] * (p,RTT[i])) = C[i]
|
||
|
|
```
|
||
|
|
La soluzione al punto fisso e' trovata per x, dove x e' usata nel calcolo di RTT e p. La soluzione **esiste ed e' unica**, perche' B e' **monotona e continua rispetto a x.**
|
||
|
|
|
||
|
|
*(vedi slides per grafici di rapporto throughput stimato / misurato e probabilita' di perdita stimata / misurata)*
|
||
|
|
Dai grafici si nota che la probabilita' di perdita e' molto precisa se il modello e' PFTK, mentre la piu' semplice square root formula predice una perdita molto piu' alta (non considerando i timeout).
|
||
|
|
|
||
|
|
## Nuove versioni di TCP
|
||
|
|
|
||
|
|
Attorno agli anni '90 si e' cominciato a modellare TCP e a costruire varianti per cui il grafico throughput / probabilita' di perdita da risultati migliori. Per ottenere questo risultato, si e' mescolato un collo di bottiglia con TCPnuovo e TCPstandard. Da questi esperimenti, molte delle *nuove* versioni di TCP hanno un throughput migliore.
|
||
|
|
|
||
|
|
Questo metodo pero' e' privo di senso, *(vedi slides per esperimento descritto matematicamente)*
|
||
|
|
|
||
|
|
Infatti, supponendo due scenari: il primo in cui tutti usano la TCPnuova e il secondo in cui tutti usano la TCP standard. Essendo che entrambe le versioni sono limitate dalla stessa velocita' del link, notiamo che la nuova versione, piu' *aggressiva*, tende a generare una probabilita' di perdita piu' **alta** rispetto alla TCP standard. Questo risultato si vede facilmente fissando C (banda) sul grafico del throughput / probabilita' di perdita.
|
||
|
|
|
||
|
|
## Utilizzo di Forward Error Correction (FEC)
|
||
|
|
|
||
|
|
Se il packet loss e' alto, il throughput e' basso di conseguenza, ma si potrebbe utilizzare la FEC a livello di pacchetto per risolvere le perdite *in avanti*, e quindi ottenere un throughput migliore.
|
||
|
|
|
||
|
|
*(vedi slides per meccanismo FEC)*
|
||
|
|
|
||
|
|
Questo meccanismo permette di utilizzare una nuova probabilita' di perdita, Pfec, che dovrebbe essere migliore della p originale.
|
||
|
|
|
||
|
|
**NON e' VERO**, perche' sebbene Pfec sembri molto piu' bassa di p, non si considera nuovamente il problema della banda:
|
||
|
|
|
||
|
|
* Avendo nuovamente banda C, utilizzando la FEC **si riduce la banda disponibile**, perche' mandare pacchetti ridondanti (e quindi scartati) e' equivalente a ridurre la banda.
|
||
|
|
|
||
|
|
Questo problema ha il seguente impatto sulle prestazioni:
|
||
|
|
|
||
|
|
```
|
||
|
|
Bfec() = Bwo() = Btcp() // un unico TCP standard, nessuna versione alternativa. Bwo e' il throughput without fec
|
||
|
|
|
||
|
|
N*Bwo(p) = Cwo
|
||
|
|
|
||
|
|
N*Bfec(Pfec) = Cfec
|
||
|
|
|
||
|
|
Come risultato: Pfec > p
|
||
|
|
```
|
||
|
|
Questo vuol dire che **utilizzare FEC riduce le prestazioni**, perche' aumenta la probabilita' di perdita (dato che Cwo e' maggiore di Cfec). Nonostante sembrerebbe logico che la probabilita' di perdita diminuisca con FEC, in realta' aumenta a causa della riduzione di banda.
|
||
|
|
|
||
|
|
### Conclusioni
|
||
|
|
|
||
|
|
Alterare (incrementare) l'aggressivita' di TCP non e' utile al throughput finale.
|
||
|
|
|
||
|
|
FEC non e' utile per migliorare il throughput (sebbene abbia senso nel caso in cui un singolo nodo mandi a un link abbia grosse perdite, in quel caso senza FEC il throughput sarebbe **piu' basso della banda disponibile**). Ma nel caso di nodi multipli, FEC e' controproducente.
|
||
|
|
|
||
|
|
## Colli di bottiglia multipli: flussi infiniti
|
||
|
|
|
||
|
|
Analizzando il caso in cui ci sia **piu' di un router congestionato** con coda RED, posso modellare il comportamento di ognuno dei colli di bottiglia. *(vedi slides)*
|
||
|
|
|
||
|
|
Ottengo infatti un sistema di V equazioni e V incognite, dove V e' il numero di router congestionati. Considero inoltre N flussi TCP.
|
||
|
|
|
||
|
|
* Domanda: probabilita' di perdita di un pacchetto che attraversa due link con probabilita' di perdita differenti.
|
||
|
|
|
||
|
|
Ovvero: con quale probabilita' attraverso con successo entrambi i link? *(probabilita' complementare, o *`1-p`*)*.
|
||
|
|
Il risultato e':
|
||
|
|
|
||
|
|
```
|
||
|
|
s = 1-p
|
||
|
|
stot = s1 * s2
|
||
|
|
|
||
|
|
Il che significa:
|
||
|
|
1 - ptot = (1-p1) * (1-p2)
|
||
|
|
|
||
|
|
ptot = 1 - (1-p1)*(1-p2) = p1 + p2 - p2*p1 (probabilita' condizionata)
|
||
|
|
```
|
||
|
|
*(vedi slides)*
|
||
|
|
|
||
|
|
## Note finali
|
||
|
|
|
||
|
|
* Nella pratica, non tutto e' TCP, ma una notevole parte dei pacchetti e' UDP. UDP **non e'responsive**, quindi si considera semplicemente di sottrarre il loro rate dalla capacita' del collo di bottiglia (in realta', bisogna supporre che il loro sending rate sia esattamente quello che fanno). Nota: oggigiorno quasi tutti i servizi con gran numero di dati, per connessioni persistenti, utilizzano TCP (anche per real time / streaming).
|
||
|
|
|
||
|
|
* Nessun flusso e' veramente infinito.
|
||
|
|
|
||
|
|
* Se si considerano flussi **finiti** di TCP, l'analisi e' piu' complessa perche' divido l'analisi in flussi **pesanti** (lunghi) e flussi **leggeri** (brevi, minore trasmissione dati). Sebbene la square root formula non sia adatta a modellare flussi brevi, ci sono modelli di flussi brevi abbastanza complessi ma accurati. In generale pero' occupano una parte minore del traffico, e sono quindi visti come rumore.
|
||
|
|
|
||
|
|
* Nel calcolo del throughput, si e' ipotizzato che il tempo di trasmissione di una finestra e' **minore di RTT**, ma questo non e' vero per flussi locali, dove gli RTT sono estremamamente piccoli.
|
||
|
|
|
||
|
|
# Analisi in transitorio (dinamica) di flussi TCP
|
||
|
|
|
||
|
|
Si modella il traffico TCP come un fluido, il cui comportamento e' descritto da delle **Ordinary differential equations** (ODE), che si risolvono **numericamente** (utilizzando un risolutore che estrapoli l'andamento nel tempo).
|
||
|
|
|
||
|
|
## Ipotesi
|
||
|
|
|
||
|
|
La rete e' astratta, in una *black box*, con trasmettitori e ricevitori. Introduce:
|
||
|
|
* RTT
|
||
|
|
* perdite distribuite come Poisson(lambda = rate)
|
||
|
|
|
||
|
|
lambda e' quindi un **rate di perdite / secondo**. Dalla rete riceviamo un flusso di eventi di perdita.
|
||
|
|
|
||
|
|
Supponiamo:
|
||
|
|
```
|
||
|
|
W = dimensione media della finestra
|
||
|
|
|
||
|
|
d(W)/dt = 1/RTT - (W/2)*lambda
|
||
|
|
|
||
|
|
notiamo che per t -> infinito
|
||
|
|
|
||
|
|
W = 2/(lambda*RTT)
|
||
|
|
```
|
||
|
|
Si nota che:
|
||
|
|
|
||
|
|
* `1/RTT` e' l'**additive increase**
|
||
|
|
* `(W/2)*lambda` e' il **multiplicative decrease**
|
||
|
|
|
||
|
|
Questo permette di definire il **throughput** come `tput = W/RTT` ottenendo una misurazione estremamente precisa.
|
||
|
|
|
||
|
|
## Modello a sistema di controllo a tempo continuo
|
||
|
|
|
||
|
|
Immaginare un *rubinetto* (sorgente) che genera un flusso fluido (continuo, in funzione di t), che attraversa un collo di bottiglia e poi viene mandato a un ricevitore, che risponde con un ACK alla sorgente **con un feedback delay Tau, pari a 3/4 RTT (circa).** *(vedi slides)*
|
||
|
|
|
||
|
|
Questo sistema e' pilotato da equazioni di variazione nel tempo:
|
||
|
|
|
||
|
|
```
|
||
|
|
rate di ricezione di ACKs = lambdaACK(t) = B(t-Tau) * (1-p(t-Tau))
|
||
|
|
|
||
|
|
rate di ricezione di segnali di congestione = lambdaLoss(t) = B(t-Tau) * (p(t-Tau))
|
||
|
|
```
|
||
|
|
Ovvero il rate di ricezione di acks e' il throughput al tempo t-(feedback delay), moltiplicato per il complementare della probabilita' di perdita al tempo t-(feedback delay).
|
||
|
|
|
||
|
|
|
||
|
|
|