Capitolo 3

Livello di trasporto

Nota per l’utilizzo:

Abbiamo preparato queste slide con l’intenzione di renderle disponibili a tutti
(professori, studenti, lettori). Sono in formato PowerPoint in modo che voi
possiate aggiungere e cancellare slide (compresa questa) o modificarne il
contenuto in base alle vostre esigenze. Computer
Come potete facilmente immaginare, da parte nostra abbiamo fatto un sacco
di lavoro. In cambio, vi chiediamo solo di rispettare le seguenti condizioni:
 se utilizzate queste slide (ad esempio, in aula) in una forma
Networking: A Top
sostanzialmente inalterata, fate riferimento alla fonte (dopo tutto, ci
piacerebbe che la gente usasse il nostro libro!)
Down Approach
 se rendete disponibili queste slide in una forma sostanzialmente inalterata 7th edition
su un sito web, indicate che si tratta di un adattamento (o che sono Jim Kurose, Keith Ross
identiche) delle nostre slide, e inserite la nota relativa al copyright.
Pearson/Addison Wesley
Thanks and enjoy! JFK/KWR April 2016
All material copyright 1996-2016
J.F Kurose and K.W. Ross, All Rights Reserved

Livello di trasporto 3-1

Capitolo 3: Livello di trasporto
obiettivi:
 capire i principi che  descrivere i protocolli
sono alla base dei del livello di trasporto
servizi del livello di di Internet:
trasporto:  UDP: trasporto senza
 multiplexing, connessione
demultiplexing  TCP: trasporto orientato
 trasferimento dati alla connessione
affidabile  controllo di congestione TCP
 controllo di flusso
 controllo di congestione

Livello di trasporto 3-2

Capitolo 3: Livello di trasporto
3.1 servizi a livello di 3.5 trasporto orientato alla
trasporto connessione : TCP
3.2 multiplexing e  struttura dei segmenti
demultiplexing  trasferimento dati affidabile
3.3 trasporto senza  controllo di flusso
connessione: UDP  gestione della connessione
3.4 principi del 3.6 principi sul controllo di
trasferimento dati congestione
affidabile 3.7 controllo di congestione TCP

Livello di trasporto 3-3

Servizi e protocolli di trasporto
applicazione
trasporto
 forniscono la comunicazione rete
link
logica tra processi applicativi su fisico

host differenti
 i protocolli di trasporto vengono
eseguiti sugli end system
 lato invio: divide i messaggi in
segmenti e li passa al livello di
rete
 lato ricezione: riassembla i applicazione
segmenti in messaggi e li passa trasporto
rete
al livello di applicazione link
fisico

 più protocolli di trasporto sono

a disposizione delle applicazioni
 Internet: TCP e UDP
Livello di trasporto 3-4
Confronto tra livello di
trasporto e livello di rete
 livello di rete: analogia con la posta ordinaria:
comunicazione i ragazzi della casa di Ann inviano
logica tra host lettere ai ragazzi nella casa di
Bill:
 livello di trasporto:  host = case
comunicazione  processi = ragazzi
logica tra processi  messaggi delle applicazioni =
 si basa sui servizi lettere nelle buste
(se può li migliora)  protocollo di trasporto = Ann
del livello di rete e Bill che smistano le lettere
 protocollo del livello di rete =
servizio postale

Livello di trasporto 3-5

Protocolli del livello di trasporto
in Internet
applicazione
 affidabile, consegne trasporto
rete

nell’ordine originario (TCP) link

fisico
rete

 controllo di congestione rete

link
link
fisico
fisico
 controllo di flusso rete
link

 setup della connessione fisico

rete

 inaffidabile, consegne link

fisico

senz’ordine: UDP rete

link
fisico
 estensione senza fronzoli del rete
link applicazione
servizio di consegna a massimo fisico
rete
link
trasporto
rete

sforzo (“best-effort”) fisico link

fisico

 servizi non disponibili:

 garanzie sui ritardi
 garanzie sulla bandwidth Livello di trasporto 3-6
Capitolo 3: Livello di trasporto
3.1 servizi a livello di 3.5 trasporto orientato alla
trasporto connessione : TCP
3.2 multiplexing e  struttura dei segmenti
demultiplexing  trasferimento dati affidabile
3.3 trasporto senza  controllo di flusso
connessione: UDP  gestione della connessione
3.4 principi del 3.6 principi sul controllo di
trasferimento dati congestione
affidabile 3.7 controllo di congestione TCP

Livello di trasporto 3-7

Multiplexing/demultiplexing
multiplexing in invio:
maneggia i dati provenienti demultiplexing in ricezione:
dalle diverse socket, aggiunge le usa le intestazioni per consegnare
intestazioni di trasporto (poi i segmenti ricevuti alla socket
usate per il demultiplexing) appropriata

applicazione

applicazione P1 P2 applicazione socket

P3 trasporto P4
processo
trasporto rete trasporto
rete link rete
link fisico link
fisico fisico

Livello di trasporto 3-8

 Come funziona il demultiplexing
 l’host riceve i datagrammi IP 32 bit
 ogni datagramma ha un N°porta N°porta
indirizzo IP sorgente e sorgente destinazione
un indirizzo IP di destinazione
altri campi di intestazione
 ogni datagramma trasporta 1
segmento a livello di trasporto
 ogni segmento ha un numero di Dati dell’applicazione
porta di origine e un numero di (messaggio)
porta di destinazione
 l’host usa gli indirizzi IP e i
numeri di porta per inviare il
segmento alla socket Struttura del segmento TCP/UDP
appropriata
Livello di trasporto 3-9
 Demultiplexing senza connessione
 la socket creata ha un  quando si crea un datagramma
numero di porta locale: da inviare a una socket UDP,
DatagramSocket mySocket1 vengono specificati
= new DatagramSocket(12534);
 indirizzo IP di destinazione
 numero di porta di destinazione

 quando un host riceve un i datagram IP con lo stesso

segmento UDP: numero di porta di
 controlla il numero di destinazione, anche se con
porta di destinazione differenti indirizzi IP sorgenti
e/o numeri di porta sorgente
 dirige il segmento UDP alla verranno diretti alla stessa
socket con quel numero di socket nella destinazione
porta
Livello di trasporto 3-10
 Demultiplexing senza connessione
DatagramSocket
DatagramSocket serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); application
(5775);
applicazione application
P1
P3 P4
trasporto
trasporto trasporto
rete
rete link rete
link fisico link
fisico fisico

porta sorgente: 6428 porta sorgente: ?

porta destinazione: 9157 porta destinazione: ?

porta sorgente: 9157 porta sorgente: ?

porta destinazione: 6428 porta destinazione: ?
Livello di trasporto 3-11
 Demultiplexing
orientato alla connessione
 il socket TCP è  un host server può
identificato da 4 parametri: supportare più socket
 indirizzo IP sorgente TCP contemporanee:
 numero di porta sorgente  ogni socket è identificata dai
 indirizzo IP di destinazione suoi 4 parametri
 numero di porta di  i server web hanno socket
destinazione differenti per ogni
 il ricevente usa tutti e connessione client
quattro i parametri per  con HTTP non-persistente
inviare i segmenti alla si avrà una socket differente
socket appropriata per ogni richiesta

Livello di trasporto 3-12

 Demultiplexing
orientato alla connessione
applicazione
applicazione P4 P5 P6 applicazione
P3 P2 P3
trasporto
trasporto trasporto
rete
rete link rete
link fisico link
fisico server: fisico
indirizzo IP
B

host: IP,porta sorgente : B,80 host:

indirizzo IP IP,porta destinazione: A,9157 IP,porta sorgente: C,5775 indirizzo IP
A IP,porta destinazione: B,80 C
IP,porta sorgente: A,9157
IP,porta destinazione: B,80
IP,porta sorgente: C,9157
IP,porta destinazione: B,80
tre segmenti, tutti destinati all’indirizzo IP: B,
porta: 80 sono demultiplexati verso socket differenti Livello di trasporto 3-13
Capitolo 3: Livello di trasporto
3.1 servizi a livello di 3.5 trasporto orientato alla
trasporto connessione : TCP
3.2 multiplexing e  struttura dei segmenti
demultiplexing  trasferimento dati affidabile
3.3 trasporto senza  controllo di flusso
connessione: UDP  gestione della connessione
3.4 principi del 3.6 principi sul controllo di
trasferimento dati congestione
affidabile 3.7 controllo di congestione TCP

Livello di trasporto 3-14

UDP: User Datagram Protocol [RFC 768]
 protocollo di  uso di UDP :
trasporto“senza fronzoli”  applicazioni di streaming
 servizio “best effort”, i multimediali (tolleranti
segmenti UDP possono alle perdite, sensibili al
essere: rate)
 perduti  DNS
 consegnati fuori sequenza  SNMP
all’applicazione  trasferimento affidabile
 senza connessione: con UDP:
 non c’è handshaking tra  l’affidabilità va aggiunta al
mittente e destinatario livello di applicazione
UDP
 il recupero degli errori
 ogni segmento UDP è deve essere gestito dalle
gestito indipendentemente applicazioni!
dagli altri
Livello di trasporto 3-15
UDP: intestazione del segmento
lunghezza in byte del
32 bit segmento UDP,
inclusa l’intestazione
N°porta N°porta
sorgente destinazione perché usare UDP?
lunghezza checksum  nessuna connessione da
stabilire (che può
aggiungere un ritardo)
dati dell’applicazione  semplice: nessuno stato di
(messaggio) connessione nel mittente
e destinatario
 intestazioni di segmento
piccole
struttura del segmento UDP  non c’è controllo di
congestione: UDP può
sparare dati a raffica
Livello di trasporto 3-16
Checksum UDP
Obiettivo: rilevare gli “errori” (bit alterati) nel segmento
trasmesso
mittente: ricevente:
 tratta il contenuto del  calcola la checksum del
segmento, compresa segmento ricevuto
l’intestazione, come una  controlla se la checksum
sequenza di interi a 16 bit
calcolata è uguale al valore
 checksum: somma del campo checksum:
(complemento a 1) dei
contenuti del segmento  NO - errore rilevato
 il mittente pone il valore  YES - nessun errore
della checksum nel campo rilevato. Ma potrebbero
checksum del segmento UDP esserci errori nonostante
questo? Altro più avanti…
Livello di trasporto 3-17
Checksum: esempio
esempio: sommare due interi a 16 bit
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

ritorno 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

somma 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Nota: quando si sommano i numeri, un riporto dal bit più

significativo deve essere sommato al risultato

Livello di trasporto 3-18

Capitolo 3: Livello di trasporto
3.1 servizi a livello di 3.5 trasporto orientato alla
trasporto connessione : TCP
3.2 multiplexing e  struttura dei segmenti
demultiplexing  trasferimento dati affidabile
3.3 trasporto senza  controllo di flusso
connessione: UDP  gestione della connessione
3.4 principi del 3.6 principi sul controllo di
trasferimento dati congestione
affidabile 3.7 controllo di congestione TCP

Livello di trasporto 3-19

Principi del trasferimento dati affidabile
 importante nei livelli di applicazione, trasporto e link
 nella top-10 dei problemi più importanti del networking!

 le caratteristiche del canale inaffidabile determinano la

complessità del protocollo di trasferimento dati affidabile
(reliable data transfer o rdt) Livello di trasporto 3-20
Principi del trasferimento dati affidabile
 importante nei livelli di applicazione, trasporto e link
 nella top-10 dei problemi più importanti del networking!

 le caratteristiche del canale inaffidabile determinano la

complessità del protocollo di trasferimento dati affidabile
(reliable data transfer o rdt) Livello di trasporto 3-21
Principi del trasferimento dati affidabile
 importante nei livelli di applicazione, trasporto e link
 nella top-10 dei problemi più importanti del networking!

 le caratteristiche del canale inaffidabile determinano la

complessità del protocollo di trasferimento dati affidabile
(reliable data transfer o rdt) Livello di trasporto 3-22
 Trasferimento dati affidabile: preparazione
rdt_send(): chiamata dall’alto, (ad es. deliver_data(): chiamata
dall’applicazione). Trasferisce i dati da da rdt per consegnare i dati al
consegnare al livello superiore del ricevente livello superiore

lato lato
invio ricezione

udt_send(): chiamata da rdt per rdt_rcv(): chiamata quando il pacchetto

trasferire il pacchetto al ricevente arriva nel lato ricezione del canale
tramite il canale inaffidabile

Livello di trasporto 3-23

 Trasferimento dati affidabile: preparazione
 svilupperemo progressivamente i lati d’invio e di ricezione
di un protocollo di trasferimento dati affidabile (rdt)
 considereremo soltanto i trasferimenti dati unidirezionali
 ma le informazioni di controllo fluiranno in entrambe le direzioni!
 utilizzeremo automi a stati finiti (finite state machine, FSM)
per specificare il mittente e il ricevente

evento che causa la transizione di stato

azioni svolte nella transizione
stato: lo stato successivo a
questo è determinato stato stato
unicamente dall’evento 1 evento
successivo 2
azioni

Livello di trasporto 3-24

rdt1.0: trasferimento affidabile su canale affidabile
 canale sottostante perfettamente affidabile
 nessun errore nei bit
 nessuna perdita di pacchetti
 FSM distinti per il mittente e per il ricevente:
 il mittente invia i dati nel canale sottostante
 il ricevente legge i dati dal canale sottostante

Attesa di rdt_send(data) Attesa di rdt_rcv(packet)

chiamata chiamata extract (packet,data)
dall’alto packet = make_pkt(data) dal basso deliver_data(data)
udt_send(packet)

mittente ricevente

Livello di trasporto 3-25

rdt2.0: canale con errori nei bit
 il canale sottostante potrebbe confondere i bit nei
pacchetti
 checksum per rilevare gli errori nei bit
 domanda: come correggere gli errori:

Come fanno gli uomini a recuperare gli“errori”

(incomprensioni) durante una conversazione?

Livello di trasporto 3-26

rdt2.0: canale con errori nei bit
 il canale sottostante potrebbe confondere i bit nei
pacchetti
 checksum per rilevare gli errori nei bit
 domanda: come correggere gli errori:
 acknowledgements (ACKs): il ricevente dice esplicitamente al
mittente che il pacchetto ricevuto è corretto
 negative acknowledgements (NAKs): il ricevente dice
esplicitamente al mittente che il pacchetto ricevuto contiene
errori
 il mittente ritrasmette il pacchetto se riceve un NAK
 nuovi meccanismi in rdt2.0 (rispetto a rdt1.0):
 rilevamento degli errori
 feedback del destinatario: messaggi di controllo (ACK, NAK)
ricevente->mittente

Livello di trasporto 3-27

rdt2.0: specifica del FSM
rdt_send(data)
sndpkt = make_pkt(data, checksum) ricevente
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Attesa di Attesa rdt_rcv(rcvpkt) &&
chiamata di ACK udt_send(sndpkt) corrupt(rcvpkt)
dall’alto o NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Attesa di
L chiamata
dal basso
mittente
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Livello di trasporto 3-28

rdt2.0: operazione senza errori
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Attesa di Attesa rdt_rcv(rcvpkt) &&
chiamata di ACK udt_send(sndpkt) corrupt(rcvpkt)
dall’alto o NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Attesa di
L chiamata
dal basso

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Livello di trasporto 3-29

rdt2.0: scenario con errore
rdt_send(data)
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Attesa di Attesa rdt_rcv(rcvpkt) &&
chiamata di ACK udt_send(sndpkt) corrupt(rcvpkt)
dall’alto o NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt) Attesa di

L chiamata
dal basso

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Livello di trasporto 3-30

rdt2.0 ha un difetto fatale!
che accade se i pacchetti gestione dei duplicati:
ACK/NAK sono  il mittente ritrasmette il
danneggiati? pacchetto corrente se
 il mittente non sa che ACK/NAK è alterato
cosa sia accaduto al  il mittente aggiunge un
destinatario! numero di sequenza
 non può semplicemente a ogni pacchetto
ritrasmettere: possibili
duplicati  il ricevente scarta il
pacchetto duplicato
stop and wait
il mittente invia un
pacchetto, poi aspetta la
risposta del destinatario
Livello di trasporto 3-31
rdt2.1: il mittente gestisce gli ACK/NAK corrotti
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Attesa di Attesa di
ACK o
isNAK(rcvpkt) )
chiamata 0
dall’alto NAK 0 udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
L
L
Attesa di Attesa di
ACK o chiamata 1
rdt_rcv(rcvpkt) && NAK 1 dall’alto
( corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)

udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)

Livello di trasporto 3-32

 rdt2.1: il ricevente gestisce gli ACK/NAK corrotti
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Attesa Attesa
rdt_rcv(rcvpkt) && di 0 dal di 1 dal rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && basso basso not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

Livello di trasporto 3-33

rdt2.1: discussione
mittente: ricevente:
 aggiunge il numero di  deve controllare se il
sequenza al pacchetto pacchetto ricevuto è
 saranno sufficienti due duplicato
numeri di sequenza (0,1).  lo stato indica se il
Perché? numero di sequenza
previsto è 0 o 1
 deve controllare se gli
 nota: il ricevente non può
ACK/NAK sono
danneggiati sapere se il suo ultimo
ACK/NAK è stato
 il doppio di stati ricevuto correttamente
 lo stato deve “ricordare” dal mittente
se il pacchetto “atteso” ha
numero di sequenza 0 o 1 Livello di trasporto 3-34
rdt2.2: un protocollo senza NAK
 stessa funzionalità di rdt2.1, utilizzando soltanto gli
ACK
 invece del NAK, il destinatario invia un ACK per
l’ultimo pacchetto ricevuto correttamente
 il destinatario deve includere esplicitamente il numero
di sequenza del pacchetto con l’ACK
 un ACK duplicato presso il mittente determina la
stessa azione del NAK: ritrasmettere il pacchetto
corrente

Livello di trasporto 3-35

 rdt2.2: mittente e ricevente
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Attesa di Attesa di isACK(rcvpkt,1) )
chiamata 0 ACK 0
dall’alto udt_send(sndpkt)
parte del FSM
mittente rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) Attesa parte del FSM
udt_send(sndpkt)
di 0 dal
basso
ricevente

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) Livello di trasporto 3-36
rdt3.0: canali con errori e perdite

nuova ipotesi: il canale approccio: il mittente attende

sottostante può anche un ACK per un tempo
perdere i pacchetti “ragionevole”
(dati o ACK)  ritrasmette se non riceve un ACK

 checksum, numero di in questo periodo

sequenza, ACK e  se il pacchetto (o l’ACK) è
soltanto in ritardo (non perso):
ritrasmissioni
aiuteranno, ma non  la ritrasmissione sarà duplicata,
saranno sufficienti ma l’uso dei numeri di sequenza
gestisce già questo
 il destinatario deve specificare il
numero di sequenza del
pacchetto riscontrato
 occorre un contatore (countdown
timer) Livello di trasporto 3-37
rdt3.0 mittente
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer L
L Attesa di Attesa
di timeout
chiamata 0
ACK 0 udt_send(sndpkt)
dall’alto
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Attesa Attesa di
timeout di chiamata 1
udt_send(sndpkt) ACK 1 dall’alto
start_timer rdt_rcv(rcvpkt)
rdt_send(data) L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
L

Livello di trasporto 3-38

 rdt3.0 in azione
mittente ricevente mittente ricevente
send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack0 send ack0 ack0 send ack0
rcv ack0 rcv ack0
send pkt1 pkt1 send pkt1 pkt1
rcv pkt1 X
ack1 send ack1 loss
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) nessuna perdita rcv pkt0
ack0 send ack0

(b) perdita di pacchetto

Livello di trasporto 3-39
 rdt3.0 in azione
mittente ricevente
mittente ricevente send pkt0 pkt0
send pkt0 pkt0 rcv pkt0
send ack0
rcv pkt0 ack0
send ack0 rcv ack0
ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
send pkt1 pkt1
send ack1
rcv pkt1 ack1
ack1 send ack1
X
loss timeout
resend pkt1 pkt1
rcv pkt1
timeout
resend pkt1 pkt1 rcv ack1 (detect duplicate)
rcv pkt1 send pkt0
pkt0
send ack1
(detect duplicate) ack1
ack1 send ack1 rcv ack1 rcv pkt0
rcv ack1 send pkt0
ack0 send ack0
send pkt0 pkt0 pkt0
rcv pkt0
rcv pkt0 ack0 (detect duplicate)
ack0 send ack0 send ack0

(c) perdita di ACK (d) timeout prematuro per ACK in ritardo

Livello di trasporto 3-40

Prestazioni di rdt3.0
 rdt3.0 funziona, ma le prestazioni non sono apprezzabili
 es.: link a1 Gbps, 15 ms di ritardo di propagazione, un
pacchetto da 1KB (8000 bit):
L 8000 bit
Dtrans = R = = 8 microsec
109 bit/sec
 U sender: utilizzo – la frazione di tempo in cui il mittente è
occupato nell’invio
U L/R .008
sender = = = 0.00027
RTT + L / R 30.008

 se RTT=30 msec, 1 pacchetto da1KB ogni 30 msec:

throughput di 33 kB/sec in un link da 1 Gbps
 il protocollo di rete limita l’uso delle risorse fisiche!
Livello di trasporto 3-41
 rdt3.0: funzionamento con stop-and-wait
mittente ricevente
primo bit del pacchetto trasmesso t = 0
ultimo bit del
pacchetto trasmesso, t = L / R
arrivo del primo bit del pacchetto
RTT arrivo dell’ultimo bit,
invio dell’ ACK

arrivo dell’ ACK, invio del pacchetto

successivo, t = RTT + L / R

U L/R .008
sender = = = 0.00027
RTT + L / R 30.008

Livello di trasporto 3-42

Protocolli con pipeline
pipelining: il mittente ammette più pacchetti in transito,
ancora da notificare
 l’intervallo dei numeri di sequenza deve essere incrementato
 buffering dei pacchetti presso il mittente e/o il ricevente

 due forme generiche di protocolli con pipeline:

go-Back-N, ripetizione selettiva
Livello di trasporto 3-43
 Pipelining: aumento dell’utilizzo
sender receiver
inizio invio primo pacchetto, t = 0
ultimo bit, t = L / R

primo bit del primo pacchetto

RTT ultimo bit del 1^ pacchetto, invio ACK
ultimo bit del 2^ pacchetto, invio ACK
ultimo bit del 3^ pacchetto, invio ACK

arrivo del primo ACK , invio

del pacchetto successivo,
t = RTT + L / R Aumento dell’utilizzo
di un fattore 3!

U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008

Livello di trasporto 3-44

 Protocolli con pipeline: panoramica
Go-back-N: Ripetizione selettiva:
 il mittente può avere fino  il mittente può avere fino
a N pacchetti consecutivi a N pacchetti consecutivi
non riscontrati in pipeline non riscontrati in pipeline
 il ricevente invia solo ack  il ricevente invia ack
cumulativi individuali per ogni
 non dà riscontro a un pacchetto
pacchetto se c’è un ‘buco’
 il mittente ha un timer  il mittente ha un timer per
per il più vecchio ogni pacchetto non
pacchetto non riscontrato riscontrato
 quando il timer scade,  quando un timer scade,
ritrasmette tutti i pacchetti ritrasmette solo il pacchetto
non riscontrati non riscontrato
Livello di trasporto 3-45
 Go-Back-N: mittente
 numero di sequenza a k bit nell’intestazione del pacchetto
 “finestra” contenente fino a N pacchetti consecutivi non riscontrati

 ACK(n): riscontro di tutti i pacchetti con numero di sequenza

minore o uguale a n - “ACK cumulativi”
 può ricevere ACK duplicati (vedere il ricevente)
 timer per il primo pacchetto in transito
 timeout(n): ritrasmette il pacchetto n e tutti i pacchetti con
numero di sequenza più grande nella finestra
Livello di trasporto 3-46
GBN: FSM esteso del mittente
rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
start_timer
nextseqnum++
}
L else
refuse_data(data)
base=1
nextseqnum=1
timeout
start_timer
Attesa udt_send(sndpkt[base])
rdt_rcv(rcvpkt) udt_send(sndpkt[base+1])
&& corrupt(rcvpkt) …
udt_send(sndpkt[nextseqnum-1])
L
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer
Livello di trasporto 3-47
GBN: FSM esteso del ricevente
default
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
L && hasseqnum(rcvpkt,expectedseqnum)
expectedseqnum=1 Attesa extract(rcvpkt,data)
sndpkt = deliver_data(data)
make_pkt(expectedseqnum,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++

ACK-only: invia sempre un ACK per un pacchetto

ricevuto correttamente con il numero di sequenza più
alto in sequenza
 può generare ACK duplicati
 deve memorizzare soltanto expectedseqnum
 pacchetto fuori sequenza:
 scartato (non salvato): non c’è buffering da parte del ricevente!
 rimanda un ACK per il pacchetto con il numero di sequenza
Livello di trasporto 3-48
più alto in sequenza
 GBN in azione
finestra d’invio (N=4) mittente ricevente
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xperso receive pkt1, send ack1
(wait)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignora ACK duplicato receive pkt5, discard,
(re)send ack1
timeout pkt 2
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5

Livello di trasporto 3-49

Ripetizione selettiva
 il ricevente invia riscontri specifici per tutti i
pacchetti ricevuti correttamente
 bufferizza i pacchetti, se necessario, per eventuali
consegne in sequenza al livello superiore
 il mittente ritrasmette soltanto i pacchetti per i
quali non ha ricevuto un ACK
 timer del mittente per ogni pacchetto non riscontrato
 finestra di invio
 N numeri di sequenza consecutivi
 limita i numeri di sequenza dei pacchetti inviati non
riscontrati

Livello di trasporto 3-50

Ripetizione selettiva: finestre di invio e ricezione

Livello di trasporto 3-51

Ripetizione selettiva
mittente ricevente
dati dall’alto: pacchetto n in [rcvbase,
rcvbase+N-1]
 se il successivo numero di
sequenza disponibile è nella  invia ACK(n)
finestra, invia il pacchetto  fuori sequenza: buffer
timeout(n):  in sequenza: consegna
(vengono consegnati anche i
 ritrasmette il pacchetto n, pacchetti bufferizzati in
riparte il timer sequenza); la finestra avanza
ACK(n) in [sendbase,sendbase+N]: al successivo pacchetto non
 marca il pacchetto n come ancora ricevuto
ricevuto pacchetto n in [rcvbase-N,
 se n è il numero di sequenza rcvbase-1]
non riscontrato più piccolo,  ACK(n)
avanza la base della finestra altrimenti: ignora
al successivo numero di
sequenza non riscontrato Livello di trasporto 3-52
 Ripetizione selettiva in azione
finestra d’invio (N=4) mittente ricevente
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5 receive pkt4, buffer,
send ack4
record ack3 arrived receive pkt5, buffer,
send ack5
timeout pkt 2
012345678 send pkt2
012345678 record ack4 arrived
012345678 rcv pkt2; deliver pkt2,
record ack5 arrived
012345678 pkt3, pkt4, pkt5; send ack2

D: che succede quando arriva ack2 ?

Livello di trasporto 3-53

Capitolo 3: Livello di trasporto
3.1 servizi a livello di 3.5 trasporto orientato alla
trasporto connessione : TCP
3.2 multiplexing e  struttura dei segmenti
demultiplexing  trasferimento dati affidabile
3.3 trasporto senza  controllo di flusso
connessione: UDP  gestione della connessione
3.4 principi del 3.6 principi sul controllo di
trasferimento dati congestione
affidabile 3.7 controllo di congestione TCP

Livello di trasporto 3-54

TCP: Panoramica RFCs: 793,1122,1323, 2018, 2581
 punto-punto:  full duplex data:
 un mittente, un destinatario  flusso di dati bidirezionale
 flusso di byte affidabile, in nella stessa connessione
sequenza:  MSS: dimensione massima di
segmento (maximum
 nessuna “limitazione ai segment size)
messaggi”
 orientato alla connessione:
 pipeline:
 l’handshaking (scambio di
 controllo di congestione e messaggi di controllo)
controllo di flusso inizializza lo stato del
mittente e del destinatario
prima di scambiare i dati
 flusso controllato:
 il mittente non sovraccarica
il destinatario Livello di trasporto 3-55
 Struttura dei segmenti TCP
numero di
riscontro: 32 bit
numero di
sequenza del Nº porta sorgente Nº porta destinazione numero di sequenza:
prossimo byte conteggio dei byte nel
atteso; A bit: sequence number flusso di dati (non dei
numero di riscontro acknowledgement number segmenti!)
valido
head not
lunghezza len used C E U A P R S F finestra di ricezione controllo di flusso:
(dell’header TCP) puntatore dati urgenti numero di byte che il
destinatario vuole
opzioni (lunghezza variabile) accettare
C, E: notifica di
congestione
opzioni TCP
dati dati inviati
RST, SYN, FIN: applicazione dall’applicazione
gestione della (lunghezza variabile) nella socket TCP
connessione

Livello di trasporto 3-56

Numeri di sequenza e ACK di TCP
segmento in uscita dal mittente
numeri di sequenza: source port # dest port #
sequence number
“numero” del primo byte acknowledgement number

del segmento nel flusso di rwnd

byte
checksum urg pointer

finestra di dimensione
acknowledgement: N

numero di sequenza del

successivo byte atteso spazio dei sequence number del mittente
dall’altro lato
ACK cumulativi inviato
ACKed
inviato,
non ancora
utilizzabile non
non utilizzabile
D: come gestisce il ACKed (“in
transito”)
ancora
inviato
destinatario i segmenti fuori segmento in arrivo al mittente
sequenza? source port # dest port #

R: la specifica TCP non lo

sequence number
acknowledgement number
dice – dipende A rwnd

dall’implementatore checksum urg pointer

Livello di trasporto 3-57

Numeri di sequenza e ACK di TCP
Host A Host B

l’utente
digita
‘C’ Seq=42, ACK=79, data = ‘C’
l’host
riscontra la
ricezione
Seq=79, ACK=43, data = ‘C’ di ‘C’ e
l’host riscontra
la ricezione reinvia ‘C’
della ‘C’
reinviata Seq=43, ACK=80

semplice scenario telnet

Livello di trasporto 3-58

TCP round trip time, timeout
D: come impostare il D: come stimare RTT?
valore del timeout di  SampleRTT: tempo
TCP? misurato dalla trasmissione
del segmento fino alla
 più grande di RTT ricezione di ACK
 ma RTT varia  ignora le ritrasmissioni
 troppo breve: timeout  SampleRTT varia, quindi
prematuri, ritrasmissioni occorre una stima “più
morbida” di RTT
non necessarie  media di più misure recenti,
 troppo lungo: reazione non semplicemente il
lenta alla perdita dei valore corrente di
segmenti SampleRTT

Livello di trasporto 3-59

TCP round trip time, timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
 media mobile esponenziale ponderata
 l’influenza dei vecchi campioni decresce esponenzialmente
 valore tipico:  = 0.125 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

RTT: da gaia.cs.umass.edu a fantasia.eurecom.fr

RTT (millisecondi)

300

250
RTT (milliseconds)

200

sampleRTT
150

EstimatedRTT

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
tempo (secondi) Livello di trasporto 3-60
SampleRTT Estimated RTT
TCP round trip time, timeout
 intervallo di timeout : EstimatedRTT più un “margine di
sicurezza”
 grande variazione di EstimatedRTT -> margine di sicurezza maggiore
 viene stimata la deviazione SampleRTT da EstimatedRTT:
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typically,  = 0.25)

TimeoutInterval = EstimatedRTT + 4*DevRTT

RTT stimato “margine di sicurezza”

Livello di trasporto 3-61

Capitolo 3: Livello di trasporto
3.1 servizi a livello di 3.5 trasporto orientato alla
trasporto connessione : TCP
3.2 multiplexing e  struttura dei segmenti
demultiplexing  trasferimento dati affidabile
3.3 trasporto senza  controllo di flusso
connessione: UDP  gestione della connessione
3.4 principi del 3.6 principi sul controllo di
trasferimento dati congestione
affidabile 3.7 controllo di congestione TCP

Livello di trasporto 3-62

Trasferimento dati affidabile del TCP
 TCP crea un servizio di
trasferimento dati
affidabile sul servizio
inaffidabile di IP
 pipeline dei segmenti inizialmente consideriamo
 ACK cumulativi un mittente TCP
 un solo timer di semplificato:
ritrasmissione  ignoriamo gli ACK
duplicati
 le ritrasmissioni
avvengono in seguito a:  ignoriamo il controllo di
flusso e il controllo di
 eventi di timeout congestione
 ACK duplicati

Livello di trasporto 3-63

 TCP: eventi del mittente
dati ricevuti dall’applicazione: timeout:
 crea un segmento con il  ritrasmette il segmento
numero di sequenza che ha causato il timeout
 il numero di sequenza è  riavvia il timer
il numero del primo byte ack ricevuto:
del segmento nel flusso  se riscontra segmenti
di byte precedentemente non
 avvia il timer, se non è riscontrati
già in funzione  aggiorna la traccia su ciò
 pensate al timer come se che è stato riscontrato
fosse associato al più  avvia il timer se ci sono altri
vecchio segmento non segmenti da riscontrare
riscontrato
 intervallo di scadenza:
TimeOutInterval Livello di trasporto 3-64
Mittente TCP (semplificato)
dati ricevuti dall’applicazione in alto
crea un segmento, seq. #: NextSeqNum
passa il segmento a IP (“send”)
NextSeqNum = NextSeqNum + lunghezza(dati)
se (timer non attivo)
L avvia il timer
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum attesa di
evento
timeout
ritrasmetti il segmento non ancora
riscontrato con il seq. # più basso
avvia il timer
ACK ricevuto, con valore y del campo ACK
se (y > SendBase) {
SendBase = y
/* SendBase–1: ultimo byte ACKed */
se (ci sono segmenti non ancora riscontrati)
avvia il timer
altrimenti ferma il timer
} Livello di trasporto 3-65
TCP: scenari di ritrasmissione
Host A Host B Host A Host B

SendBase=92
Seq=92, 8 byte di dati Seq=92, 8 byte di dati

Seq=100, 20 byte di dati

timeout

timeout
ACK=100
X
ACK=100
ACK=120

Seq=92, 8 byte di dati Seq=92, 8

SendBase=100 byte di dati
SendBase=120
ACK=100
ACK=120

SendBase=120

scenario con ACK perso timeout prematuro

Livello di trasporto 3-66
TCP: scenari di ritrasmissione
Host A Host B

Seq=92, 8 byte di dati

Seq=100, 20 byte di dati

timeout

ACK=100
X
ACK=120

Seq=120, 15 byte di dati

ACK cumulativo
Livello di trasporto 3-67
TCP: generazione di ACK [RFC 1122, RFC 2581]

evento nel destinatario azione del ricevente TCP

arrivo ordinato di un segmento con ACK ritardato. Attende fino a 500 ms
numero di sequenza atteso. Tutti i dati l’arrivo del prossimo segmento. Se il
fino al numero di sequenza atteso segmento non arriva, invia un ACK
sono già stati riscontrati
arrivo ordinato di un segmento con invia immediatamente un singolo ACK
numero di sequenza atteso. Per un cumulativo, riscontrando entrambi i
altro segmento è stato inviato l’ACK segmenti ordinati
ma non ancora riscontrato

arrivo non ordinato di un segmento invia immediatamente un ACK duplicato,

con numero di sequenza superiore indicando il numero di sequenza del
a quello atteso. Viene rilevato un buco prossimo byte atteso

arrivo di un segmento che colma invia immediatamente un ACK, ammesso

parzialmente o completamente il buco che il segmento cominci all’estremità
inferiore del buco

Livello di trasporto 3-68

 Ritrasmissione rapida
 il periodo di timeout spesso
è relativamente lungo: ritrasmissione rapida
 lungo ritardo prima di se il mittente riceve 3
ritrasmettere il pacchetto ACK per lo stesso dato
perduto
(“triple duplicate ACKs”),
 rileva i segmenti perduti
tramite gli ACK duplicati. re-invia il segmento non
acked con il numero di
 il mittente spesso invia molti
segmenti sequenza più basso
 se un segmento viene  suppone che il segmento
smarrito, è probabile che ci non acked sia andato
saranno molti ACK duplicati. perso, e non aspetta il
timeout

Livello di trasporto 3-69

Ritrasmissione rapida
Host A Host B

Seq=92, 8 byte di dati

Seq=100, 20 byte di dati
X

ACK=100
timeout

ACK=100
ACK=100
ACK=100
Seq=100, 20 byte di dati

ritrasmissione rapida dopo che il mittente

ha ricevuto il triple duplicate ACK Livello di trasporto 3-70
Capitolo 3: Livello di trasporto
3.1 servizi a livello di 3.5 trasporto orientato alla
trasporto connessione : TCP
3.2 multiplexing e  struttura dei segmenti
demultiplexing  trasferimento dati affidabile
3.3 trasporto senza  controllo di flusso
connessione: UDP  gestione della connessione
3.4 principi del 3.6 principi sul controllo di
trasferimento dati congestione
affidabile 3.7 controllo di congestione TCP

Livello di trasporto 3-71

TCP: controllo di flusso
processo
potrebbe accadere che applicazione
l’applicazione riesca a applicazione
prendere i dati dal
buffer della socket TCP …. buffer della socket SO
TCP del ricevente
… più lentamente di
quanto il ricevente TCP
riesca a inviarglieli
codice
(il mittente sta inviando) TCP

controllo di flusso
codice
il destinatario modera il mittente, IP
così da non sovraccaricare il buffer
del destinatario trasmettendo
troppi dati, troppo velocemente dal mittente

pila protocollare del ricevente

Livello di trasporto 3-72
TCP: controllo di flusso
 il ricevente comunica lo spazio
disponibile includendo il valore processo applicativo
rwnd nelle intestazioni TCP
dei suoi segmenti
 la dimensione di RcvBuffer è RcvBuffer dati bufferizzati
impostata tramite opzioni della
socket (il default tipico è 4096 rwnd spazio libero nel buffer
byte)
 molti sistemi operativi hanno un
autoadjust di RcvBuffer
dati dai segmenti TCD
 il mittente limita la quantità di
dati unacked (“in-flight”) al
valore rwnd del ricevente buffering lato ricevente
 garantisce che il buffer di
ricezione non vada in overflow
Livello di trasporto 3-73
Capitolo 3: Livello di trasporto
3.1 servizi a livello di 3.5 trasporto orientato alla
trasporto connessione : TCP
3.2 multiplexing e  struttura dei segmenti
demultiplexing  trasferimento dati affidabile
3.3 trasporto senza  controllo di flusso
connessione: UDP  gestione della connessione
3.4 principi del 3.6 principi sul controllo di
trasferimento dati congestione
affidabile 3.7 controllo di congestione TCP

Livello di trasporto 3-74

Gestione della connessione
prima di scambiarsi dati, sender e receiver effettuano
l’“handshake” (stretta di mano):
 si accordano nello stabilire la connessione (ognuno sa che
l’altro vuole stabilire la connessione)
 si accordano sui parametri della connessione
applicazione applicazione

stato connessione: ESTAB stato connessione : ESTAB

variabili di connessione: variabili di connessione :
seq # client-to-server seq # client-to-server
server-to-client server-to-client
size del rcvBuffer size del rcvBuffer
di server e client di server e client

rete rete

clientSocket.connect( connectionSocket, addr =

(serverName,serverPort)) serverSocket.accept()
Livello di trasporto 3-75
 TCP 3-way handshake

stato client stato server

LISTEN LISTEN
sceglie seq num iniz , x
invia messaggio TCP SYN
SYNSENT SYNbit=1, Seq=x
sceglie seq num iniz, y
invia messaggio TCP
SYNACK, ack-ando SYN SYN RCVD
SYNbit=1, Seq=y
riceve SYNACK(x) ACKbit=1; ACKnum=x+1
che indica che il server è vivo;
ESTAB invia l’ACK per SYNACK;
questo segmento può già
contenere dati client-to-server ACKbit=1, ACKnum=y+1
riceve ACK(y) che
indica che il client è vivo
ESTAB

Livello di trasporto 3-76

TCP 3-way handshake: FSM

chiusa

connectionSocket, addr =
serverSocket.accept()

L clientSocket.connect(
SYN(x) (serverName,serverPort))
SYNACK(seq=y,ACKnum=x+1)
crea una nuova socket per SYN(seq=x)
communicare con il client ascolto

SYN SYN
ricevuto inviato

SYNACK(seq=y,ACKnum=x+1)
ESTAB ACK(ACKnum=y+1)
ACK(ACKnum=y+1)
L

Livello di trasporto 3-77

TCP: chiudere una connessione
 client e server chiudono il loro lato della connessione
 inviano un segmento TCP con bit FIN = 1
 rispondono al FIN ricevuto con un ACK
 alla ricezione del FIN, l’ACK può essere combinato con il
proprio FIN
 uno scambio di FIN simultanei può essere gestito

Livello di trasporto 3-78

TCP: chiudere una connessione
stato client stato server
ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 non può più FINbit=1, seq=x
inviare ma può
ricevere dati CLOSE_WAIT
ACKbit=1; ACKnum=x+1
può ancora
FIN_WAIT_2 attende la chiusura inviare dati
del server

LAST_ACK
FINbit=1, seq=y
TIME_WAIT non può più
inviare dati
ACKbit=1; ACKnum=y+1
tempo pari a
2*max tempo CLOSED
di vita di un segmento

CLOSED

Livello di trasporto 3-79

Capitolo 3: Livello di trasporto
3.1 servizi a livello di 3.5 trasporto orientato alla
trasporto connessione : TCP
3.2 multiplexing e  struttura dei segmenti
demultiplexing  trasferimento dati affidabile
3.3 trasporto senza  controllo di flusso
connessione: UDP  gestione della connessione
3.4 principi del 3.6 principi sul controllo di
trasferimento dati congestione
affidabile 3.7 controllo di congestione TCP

Livello di trasporto 3-80

Principi del controllo di congestione
congestione:
 informalmente: “troppe sorgenti inviano troppi dati
troppo velocemente perché la rete li gestisca”
 differente dal controllo di flusso!
 sintomi:
 pacchetti persi (buffer overflow nei router)
 lunghi ritardi (accodamento nei buffer dei router)
 problema nella top-10!

Livello di trasporto 3-81

 Cause/costi della congestione: scenario 1
dati originali : lin throughput: lout
 due mittenti,
due destinatari Host A

 un router, con buffer illimitati buffer

illimitati di output

 capacità del link di output : R

 nessuna ritrasmissione
Host B

R/2

delay
lout

lin R/2 lin R/2

 throughput massimo  lunghi ritardi se il rate in
per connessione : R/2 arrivo, lin, si avvicina alla
capacità Livello di trasporto 3-82
Cause/costi della congestione: scenario 2
 un router, buffer finiti
 ritrasmissione dei pacchetti timed-out
 input nell’application-layer = output dell’application-layer :
lin = lout
 l’input del transport-layer include le ritrasmissioni : l‘ in lin

lin : dati originali

lout
l'in: dati originali, più
dati ritrasmessi

Host A

buffer finiti sul

Host B
link di output
Livello di trasporto 3-83
Cause/costi della congestione: scenario 2
R/2
idealizzazione: conoscenza
perfetta

lout
 il mittente invia solo
quando i buffer dei router
sono disponibili lin R/2

lin : dati originali

lout
copia l'in: dati originali, più
dati ritrasmessi

A spazio libero nel buffer!

buffer finiti sul

Host B
link di output
Livello di trasporto 3-84
Cause/costi della congestione: scenario 2
idealizzazione: perdite note
i pacchetti possono essere
persi, scartati dai router a
causa dei buffer pieni
 il mittente re-invia solo se
sa che il pacchetto è andato
perso
lin : dati originali
lout
copia l'in: dati originali, più
dati ritrasmessi

A
no spazio nel buffer!

Host B
Livello di trasporto 3-85
Cause/costi della congestione: scenario 2
idealizzazione: perdite note R/2
capacità “sprecata”
i pacchetti possono essere per le ritrasmissioni

throughput: lout
persi, scartati dai router a inviando a R/2,
causa dei buffer pieni alcuni pacchetti
 il mittente re-invia solo se sono
ritrasmissioni
sa che il pacchetto è andato
perso lin R/2
lin : dati originali
lout
l'in: dati originali, più
dati ritrasmessi

A spazio libero nel buffer!

Host B
Livello di trasporto 3-86
Cause/costi della congestione: scenario 2
realistico: duplicati non necessari R/2

 i pacchetti possono essere capacità “sprecata”

throughput: lout
per ritrasmissioni
persi, scartati dai router a inutili
causa dei buffer pieni inviando a R/2,
 il mittente, per time out alcuni pacchetti
prematuri, invia due copie, sono ritrasmissioni
inclusi i duplicati
entrambe trasmesse inutili che sono
lin R/2 trasmessi!
lin
timeout
copy l'in lout

A
free buffer space!

Host B
Livello di trasporto 3-87
Cause/costi della congestione: scenario 2
realistico: duplicati non necessari R/2

 i pacchetti possono essere capacità “sprecata”

throughput: lout
per ritrasmissioni
persi, scartati dai router a inutili
causa dei buffer pieni inviando a R/2,
 il mittente, per time out alcuni pacchetti
prematuri, invia due copie, sono ritrasmissioni
inclusi i duplicati
entrambi trasmesse inutili che sono
lin R/2 trasmessi!

“costi” della congestione:

 più lavoro (ritrasmissioni) per avere “goodput”
 ritrasmissioni non necessarie: il link trasmette copie multiple
di pacchetti
 decresce il goodput

Livello di trasporto 3-88

Cause/costi della congestione: scenario 3
 quattro mittenti D: che succede se lin e lin’
aumentano ?
 cammini multihop
R: se il lin’ rosso aumenta, tutti i
 timeout/ritrasmissioni pacchetti blu verranno scartati,
throughput blu g 0
Host A
lin : dati originali lout
Host B
l'in: dati originali, più
dati ritrasmessi
buffer finiti sul link
di output

Host D
Host C

Livello di trasporto 3-89

Cause/costi della congestione: scenario 3

C/2
lout

lin’ C/2

un altro “costo” della congestione:

 quando il pacchetto è scartato, parte della
capacità di trasmissione è stata sprecata per
quel pacchetto!

Livello di trasporto 3-90

Capitolo 3: Livello di trasporto
3.1 servizi a livello di 3.5 trasporto orientato alla
trasporto connessione : TCP
3.2 multiplexing e  struttura dei segmenti
demultiplexing  trasferimento dati affidabile
3.3 trasporto senza  controllo di flusso
connessione: UDP  gestione della connessione
3.4 principi del 3.6 principi sul controllo di
trasferimento dati congestione
affidabile 3.7 controllo di congestione TCP

Livello di trasporto 3-91

 Controllo di congestione TCP: AIMD
 approccio: il mittente incrementa il rate di invio, fino a quando non si
verifica una perdita (congestione), a seguito della quale decrementa
il rate
Additive Increase Multiplicative Decrease
incrementa il rate di invio di 1 riduce il rate della metà
MSS ogni RTT finché non ci sono dopo ogni perdita
perdite

Dente di sega
TCP rate di invio mittente

AIMD:
sondare
la bandwidth

tempo Livello di trasporto 3-92

Controllo di congestione TCP: altro
Dettagli multiplicative decrease: il rate di invio è
 ridotto della metà per perdite rilevate dal triple
duplicate ACK (TCP Reno)
 ridotto a 1 MSS (maximum segment size) per perdite
rilevate dal timeout (TCP Tahoe)

Perché AIMD?
 AIMD – un algoritmo distribuito e asincrono – è stato
dimostrato che:
• ottimizza i flussi congestionati su tutta la rete!
• ha le necessarie proprietà di stabilità

Livello di trasporto 3-93

Controllo di congestione TCP: dettagli
spazio dei sequence number del mittente
cwnd rate di invio TCP:
 brutalmente: invia
cwnd byte, aspetta
ultimo byte ultimo byte
RTT per gli ACK, e
ACKed inviato, non inviato
ancora ACKed poi invia altri byte
(“in transito”)
cwnd
rate ~
~ bytes/sec
RTT

 il mittente limita la trasmissione: LastByteSent-LastByteAcked < cwnd

 cwnd è dinamica, funzione della congestione della rete percepita
(implementando il controllo di congestione TCP)

Livello di trasporto 3-94

 Partenza lenta
Host A Host B
 quando parte una connessione,
il rate viene incrementato
esponenzialmente fino al primo

RTT
evento di perdita
• inizialmente cwnd = 1 MSS
• raddoppia cwnd ogni RTT
• cwnd è incrementato a ogni
ACK ricevuto
 risultato: il rate iniziale è lento
ma si impenna con velocità
esponenziale tempo

Livello di trasporto 3-95

TCP: rilevazione e reazione alle perdite
 perdite indicate dai timeout:
 cwnd impostato a 1 MSS;
 la finestra cresce esponenzialmente (come nella
partenza lenta) fino alla soglia, poi cresce linearmente
 perdite indicate da 3 duplicate ACK: TCP RENO
 gli ACK duplicati indicano la capacità della rete di
consegnare segmenti
 cwnd viene dimezzato poi cresce linearmente
 TCP Tahoe imposta sempre cwnd a 1 (timeout
o 3 duplicate ack)
Livello di trasporto 3-96
TCP: da partenza lenta a Congestion Avoidance

D: quando la crescita da
esponenziale deve
passare a lineare?
X
R: quando cwnd raggiunge
1/2 del suo valore prima
del timeout.

Implementazione:
 ssthresh variabile
 in caso di perdita,
ssthresh viene
impostata a 1/2 del valore
di cwnd prima della
perdita

Livello di trasporto 3-97

Riassunto: Controllo di congestione TCP
New
New ACK!
ACK! nuovo ACK
ACK duplicati
dupACKcount++ nuovo ACK
.
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS transmette nuovi segmenti
dupACKcount = 0
L transmette nuovi segmenti
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0 partenza L evitamento
lenta timeout congestione
ssthresh = cwnd/2
cwnd = 1 MSS ACK duplicati
timeout dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 ritrasmette i segmenti mancanti
cwnd = 1 MSS
dupACKcount = 0
ritrasmette i segmenti mancanti
New
ACK!
timeout
ssthresh = cwnd/2
cwnd = 1 nuovo ACK
dupACKcount = 0
ritrasmette i segmenti mancanti cwnd = ssthresh ACK duplicati == 3
ACK duplicati == 3 dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
ritrasmette i segmenti mancanti ritrasmette i segmenti mancanti
ripresa
veloce
ACK duplicati
cwnd = cwnd + MSS
transmette nuovi segmenti

Livello di trasporto 3-98

 TCP CUBIC
 C’è un modo migliore dell’ AIMD per “sondare” la bandwidth?
 Considerazione:
• Wmax: rate di invio quando viene rilevata una perdita da congestione
• lo stato del link di bottleneck non sarà (?) cambiato di molto
• dopo aver dimezzato rate/window, inizialmente riaumentali
verso Wmax rapidamente, quando sei vicino a Wmax lentamente

Wmax TCP classico

TCP CUBIC -
Wmax/2 maggior
throughput in
questo
esempio

Livello di trasporto 3-99

 TCP CUBIC
 K: tempo nel quale la finestra di invia raggiungerà Wmax
• K è a sua volta regolabile
 incrementa W come una funzione del cubo della distanza
tra il tempo corrente e K
• maggiori incrementi quando lontani da K
• incrementi minori (più prudenti) vicino a K

 TCP CUBIC è il W max

default in Linux, TCP Reno

molto popolare per TCP TCP CUBIC
Web server sending
rate
popolari time
t0 t1 t2 t3 t4
Livello di trasporto 3-100
 TCP e il link “bottleneck”
 TCP (classico, CUBIC) incrementa il rate di invio finché non c’è
una perdita nell’interfaccia di qualche router: il bottleneck link

sorgente destinazione
application application
TCP TCP
network network
link link
physical physical
coda di pacchetti quasi
mai vuota, talvolta in
overflow (perdita)

bottleneck link (quasi sempre sovraccarico)

Livello di trasporto 3-101
 TCP e il link “bottleneck”
 TCP (classico, CUBIC) incrementa il rate di invio finché non c’è
una perdita nell’interfaccia di qualche router: il bottleneck link
 congestione: poniamo attenzione al bottleneck link congestionato

fatto: incrementare il rate di invio TCP

sorgente non aumenterà il throughout end- destinazione
end con il bottleneck congestionato
application application
TCP TCP
network network
link link
physical physical

fatto: incrementare il
rate di invio TCP
aumenterà l’RTT
misurato Goal: “tenere la pipe end-end quasi piena, ma non piena”

Livello di trasporto 3-102

 Controllo di congestione delay-based
Tenendo la coda “quasi piena, ma non piena”: mantiene il
bottleneck link al lavoro, ma evita elevati delay/buffering

# byte inviati
nell’ultimo
RTTmisurato throughput intervallo RTT
misurato =
RTTmisurato
Approccio delay-based :
 RTTmin - RTT minimo osservato (cammino non congestionato)
 il throughput non congestionato con finestra cwnd è cwnd/RTTmin
se il throughput misurato è “molto vicino” al throughput non congestionato
incrementa cwnd linearmente /* visto che il cammino non è congestionato */
se il throughput misurato è “molto al di sotto” del throughput non congestionato
decrementa cwnd linearmente /* visto che il cammino è congestionato */
Livello di trasporto 3-103
Controllo di congestione delay-based

 controllo di congestione senza arrivare alle perdite

 massimizzando il throughout (“tenendo la pipe quasi
piena… ”) tenendo il delay basso (“…ma non piena”)
 varie versioni di TCP hanno un approccio delay-based
 BBR utilizzato nella rete backbone (interna) di Google

Livello di trasporto 3-104

 Explicit Congestion Notification (ECN)
Le versioni di TCP spesso implementano il controllo di congestione
assistito-dalla-rete :
 due bit nell’header IP (campo ToS) marcati dal router per indicare congestione
• le policy per decidere la marcatura sono scelte dall’operatore di rete
 l’indicazione di congestione giunge alla destinazione
 la destinazione setta i bit ECE nel segmento di ACK per notificare alla sorgente la
congestione
 coinvolge sia l’IP (marcatura dei bit ECN nell’header IP) che il TCP (marcatura dei bit C,E
nell’header TCP)
sorgente segmento TCP di ACK
destinazione
application application
TCP ECE=1
TCP
network network
link link
physical physical

ECN=10 ECN=11

datagramma IP

Livello di trasporto 3-105

Equità di TCP
obiettivo di equità: se K sessioni TCP condividono lo
stesso link bottleneck con bandwidth R, ogni
sessione dovrebbe avere un rate di R/K

connessione TCP 1

router
bottleneck
con capacità R
connessione TCP 2

Livello di trasporto 3-106

Perché TCP è equo?
due connessioni:
 l’incremento additivo determina una pendenza pari a 1,
all’aumentare del throughout
 il decremento moltiplicativo riduce il throughput in modo
proporzionale
Condivisione equa
R dell’ampiezza di banda

perdita: riduce la finestra di un fattore 2

congestion avoidance: incremento additivo
perdita: riduce la finestra di un fattore 2
congestion avoidance: incremento additivo

R Livello di trasporto 3-107

Throughput della connessione 1
Equità (altro)
Equità e UDP Equità e connessioni TCP
 le applicazioni parallele
multimediali spesso  le applicazioni possono aprire
non usano TCP più connessioni parallele tra
 non vogliono che il due host
loro rate venga ridotto
dal controllo di  i web browsers lo fanno
congestione  es., link con rate R e 9
 utilizzano UDP: connessioni esistenti:
 immettono audio/video  se una nuova applicazione chiede 1
a frequenza costante, connessione TCP, ottiene un rate R/10
tollerano la perdita di  se la nuova applicazione chiede 11
pacchetti connessioni TCP, ottiene un rate
superiore a R/2

Livello di trasporto 3-108

 Evoluzione del transport-layer
 TCP, UDP: principali protocolli di trasporto per 40 anni
 vari “surrogati” di TCP sviluppati, per scenari specifici:

Scenario Sfide
Pipe lunghe e piene (grossi Molti pacchetti “in circolo”; le perdite
trasferimenti di dati) rallentano le pipe
Reti wireless Perdite dovute a link wireless rumorosi,
mobilità; il TCP le considera congestione
Long-delay link RTT estremamente lunghi
Reti di data center Sensibili alla latenza
Flussi di traffico background Dare una priorità più bassa

 spostare le funzioni del transport–layer nell’application layer,

utilizzando UDP
• HTTP/3: QUIC
Livello di trasporto 3-109
QUIC: Quick UDP Internet Connection
 protocollo dell’application-layer, che utilizza UDP
 incrementa le performance di HTTP
 utilizzato su molti server Google, app (Chrome, YouTube
app per mobile )

HTTP/2 HTTP/2 (snellito)

Application HTTP/3
TLS QUIC

Transport TCP UDP

Network IP IP

HTTP/2 sopra TCP HTTP/2 sopra QUIC sopra UDP

Livello di trasporto 3-110

QUIC: Quick UDP Internet Connection
adotta gli approcci visti in questo capitolo per la creazione della
connessione, controllo degli errori, controllo di congestione
• controllo di errori e di congestione : “I lettori familiari con la
rilevazione di perdite e il controllo di congestione del TCP
troveranno qui algoritmi che rispecchiano quelli del TCP.” [dalle
specifiche QUIC]
• apertura della connessione: affidabilità, controllo di
congestione, autenticazione, cifratura, e creazione della
connessione in un RTT

 “flussi” multipli nell’application-level multiplex-ati

su una singola connessione QUIC
 separa il trasferimento dati affidabile, la sicurezza
 usuale controllo di congestione

Livello di trasporto 3-111

QUIC: stabilire la connessione

handshake TCP
(transport layer) Handshake QUIC

dati
handshake TLS
(sicurezza)
dati

TCP (affidabilità, controllo di QUIC: affidabilità, controllo di

congestione) + TLS (autenticazione, congestione, autenticazione, cifratura
cifratura)
 1 handshake
 2 handshake in serie

Livello di trasporto 3-112

flussi QUIC: parallelismo e no blocco HOL

HTTP
GET
HTTP
application
GET
HTTP
GET

TLS encryption TLS encryption

TCP RDT TCP

error! RDT
transport

TCP Cong. Contr. TCP Cong. Contr.

(a) HTTP 1.1

Livello di trasporto 3-113
flussi QUIC: parallelismo e no blocco HOL

HTTP
GET HTTP
GET
HTTP
application

GET

QUIC QUIC QUIC QUIC QUIC QUIC

encrypt encrypt encrypt encrypt encrypt encrypt
QUIC QUIC QUIC QUIC QUIC QUIC
RDT RDT RDT error!
RDT RDT RDT

QUIC Cong. Cont. QUIC Cong. Cont.

transport

UDP UDP

(b) HTTP/2 con QUIC: nessun blocco HOL

Livello di trasporto 3-114
Capitolo 3: Riassunto
 principi alla base dei
servizi del livello di
trasporto:
 multiplexing, prossimamente:
demultiplexing  lasciare la “periferia”

 trasferimento dati della rete (livelli di

applicazione e di
affidabile trasporto)
 controllo di flusso  entrare nel “cuore”
 controllo di congestione della rete
 implementazione in
Internet
 UDP
 TCP Livello di trasporto 3-115