Fondamenti di Internet e Reti

Fondamenti di Internet e Reti
Strato di trasporto
Francesco Musumeci
Dipartimento di Elettronica, Informazione e Bioingegneria
(DEIB) – Politecnico di Milano

Livello di Trasporto
• Introduzione
• Protocollo UDP
• Trasporto affidabile
– Protocolli di ritrasmissione
– Controllo di flusso a finestra mobile
• Protocollo TCP
F. Musumeci – FIR: Strato di trasporto 2

4e – Transmission Control Protocol (TCP)
RFC 793, RFC 2581, etc.

• Protocollo TCP
– Generalità
– Gestione delle connessioni
– Controllo di flusso e trasporto dei dati
– Meccanismo di ritrasmissione
– Controllo di congestione

TCP
Generalità
• Protocollo connection-oriented (connessioni bidirezionali full
duplex)
• Servizio di trasporto affidabile
• Flusso di dati organizzato in gruppi di byte a loro volta organizzati
in segmenti (≈UI liv. trasporto) di dimensione variabile
• Fornisce
– Multiplazione per mezzo dei socket
– Consegna in sequenza (UI accettate anche fuori sequenza)
– Controllo di flusso e di perdita

Formato del segmento TCP
Source Port Destination Port
16 bit 16 bit
Sequence Number
32 bit
20 Acknowledgment Number
byte 32 bit
C E U A P R S F
HLEN RSV
W C R C S S Y I
Window
4 bit 4 bit R E G K H T N N 16 bit
Checksum Urgent Pointer

16 bit 16 bit
Fino a
Options e Padding
40
lunghezza variabile
byte
Dati
lunghezza variabile

Header Segmento TCP (1) SN/AN=32 bit  numerazione max modulo N=232
• Source port, Destination port (16 bit ciascuno): indirizzi di porta sorgente
e porta destinazione
• Sequence Number (32 bit): numero di sequenza del primo byte nel
payload
• Ack Number (32 bit): numero di sequenza del prossimo byte che si
intende ricevere (numero valido solo se flag ACK valido)
• HLEN (4 bit): contiene la lunghezza complessiva dell’header TCP,
espressa come numero di «parole» da 32 bit Max HLEN = 5 (base) + 10 (opt) = 15
– necessario per via del campo Option a lunghezza variabile
– eventualmente nel campo Option si usa padding
• Window (16 bit): contiene il valore della finestra di ricezione
(comunicatoa dal ricevitore al trasmettitore)
• Checksum (16 bit): calcolato come in UDP
– per il calcolo si include pseudoheader

Header Segmento TCP (2)
• Flags (1 bit ciascuno): 8 campi, ciascuno assume valore 0 o 1
– CWR (congestion window reduced): settato quando si notifica al TCP remoto che si è
ridotta la finestra di congestione (vedremo dopo cos’è)
– ECE (Explicit Congestion Notification Echo): serve a segnalare che si è rilevata una
congesione e quindi serve a chiedere al TCP remoto di rallentare la trasmissione
– URG: vale 1 se vi sono dati urgenti e quindi il TCP deve passare in modalità urgente;
in questo caso urgent pointer dà indicazione sulla posizione dei dati urgenti presenti
nel payload (oltre questi dati TCP può tornare in modalità normale)
– ACK: vale 1 se il pacchetto è un ACK valido; in questo caso l’acknowledge number
contiene un numero valido
– PSH: vale 1 quando il trasmettitore intende usare il comando di PUSH; il ricevitore
può anche ignorare il comando (dipende dalle implementazioni)
– RST: serve a resettare la connessione
– SYN: synchronize; usato durante il setup per
comunicare i numeri di sequenza iniziale
– FIN: usato in fase di chiusura connessione

Funzione Push
• TCP originariamente prevedeva una gestione “speciale” per i

dati che richiedono di essere immediatamente consegnati
all’applicazione ricevente
• Per ottenere un inoltro immediato dei dati da parte del TCP
ricevente all’applicazione ricevente, l’applicazione trasmittente
può inviare un comando di PUSH
– Viene settato il flag di PSH nel segmento
– E’ questo il caso di applicazioni come TELNET
• In verità l’uso del PUSH non è generalmente implementato nella
primitiva SEND( ) delle interfacce TCP offerte dai linguaggi di
programmazione
– Viene automaticamente settato da TCP (sistema operativo)
nell’ultimo segmento che svuota il buffer

Dati URGENT
• La modalità di funzionamento di TCP può essere cambiata in URGENT
• Confusione negli RFC
– RFC 793 (1981): puntatore all’inizio del primo byte dopo i dati urgenti
– RFC 1122 (1989): puntatore all’inizio dell’ultimo byte dei dati urgenti
• Nonostante RFC successivi ribadiscano il contenuto di RFC 1122, molte implementazioni
di TCP seguono ancora il vecchio RFC
– Inoltre, sistemi operativi differenti implementano URGENT in maniera differente
– Consiglio: semantica e implementazione dubbie, meglio non usare.
Source Port Destination Port
16 bit 16 bit
Sequence Number
32 bit
Acknowledgment Number
32 bit
C E U A P R S F
HLEN Reserved
W C R C S S Y I Window
4 bit 4 bit R E G K H T N N 16 bit
Checksum Urgent Pointer

16 bit 16 bit
Options e Padding
lunghezza variabile
dati

Header Segmento TCP (3)
• Options and Padding (dimensione variabile): riempimento e campi opzionali

– Options: usati, ad esempio, durante il setup per comunicare il MSS (il
valore di default è 536 byte)
– Padding: riempimento fino a multipli di 32 bit con uso di «no-operation» e
«end-of-option» (v. slide successiva)

Opzioni
• Le opzioni sono aggiunte all’header TCP

• Diversi tipi di opzioni
– Opzioni di 1 byte: servono come riempimento per avere un
header multiplo di 32 bit
o no operation: 00000001 (serve come riempimento per avere un header
multiplo di 32 bit)
o end of option: 00000000 (byte di riempimento finale – come “no
operation”, ma usato alla fine dell’header TCP)
– Opzioni lunghe:
o Per ciascuna di queste opzioni esiste un campo "length" che ne indica
la dimensione (in byte)
o Maximum segment size (MSS) – 32 bit
o Fattore di scala della finestra – 24 bit
o …
o http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml

Opzioni
Maximum Segment Size (MSS) – RFC 793
• Definisce la dimensione massima del segmento (solo i
DATI, non include l’header) che verrà usata durante la
connessione TCP
– Non si modifica durante la connessione
• La dimensione è decisa da ciascuna delle due parti durante
la fase di setup (ciascuna delle parti decide il MSS dei
segmenti che potrà ricevere)
• Il valore di default è 536 byte, il valore massimo teorico è
65535 (=216-1) byte
Kind Length MSS

(00000010) (00000100) 16 bit
32 bit

TCP
Encapsulation e Frammentazione
• Il messaggio dell’applicazione può essere frammentato da TCP in più
segmenti
• Da ciascun segmento si deve “produrre” esattamente un datagramma
IP (anche se IP può operare frammentazione all’occorrenza, come
accade con UDP)
Liv. Applicativo
Liv. di Trasporto Header TCP TCP data Header TCP TCP data
Liv. di Rete Header IP IP data Header IP IP data

TCP
Encapsulation e Frammentazione
• MSS deve essere scelto in modo da far corrispondere un
segmento ad un datagramma, considerando la max dimensione
del datagramma (imposta dal valore della MTU di livello 2)
– Interferenza tra layer diversi, che non dovrebbe esserci [RFC
879]
MSS = MTU – size{IP_heder} – size {TCP_header}
– Gli header hanno dimensione variabile  si fanno delle stime

o Stima larga: size{IP_header} = size{TCP_header} = 20 byte
o Stima conservativa: size{IP_header} = size{TCP_header} = 60 byte
MTU = Maximum
Transmission Unit = MSS
dimensione max del
payload della PDU di
livello 2
es. trama ethernet:
MTU = 1500 byte
MTU

Opzioni
Fattore di scala della finestra – RFC 7323
• Definisce il fattore di scala (fs) della finestra di ricezione
• Settato in fase di apertura connessione, poi non cambia
• L’opzione fa sì che il valore del campo Window (W) venga
scalato, per ottenere come segue il valore reale della
finestra di ricezione (Rwnd):
Rwnd = W ⋅ 2 fs
max{ fs} = 14 ⇒ max{Rwnd } = 216 ⋅ 214 = 230 < max{SN } = 232
(anche se il campo è a 8 bit)
Kind Length Fattore di scala

(00000011) (00000011) 8 bit
24 bit

• Protocollo TCP
– Generalità

Setup delle connessioni
• Prima di iniziare la connessione (call setup), le applicazioni dal lato

client e dal lato server devono comunicare con il software TCP locale
1. Il server fa una Passive Open, con cui comunica al TCP locale che è
pronto per accettare nuove connessioni
2. Il client che desidera comunicare fa una Active Open, che comunica al
TCP locale che l’applicativo intende effettuare una connessione verso un
dato socket remoto
client server
application application
2. Active Open 1. Passive Open
TCP TCP

3. Il client TCP estrae a caso un numero di sequenza iniziale, ISN, (ad

es: 67803) e manda un segmento TCP di tipo SYNchronize (flag
SYN=1) contenente questo numero di sequenza. Indica qui anche altri
parametri della connessione (MSS, fs)
– L’estrazione casuale del numero iniziale evita problemi nel caso in

cui il setup non vada a buon fine a causa della perdita di pacchetti e
un nuovo setup viene iniziato subito dopo
client server
3. SYN, SN=67803
TCP TCP

4. Quando riceve il SYN, il TCP server estrae a caso un numero di

sequenza iniziale (es., 5608) e manda un segmento SYN/ACK (flag
SYN=1, flag ACK=1) contenente anche un AN (es., 67804), per
riscontrare il numero di sequenza iniziale precedentemente inviato dal
TCP client.
– AN (=67804) sta riscontrando il SN (=67803) che aveva inviato il client
– NUOVO significato dell’ack: “ti dico qual è il PROSSIMO byte atteso”
client server
4. SYN / ACK,
SN=5608, AN=67804
TCP TCP

5. Il TCP client riceve il messaggio SYN/ACK del server, e

invia un ACK (es., 5609). Nel payload inserisce i primi dati
della connessione con numero di sequenza del primo byte
(es., 67804). Inserisce anche la dimensione della finestra a
imporre al server (campo Window).
client server
5. ACK,
TCP SN=67804, AN=5609 TCP

6. Il TCP client notifica all’applicazione che la connessione

è aperta
7. Quando il TCP server riceve l’ACK del TCP client,
notifica al suo applicativo che la connessione è aperta
client server
6. Connection Open 7. Connection Open
TCP TCP

Ricapitolando…
client server
2. Active Open 6. Connection Open 1. Passive Open 7. Connection Open
TCP TCP
3. SYN, SN=67803
i messaggi di
setup per 4. SYN / ACK,
convenzione SN=5608, AN=67804 Three-way
“consumano” un
5. ACK, handshaking
byte (v. AN al
passo 4 ed AN- SN=67804, AN=5609
SN al passo 5.)

In passato l’Initial Sequence Number era
Gestione della connessione generato sulla base di un clock interno. La
Initial Sequence Number procedura non si usa più per evitare la
predicibilità dei SN
• Numeri di sequenza in transito devono essere univoci

Problema # 1. I numeri di byte di una connessione non
devono sovrapporsi con i numeri di byte di altre
connessioni tra le stesse socket
– Ambiguità se un segmento di una connessione precedente
viene consegnato in ritardo insieme ai segmenti della
connessione corrente
• Per evitare ambiguità, la scelta dell’Initial Sequence
Number (ISN) è pseudocasuale
– In ogni host contatore conta ciclicamente modulo 232
(tra 0 e 232 – 1 ≈ 4⋅109) con passi di 4 µs (ciclo completo ogni
≈ 4.77 h)
– L’host assegna a ISN il valore corrente del contatore

Gestione della connessione
Maximum Segment Lifetime
• Numeri di sequenza in transito devono essere univoci
Problema # 2. Ogni byte di una stessa connessione in rete deve
essere unico
– Ambiguità se in rete sono presenti 232 byte di una stessa
connessione
• Si applica un vincolo sul Maximum Segment Lifetime (MSL) per evitare
ambiguità
– Capacità della connessione: B (bit/s)
– MSL deve essere scelto minore dell’intervallo minimo tra due numeri
di byte uguali
232 ⋅ 8
MSL <
B
– Esempio:
o MSL = 2 min (es. con B = 10 Mbit/s  circa 1 h tra due SN uguali)
– Per connessioni veloci (es. B=1Gbit/s) si usa PAWS (protect against
wrapped sequence), ovvero si inserisce un timestamp nel segmento
TCP (indica quando il segmento è stato trasmesso)

Tear down (chiusura) delle connessioni
1. Il TCP che chiude la connessione invia un segmento
TCP di tipo FIN (flag FIN=1) con gli ultimi dati
2. Il TCP dall’altra parte invia un ACK per confermare la
chiusura
client server
1. FIN, SN=127504
TCP TCP
2. ACK, AN=127505

N.B. La connessione può anche rimanere aperta nell’altra
direzione nel caso il TCP dall’altra parte voglia continuare
ad inviare dati
client server
SN=8763
TCP TCP
SN=9001

3. Appena completa la trasmissione, il TCP chiude la
connessione anche nell’altra direzione, inviando un
messaggio di FIN (flag FIN=1)
4. Il TCP che aveva già chiuso la connessione in
direzione opposta invia un ACK finale per confermare
client server
3. FIN, SN=9024
TCP TCP
4. ACK, AN=9025

Ricapitolando…
client
client server
server
application
application
TCP
TCP TCP
TCP
1. FIN, SN=120893
Anche per la 2. ACK,

chiusura si può SN=8763, AN=120894
usare 3-way
handshake
usando solo i
passi 1, 2 e 4
3. FIN, SN=9025
4. ACK, AN=9026

Collisione di richieste
• Se due richieste di instaurazione di connessione hanno

stessi socket sorgente e destinazione (in ordine inverso) si
instaura una sola connessione

Reset della connessione
• La connessione può anche essere chiusa senza scambio

di messaggi nei due versi
• E’ possibile infatti settare il flag di RESET nel segmento e
interrompere la connessione in entrambe le direzioni
• Il TCP che riceve un RESET chiude la connessione
interrompendo ogni invio di dati

• Protocollo TCP
– Generalità

Implementazione del controllo di flusso
• Il TCP ricevente controlla il flusso di quello trasmittente
• Lato ricevitore:
– Buffer di ricezione: accumula i byte ricevuti e non ancora assorbiti
dall’applicazione
• Lato trasmettitore:
– Buffer di trasmissione: accumula i byte in attesa di essere trasmessi
(ovvero, in attesa che il ricevitore dia il “consenso” a trasmetterli)

Finestre di trasmissione e ricezione e campi TCP
Finestra di trasmissione Buffer di ricostruzione
Finestra di ricezione
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
A B
• Si evidenzia solo la connessione AB (analogo per BA)

• La finestra di ricezione di B, Rwnd, (in assenza di errori e a meno del ritardo di
trasferimento) si sposta “in sincronia” con la finestra di trasmissione
– B determina Rwnd in base alle dimensioni del proprio buffer di ricostruzione
– A adatta l’ampiezza della finestra di trasmissione in base al valore Rwnd ricevuto da B

Finestra di ricezione e campi TCP
Finestra di Ultimo byte che
Byte non ancora letto Dimensione fissa del buffer di viene
trasmissione dall’applicazione ricostruzione al ricevitore memorizzato
anche se arriva
fuori sequenza
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ultimo byte letto
dall’applicazione
A Ultimo byte w
Primo byte che
viene scartato
ricevuto e
riscontrato B se arriva fuori
sequenza
AN=y Rwnd=w Ultimo segmento

trasmesso da B

Finestra di trasmissione e campi TCP
Finestra di trasmissione
Ultimo byte che si può mandare
Primo byte non Ultimo byte inviato in attesa di un nuovo ACK
riscontrato y+w–1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ultimo byte x
riscontrato
A SN=x-L+1
B
L = numero di byte trasmessi con
AN=y Rwnd=w l’ultimo segmento TCP
(es. in questo caso L=5 se è stato
inviato un solo segmento con i
byte da 4 a 8)
I segmenti che contengono i byte da y a x vengono copiati in un altro buffer presente al

trasmettitore A (buffer delle ritrasmissioni). Quando un segmento viene riscontrato, i
relativi byte vengono eliminati dal buffer delle ritrasmissioni. Se scade il timeout di
ritrasmissione, si ritrasmette il primo segmento presente nel buffer delle ritrasmissioni.

Controllo di flusso: lato ricevitore
Ultimo byte assorbito dall’ applicazione ricevente
• Receive Window (Rwnd): spazio
del buffer in ricezione disponibile 1100
100 200 300
per ricevere nuovi dati 1101 1400

Receive Window
• Il buffer di ricezione può riempirsi, 300
per esempio, a causa di
1100
congestione nel sistema operativo 1101 1200 1400
Receive Window
del ricevitore 200
• Rwnd si estende dall’ultimo byte
ricevuto (e riscontrato) dal TCP 1100 1101 1300 1400
Receive
fino alla fine del buffer Window
100
• La dimensione di Rwnd è
1101 1300
segnalata in ogni segmento assorbimento
inviato dal ricevitore al dell’applicazione
trasmettitore 1300 1301 1600

Receive Window
Slittamento in avanti di 200 byte 300

Controllo di flusso: lato trasmettitore
Ultimo byte riscontrato
100 200 300
• Il trasmettitore mantiene un buffer di 1100
trasmissione che tiene traccia di 1101
Free SWindow
1400
– dati che sono stati trasmessi ma 300

non ancora riscontrati Send Window
– dimensione della finestra di 1100 1101 1200 1400
ricezione del partner Free SWindow
200
• Se Send Window (Swnd) = Rwnd unacked
ACK=1201, Window = 200 Slittamento di 100

 il buffer di trasmissione si estende + accorciamento
dal primo byte non riscontrato
1200 1300 1400
all’estremo a destra della finestra di Free
ricezione del ricevitore SWindow
100
unacked
• La parte inutilizzata del buffer, ACK=1301, Window = 300
Send Window
rappresenta i byte che possono
Send Window
essere trasmessi senza attendere 1300 1301 1600
ulteriori riscontri Free SWindow
Slittamento di 100 + allungamento
300

Controllo di flusso: lato trasmettitore
Ultimo byte riscontrato
100 200 300
• Il trasmettitore mantiene un buffer di 1100
trasmissione che tiene traccia di 1101
Free SWindow
1400
– dati che sono stati trasmessi ma 300

non ancora riscontrati Send Window
– dimensione della finestra di 1100 1101 1200 1400
ricezione del partner Free SWindow
200
• Se Send Window (Swnd) = Rwnd * unacked
ACK=1201, Window = 200 Slittamento di 100

 il buffer di trasmissione si estende + accorciamento
dal primo byte non riscontrato
1200 1300 1400
all’estremo a destra della finestra di Free
ricezione del ricevitore SWindow
100
unacked
• La parte inutilizzata del buffer, ACK=1301, Window = 300
Send Window
* Può anche verificarsi il caso in cui Swnd ≠ Rwnd
rappresenta
(in particolare i byte che possono
Swnd <Rwnd).
Send Window
Ciòessere trasmessi
avviene quando si ha un senza attendere
vincolo più stringente
1300 1301
perulteriori 1600
riscontridi congestione (v. dopo)
effetto del controllo
Free SWindow
Slittamento di 100 + allungamento
300

Problemi con la finestra
• Silly window syndrome - lato ricevitore:

– L’app ricevente svuota lentamente il buffer di ricezione
– Comunica al trasmettitore una finestra molto piccola
– Il trasmettitore invia segmenti corti con molto overhead
• Soluzione (algoritmo di Clark)

– Il ricevitore “mente” al trasmettitore indicando una finestra
nulla sino a che il buffer di ricezione non si è svuotato per
metà o per una porzione almeno pari al MSS
If Finestra.free <= max(1/2 Receive_Buffer_Size, Maximum_Segment_Size)

 Rwnd = 0
Else
 Rwnd = Finestra.free

Problemi con la finestra
• Silly window syndrome - lato trasmettitore:

– L’app trasmittente genera dati lentamente
– TCP invia segmenti molto piccoli (quindi con molto overhead)
man mano che vengono prodotti
• Soluzione (algoritmo di Nagle)

– Il TCP sorgente invia la prima porzione di dati anche se corta
– Gli altri segmenti vengono generati e inviati solo se si verifica
una delle due seguenti condizioni
o Il buffer d’uscita contiene dati sufficienti a riempire un MSS
oppure
o quando si riceve un acknowledgement per un segmento
precedente.

• Protocollo TCP
– Generalità

Meccanismo di ritrasmissione
• TCP non usa NACK

– le ritrasmissioni avvengono solo per scadenza di timeout
• Poiché i segmenti TCP attraversano una RETE essi subiscono ritardi
variabili
– RTT per invio segmento e ricezione riscontro non è fisso
• Uno dei problemi è stabilire il valore ottimo del timeout
– Timeout troppo breve: il trasmettitore riempirà il canale di ritrasmissioni di
segmenti
– Timeout troppo lungo: impedisce il recupero veloce di reali errori
• Il valore ottimale dipende fortemente dal ritardo in rete (rete locale o
collegamento satellitare?)
• Il TCP misura continuamente l’RTT per effettuare delle stime utili a
impostare un valore “appropriato” di timeout

Stima del RTT in TCP
• Utilizzo di un filtro a media mobile

• RTT viene misurato per ogni segmento al ricevimento del rispettivo
riscontro
– La misura dell’RTT dell’ultimo segmento è detta RTTlast
– Non si valuta RTT per i segmenti che vengono ritrasmessi
• Stima corrente (Smoothed RTT) data da
RTTav = (1 − α )RTTav + α ⋅ RTTlast 0 <α ≤1
• Stima della variabilità di RTT

RTTdev = (1 − β )RTTdev + β ⋅ RTTlast − RTTav 0 < β ≤1
• Valori tipici α = 0.125, β = 0.25

• Valori iniziali (ad esempio): RTTav = 0; RTTdev = 1.5 s
– Al ricevimento del primo ACK: RTTav = RTTlast; RTTdev = RTTlast/2

Stima del RTT in TCP
Esempio
• RTT reale vs RTT_av
– Ping Milano-UCDavis (California-USA)

Impostazione del Timeout
Algoritmo di Karn
• Normalmente il timeout viene determinato sulla base del RTT stimato
(Jacobson)
To = RTTav + n ⋅ RTTdev (To iniziale = 3 s
Valori di n tipici: 2, 3, 4 con n = 2)
• Problema: Con rete improvvisamente congestionata quasi tutti i

segmenti vengono ritrasmessi  il time-out non verrebbe più
aggiornato, visto che RTTlast non si valuta sui pacchetti ritrasmessi!
– Circolo vizioso: mancati aggiornamenti del timeout, aumentano le
ritrasmissioni
• Soluzione: Algoritmo di Karn (timer backoff): ad ogni ritrasmissione

dovuta a scadenza di timeout, il timeout viene aumentato
– Timeout aumentato con tecnica moltiplicativa (tipicamente x 2)
– Aumento avviene fino a una soglia (per esempio To ≤ 60 s)
– Al primo segmento ricevuto senza scadenza del time-out si torna
alla procedura standard

TCP
Fast retransmit
• Ritrasmissione “standard”
– Se un segmento di una sequenza va perso, il ricevitore B può
mantenere nel buffer i segmenti ricevuti fuori sequenza, ma in ogni
caso ad ogni nuovo segmento B invia immediatamente l’ACK di
quello mancante (ACK ripetuti)
– Il nuovo ACK cumulativo verrà trasmesso da B solo dopo aver
ricevuto il segmento mancante
– A ritrasmette il segmento perso solo dopo la scadenza del timeout
 sarebbe più efficiente che A lo ritrasmettesse più velocemente
• Upgrade del meccanismo di ritrasmissione: Fast retransmit (RFC
2001)
– Alla ricezione di 3 ACK consecutivi “ripetuti” (dopo il primo non
ripetuto), si procede a ritrasmissione anche prima che scatti il time-
out (equivale a un NACK implicito)
– Fast retransmit richiede che si disabiliti il “Delayed ACK”

Fast retransmit
Esempio
1 + 3 ripetuti = NACK
Si noti che non esiste NACK esplicito
Senza Fast retransmit Con Fast retransmit

Persistenza
• Se il destinatario fissa a zero la finestra di ricezione la sorgente TCP

interrompe la trasmissione
• La trasmissione riprende quando il destinatario invia un ACK con
una dimensione della finestra diversa da zero
• Cosa accadrebbe se questo ACK andasse perso?
– La connessione rimarrebbe bloccata!
• Per evitare questa situazione si usa un timer di persistenza che
viene attivato quando arriva un segmento con valore del campo
window nullo
– valore di timer di persistenza coincide con il time-out di ritrasmissione
• Quando il timer di persistenza scade viene inviato un piccolo
segmento di sonda (probe)
• Se viene ricevuto un ACK per questo segmento si esce dallo stato
critico altrimenti si riavvia il timer di persistenza e al nuovo scadere
del timeout si invia un altro probe e così via…

• Protocollo TCP
– Generalità

Controllo di congestione
• Il controllo di flusso
– dipende solo dalla capacità del ricevitore
– non è sufficiente ad evitare la congestione nella rete
• Nella rete INTERNET attuale non ci sono meccanismi sofisticati
di controllo di congestione a livello di rete (come ad esempio
meccanismi di controllo del traffico in ingresso)
• Il controllo di congestione è delegato al TCP!!!
– Essendo il TCP implementato solo negli host, il controllo di
congestione è di tipo end-to-end

• Un evento di congestione si verifica quando il rate di

trasmissione porta in congestione un link sul percorso in rete
verso la destinazione
• Un link è congestionato quando la somma dei rate di
trasmissione dei flussi che lo attraversano è maggiore della sua
capacità
∑Ri
i >C

• Il modo più naturale per controllare il ritmo di immissione in rete

dei dati per il TCP è quello di regolare la finestra di
trasmissione
• Il trasmettitore mantiene una Congestion Window (Cwnd) che
varia in base agli eventi che osserva (ricezione ACK, timeout)
• In ogni istante la finestra del trasmettitore Swnd (=Ws) è
dimensionata al minimo tra Rwnd e Cwnd
– In ogni istante Swnd = min (Rwnd, Cwnd)
TCP
Come regolare la Cwnd?

Come sapere della congestione?

• L’idea base del controllo di congestione del TCP è quello di

interpretare la perdita di un segmento, segnalata dallo
scadere di un timeout di ritrasmissione, come un evento di
congestione
• La reazione ad un evento di congestione è quella di ridurre
l’ampiezza della finestra di congestione (Cwnd)
TCP

Slow start & Congestion avoidance
• Il valore della finestra Cwnd viene aggiornato dal trasmettitore

TCP in base ad un algoritmo
• Il modo in cui avviene l’aggiornamento dipende dalla fase (o
stato) in cui si trova il trasmettitore
• Esistono due fasi fondamentali:
– Slow start
– Congestion avoidance
• Per distinguere tra le due fasi si usa una soglia, Ssthresh, che
è gestita dall’entità TCP al trasmettitore:
 se Cwnd < Ssthresh si è in Slow start
 se Cwnd ≥ Ssthresh si è in Congestion avoidance

Aggiornamento della Finestra di Congestione
• Vediamo ora come viene aggiornato il valore della finestra Cwnd

dal trasmettitore TCP in queste due fasi
– Slow start

Slow start
• All’inizio di una connessione, il trasmettitore pone la Cwnd a 1

segmento (MSS) e la Ssthresh ad un valore di default molto
elevato
• Essendo Cwnd < Ssthresh si inizia in Slow start
• Regola di incremento della Cwnd in Slow Start:

– la Cwnd viene incrementata di 1 MSS per ogni ACK ricevuto
• Si invia un segmento e dopo un intervallo = RTT si riceverà

l’ACK; quindi si pone Cwnd a 2 e si inviano 2 segmenti, si
ricevono 2 ACK, si pone Cwnd a 4 e si inviano 4 segmenti, ...
W 2W 4W 8W
RTT RTT RTT RTT

Slow start
• All’inizio di una connessione, il trasmettitore pone la Cwnd a 1

segmento (MSS) e la Ssthresh ad un valore di default molto
elevato
• Essendo Cwnd < Ssthresh si inizia in Slow start
• Regola di incremento della Cwnd in Slow Start:

– la Cwnd viene incrementata di 1 MSS per ogni ACK ricevuto
N.B. In realtà, la finestra di congestione è
espressa in numero di byte (così come la
• Si invia un segmento e dopo un intervallo
finestra di = RTT si
ricezione riceverà
vista nel controllo di
l’ACK; quindi si pone Cwnd a 2 e siflusso).
inviano 2 segmenti,
Per semplicità, si
facciamo
ricevono 2 ACK, si pone Cwnd a 4 riferimento
e si inviano 4 di
all’unità segmenti,
misura MSS....
W 2W 4W 8W
RTT RTT RTT RTT

Slow start
• Al contrario di quanto il nome faccia credere, l’incremento della

finestra avviene in modo esponenziale (raddoppia ogni RTT)
CWND = 1 2 34 56 78
Hp: riscontri
di durata
trascurabile

Slow start
• L’incremento del numero di segmenti inviato può andare avanti

fintantoché non si verifica almeno uno dei seguenti eventi
– Cwnd ≥ Ssthresh (entro in Congestion Avoidance)
– si verifica il primo evento di congestione (scadenza To)
– Cwnd ≥ Rwnd (in questo caso Cwnd continua ad aumentare,
ma la finestra di trasmissione è vincolata da Rwnd)
• Insieme alla finestra aumenta il rate di trasmissione, che può
essere stimato come: Cwnd
Cwnd RTT
R= [byte/s]
RTT
• Ad un certo punto, la trasmissione può
diventare continua

Aggiornamento della Finestra di Congestione
• Vediamo ora come viene aggiornato il valore della finestra Cwnd

dal trasmettitore TCP in queste due fasi
– Slow start

Congestion avoidance
• Slow start continua fino a che Cwnd non eguaglia Ssthresh e poi
parte la fase di Congestion avoidance
• Regola di incremento della Cwnd in Congestion Avoidance:
– la Cwnd viene incrementata di 1/Cwnd ad ogni ACK ricevuto
• Se la Cwnd consente di trasmettere W segmenti, la ricezione degli

ACK relativi a tutti i W segmenti porta la Cwnd ad aumentare di 1
segmento
– In altre parole, in Congestion avoidance si attua un incremento lineare
della finestra di congestione
– ATTENZIONE: si tratta di un’approssimazione, perché nella realtà
l’aumento avviene per ciascun singolo ACK
W W+1 W+2 W+3 W+4
RTT RTT RTT RTT

Congestion avoidance
• Dopo aver raggiunto Ssthresh la finestra continua ad aumentare

ma molto più lentamente
4.71+1/4.71=4.9 ≈ 5
4.49+1/(4.49)=4.71 6 7
……… ……..
17/4+1/(17/4)=4.49
CWND = 4 5+1/5 6+1/6
4+1/4=17/4=4.25
Hp: riscontri
di durata
trascurabile

Evento di congestione
• Se avviene congestione, ovvero se scade un timeout

(riscontri ritardati, persi o mai trasmessi), sia in Slow start
che in Congestion avoidance
– la finestra non cresce più nel momento in cui smetto di
ricevere i riscontri
– agisco sulla Ssthresh e sulla Cwnd come mostrato nelle
slide seguenti

• Scade un timeout di ritrasmissione
– il TCP reagisce ponendo Ssthresh uguale alla metà dei “byte in volo”
(byte trasmessi ma non riscontrati); più precisamente
 FlightSize 
Ssthresh = max 2 MSS , 
 2 
– Cwnd viene posta pari a 1 (TCP Tahoe)
• Si noti che di solito (ma non necessariamente) i “byte in volo”

sono in numero pari a Swnd=min(Rwnd,Cwnd)
• FlightSize resta determinata da x-y+1 (vedi slide seguente)
• [RFC 5681] La Ssthresh NON viene modificata se la scadenza
del timeout è relativa a un segmento già inviato almeno una volta
(ovvero se è relativa a una ritrasmissione).
– Regola introdotta di recente NB: Flightsize<=Swnd=min(Cwnd, Rwnd).
Il caso Flightsize=Swnd è il più comune/intuitivo.
Il caso Flightsize<Swnd si verifica, per esempio,
quando il trasmettitore è più lento del ricevitore
FlightSize
Finestra di
trasmissione
y+w–1 Finestra di ricezione
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
x
A SN=x-L+1
B
AN=y Rwnd=w
FlightSize=x-y+1

• Come risultato:
– Cwnd è minore di Ssthresh  si entra nella fase di Slow Start
o Il trasmettitore invia un segmento e la sua Cwnd è incrementata di 1 ad
ogni ACK
– Il segmento che viene inviato per primo è quello per cui era scaduto
il timeout (le ritrasmissioni hanno precedenza sulle nuove
trasmissioni)
• In seguito:
– TCP base (Tahoe): il trasmettitore ritrasmette tutti i segmenti
successivi già trasmessi (il ricevitore li ha eliminati  scadranno i
timeout loro associati). Analogo a GBN
– TCP avanzato (Reno): il trasmettitore invia nuovi segmenti (il
ricevitore può risequenziare quelli già ricevuti  invia ACK
cumulativo con “delayed ACK”). Analogo a SR
• Il valore a cui è posta la Ssthresh corrisponde ad una stima
(conservativa) della finestra ottimale che eviterebbe futuri eventi
di congestione

Esempio di funzionamento
Slow Start Waiting Slow Start Congestion Waiting Slow Congestion
for Avoidance for Start Avoidance
timeout timeout
SSTHRESH
Segment Timeout
loss
Segment
loss Timeout
CWND
Time

Esempio
• Ipotesi
– ISNA = 1136 CWND [MSS]
– MSS = 536
– Cwnd = 1 MSS Slow Start
1
– RTT = 4.5 Ts
(Ts: tempo di
trasmissione
di un segmento) 2
– Ssthresh = 2000
= 3.7 MSS
(Cwnd>Ssthr)
 Cong Avoid

Esempio (cont.)
• Ipotesi
– Ssthresh = 2000 CWND [MSS]
= 3.7 MSS Cong. Avoid.

– RTT = 6.5 Ts
(Ts: tempo di 4+4⋅1/4=5
trasmissione
di un segmento)
5+5⋅1/5=6
N.B. Per semplicità, nell’esempio CWND viene 6+6⋅1/6=7

calcolata solo al termine della ricezione di tutti gli
ACK di un burst

Versioni di TCP
• Tahoe
– Versione base: non implementa il fast retransmit (3ack) e non
accetta fuori sequenza
• Reno: fast retransmit/fast recovery + fuori-sequenza accettati +
dopo 3 ACK ripetuti:
 FlightSize  Cwnd = Sshthresh
Sshthresh = max 2 MSS ,  (Invece di Cwnd = 1)
 2  Così si salta la fase di Slow start
• Vegas: tenta di evitare la congestione piuttosto che reagire ad

essa
• Westwood
• TIBET Versioni TCP ottimizzate per scenari wireless
• ........

Lingua

Benvenuto in Scribd!

Fondamenti di Internet e Reti

Caricato da

Informazioni sul documento

Descrizione:

Data di caricamento

Titolo originale

Copyright

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Descrizione:

Copyright:

Fondamenti di Internet e Reti

Titolo originale:

Caricato da

Descrizione:

Copyright:

Titoli correlati

Fondamenti di Internet e Reti

Fondamenti di Internet e Reti

F. Musumeci – FIR: Strato di trasporto 2

RFC 793, RFC 2581, etc.

Fondamenti di Internet e Reti

F. Musumeci – FIR: Strato di trasporto 4

F. Musumeci – FIR: Strato di trasporto 5

Checksum Urgent Pointer

F. Musumeci – FIR: Strato di trasporto 6

F. Musumeci – FIR: Strato di trasporto 7

F. Musumeci – FIR: Strato di trasporto 8

• TCP originariamente prevedeva una gestione “speciale” per i

F. Musumeci – FIR: Strato di trasporto 9

Checksum Urgent Pointer

F. Musumeci – FIR: Strato di trasporto 10

• Options and Padding (dimensione variabile): riempimento e campi opzionali

F. Musumeci – FIR: Strato di trasporto 11

• Le opzioni sono aggiunte all’header TCP

F. Musumeci – FIR: Strato di trasporto 12

Kind Length MSS

F. Musumeci – FIR: Strato di trasporto 13

Liv. di Rete Header IP IP data Header IP IP data

F. Musumeci – FIR: Strato di trasporto 14

– Gli header hanno dimensione variabile  si fanno delle stime

F. Musumeci – FIR: Strato di trasporto 15

Kind Length Fattore di scala

F. Musumeci – FIR: Strato di trasporto 16

F. Musumeci – FIR: Strato di trasporto 17

• Prima di iniziare la connessione (call setup), le applicazioni dal lato

F. Musumeci – FIR: Strato di trasporto 18

3. Il client TCP estrae a caso un numero di sequenza iniziale, ISN, (ad

– L’estrazione casuale del numero iniziale evita problemi nel caso in

F. Musumeci – FIR: Strato di trasporto 19

4. Quando riceve il SYN, il TCP server estrae a caso un numero di

F. Musumeci – FIR: Strato di trasporto 20

5. Il TCP client riceve il messaggio SYN/ACK del server, e

F. Musumeci – FIR: Strato di trasporto 21

6. Il TCP client notifica all’applicazione che la connessione

F. Musumeci – FIR: Strato di trasporto 22

F. Musumeci – FIR: Strato di trasporto 23

• Numeri di sequenza in transito devono essere univoci

F. Musumeci – FIR: Strato di trasporto 24

F. Musumeci – FIR: Strato di trasporto 25

F. Musumeci – FIR: Strato di trasporto 26

F. Musumeci – FIR: Strato di trasporto 27

F. Musumeci – FIR: Strato di trasporto 28

Anche per la 2. ACK,

F. Musumeci – FIR: Strato di trasporto 29

• Se due richieste di instaurazione di connessione hanno

F. Musumeci – FIR: Strato di trasporto 30

• La connessione può anche essere chiusa senza scambio

F. Musumeci – FIR: Strato di trasporto 31

F. Musumeci – FIR: Strato di trasporto 32

F. Musumeci – FIR: Strato di trasporto 33

• Si evidenzia solo la connessione AB (analogo per BA)

F. Musumeci – FIR: Strato di trasporto 34

AN=y Rwnd=w Ultimo segmento

F. Musumeci – FIR: Strato di trasporto 35