TCP-parte3

protocollo TCP
versioni e implementazioni
implementazioni
TCP implementations use Slow Start in as many as
three different ways:
(1) to start a new connection
(2) to restart transmission after a long idle period
(3) to restart transmission after a retransmit timeout
2
implementazioni (2)
If one segment is dropped from the initial window,
there are three different ways for TCP to recover:
1.
2.
3.
Slow-starting from a window of one segment, as is done
after a retransmit timeout, or after Fast Retransmit
Fast Recovery as is done after three duplicate ACKs
Fast Recovery with SACK, for TCP where both the sender
and the receiver support the SACK option
3
In generale
4
Evolution of TCP
5
Post 1990
6
politiche di trasmissione
7
politiche di trasmissione
●
cosa trasmettere
■
■
■
●
quando farlo
■
■
●
Sliding Window
ACK
SACK
timeout (RTO)
DupACK (#3)
come farlo
■
■
■
■
■
■
TCP-zero: No SS (Slow Start)
OldTahoe: SS + CA (CongestionAvoidance)
Tahoe: SS + CA + FR (Fast Retransmit)
Reno: SS + CA + FR + FRec (Fast Recovery)
Vegas: SS + CA + FRec + New FR
NewReno: SS + CA + FR + FRec (calcolo RTO più accurato)
8
versioni TCP
Meccanismi
OldTahoe
(1988)
Tahoe
(1988)
Reno
(1990)
SACK
(1996)
NewReno
(1996)
Stima varianza
RTT
X
X
X
X
X
Exp. backoff
X
X
X
X
X
Alg. Karn
X
X
X
X
X
Slow start
X
X
X
X
X
Dynamic
window
control
X
X
X
X
X
X
X
X
X+
X
X
X+
X
X?
Fast
retransmit
Fast recovery
Selective ACK
9
BSD pre-4.3 : nessun meccanismo di
controllo della congestione. Trasmette tanti
pacchetti quanti necessari a riempire la finestra
di ricezione. Stima del valore di RTT primitiva e
controllo di flusso tipo GoBack-N
BSD 4.3 Tahoe : calcolo di RTO con algoritmo
di Jacobson e introduzione delle tecniche di
controllo della congestione
BSD 4.3 Reno : Introduzione di Fast Recovery
BSD 4.4 : Multicasting e introduzione delle Long
Fat Pipes.
TCP Vegas : Nuovi meccanismi di stima per
RTT e gestione delle finestre di spedizione.
TCP Boston : TCP ottimizzato per reti ATM.
10
BSD 4.3 Tahoe
●
●
realizzata da Jacobson (1988)
meccanismi previsti:
■
■
■
■
■
■
Slow start
Congestion avoidance
Fast Retransmit
Variazioni all’algoritmo di stima RTT
Exponential Backoff per la trasmissione
Algoritmo di Karn
11
TCP Versions: Tahoe
set window to 1, and do slow start!
X
X
X
X
Sequence No
Time
12
performance di Tahoe
●
Tahoe TCP è sensibile alla perdita di pacchetti
■ Window Size is set to minimum value after packet
loss.
■ Every packet loss is assumed to be serious
congestion.
●
La perdita dell'1% dei pacchetti causa una
diminuzione del 50-75% del throughput
13
performance Tahoe
14
BSD 4.3 Reno
●
●
modifiche alla versione Tahoe di TCP, introdotte da Van
Jacobson nel 1990
presenta Fast Recovery
■ Timeout -> congestione rilevante
● cwnd al minimo. Slowstart
■ 3 DupACK -> congestione non grave
● … almeno tre pacchetti sono arrivati dopo quello perso
● cwnd dimezzata. Congestion avoidance
15
BSD 4.3 Reno
●
altre meccanismi
■
SLIP header compression
●
■
TCP header prediction
●
●
■
SLIP header compression, ottimizzazione della
dimensione dello header del pacchetto per comunicazioni
che non sfruttano le capacità del link (per esempio
Telnet) su collegamenti punto-punto
Seq ricevuto successivo all'ultimo: elaborazione veloce
Altrimenti: normale: ricostruzione dell'ordine
Path MTU discovery
16
TCP Versions: Reno
Recover 1 packet loss ok, but multiple loss => timeout
X
X
X
X
Now what? - timeout
Sequence No
Time
17
performance Reno
window
SS
time
CA
SS: Slow Start
CA: Congestion Avoidance
fast retransmission/fast recovery
18
Problemi di Reno
●
non riesce a recuperare una situazione di congestione in
cui più pacchetti di una stessa finestra di trasmissione
sono stati persi. In questo caso è costretto a ripartire con
Slow Start dopo lo scadere del timeout.
●
SACK può risolvere il problema, ma deve essere
implementato da mittente e destinatario
19
TCP Vegas
●
●
●
●
nuova soluzione (1994) per TCP, non inclusa nelle
varie versioni di BSD
sviluppato presso il Science Departement of Arizona
University da Brakmo e Peterson con il supporto di
National Science Foundation e ARPA.
evoluzione della versione Reno. Le modifiche
riguardano solo il lato mittente, portando un
incremento delle prestazioni pari al 40-70% (senza
sottrarre banda alle altre connessioni presenti)
Idea chiave: sfruttare l'RTT per prevenire le
congestioni. (Perché?)
20
TCP Vegas
●
cerca di prevenire la congestione, adattando la portata
dei dati in rete, in base alle variazioni della stima del
valore di RTT
●
Un aumento dell'RTT indica un 'allungamento' delle
code dei router
Slow start interrotta basandosi su RTT
Tentativo di utilizzare almeno una posizione nelle code
(ma non più di tre) durante congestion avoidance
●
●
21
TCP Vegas
22
BSD 4.4. NewReno
●
TCP Reno, presenta alcune lacune nella gestione di alcuni casi di congestione.
(perdite multiple)
●
nuova versione di TCP (NewReno) sviluppata dalla Berkeley University nel
1999.
●
si introduce lo stato 'fase di recupero' (Fast Retransmission Phase) nel quale
vengono spediti i pacchetti mancanti.
■
■
■
●
in questa fase, non vengono spediti nuovi dati fino a quando tutti i pacchetti rimasti
da confermare al momento della congestione, non siano stati ricevuti correttamente
dal destinatario.
Gli ACK ricevuti in tale fase, verranno considerati in maniera leggermente diversa dal
normale. Infatti, il numero di sequenza presente nell’ACK può solo confermare dei
pacchetti ritrasmessi nella fase di recupero e non quelli trasmessi prima della
congestione.
Questo tipo di gestione degli ACK va sotto il nome di partial ACK.
Se ci si trova di fronte alla perdita di più pacchetti in una finestra di spedizione,
si possono prendere in considerazione le opzioni SACK [RFC2582].
23
NewReno
Recover multiple losses in successive RTTs using notion of
“partial ack”. No timeout.
X
X
X
X
Now what? – partial ack
recovery
Sequence No
Time
24
SACK
X
X
X
X
Sequence No
Time
Now what? – send
retransmissions as soon
as detected
25
TCP e gestione delle code (queue)
●
●
Eliminazione della coda (tail drop)
■ Se la coda del router è piena vengono i
datagrammi vengono scartati
■ Rischio di 'sincronizzazione globale' (slow-start per
tutte le connessioni)
Scarto casuale anticipato (RED: random early drop)
■
■
■
Se la coda è piena il datagramma viene sempre scartato
Se la coda è quasi piena, il datagramma viene scartato con
probabilità legata allo spazio disponibile in coda
Utilizzo della media pesata dello spazio disponibile per
ignorare picchi istantanei
26
Varianti di RED
●
●
Stochastic Fair Blue
■ Simile a RED ma autoconfigurante (probabilità
modificata ogni volta che la coda è vuota o piena)
Weighted RED
■
●
Probabilità diverse secondo Type of Service
Adaptive / Active RED (ARED)
■
La lunghezza media della coda viene utilizzata per decidere
la rapidità di adattamento alle variazioni (parametri media
pesata)
27
Source Quench
●
●
●
In caso di congestione il router invia un messaggio
"ICMP Source Quench" al mittente.
Il mittente riduce (al minimo) la finestra
Contro:
■
●
In caso di congestione aumenta il traffico
Pro:
■
Individuazione delle congestioni rapida
28
Explicit Congestion Notification (ECN)
●
●
●
In caso di congestione il router imposta gli "ECN bit"
nell'IP header.
Il ricevente imposta "ECN echo"
Il mittente, dopo la ricezione di “ECN echo”, imposta
la finestra al minimo
29
Explicit Congestion Notification (ECN)
●
Contro
■
●
ECN è più lento di Source Quench.
Pros.
■
■
Può prevenire la perdita di pacchetti
Non aumenta il traffico
30
Problemi di TCP in reti a banda larga
●
Dimensioni delle code dei router
■
●
Dimensioni dei buffer di spedizione e ricezione
■
●
Possono causare perdite di pacchetti
I dati da spediti devono essere conservati fino ad ACK
Wireless:
■
TCP potrebbe confondere la perdita di pacchetti dovuta a
problemi radio con problemi di congestione
●
●
Diminuzione non necessaria della velocità di trasmissione
Difficoltà a ripristinare la velocità ottimale
31
FAST (FAST AQM Scalable TCP) TCP
●
●
●
●
Congestion Avoidance per Long fat network (alto
valore bandwidth*delay)
Modifiche sender side
Usa RTT in modo simile a Vegas
Obiettivo:
■
●
Mantenere costante il numero di 'flying bits'
Problemi:
■
Coesistenza con versioni di TCP 'loss based': viene
prevenuta al congestione a vantaggio di chi non la previene
32
H TCP
●
Loss-based, additive increase, mult decrease
●
Il rate di incremento addittivo aumenta al passare del
tempo dal precedente loss
●
Unfair....
33
TCP Illinois
34
Scalable TCP
35
Westwood (+)
●
●
Variante di NewReno, modifiche solo al mittente
Pensato per
■
■
■
●
●
●
Cammini con alti valori banda*latenza (large pipes)
Potenziali perdite di dati (leaky pipes)
Carico variabile (dynamic pipes)
Agile probing (modifica di slow start)
Eligible Rate basata su rate di ricezione ACK
■ Utilizzata nel calcolo di ssthresh e cwin
Persistent Non Congestion Detection (PNCD)
■
'Accellera' in caso di mancata congestione
36
Westwood (+)
37
versioni commerciali di TCP/IP
●
●
●
Windows
Linux
MacOS
38
Windows
●
●
Network Device Interface (NDIS) :
interfaccia posta tra il livello 2 e 3
del modello OSI.
Transport Driver Interface
Specification (TDI) : interfaccia per
il livello 4 del modello OSI.
■
utilizzo di Selective ACK [RFC2018] ed
estensioni di TCP per ottenere alte
prestazioni [RFC1323].
39
Windows (2)
●
●
●
Keep-Alive Messages : vengono scambiati dei messaggi tra i due
host in comunicazione per sapere se sono ancora connessi.
Time-wait Delay : nella fase di chiusura della connessione,
prima di terminare la comunicazione, si deve attendere un
tempo pari a 2MSL. In Windows 2000, questo tempo viene
fissato per default a quattro minuti
Calcolo dimensione di Receiver Window e Scaling Window
meccanismi che permettono la spedizione di dati in reti molto
performanti e con grandi periodi di latenza
■
è possibile specificare un fattore di scala che può portare la
dimensione massima di un pacchetto, a uno, due o più volte il
limite massimo convenzionale di 64KByte.
40
Windows (3)
●
●
●
●
Delayed ACK : per ridurre il numero di pacchetti spediti, si utilizza
una tecnica che attende un certo periodo di tempo, prima di
inviare gli ACK, sfruttando la possibilità di utilizzare gli ACK
cumulativi. In generale, per verificare l’arrivo di un nuovo
pacchetto da confermare, si attendono 200ms.
Selective ACK : è previsto l’utilizzo della tecnica di Selective ACK.
Agli header vengono aggiunti 2 byte per ospitare tale opzione.
Timestamps : ad ogni pacchetto spedito, vengono allegate delle
informazioni sul momento esatto di trasmissione, in modo tale da
permettere una accuratezza maggiore nel calcolo del valore di
RTT.
Meccanismi di controllo della congestione : Slow start,
Congestion Avoidance, Fast Retransmit e Fast Recovery
analogamente alla versione Reno di TCP.
41
Macintosh
●
●
●
In MacOS X, è stato utilizzato un sistema di
comunicazione interamente basato sul NetBSD 4.4
versione NewReno, con funzionalità per Long Fat
Pipes (analogo a Window Scaling) e nuove
metodologie di calcolo del valore di RTT basate su
timestamp.
Vengono inoltre implementate le direttive per un
protocollo TCP ad elevate performance [RFC1323]
42
UNIX
●
●
gli ambienti UNIX come Linux, Solaris, e tutte le
versioni commerciali, utilizzano come punto di
riferimento le versioni di BSD, contenute nelle diverse
distribuzioni (NetBSD, OpenBSD, FreeBSD).
La differenza di implementazione fra i vari sistemi
operativi è pressoché minima e, come MacOS X, tutte
basate sulla versione 4.4 di BSD.
43
Linux
sysctl -w net.ipv4.tcp_congestion_control=westwood
oppure
echo "westwood" > /proc/sys/net/ipv4/tcp_congestion_control
Oppure (modifica permanente)
In /etc/sysctl.conf
net.ipv4.tcp_congestion_control=westwood
44