Esercizio - UDP e TCP su tre collegamenti, messaggio da 225 kB

Testo. Si trasmette un messaggio di $M=225$ kbyte dall'host $A$ all'host $B$ attraverso $A\to R_1\to R_2\to B$ con $C_1=24$ Mbit/s, $\tau_1=1$ ms; $C_2=6$ Mbit/s, $\tau_2=4$ ms; $C_3=24$ Mbit/s, $\tau_3=4$ ms.

1. Con UDP a livello di trasporto e pacchetti di dimensione massima $L=1500$ byte, calcolare il tempo totale (si trascurano elaborazione, accodamento e intestazioni di tutti i livelli).
2. Con TCP tra $A$ e $B$: $\text{MSS}=1500$ B, ACK e segmenti di apertura trascurabili, intestazioni trascurabili, $\text{cwnd}$ iniziale $=1500$ B, $\text{ssthresh}=12\,000$ B, $\text{rwnd}=1$ MB. Calcolare il tempo totale (dall'apertura della connessione alla ricezione dell'ultimo ACK), con la trasmissione dei dati che comincia il prima possibile.
3. Ripetere con $\text{rwnd}=13{,}5$ kB.
4. Ripetere (con $\text{rwnd}=13{,}5$ kB) nel caso in cui la seconda finestra di pacchetti sia persa, con timeout pari a $3$ RTT; i pacchetti fuori ordine vengono scartati e non generano ACK.

Teoria usata: Protocollo UDPUDP (User Datagram Protocol) è il protocollo di trasporto senza connessione e inaffidabile: rispetto a IP aggiunge soltanto la comunicazione processo-processo (numeri di porta) e un controllo d'errore facoltativo. L'intestazione è di soli 8 byte (porta sorgente, porta destinazione, lunghezza, checksum). Il checksum copre pseudo-intestazione (indirizzi IP, protocollo 17, lunghezza), intestazione e dati, ed è il complemento a uno della somma a 16 bit; se vale 0 significa "non calcolato", e un risultato 0 si trasmette come 0xFFFF. UDP non ha connessione, numeri di sequenza, controllo di flusso, di errore né di congestione: si sceglie per i messaggi brevi (DNS, DHCP, RIP, SNMP) e per le applicazioni in tempo reale, dove conta non aggiungere ritardo.Protocollo UDP →, TCP - controllo di congestioneLa congestione nasce quando collegamenti veloci alimentano un collegamento lento: le code dei router si riempiono, i pacchetti si perdono o ritardano e, nel caso peggiore, la rete collassa (quasi solo ritrasmissioni). TCP controlla la propria finestra di congestione cwnd con il feedback delle perdite (timeout o tre ACK duplicati): slow start (cwnd raddoppia a ogni RTT) fino alla soglia ssthresh, poi congestion avoidance (+1 MSS per RTT); a ogni perdita ssthresh = W/2. Le varianti si distinguono per come reagiscono ai tre dupACK: Tahoe riparte da cwnd = 1 dopo la ritrasmissione rapida; Reno usa il fast recovery (ssthresh = cwnd/2, cwnd = ssthresh + 3, +1 per ogni altro dupACK); NewReno gestisce gli ACK parziali e recupera più perdite nella stessa finestra; SACK riscontra i blocchi ricevuti e ritrasmette solo quello che manca.TCP - controllo di congestione →, TCP - connessione, affidabilità e controllo di flussoTCP (Transmission Control Protocol) è il protocollo di trasporto con connessione e affidabile: trasforma il servizio senza connessione e inaffidabile di IP in un flusso di byte ordinato, senza errori né duplicati. La connessione si apre con l'handshake a tre vie (SYN, SYN+ACK, ACK) e si chiude con tre o quattro segmenti (FIN). I byte sono numerati: il numero di sequenza è quello del primo byte del segmento, il numero di ACK (cumulativo) è il prossimo byte atteso. Il mittente può inviare $\min(\text{rwnd},\text{cwnd})$ byte non ancora confermati; rwnd (finestra del ricevitore, in un campo di 16 bit) è il controllo di flusso. L'errore si gestisce con checksum, ACK, timeout di ritrasmissione (RTO) e ritrasmissione rapida dopo tre ACK duplicati. Per usare tutto il canale la finestra deve valere almeno il prodotto banda-ritardo (BDP); il throughput massimo è $\text{MSS}\cdot W_{\max}/\text{RTT}$.TCP - connessione, affidabilità e controllo di flusso →, Analisi delle prestazioni di reteLe prestazioni di una rete si misurano con tre famiglie di metriche: traffico (bitrate $R_0$ massimo del collegamento, throughput $S\le R_0$ dati consegnati con successo, goodput al livello applicazione), ritardo (end-to-end $d_{tot}=d_{proc}+d_{queue}+d_{trans}+d_{prop}$ con $d_{trans}=L/R$ e $d_{prop}=d/v$; jitter; RTT) e capacità del tubo (BDP $=R\cdot$ ritardo, bit che riempiono il collegamento), più l'affidabilità (PER, PDR, PLR). Il throughput di un percorso è quello del collegamento collo di bottiglia, $\min$ dei bitrate, ricordando che i collegamenti condivisi dividono la capacità.Analisi delle prestazioni di rete →. Convenzione di calcolo (apertura a $2\tau$, round a distanza di un RTT, flusso continuo): vedi Esercizio - TCP, slow start e messaggio da 18 kB su un collegamento da 8 Mbps.

Dati comuni

$\text{MSS}=1500\cdot8=12\,000$ bit. Tempi di trasmissione di un segmento: $T_1=T_3=12\,000/(24\cdot10^6)=0{,}5$ ms, $T_2=12\,000/(6\cdot10^6)=2$ ms; il collegamento 2 è il collo di bottiglia. Somma delle propagazioni $\tau=1+4+4=9$ ms. Segmenti: $225\,000/1500=150$.

$$\text{RTT}=T_1+T_2+T_3+2\tau=0{,}5+2+0{,}5+18=21\ \text{ms},\qquad\text{apertura}=2\tau=18\ \text{ms}.$$

(1) UDP

UDP non ha apertura, né ACK, né finestra: $A$ spedisce i $150$ pacchetti uno dietro l'altro. Il collegamento 2 è più lento del 1, quindi i pacchetti escono da $R_1$ a distanza $T_2=2$ ms: il tempo è determinato dal collo di bottiglia. Si finisce quando l'ultimo pacchetto arriva a $B$ (nessun ACK da aspettare).

• il primo pacchetto arriva a $R_1$ dopo $T_1+\tau_1=1{,}5$ ms;
• il collegamento 2 lavora senza pause per $150\cdot T_2=300$ ms;
• l'ultimo pacchetto, finita la trasmissione sul collegamento 2, si propaga per $\tau_2$, viene trasmesso dal collegamento 3 in $T_3$ e si propaga per $\tau_3$.

$$T_{UDP}=T_1+\tau_1+K\,T_2+\tau_2+T_3+\tau_3=0{,}5+1+150\cdot2+4+0{,}5+4=\boxed{310\ \text{ms}}.$$

(2) TCP con $\text{rwnd}=1$ MB

$\text{ssthresh}=12\,000/1500=8$ segmenti; $\text{rwnd}=10^6/1500\approx666$ segmenti (non limita).

Soglia del flusso continuo. Il collo di bottiglia ha $T_2=2$ ms, quindi servono $\text{swnd}\cdot T_2\ge\text{RTT}$, cioè $\text{swnd}\ge21/2=10{,}5$ segmenti, che con finestre intere significa $11$.

Slow start $1,2,4,8$ ($1+2+4+8=15$, una somma geometrica1 + 2 + 4 + ... + 2^k = 2^(k+1) − 1, perché ogni termine è il doppio del precedenteSerie notevoli - geometrica, telescopica, armonica →), poi avoidance $9,10$; con $\text{cwnd}=11\ge10{,}5$ il flusso diventa continuo. Nei primi sei round si inviano $34$ segmenti; restano $150-34=116$, tutti in flusso continuo a partire da $144$ ms: uno ogni $T_2=2$ ms. L'ultimo inizia $115\cdot2=230$ ms dopo, a $374$ ms, e il suo ACK torna un RTT dopo: $$T_{TCP}=T_{setup}+6\,\text{RTT}+(150-34-1)T_2+\text{RTT}=18+126+230+21=\boxed{395\ \text{ms}}.$$

(3) TCP con $\text{rwnd}=13{,}5$ kB

$13\,500/1500=9$ segmenti: $\text{swnd}=\min(\text{cwnd},9)$. La finestra non può superare $9<10{,}5$, quindi non si arriva mai al flusso continuo: ogni finestra dura $9T_2=18$ ms $<21$ ms.

Dopo i primi $15$ segmenti restano $135=15\cdot9$ segmenti: esattamente $15$ finestre da $9$, la prima a $102$ ms, l'ultima a $102+14\cdot21=396$ ms; i suoi $9$ segmenti escono in $8T_2=16$ ms e l'ACK dell'ultimo torna un RTT dopo l'inizio dell'ultimo segmento: $$T_{TCP}=T_{setup}+4\,\text{RTT}+15\,\text{RTT}+(9-1)T_2=18+84+315+16=\boxed{433\ \text{ms}}.$$

(4) Perdita della seconda finestra, $\text{rwnd}=13{,}5$ kB

• A $18$ ms parte la prima finestra (1 segmento); l'ACK torna a $39$ ms.
• A $39$ ms parte la seconda finestra, di $2$ segmenti ($\text{cwnd}=2$): vanno persi entrambi.
• Il temporizzatore parte a $39$ ms e scade dopo $3\,\text{RTT}=63$ ms, a $102$ ms.
• Alla scadenza: $\text{ssthresh}=\text{cwnd}/2=2/2=1$ segmento e $\text{cwnd}=1$. Poiché $\text{cwnd}=\text{ssthresh}$, la ripartenza avviene già in congestion avoidance: non c'è slow start, la finestra cresce di $1$ per round: $1,2,3,\dots$
• I segmenti fuori ordine sono scartati senza ACK (nessun ACK duplicato, quindi niente ritrasmissione rapida).

I segmenti inviati fino alla finestra da $8$ inclusa sono $1+(1+2+\dots+8)=1+36=37$ (somma dei primi numeri naturali1 + 2 + ... + n = n(n+1)/2Sommatorie →: $8\cdot9/2=36$). Restano $150-37=113$, inviati con finestre da $9$: $113=12\cdot9+5$, cioè $12$ finestre complete (da $270$ ms) più un'ultima da $5$ segmenti, che comincia a $270+12\cdot21=522$ ms: $$T_{TCP}=T_{setup}+\text{RTT}+T_{out}+8\,\text{RTT}+12\,\text{RTT}+\text{RTT}+(5-1)T_2=18+21+63+168+252+21+8=\boxed{551\ \text{ms}}.$$ Nessuna finestra è continua ($9T_2=18<21$).

(I risultati TCP, $395$, $433$ e $551$ ms, sono stati verificati con Python con un simulatore a eventi di collegamenti in serie; il caso UDP con la formula: $310$ ms.)

Confronto con la soluzione ufficiale

Le slide danno $310$ ms, $395$ ms, $433$ ms, $551$ ms: coincidono. Nel caso (4) la slide scrive, nella scomposizione, "$1+1+2+3+4+5+6+7+8=37$": il primo $1$ è la prima finestra, il secondo $1$ la finestra di ripartenza dopo il timeout. Resta implicito che $\text{rwnd}=13{,}5$ kB si mantiene anche nel caso (4) (si vede dal grafico, $\text{swnd}=\text{rwnd}=9$).

Con la regola abituale $\text{ssthresh}\ge2$ MSS la ripartenza sarebbe in slow start e il risultato diverso; qui il corso, con $\text{ssthresh}=2/2=1$, parte direttamente in avoidance.

Errori comuni

• Dimenticare che UDP non ha apertura né ACK: il tempo è fissato dal collo di bottiglia e termina all'arrivo dell'ultimo pacchetto ($310$ ms invece di $395$ ms).
• Usare la soglia $2\tau$ al posto del RTT per il flusso continuo: con $\text{rwnd}=9$ segmenti $9T_2=18$ ms $<21$ ms, quindi la finestra limita ancora.
• Nel caso (4) riprendere in slow start dopo il timeout: con $\text{ssthresh}=1$ si cresce già linearmente.
• Nel caso (4) non contare nel tempo l'attesa del timeout ($3$ RTT) e il RTT della prima finestra.