TCP: Transport Control Protocol - INFN-CNAF

TCP: Transport Control Protocol 

Tiziana Ferrari, 

INFN-CNAF 

Tiziana.Ferrari@cnaf.infn.it 

Tiziana Ferrari Reti di telecomunicazione, Anno Acc. 2003/2004 1

Indice 

• Caratteristiche principali del protocollo TCP 

• Multiplexing di connessioni 

• Affidabilita’ (reliability) 

• Controllo e prevenzione di congestione: 

– Congestion control 

– Congestion avoidance 

• Ottimizzazioni del protocollo 

– Algoritmi di fast recovery e fast retransmit 

– Silly window syndrome 

– Delayed acknowledgement 


• 1 Basic Data Transfer 

• 2 Reliability Flow Control 

• 3 Multiplexing 

• 4 Connections 

• 5 Precedence and Security 

• (*) RFC: Request For Comment 

TCP secondo l’RFC 793 (*) 


TCP secondo l’RFC 793 (1) 

• Basic Data Transfer: 

– The TCP is able to transfer a continuous stream of octets in 

each direction between its users by packaging some number 

of octets into segments for transmission through the internet 

system. In general, the TCPs decide when to block and 

forward data at their own convenience. Sometimes users 

need to be sure that all the data they have submitted to the 

TCP has been transmitted. For this purpose a push function is 

defined. To assure that data submitted to a TCP is actually 

transmitted the sending user indicates that it should be 

pushed through to the receiving user. A push causes the 

TCPs to promptly forward and deliver data up to that point to 

the receiver. The exact push point might not be visible to the 

receiving user and the push function does not supply a record 

boundary marker. 



• Reliability: 

– The TCP must recover from data that is damaged, lost, 

duplicated, or delivered out of order by the internet 

communication system. This is achieved by assigning a 

sequence number to each octet transmitted, and requiring a 

positive acknowledgment (ACK) from the receiving TCP. If 

the ACK is not received within a timeout interval, the data is 

retransmitted. At the receiver, the sequence numbers are used 

to correctly order segments that may be received out of order 

and to eliminate duplicates. Damage is handled by adding a 

checksum to each segment transmitted, checking it at the 

receiver, and discarding damaged segments. As long as the 

TCPs continue to function properly and the internet system 

does not become completely partitioned, no transmission 

errors will affect the correct delivery of data. TCP recovers 

from internet communication system errors. 


• Flow Control: 


– TCP provides a means for the receiver to govern the amount 

of data sent by the sender. This is achieved by returning a 

"window" with every ACK indicating a range of acceptable 

sequence numbers beyond the last segment successfully 

received. The window indicates an allowed number of octets 

that the sender may transmit before receiving further 

permission. 


• Multiplexing: 


– To allow for many processes within a single Host to use TCP 

communication facilities simultaneously, the TCP provides a 

set of addresses or ports within each host. Concatenated with 

the network and host addresses from the internet 

communication layer, this forms a socket. A pair of sockets 

uniquely identifies each connection. That is, a socket may be 

simultaneously used in multiple connections. The binding of 

ports to processes is handled independently by each Host. 

However, it proves useful to attach frequently used processes 

(e.g., a "logger" or timesharing service) to fixed sockets 

which are made known to the public. These services can then 

be accessed through the known addresses. Establishing and 

learning the port addresses of other processes may involve 

more dynamic mechanisms. 



• Connections: 

– The reliability and flow control mechanisms described above 

require that TCPs initialize and maintain certain status 

information for each data stream. The combination of this 

information, including sockets, sequence numbers, and 

window sizes, is called a connection. Each connection is 

uniquely specified by a pair of sockets identifying its two 

sides. When two processes wish to communicate, their TCP's 

must first establish a connection (initialize the status 

information on each side). When their communication is 

complete, the connection is terminated or closed to free the 

resources for other uses. Since connections must be 

established between unreliable hosts and over the unreliable 

internet communication system, a handshake mechanism 

with clock-based sequence numbers is used to avoid 

erroneous initialization of connections. 



• Precedence and Security: 

– The users of TCP may indicate the security and precedence 

of their communication. Provision is made for default values 

to be used when these features are not needed. 


Le funzioni di TCP nel dettaglio 

• Scambio di informazioni di controllo tra mittente e destinatario 

• Affidabilita’ (reliability): dato un sistema trasmissivo inaffidabile – cioè 

soggetto ad errori di trasmissione e a perdita di unità di dati – viene simulata 

l’affidabilità attraverso la ritrasmissione delle unità di dato perse. Ciò avviene 

attraverso 

1. identificazione della perdita di messaggio 

2. segnalazione dell’avvenuta perdita attraverso il meccanismo di positive 

acknowledgement: periodicamente il destinatario comunica il numero di 

sequenza dell’ultimo byte ricevuto 

• Identificazione dell’esatto processo di destinazione presente sull’end-node 

ricevente (piu’ processi possono ricevere dati in modo concorrente) 

• Controllo di congestione 

• Prevenzione della congestione 

• Unita’ dati TCP: l’unita’ di dati generata dal protocollo TCP (e poi 

incapsulata in un messaggio IP) viene detta segmento 


Caratteristiche generali 

• Viene creata una connessione virtuale tra mittente e destinatario 

attraverso lo scambio di informazioni di controllo (fase di call 

set-up). 

• La creazione della connessione è seguita dalla fase di 

trasferimento dati vera e propria. Durante la trasmissione il 

protocollo TCP continua a scambiare informazioni di controllo. 

La connessione e’ di tipo bidirezionale: una direzione viene 

utilizzata per scambiare i byte di informazione utile (mittente 

→destinatario), mentre la direzione opposta viene utilizzata 

esclusivamente per lo scambio di informazione di controllo 

(destinatario → sorgente) 

• Per le applicazioni di natura interattiva in cui deve essere 

minimizzato il ritardo di ricezione delle unità di dato (e.g. 

telnet), viene forzato l’invio di pacchetti non appena è 

disponibile qualche byte di informazione (meccanismo di data 

push) 


Send e receive buffer 

• Si dice “buffer” un’area della memoria dell’applicazione che contiene i dati 

da scambiare tra mittente e destinatario. I dati vengono mano mano copiati - 

in unità di memoria di dimensione configurabile da parte di una applicazione 

- nell’area di memoria del sistema operativo attraverso la system call write(). 

Per ottimizzare il rapporto tra le informazioni di controllo poste 

nell’intestazione e la quantità di byte di dati disponibili nell’area data, un dato 

messaggio vene inviato soltanto nel momento in cui la parte di dati 

disponibile nel buffer eccede una data soglia configurabile. 

• Send buffer: area di memoria in cui TCP pone i messaggi in attesa di 

trasmissione; il send buffer è anche detto “send socket buffer”. 

• Receive buffer: area di memoria del sistema operativo in cui TCP pone i 

messaggi ricevuti; il receive buffer è anche detto “receive socket buffer” 

• Per ogni nuova connessione vengono allocati una nuova coppia di send e 

receive buffer 


Send e receive buffer (cont) 

Applicazione 1 Applicazione n 

dati ... dati 

write() write() 

SEND SOCKET 

RECEIVE SOCKET 

AREE DI MEMORIA 

DELLE APPLICAZIONI 

AREA DI MEMORIA 

DELLE SISTEMA OPERATIVO 

Connessione 1 

Connessione n 


Segmento 

• Viene definita segmento la parte dati di una unita’ di 

trasmissione del protocollo TCP . 

• Viene definito messaggio l’unione del segmento e 

dell’intestazione TCP. 

dati 

SEGMENTO TCP 

MESSAGGIO TCP 

Intestazione TCP 

• La dimensione massima di un segmento e’ pari alla dimensione 

massima del pacchetto IP, esclusi i byte dell’intestazione TCP e 

IP. Essa viene definita Maximum Segment Size (MSS): 

MSS = MTU – sizeof(TCP header) – sizeof(IP header) 


Intestazione TCP: formato 

Source port Destination port 

Sequence number 

Acknowledgement number 

Offset Reserved Code Window 

Checksum Urgent pointer 

Options Padding 

Data 

... 

0 8 16 31 

Source/destination port: identificazione dell’applicazione mittente/ricevente attive 

rispettivamente sul nodo mittente IP_source e nodo destinatario IP_dest 

Sequence number: numero di sequenza del primo byte del campo Data 

nell’ambito del flusso di byte generati dalla sorgente (ne identifica la posizione) 

Acknowledgement number: numero di sequenza del primo byte di dati atteso. Tale 

numero corrisponre al numero di sequenza successivo al numero di sequenza 

dell’ultimo segmento correttamente ricevuto. Il numero di sequenza si riferisce al 

flusso generato nel senso opposto del traffico (gli ackknowledgement sono generati sempre 

dal ricevente di un dato stream e quindi viaggiano nel senso inverso del flusso dati). 


Intestazione TCP: formato (cont) 

Offset: indica la dimensione della porzione Data del segmento TCP 

Reserved: campo non specificato, riservato ad usi futuri 

Code: codice che identifica la funzione del segmento (e.g. Segmento di apertura di 

una connession: SYN, segmento di chiusura: FIN, segmento dati, segmento 

che include esclusivamente informazione di acknowledgement 

URG: urgent pointer set, il segmento non è soggetto a buffering al lato ricevente 

ACK: campo ACK valido 

PUSH: il segmento non è soggetto a buffering al lato mittente 

RST: reset della connessione 

SYN: synchronize sequence numbers 

FIN: il mittente ha raggiunto la fine del byte stream generato dalla 

applicazione 

Window: il mittente/ricevente comunica al ricevente/mittente la quantità di 

memoria disponibile per momorizzare dati 

Options: le opzioni servono per scambiare specifici elementi di informazione tra 

mittente e destinatario, come il Maximum Segment Size (la massima dimensione 

del segmento che può essere accettata) 

Checksum: controllo d’errore applicato alla sola intestazione TCP (non alla parte 

data), per il calcolo del codice di controllo d’errore si assume che il campo 

checksum contenga una stringa di 0 


Multiplexing di connessioni 

• Il multiplexing di connessioni consiste nella possibilita’ di stabilire molteplici 

connessioni TCP concorrenti in trasmissione o ricezione in un dato nodo. 

A questo scopo, vengono utilizzate le porte TCP: ogni punto terminale di 

una connessione in un dato host H e’ definito da un coppia di 

identificatori detta socket cosi’ formata: 

Socket = (TCP port, IP address(H)) 

Dunque una connessione TCP tra due nodi H1 e H2 e’ identificata dalla 

coppia di socket: 

Connessione = ( TCP source port, add(H1), TCP destination port, add(H2) ) 

Dunque in un dato istante un socket puo’ essere utilizzato da piu’ di una 

connessione: es. il socket associato ad un www server o ad un ftp server. 

131.154.3.1 

Sock1=(port1, 131.154.3.1) 

131.154.3.41 

Sock2=(port2, 131.154.3.41) 

Sock4=(port4, 131.154.3.10) 

Sock3=(port3, 131.154.3.41) 

Sock5=(port5, 131.154.3.10) 

conn3 

conn1 

conn2 

131.154.3.10 

Conn1=(sock1, sock4) 




Affidabilità 


P1 

MITTENTE 

RICEVENTE 

s1 

P2 

s2 

P3 

Positive acknowledgement 

s3 

P4 

s4 

P5 

P1 P2 P3 P4 

timeout 

P4 P5 

s5 

ACK(s1+1) ACK(s2+1) ACK(s3+1) ACK(s3+1) ACK(s3+1) 

ACK duplicati 

Numero di sequenza del byte 

Sn: numero di sequenza dell’ultimo byte dell’n-esimo messaggio; il numero di sequenza 

Iniziale del primo byte nel flusso di dati viene definito in fase di call set-up 

Svantaggio: ritardo tra la trasmissione di un messaggio e il successivo derivante dall’attesa 

dell’acknowledgement 

Tiziana Ferrari Reti di telecomunicazione, Anno Acc. 2003/2004 19 

t 

t

Sliding window 

• Ottimizzazione dell’algoritmo di positive acknowledgement in cui il mittente 

e’ autorizzato ad inviare m pacchetti (n byte) prima di porsi in attesa della 

ricezione dell’acknowledgement relativo al primo messaggio inviato. 

• n rappresenta la dimensione della window, ovvero la quantita’ di dati che il 

mittente e’ autorizzato ad inviare dopo essersi posto in attesa dell’ack del 

primo messaggio della window stessa 

• Nel caso in cui il tempo che intercorre tra l’invio del primo messaggio e la 

ricezione del relativo acknowledgement sia piccolo, il mittente può inviare 

dati in modo continuativo senza mai sperimentare periodi di inattività che 

limitano le prestazioni dell’applicazione. 

• Il fenomeno contrario, in cui il mittente trascorre la maggior parte del tempo 

attendendo la ricezione dell’ack (per esempio su connessioni ad elevato 

tempo di propagazione, come nelle connessioni satellitari) viene detto: stopand-wait. 

• Il ricevente deduce la presenza di un messaggio perso nel caso in cui ack(Sn) 

non sia ricevuto entro un intervallo prestabilito, al termine del quale si 

procede con la ritrasmissione. La durata ottimale di tale timeout viene 

determinata stimando la media e la variazione del ritardo che intercorre tra la 

trasmissione di un messaggio e la ricezione del corrispondente 

acknowledgement (Round Trip Time) 


100by 

P1 P2 

Sliding window (cont) 

Ipotesi: ogni messaggio ha lunghezza costante di 100 by, la dimensione della window e’ 

costante e pari a 400 by. 

200by 300by 400by 

P3 P4 P5 P6 

timeout 

500by 600by 700by 

800by 

P4 P5 

P6 P7 P5 

t 

ACK(s1) ACK(s2) ACK(s3) ACK(s3) ACK(s3) ACK(s4) ACK(s5) ACK(s6) ACK(s7) 

Sn: numero di sequenza dell’ultimo byte dell’n-esimo messaggio; il numero di sequenza 

Iniziale del primo byte nel flusso di dati viene definito in fase di call set-up 


t 

by

AL LATO MITTENTE: 

acked 

Terminologia 

1 2 3 4 

Byte sequence number 

• 1: sequence number vecchi che hanno già ricevuto un acknowledgement 

• 2: sequence number che non hanno ancora ricevuto un acknowledgement 

• 3: sequence number di pacchetti che non sono stati ancora trasmessi ma che 

posono essere trasmessi essendo essi all’interno della window (SEND 

WINDOW) 

• 4: sequence number futuri relativi a dati che non possono essere trasmessi, 

essendo essi esterni alla window 

AL LATO RICEVENTE: 

not acked send window 

window 

1 2 3 

receive window 

Byte sequence number 

acked Seq number non ancora autorizzati 

• 1: sequence number di pacchetti di cui è già stato inviato l’ack 

• 2: spazio di memoria disponibile per la ricezione di nuovi dati (RECEIVE 

WINDOW) 

• 3: sequence number futuri che non sono ancora ammessi 


Terminologia (cont) 

• offered window: la dimensione della finestra segnalata dal 

ricevente. L’offered window varia nel tempo, il valore massimo 

equivale alla dimensione di memoria disponibile per la 

memorizzazione di dati. 

• Usable window: min [send window, offered window] 


Controllo e prevenzione della congestione 


Controllo della congestione 

• Per scoprire la presenza di un punto di congestione sul cammino 

di collegamento di due end-node, utilizzando un metodo che 

NON introduca traffico di monitoraggio aggiuntivo, può essere 

sufficiente effettuare una stima del ritardo di propagazione di un 

messaggio sul cammino (mittente → destinatario → mittente): 

RTT (Round Trip Time) 

• Acknowledgement: messaggio inviato dal destinatario alla 

sorgente per segnalare che un dato messaggio M i e’ stato 

ricevuto correttamente 

• Data una stima del round trip time RTT, se dopo RTT sec 

ack(M i ) non e’ stato ancora ricevuto si assume che M i sia stato 

perso e si procede con la ritrasmissione e la fase di controllo 

della congestione 


One-way delay e RTT 

• One-way delay: tempo che intercorre tra l’istante in cui l’ultimo bit del 

messaggio viene trasmesso e l’istante in cui il primo bit raggiunge la 

destinazione remota (one-way delay ∼ RTT/2) 

• data una connessione con n hop, detta L i la latenza dovuta alla 

memorizzazione e al forwarding del messaggio introdotta dall’i-esimo router, 

M la dimensione del messaggio, C i e prop i rispettivamente la capacita’ dell’iesimo 

link di output e il tempo di propagazione del segnale fisico nel mezzo 

trasmissivo: 

1-way Delay = ∑ ( M/ C i + L i + prop i ) 

• Connessioni dominate dal delay: 

Si tratta delle connessioni in cui il RTT e’ principalmente dovuto al tempo di 

propagazione fisica del segnale e dal tempo dovuto alle operazioni di 

memorizzazione e di forwarding nei router 

Es: connessioni intercontinentali caratterizzate da un numero elevato di hop 

• Connessioni dominate dalla capacita’ dei link di collegamento: 

Si tratta delle connessioni caratterizzate da link a bassa velocita’, per le quali 

il RTT di un messaggio e’ fortemente influenzato dalla dimensione media 

del messaggio stesso, cioe’ 1-way delay e’ demoniato dal termine M/ C i 

(Es: connessioni ISDN) 


Stima del Round Trip Time (RTT) 

• Componente dell’algoritmo di ritrasmissione necessaria per prevedere il 

tempo necessario di ricezione di un acknowledgement; é importante non 

sottostimare RTT per evitare ristrasmissioni nel caso di aumento del tempo di 

trasmissione dovuto ad un aumentato carico di traffico 

• Smoothed RTT (SRTT): 

SRTT(i) := α SRTT(i-1)+(1- α)M 

– α: filtro, valore raccomandato 0.90 

– M: misura relativa al messaggio di cui si e’ ricevuto l’ack piu’ recente 

• Retransmit timeout interval I: 

I = min[lim SUP , max [lim INF , (β *SRTT)]] 

– β: fattore di varianza del delay (es. β =2 per un carico di traffico ≤ 30% 

capacita’ di linea) 

– lim SUP : limite superiore dell’intervallo (es. 1 min) 

– lim INF : limite inferiore dell’intervallo (es. 1 sec) 


Meccanismi di controllo di flusso 

• Si dividono in due gruppi: 

– Congestion control → (implementato dall’algoritmo “slow 

start”), serve per fronteggiare situazioni di congestione grave, 

ovvero quando scade il timeout al lato mittente. E’ 

caratterizzato da un incremento esponenziale della usable 

window. 

– Congestion avoidance → viene adottato in assenza di 

congestione grave, ovvero solo in presenza di 

acknowledgement duplicati. Permette un incremento 

graduale della usable window (lineare) 


Congestion Control (Slow Start) e Congestion Avoidance: meccanismo di base 

Connection opening : cwnd = 1 segment 

Slow Start 

Exponential 

increase for cwnd until 

cwnd = SSTHRESH 

Retransmission timeout 

SSTHRESH:=cwnd/2 

cwnd = SSTHRESH 

Retransmission timeout 

SSTHRESH:=cwnd/2 

cwnd:= 1 segment 

•Exponential increase for cwnd : 

for every useful acknowledgment received, cwnd := cwnd + (1 segment size) 

Congestion Avoidance 

Additive 

increase for cwnd 

•Additive increase for cwnd : 

for every useful acknowledgment received, cwnd := cwnd + (segment size)*(segment size) / cwnd 

it takes a full window to increment the window size by one. 


CONGESTION CONTROL 



Slow start 

TCP entra nella fase slow start ogni volta che viene riscontrata la perdita di un 

messaggio (cioè come conseguenza dello scadere di un timeout). TCP è nella 

fase di Slow start anche inizialmente, in apertura della connessione, e ogni 

qual volta una connessione TCP viene riattivata dopo un periodo di pausa 

La fase slow start serve per limitare il numero di pacchetti in transito tra la 

sorgente e il destinatario in presenza di congestione oppure inizialmente, 

quando deve essere ancora determinata la frequenza di trasmissione dei 

pacchetti ottimale, per incrementare in modo graduale la frequenza di 

trasmissione 

IMPLEMENTAZIONE: viene utilizzata una variabile chiamata “congestion 

window” (indicata con la sigla: cwind). Cwind è un parametro il cui 

valore varia durante le varie fasi di un trasferimento TCP secondo le 

seguenti regole: 

• all’inizio e per ogni restart di una trasmissione: cwind=1 

• ∀ack ricevuto: cwind=cwind+const (e.g. const=1) 

• Usable Window = min (cwind, RCV advertized window) 

Il tempo necessario affinché cwind raggiunga una ampiezza pari a W 

(supponendo che W sia espresso in pacchetti) varia secondo la regola: 

time = RTT * log2 W 



• Vantaggi: 

Slow Start (cont) 

– non vengono inviati burst (=sequenze di pacchetti affiancati) che 

peggiorano la situazione di congestione nei colli di bottiglia della rate e 

nei router che iniettano traffico da una interfaccia I di input ad una di 

output O, dove 

capacita(I) > capacita(O) 

• Svantaggi: 

– Poiché la window viene ridotta di dimensione in presenza di congestione, 

in caso di elevata percentuale di pacchetti persi (packet loss) la 

connessione non è mai in grado di sfruttare pienamente la banda 

disponibile su alcuni tratti della rete 

– In caso di connessioni ad alto tempo di propagazione (RTT >>, per 

esempio su link satellitari, in cui il tempo di propagazione e’ la 

componente più significativa della latenza end-to-end), la durata della 

fase slow start è considerevole, con un conseguente calo delle prestazione 

e una latenza superiore necessaria per raggiungere uno stato di 

“equilibrio” 



Cwin=1 

P1 

Ack(P2) 

Cwin=3 

Ack(P4) 

Cwin=5 

Ack(P3) 

Cwin=4 

P4 P5 P6 P7 

Ack(P5) 

Cwin=6 

Ack(P6) 

Cwin=7 

Ack(P7) 

Cwin=8 

Esempio 

RTT 

Packet Time: intervallo di tempo fra 2 pacchetti consecutivi 

P8 P9 P10 P11 P12 P13 P14 P15 

Ack(P1) 

Cwin=2 

P2 P3 

Ack(P8) 

Cwin=9 


t 

t 

t

CONGESTION AVOIDANCE 



Congestion avoidance 

• TCP si trova nella fase di congestion avoidance quando raggiunge una situazione di 

equilibrio (cioè TCP non è soggetto a perdita di pacchetti). In questa fase TCP tenta 

ancora di aumentare il parametro cwind allo scopo di verificare la possibilità di 

aumentare la frequenza di trasmissione dei pacchetti per raggiungere la MASSIMA 

frequenza trasmisssiva ammessa dai link di collegamento presenti nel cammino tra la 

sorgente e il destinatario. 

• AUMENTO DELLA FREQUENZA TRASMISSIVA: 

Nella fase di congestion avoidance il parametro cwind viene aumentato in modo più 

lento e graduale, per esempio facendo in modo che anziché incremenatare 

esponenzialmente nel tempo (come nella fase di slow start), l’aumento sia 

lineare. 

In fase slow start: 

∀ack ricevuto, cwind=cwind+const 

In fase di congestion avoidance: 

∀ack ricevuto, cwind = cwind + const/cwind 

1. const = 1 // se cwin espresso in numero di segmenti 

2. const = MSS*MSS // cwin espresso in byte 

ovvero ad ogni scadere di 1 RTT, cwind aumenta all’incirca di 1 messaggio. Lo 

scopo e’ quello di evitare la sovrastima della banda disponibile per non entrare 

nuovamente nella fase di slow start. 


Congestion avoidance (cont) 

• DIMINUZIONE DELLA FREQUENZA TRASMISSIVA: 

1. In presenza di ack duplicati (ack del medesimo sequence number S i ) la 

window size viene ridotta secondo la regola moltiplicativa: 


cwindi = d * cwindi-1 (d < 1, e.g. 1/2) 

cwind e’ espresso in byte 

2. In presenza di un timeout che scade si passa alla fase di slow start: 

cwind=1 

In caso di congestione persistente la formula al punto 1. produce un effetto 

di decrescita esponenziale nel tempo del parametro (essendo applicata ad 

ogni messaggio iterativamente) 

Anche in fase di congestion avoidance, in ogni istante: 

W = min(cwind, RCV advertized win) 


CONGESTION AVOIDANCE ↔ CONGESTION CONTROL 

• Come si passa dalla fase di congestion control a quella di 

congestion avoidance e viceversa? 

Si utilizza una variabile (threshold T) tale che: 

– Inizialmente T=64 KB 

– Se cwind < T: TCP in fase di slow start (congestion control) 

– Se cwind ≥ T: TCP in fase di congestion avoidance 

• Quando si passa dalla fase di congestion avoidance a quella di 

congestion control? 

Al lato mittente ogni qual volta scade un timeout, il parametro 

T viene dimezzato: T := cwind/2, e cwind=1 

A questo punto comincia la fase di slow start. 


Slow start e congestion avoidance: esempio 

SSTHRESH 

Slow start Congestion Avoidance 

•Slow start : incremento rapido di cwnd 

•Congestion Avoidance : incremento piu’ lento della cwnd 

Cwnd average of the last 10 samples. 

Cwnd average over the life of the connection to 

that point 


Slow start 

Infulenza del parametro threshold T sulle prestazioni 

Congestion avoidance 

SSTHRESH = 730Kbyte 

SSTHRESH = 1460Kbyte 

Durante la fase di congestion avoidance e in assenza di perdite di paccheti, cwnd incrementa di un 

segmento per ogni RTT. Nel nostro caso, essendo tutti i pacchetti ricevuti correttamente, la window 

incrementa di 1460 byte (supponendo una MTU di 1500 by) ogni 175 ms. 

Se la cwnd e’ pari a 730 kbyte, sono necessari almeno 4 minutes per ottenere una cwnd piu’ larga dek 

prodotto bandwidth*delay (nel nostro esempio pari a 2,65 MByte). In altri termini, sono necessari 

almeno 4 min per ottenere un pieno utilizzo della banda. 


Oscillazioni di cwnd in caso di perdita di pacchetti 

1) A packet is lost 

2) Fast Recovery 

(Temporary state to repair the 

lost) 

New loss 

Cwnd when packets are lost because the window size is too large 

Losses occur 

when the cwnd is 

larger than 3,5 

Mbyte 

Nei casi in cui la cwnd e’ in grado di superare il bandwidth-delay product, possono verificarsi 

perdite di dati che comportano un abbassamento delle prestazioni. Nell’esempio illustrato dal 

grafico, la cwnd supera il bandwidth delay product e il throughput medio (dati trasmessi/tempo) 

viene drasticamente ridotto. Le perdite sono dovute all’insufficiente quantita’ di memoria in una o 

piu’ code trasmissive lungo il cammino tra il mettente e il ricevente. 


Linux 2.4: Auto-tuning 

• In nel kernel Linux 2.4, TCP adotta dei meccanismi di adattamento dinamico 

della dimensione dei socket buffer (da cui dipende cwnd) in funzione della 

banda disponibile tra una data coppia di nodi. 

• Se l’applicazione setta esplicitamente le dimensioni dei socket attraverso la 

funzione setsocketopt(), allora auto-tuning e’ disabilitato. 

• La dimensione dei socket buffer dipende da: 

– La domanda di memoria kernel (in caso di penuria di memoria la 

dimensione dei socket viene limitata o addirittura ridotta) 

– Un insieme di parametri del kernel che regolano il meccanismo di autotuning 

(vedi slide successiva) 

• Linux 2.4 duplica l’ammontare di memoria richiesta da una applicazione 

attraverso la funzione setsocketopt() 

• Linux 2.4 limita la dimensione di cwnd (cwnd moderation) attraverso la stima 

in ogni istante della quantita’ di pacchetti in viaggio verso il ricevente (di cui 

il mittente non ha ancora ricevuto il corrispondente ACK). In questo modo 

non viene ecceduto il prodotto bandwidth*delay e vengono minimizzati 

fenomini di elevato ritardo e perdita dovuti all’accodamento. 


Parametri TCP nel Kernel Linux 

• Linux Cross Reference 

(http://www.iglu.org.il/lxr/source/Documentation/networking/ip-sysctl.txt) 

• tcp_wmem – vector of 3 INTEGERs: min, default, max 

– min: Amount of memory reserved for send buffers for TCP 

socket. Each TCP socket has rights to use it due to fact of its 

birth. Default: 4K 

– Default: Amount of memory allowed for send buffers for 

TCP socket by default. This value overrides 

net.core.wmem_default used by other protocols, it is usually 

lower than net.core.wmem_default. Default: 16K 

– max: Maximal amount of memory allowed for automatically 

selected send buffers for TCP socket. This value does not 

override net.core.wmem_max, "static" selection via 

SO_SNDBUF does not use this. Default: 128K 


Parametri TCP nel Kernel Linux (cont) 

• tcp_rmem - vector of 3 INTEGERs: min, default, max 

• min: Minimal size of receive buffer used by TCP sockets. It is 

guaranteed to each TCP socket, even under moderate memory 

pressure. Default: 8K 

• default: default size of receive buffer used by TCP sockets. This 

value overrides net.core.rmem_default used by other protocols. 

Default: 87380 bytes. This value results in window of 65535 

with default setting of tcp_adv_win_scale and tcp_app_win:0 

and a bit less for default tcp_app_win. See below about these 

variables. 

• max: maximal size of receive buffer allowed for automatically 

selected receiver buffers for TCP socket. This value does not 

override net.core.rmem_max, "static" selection via 

SO_RCVBUF does not use this. Default: 87380*2 bytes. 



• tcp_mem - vector of 3 INTEGERs: min, pressure, max 

• low: below this number of pages TCP is not bothered about its 

memory appetite. 

• pressure: when amount of memory allocated by TCP exceeds 

this number of pages, TCP moderates its memory consumption 

and enters memory pressure mode, which is exited when 

memory consumtion falls under "low". 

• high: number of pages allowed for queueing by all TCP sockets. 

Defaults are calculated at boot time from amount of available 

memory. 



• net.ipv4.tcp_rmem_max: max receive socket buffer size 

• net.ipv4.tcp_wmem_max: max send socket buffer size 

• net.ipv4.tcp_rmem_default: default receive socket buffer size 

• net.ipv4.tcp_wmem_default: default send socket buffer size

TCP: Transport Control Protocol - INFN-CNAF

Create successful ePaper yourself

Delete template?

Save as template?