Esercizio - Messaggio da 225 KB con UDP e con TCP Reno, anche con il terzo segmento perso

Testo (tema d'esame, sessione di gennaio, esercizio 1 con soluzioni numeriche). Rete a commutazione di pacchetto a datagramma (store-and-forward), code indipendenti per ogni interfaccia di uscita.

La domanda 1 (arrivo dei due pacchetti di C verso E e G con traffico concorrente di A e B) è già svolta in Esercizio - Pacchetti di C verso E e G con traffico concorrente. Qui le altre tre. Senza altro traffico, si trasferisce un messaggio di $M=225$ KB da A a D (cammino $C_1,C_2,C_7$).

2. Tempo totale con UDP, pacchetti massimi di $L=1500$ B, senza intestazioni né elaborazione.
3. Con TCP Reno, $\text{MSS}=1500$ B, apertura e ACK trascurabili, $\text{cwnd}=1500$ B all'inizio, $\text{ssthresh}=12\,000$ B, $\text{rwnd}=1$ MB: tempo totale dall'apertura all'ultimo ACK, con i dati che partono appena possibile.
4. Con $\text{rwnd}=13{,}5$ KB: stesso calcolo se il terzo segmento è perso e il timeout è $3$ RTT.

Teoria usata: 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 →, 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 →, 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 →.

Grandezze di base

$L=1500$ B $=12\,000$ bit; numero di segmenti $K=225\,000/1500=150$. Tempi di trasmissione sul cammino A→D:

Il collo di bottiglia è $C_2$: $T_b=2$ ms.

• Andata di un segmento: $0{,}5+1+2+4+0{,}5+4=12$ ms.
• Ritorno dell'ACK (trascurabile): $\tau_7+\tau_2+\tau_1=4+4+1=9$ ms.
• $\text{RTT}=12+9=21$ ms; $\text{BDP}=6\ \text{Mbit/s}\cdot21\ \text{ms}=126$ kbit $=10{,}5$ MSS, quindi $\text{swnd}^*=11$ MSS.

Domanda 2: UDP

Nessun ACK né attese; i segmenti escono dal collo di bottiglia uno ogni $T_b=2$ ms. L'ultimo ($150$-esimo) arriva a

$$T_{\text{UDP}}=12+(150-1)\cdot2=\mathbf{310\ \text{ms}}.$$

Domanda 3: TCP Reno, nessuna perdita

Apertura. SYN e SYN+ACK di lunghezza trascurabile: solo propagazione, $\tau_1+\tau_2+\tau_7=9$ ms per ciascuno, $18$ ms in totale; l'ACK finale porta il primo segmento di dati, che parte a $18$ ms.

Crescita della finestra. $\text{ssthresh}=12\,000/1500=8$ MSS. In slow start la finestra raddoppia ogni RTT ($1,2,4,8$); a $8$ inizia la congestion avoidance con $+1$ MSS per RTT ($9,10,11,\dots$).

Segmenti inviati: $1+2+4+8+9+10=34$ (la parte di slow start è una somma geometrica1 + 2 + 4 + ... + 2^k = 2^(k+1) − 1, perché ogni termine è il doppio del precedenteSerie notevoli - geometrica, telescopica, armonica →: $1+2+4+8=15$; poi $9+10=19$). Poiché $\text{swnd}^*=11$, finché la finestra è $\le10$ il mittente aspetta un RTT per finestra; dalla settima finestra $\text{swnd}=11\ge\text{BDP}$: flusso continuo per i $150-34=116$ segmenti restanti.

$$T_{\text{TCP}}=\underbrace{18}_{\text{apertura}}+6\,\text{RTT}+(116-1)\,T_b+\text{RTT}=18+126+230+21=\mathbf{395\ \text{ms}}.$$

Il termine $+\text{RTT}$ finale è il ritorno dell'ACK dell'ultimo segmento (dal suo invio): in totale $395$ ms dall'inizio dell'apertura all'ultimo ACK. Lettura dei termini: $18$ ms l'handshake; $6\,\text{RTT}=126$ ms le prime sei finestre, ciascuna lunga un RTT perché $\text{swnd}\cdot T_b<\text{RTT}$ (con $10$ segmenti: $20<21$ ms); $(116-1)\,T_b=230$ ms il flusso continuo (il primo dei $116$ segmenti parte all'inizio della settima finestra, l'ultimo $115\,T_b$ dopo).

Domanda 4: $\text{rwnd}=13{,}5$ KB, terzo segmento perso

$\text{rwnd}=13\,500/1500=9$ MSS: la finestra di invio è $\min(\text{cwnd},9)$, quindi cresce fino a $9$ e lì si ferma. Poiché $9\,T_b=18$ ms $<\text{RTT}=21$ ms, il mittente è limitato dalla finestra: $9$ segmenti per RTT.

Fino alla perdita.

1. $t=18$ ms: parte il segmento $1$; il suo ACK torna a $18+21=39$ ms, $\text{cwnd}=2$.
2. $t=39$ ms: partono i segmenti $2$ e $3$; il $3$ comincia a essere trasmesso a $39+0{,}5=39{,}5$ ms ed è perso. Il segmento $2$ arriva, il suo ACK ($\text{cwnd}=3$) permette di inviare i segmenti $4,5$, che arrivano fuori ordine e sono scartati: niente ACK nuovi.
3. Il timeout scade $3\,\text{RTT}=63$ ms dopo l'invio del segmento $3$: a $39{,}5+63=102{,}5$ ms.

Dopo il timeout. $\text{ssthresh}=\text{cwnd}/2=3/2\to2$ MSS (almeno $2$ MSS) e $\text{cwnd}=1$. Si ritrasmette dal segmento $3$ (consegnati finora: $1$ e $2$; restano $148$). Finestre: $1,2$ (si raggiunge ssthresh), poi $+1$ per RTT: $3,4,5,6,7,8,9$ (limite di rwnd): in $9$ RTT si inviano $1+2+\dots+9=45$ segmenti (somma dei primi numeri naturali1 + 2 + ... + n = n(n+1)/2Sommatorie →: $9\cdot10/2=45$); ne restano $148-45=103=11\cdot9+4$:

• $11$ finestre da $9$ (ognuna dura un RTT, perché $9\,T_b<\text{RTT}$);
• una finestra finale da $4$ segmenti.

L'ultimo segmento parte $3\,T_b$ dopo il primo della finestra finale, e il suo ACK torna dopo un RTT:

$$T=102{,}5+9\,\text{RTT}+11\,\text{RTT}+3\,T_b+\text{RTT}=102{,}5+189+231+6+21=\mathbf{549{,}5\ \text{ms}}.$$

Lettura dei termini: $102{,}5$ ms è l'istante del timeout (dall'inizio dell'apertura); $9\,\text{RTT}$ le nove finestre $1,\dots,9$ dopo il timeout; $11\,\text{RTT}$ le undici finestre da $9$; $3\,T_b$ la serializzazione dei $4$ segmenti dell'ultima finestra; $\text{RTT}$ il ritorno dell'ultimo ACK.

Confronto con la soluzione ufficiale

Coincide. (La soluzione ufficiale riporta solo i risultati.) Il valore dell'ultima domanda dipende da dove si fa partire il timeout: contandolo dall'inizio dell'invio del segmento perso (come qui) si ottiene $549{,}5$ ms; contandolo dalla fine della sua trasmissione si avrebbero $0{,}5$ ms in più.

Errori comuni

• Mettere nel conto la finestra di $11$ MSS come se fosse ancora in congestion avoidance a $+1$ per RTT: dalla settima finestra il collegamento è saturo e il tempo cresce solo di $T_b$ per segmento.
• Con $\text{rwnd}=9$ MSS dimenticare che la finestra si ferma a $9$ (non a $\text{swnd}^*=11$): il collegamento resta non saturo.
• Contare come consegnato il segmento $3$ o i successivi (scartati perché fuori sequenza).
• Prendere $\text{ssthresh}=\text{ssthresh}_{\text{vecchio}}/2=4$: si usa la finestra effettiva al momento della perdita.

(Verificato con Python: simulatore TCP a finestra intera con ACK cumulativi e timeout: $395$ ms e $549{,}5$ ms; UDP $310$ ms con il simulatore a eventi a coda.)