10 KiB
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/RTTe' l'additive increase(W/2)*lambdae' 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).