Gestione della Connessione in TCP

Riscontro e Ritrasmissione
I se m estre 02/03
Gestione della
Connessione in TCP
Š Per ogni segmento spedito la sorgente si aspetta di
ricevere un ACK
Prof. Vincenzo Auletta
„
Deve arrivare entro un tempo fissato
„
Al momento della trasmissione la sorgente fa partire un timer
„
Se il timer arriva a 0 il segmento è ritrasmesso
Š Gli ACK sono cumulativi
[email protected]
http://www.dia.unisa.it/~auletta/
„
„
Università degli studi di Salerno
Laurea e Diploma in Informatica
„
Interactive flow (rlogin, telnet)
„
Š L’applicazione produce i dati da spedire un po’ alla volta
Bulk data (ftp, mail)
Se si perde un riscontro viene coperto dal successivo
Ogni carattere viene inviato dal client al server un
byte per volta
Ogni carattere viene rispedito dal server al client per
la visualizzazione...(echo)
• Un byte genera 4 segmenti:
Š L’applicazione produce grossi volumi di dati
utilizzati algoritmi differenti
ottimizzare l’utilizzo della connessione
inferiore
• Telnet
due categorie
Š Vengono
identificatore
Applicazioni Interactive Flow
Š Le applicazioni che utilizzano TCP si dividono in
„
con
2
Flussi di Dati
„
Riscontra tutti gli ottetti
all’acknowledgement number
„
per
„
„
„
byte di dati (client ---> server)
ack del byte (server --> client)
echo del byte per visualizzazione (server --> client)
ack dell’echo (client ---> server)
• La maggior parte di questi segmenti contiene un
3
4
solo byte di dati (tinygrams)
„
40 byte di header
Riscontro Ritardato (Delayed
Ack)
Algoritmo di Nagle
• In genere TCP non invia l’ACK subito dopo aver
• I tinygrams creano grande congestione, soprattutto su
WAN
ricevuto un segmento
„
• Algoritmo di Nagle
ritarda nella speranza che vi siano dei dati che
viaggiano nella stessa direzione su cui si possa
effettuare il piggybacking
„
„
• La maggioranza delle implementazioni utilizza
un ritardo di 200 ms
I dati vengono accumulati e spediti in un unico segmento
quando arriva l‘ACK relativo ai dati in attesa
• È possibile disabilitare l’algoritmo di Nagle
5
„
Per dati che non possono essere ritardati
„
Con socket si usa l’opzione TCP_NODELAY
6
Calcolo del Timeout dell’ACK
Ambiguità dell’ACK
Š Il tempo di attesa di un ACK è variabile
Š Quando si verifica una ritrasmissione non si può
„
usare l’ACK per stimare il RTT
Il RTT dipende dal percorso seguito dal segmento
e dal traffico presente sulla rete
„
Š Il modulo software che implementa TCP
„
„
„
„
Fa una media di questi tempi per ottenere una
stima del RTT (round trip sample)
„
RTT = (α * old_RTT) + (1-α)* new_sample
timeout = β * RTT
β >= 2
ACK non riferito ad un segmento
Non sappiamo a quale trasmissione si riferisce
Š Algoritmo di Kahn
calcola per ogni segmento il tempo che
impiega l’ACK ad arrivare
7
se un endpoint ha grandi quantità di dati not ackwnoledged,
allora non può trasmettere tinygram
8
Ignora gli ACK relativi a dati ritrasmessi
Utilizza una backoff strategy per calcolare in nuovo
timeout
Riutilizza la stima del RTT quando arriva un nuovo
ACK relativo a dati non ritrasmessi
new_timeout = χ * timeout
χ=2
Stima accurata del RTT
Controllo del Flusso
Š L’algoritmo utilizzato da TCP per la stima del
Š TCP implementa un meccanismo di controllo del
RTT non è efficace in presenza di notevoli
variazioni dei ritardi effettivi
„
„
flusso
„
Usa solo la media
Bisogna calcolare sia la media che la varianza
Un endpoint può segnalare all’altro di rallentare o
accellerrare il tasso di trasmissione
Š Basato su tecnica della Sliding Window
Š Le nuove specifiche utilizzano una stima della
„
varianza per calcolare β
„
S_RTT = old_RTT + δ * (SMPL – old_RTT)
il trasmettitore può inviare più segmenti in sequenza
senza dover attendere l’ACK
Il ricevitore può segnalare al trasmettitore quanti
segmenti può inviare senza aspettare l’ACK
DEV = old_DEV + ρ(|SMPL – old_RTT)| –old_DEV)
9
timeout = S_RTT + µ * DEV
10
Dimensione della Finestra
Congestione sulla Rete
Š Il tempo di trasmissione di un segmento non
Š La dimensione della finestra è in byte, non in
dipende solo dal carico degli endpoint ma
anche dallo stato della rete
segmenti
„
Il campo “window” del pacchetto TCP indica lo spazio
disponibile nel buffer del ricevente per accomodare
dati
„
„
Š La dimensione della finestra cambia ad ogni
„
operazione sul flusso di dati
„
„
11
aumenta in corrispondenza di operazioni di read da
parte dell’applicazione
diminuisce in corrispondenza di ricezione di segmenti
TCP
I datagram IP attraversano vari router
Ogni router accoda tutti i datagram ricevuti e li
smista uno alla volta (store and forward)
All’aumentare del numero di datagram i router
rallentano e possono collassare
Š Gli endpoint non hanno modo di conoscere la
situazione dei router e l’istradamento dei
pacchetti
12
„
Vedono solo aumentare i tempi di trasmissione
Slow Start
Implementazione di Slow Start
Š Slow start utilizza la congestion window per
Š Per evitare di congestionare i router gli
calcolare il numero di segmenti da inviare
endpoint riducono il numero di segmenti spediti
sulla connessione
Š Algoritmo slow start
„
„
window = min(rwin, cwin*seg_size)
„
rwin è il controllo effettuato dal destinatario
Š espresso in byte
i segmenti non possono essere inviati più
velocemente di quanto vengono ricevuti gli ACK
„
cwin è il controllo effettuato dalla sorgente
Š espresso in segmenti
Š cwin è inizializzata a 1
„
13
14
Congestion Avoidance
Implementazione di Congestion
Avoidance
Š Lasciato
Š Congestion
senza
vincoli,
esponenzialmente fino a
dimensione di rwin
„
cwin
cresce
raggiungere la
Può saturare la memoria di un router
ACK o la ricezione di un ACK duplicato come
segnali di congestione
„
sorgente cerca di collaborare
eliminazione della congestione
„
„
La ricezione di pacchetti danneggiati è poco probabile
Š La
entra in uno stato di congestion avoidance
avoidance impedisce che la
della window aumenti troppo
dimensione
velocemente
Š Durante la fase di congestion avoidance cwin è
incrementato di 1/cwin per ogni ACK ricevuto
Š L’endpoint interpreta la mancata ricezione di un
15
„
Per ogni ACK ricevuto cwin = cwin + 1
Per ogni segmento non riscontrato cwin = 1
alla
16
Invece di 1
Congestion Avoidance & Slow
Start
Fast Retransmit and Fast
Recovery
Š TCP genera un ACK duplicato se i segmenti arrivano in
Š Per ogni connessione TCP mantiene due
ordine errato
variabili: cwin e tresh
„
„
„
„
Inizialmente cwin = 1 (segmento) e tresh = 65535
(byte)
Quando si verifica congestione poniamo tresh =
cwin/2
se è scaduto un timeout poniamo cwin = 1
„
segmento perso
„
segmenti arrivati in ordine errato
„
ricevente
invia
3 ACK duplicati sono forte indicazione che un segmento è
stato perso
Š fast retransmit: segmento perso ritrasmesso anche
Sindrome da Finestra Sciocca
senza attendere time-out
Š fast recovery: si attua congestion avoidance
Come Evitare la Sindrome
Š Ricevente
Š In alcune situazioni i due endpoint possono
trovarsi in situazioni in cui inviano piccoli
segmenti anche se hanno dati a disposizione
„
„
non deve annunciare valori piccoli
forzato ad aspettare valori decenti
Š Trasmittente non invia dati a meno che
Entrambi pubblicizzano piccoli valori nel campo
window dell’header
„
„
„
19
il
Š Algoritmo:
18
„
sequenza
Š ACK duplicato può essere dovuto a
Š se cwin < tresh implementa slow start
Š altrimenti implementa congestion avoidance
17
per ogni segmento fuori
immediatamente un ACK
20
un intero segmento può essere inviato
possiamo inviare almeno metà della massima finestra
annunciata
possiamo inviare tutto ciò che abbiamo
Dati Urgenti
Š TCP prevede la possibilità da parte di un
endpoint di segnalare all’altro endpoint che dei
dati urgenti sono stati inseriti nel flusso
„
„
Il flag URG segnala la presenza dei dati
Il campo URGENT POINTER indica la posizione dei
dati urgenti
Š Offset dal sequence number
„
Il destinatario può decidere come comportarsi
Š Segnala all’applicazione la situazione
Š Utilizzato dal server per segnalare al client
l’invio di dati
21
„
Anche se il client ha annunciato una window = 0