Riassunto e traduzione dell'originale articolo che introduce i concetti di controllo della congestione e del flusso in una connessione TCP.

1. TCP - Congestion avoidance and control
Le reti di computer sono cresciute esponenzialmente e questa crescita è accompagnata da
importanti problemi di congestione. In media, infatti, un gateway perde circa il 10%
dei pacchetti in entrata a causa dell’overflow dei buffer di ricezione.
Il TCP ha due importanti obiettivi:
• controllare il flusso di invio dei pacchetti affinchè il buffer del destinatario
non vada in overflow
• controllare la congestione della rete quando il router riceve molti più
pacchetti di quanti ne possa trasmettere su un certo link (provocando,
inevitabilmente, la perdita di pacchetti in eccesso)
1. ADVERTISED WINDOW
Il primo problema viene risolto utilizzando una variabile detta Advertised Window,
dove il destinatario comunica al mittente quanto spazio è ancora rimanente nel
proprio buffer.
Il buffer viene rappresentato da un integratore: dato che da esso vengono tolti e aggiunti
pacchetti, c’è un ingresso positivo (pacchetti inviati dal mittente) e un ingresso
negativo (pacchetti letti dal destinatario). Inoltre, il tempo necessario ai dati per
raggiungere il destinatario (𝑻𝑻𝒇𝒇𝒇𝒇 – Tempo feed-forward) e a questi per far ricevere
l’ACK (𝑻𝑻𝒇𝒇𝒃𝒃 – Tempo feed-back) è chiamato round-trip time o RTT.
Il sistema può essere rappresentato nel seguente modo:
1. 𝐺𝐺𝑐𝑐(𝑠𝑠) =
𝐾𝐾
1+
𝐾𝐾
𝑠𝑠
[1−𝑒𝑒−𝑠𝑠𝑇𝑇]
𝑐𝑐𝑐𝑐𝑐𝑐 𝑇𝑇 = 𝑅𝑅𝑅𝑅𝑅𝑅
2. 𝐺𝐺𝑐𝑐(𝑠𝑠)∆𝑊𝑊 =
𝐾𝐾∆𝑊𝑊
1+
𝐾𝐾
𝑠𝑠
[1−𝑒𝑒−𝑠𝑠𝑇𝑇]
= 𝑢𝑢(𝑡𝑡)

2. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
3. → 𝐾𝐾∆𝑊𝑊 = 𝑈𝑈(𝑠𝑠) �1 +
𝐾𝐾
𝑠𝑠
[1 − 𝑒𝑒−𝑠𝑠𝑇𝑇]�
4. → 𝐾𝐾∆𝑊𝑊 = 𝑢𝑢(𝑡𝑡) + 𝐾𝐾 ∫ 𝑢𝑢(𝜏𝜏) − 𝑢𝑢(𝜏𝜏 − 𝑇𝑇)𝑑𝑑𝜏𝜏
𝑡𝑡
−∞
5. → 𝑢𝑢(𝑡𝑡) = 𝐾𝐾 �∆𝑊𝑊 − ∫ 𝑢𝑢(𝜏𝜏) − 𝑢𝑢(𝜏𝜏 − 𝑇𝑇)𝑑𝑑𝜏𝜏
𝑡𝑡
−∞
�
L’integrale può essere scritto come: �∫ 𝑢𝑢(𝜏𝜏)𝑑𝑑𝜏𝜏
𝑡𝑡−𝑇𝑇
−∞
+ ∫ 𝑢𝑢(𝜏𝜏)𝑑𝑑𝜏𝜏
𝑡𝑡
𝑡𝑡−𝑇𝑇
− ∫ 𝑢𝑢(𝜏𝜏)𝑑𝑑𝜏𝜏
𝑡𝑡−𝑇𝑇
−∞
� dove il
primo e l’ultimo integrale si semplificano in quanto sono opposti
Quindi, si ha che:
𝑢𝑢(𝑡𝑡) = 𝐾𝐾 �∆𝑊𝑊 − � 𝑢𝑢(𝜏𝜏)𝑑𝑑𝑑𝑑
𝑡𝑡
𝑡𝑡−𝑇𝑇
�
L’integrale prende il nome di in-flight packets, cioè un insieme di pacchetti, il cui primo
questo insieme è stato inviato nell’istante 𝑡𝑡 − 𝑇𝑇, e che non sono ancora stati riscontrati.
Sono anche detti outstanding packets.
Dunque, la grandezza della finestra di trasmissione è data dall’Advertised Window meno
gli outstanding packets che stanno per andare a occupare altro spazio nel buffer.
𝑊𝑊 =
𝑢𝑢(𝑡𝑡)
𝐾𝐾
= 𝐴𝐴𝐷𝐷𝐷𝐷 − 𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛 𝑛𝑛

3. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
2. EQUILIBRIO INIZIALE: SLOW START
L’algoritmo introdotto da Van Jacobson permette di controllare il traffico della rete in modo
più equilibrato.
L’errore, nella connessione, viene causato da una connessione riavviata dopo la perdita di un
pacchetto. Dato che il destinatario non può generare ACK più velocemente di quanto i
pacchetti fluiscano nella rete, il protocollo si definisce “self-clocking”. I sistemi di questo
genere modificano automaticamente la banda e i ritardi e hanno un ampio dynamic
range (velocità di trasmissione dei pacchetti).
Figura 1. Meccanismo di self-clocking
Rappresentazione di mittente e destinatario con reti di accesso ad alta banda, connesse
da una rete lenta. Il mittente ha appena iniziato e ha trasmesso una finestra di
pacchetti, mentre l’ACK del primo di questi pacchetti sta per arrivargli.
La dimensione verticale è la banda, quella orizzontale è il tempo: dunque, l’area di
un pacchetto (banda per tempo) equivale alla dimensione del pacchetto
stesso, cioè al numero dei suoi bit. Dato che il numero di bit/pacchetto non cambia,
con una banda minore sarà necessario più tempo per trasmettere quei bit,
quindi il pacchetto viene “spalmato” sull’asse orizzontale.
𝑃𝑃𝑏𝑏 rappresenta il tempo di trasmissione del pacchetto sul link più lento (il
bottleneck); se il tempo di elaborazione 𝑃𝑃𝑟𝑟 del destinatario è lo stesso per tutti i
pacchetti, l’intervallo tra due ACK consecutivi è di 𝐴𝐴𝑟𝑟 = 𝑃𝑃𝑟𝑟 = 𝑃𝑃𝑏𝑏.
Se lo slot temporale 𝑃𝑃𝑏𝑏 è grande abbastanza per il pacchetto, lo è anche per l’ACK
che ha dimensione minore, dunque l’intervallo tra due ACK viene preservato
durante il cammino di ritorno. Quindi, se effettivamente dopo il primo avvio, i
pacchetti vengono inviati in risposta a un ACK, l’intervallo tra i pacchetti inviati
dal mittente sarà equivalente al tempo di trasmissione di un pacchetto sul
link più lento del percorso.

4. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
Tuttavia, la stessa cosa che rende un sistema self-clocked stabile quando è attivo, lo rende
anche difficile da avviare: per avere un flusso di dati ci deve essere un ACK che dia il
“segnale” in modo che tale flusso venga inviato, ma per avere ACK ci deve essere un flusso
di dati a sua volta.
Per far partire questo “segnale”, viene proposto l’algoritmo di slow-start, che aumenta
gradualmente la quantità di dati trasmessi. In realtà, lo slow-start non è così lento: impiega
un tempo 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅2 𝑊𝑊 , dove 𝑹𝑹 è il round-trip time mentre 𝑾𝑾 è la dimensione della
finestra di trasmissione. Significa che la finestra si apre abbastanza rapidamente da non
avere effetti tangibili sulle prestazioni. L’algoritmo garantisce che una connessione
trasmetterà dati ad un rate al massimo doppio del massimo possibile sul
percorso.
Figura 2. Meccanismo slow-start
La direzione orizzontale è il tempo, che è stato suddiviso in intervalli grandi 1
RTT, messi verticalmente uno sopra l’altro. I box grigi sono i pacchetti, quelli bianchi
sono gli ACK corrispondenti.
All’arrivo di ogni ACK corrispondono due pacchetti: uno per l’ACK (l’ACK dice
che un pacchetto ha “lasciato” il sistema, quindi un altro può prendere il suo posto) e
un altro perché nello slow-start l’ACK aumenta la finestra di un pacchetto.
Se la rete di accesso è molto più veloce di quella che collega i due utenti, i due ACK
arrivano al bottleneck praticamente nello stesso momento (motivo per cui questi due
pacchetti sono mostrati uno sopra l’altro).

5. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
Figura 3. Confronto tra i comportamenti di avvio senza e con slow-start
La dimensione della finestra è di 16KB e il buffer del gateway del bottleneck può
contenere 30 pacchetti. Il percorso si compone di sei nodi. Ciascun punto indica un
pacchetto di 512B. L’asse orizzontale è contiene gli instanti in cui i pacchetti vengono
inviati, l’asse verticale indica i sequence number. Due punti con stessa y ma x
diversa indicano una ritrasmissione.
Il comportamento ideale è che il grafico vada come una diagonale che parte
dall’origine. In questo caso, senza slow-start, solo il 35% della banda viene
utilizzato e quasi tutti i pacchetti vengono ritrasmessi almeno una volta,
eccetto i dati da 54 a 58KB, che vengono ritrasmessi cinque volte.
Nelle stesse condizioni ma con l’uso dello slow-start, non c’è spreco di banda
per le ritrasmissioni.

6. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
3. CONSERVAZIONE DELL’EQUILIBRIO: ROUND-TRIP
TIMING
Ottenere una buona stima del round-trip time è il fulcro di qualsiasi implementazione del
protocollo TCP.
Un errore che viene commesso è che non viene stimata la variazione 𝝈𝝈𝑹𝑹 del round-trip
time R. Dalla teoria delle code, si sa che R e la sua variazione 𝜎𝜎𝑅𝑅 si incrementano
rapidamente col carico. Se il carico è 𝝆𝝆 (il rapporto tra il tasso di arrivi e il tasso di
invii) allora R e 𝜎𝜎𝑅𝑅 scalano di un fattore (1 − 𝜌𝜌)−1
.
Per esempio, se la rete lavora al 75% della sua capacità, ci si aspetta una variazione del round-
trip time di un fattore 16 (da −2𝜎𝜎 a 2𝜎𝜎). Infatti:
𝜌𝜌 = 75% = 0,75
(1 − 𝜌𝜌)−1
= 4
[−2𝜎𝜎; 2𝜎𝜎] = [−8; 8] 𝑐𝑐𝑐𝑐𝑐𝑐è 𝑢𝑢𝑢𝑢 𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 𝑑𝑑𝑑𝑑 16
Il protocollo TCP suggerisce di stimare un round-trip time medio attraverso un filtro passa
basso:
𝑅𝑅 = 𝛼𝛼𝛼𝛼 + (1 − 𝛼𝛼)𝑀𝑀
dove R è la stima del RTT medio, M è la misura del RTT più recente, 𝜶𝜶 è il
guadagno del filtro (con un valore suggerito di 0.9). Una volta che il valore di R viene
aggiornato, il retransmit rimetout (RTO) per il prossimo pacchetto viene settato a 𝛽𝛽𝛽𝛽.
Il parametro 𝛽𝛽 considera le variazioni di RTT: con un 𝛽𝛽 = 2, la rete può adattarsi a un
carico di, al massimo, il 30%; superata questa soglia, una connessione risponderà agli
aumenti di carico con la ritrasmissione di pacchetti che, in realtà, stanno solo
venendo ritardati nella trasmissione ma che non sono andati persi. Questo forza la
rete a svolgere del lavoro aggiuntivo inutile, consumando banda per pacchetti duplicati che
verranno comunque consegnati. È l’equivalente di gettare benzina sul fuoco. Un vantaggio
di utilizzare un 𝛽𝛽 stimato piuttosto che uno fisso è che migliorano le prestazioni quando la
rete è a basso o ad alto carico, soprattutto su quei percorsi molto lenti (come le connessioni
satellitari).
Uno dei più semplici stimatore del RTT è il Recursive Prediction Error. Data una nuova
misura m del RTT, si aggiorna la stima del RTT nel seguente modo:

7. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
𝑎𝑎 = (1 − 𝑔𝑔)𝑎𝑎 + 𝑔𝑔𝑔𝑔
dove 𝑔𝑔 è il guadagno (0 < 𝑔𝑔 < 1), legato al rapporto segnale-rumore di 𝒎𝒎. La formula
assume più senso se viene modificata nel seguente modo:
𝑎𝑎 = 𝑎𝑎 + 𝑔𝑔(𝑚𝑚 − 𝑎𝑎)
Bisogna pensare ad ‘𝑎𝑎’ come una predizione della prossima misurazione. Il valore ‘𝑚𝑚 − 𝑎𝑎’ è
l’errore su tale predizione e l’espressione sopra dice che la nuova predizione si
basa su quella vecchia più un certo errore. L’errore di predizione si compone di due
parti: l’errore dovuto al rumore sulla misura (𝒈𝒈𝒈𝒈) e l’errore dovuto allo
scostamento di ‘𝒂𝒂’ dal valore vero (𝒈𝒈𝒈𝒈). Il primo viene denominato 𝐸𝐸𝑟𝑟, il secondo 𝐸𝐸𝑒𝑒.
𝑎𝑎 = 𝑎𝑎 + 𝑔𝑔𝐸𝐸𝑟𝑟 + 𝑔𝑔𝐸𝐸𝑒𝑒
In senso figurato, si può dire che 𝑔𝑔𝐸𝐸𝑒𝑒 spinge 𝑎𝑎 nella direzione giusta, mentre 𝑔𝑔𝐸𝐸𝑟𝑟 lo porta in
una direzione casuale. Su una moltitudine di campioni, i contributi di 𝒈𝒈𝑬𝑬𝒓𝒓 tendono a
cancellarsi reciprocamente (troveremo un valore di errore positivo che verrà
compensato da un valore di errore negativo), quindi l’algoritmo tende verso il
valore corretto.
Tuttavia ‘𝑔𝑔’ rappresenta un compromesso: si vuole un 𝑔𝑔 grande per incrementare gli effetti
di 𝐸𝐸𝑒𝑒 ma uno piccolo per minimizzare la deviazione introdotta da 𝐸𝐸𝑟𝑟; in realtà, dato che 𝐸𝐸𝑒𝑒
porta 𝑎𝑎 verso il valore vero, non importa che valore si dia a 𝒈𝒈, è sempre meglio usare
un piccolo guadagno. Inoltre, un 𝒈𝒈 più piccolo produce un 𝒂𝒂 più stabile, a scapito
di richiedere più tempo per raggiungere il valore vero. Tipici valori sono 0.1/0.2
Un altro errore sta nel backoff dopo la ritrasmissione: se un pacchetto deve essere
ritrasmesso più di una volta, come dovrebbero distribuirsi nel tempo queste
ritrasmissioni? Per un endpoint che si trova in una rete di sconosciuta topologia con una
sconosciuta e non conoscibile popolazione, c’è solo una soluzione e cioè quella di usare un
backoff esponenziale. Sebbene tale trattazione non rientri nell’articolo, una prova di
quanto detto sta nel seguente assunto.
Una rete, con buona approssimazione, è un sistema lineare cioè composto da integratori,
guadagni e ritardi. La teoria dei sistemi lineari dice che se è un sistema è stabile, allora la
sua stabilità è esponenziale: ciò suggerisce che un sistema instabile può essere
stabilizzato aggiungendo degli smorzamenti esponenziali (quindi dei backoff
esponenziali) alle sollecitazioni iniziali (le sorgenti di traffico).

8. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
4. ADATTAMENTO AL PERCORSO: CONGESTION
AVOIDANCE
Se i timer sono configurati correttamente, è possibile affermare con una certa confidenza che
un timeout indica un pacchetto perso e non un timer non funzionante. I pacchetti
vengono persi per due ragioni: vengono danneggiati durante il transito oppure la rete è
congestionata e da qualche parte, lungo il percorso, il buffer è insufficiente. Sulla maggior
parte dei link, la corruzione del pacchetto è un evento raro (<1% dei casi), quindi è
molto più probabile che la perdita di pacchetto sia dovuta alla congestione della rete.
Una strategia di “congestion avoidance” deve necessariamente avere due componenti:
• la rete deve essere capace di segnalare agli endpoint che una congestione è
avvenuta o sta per verificarsi
• gli endpoint devono avere una politica che riduce la trasmissione alla ricezione
di questo segnale o la aumenta se non viene ricevuto nulla
Dato che la perdita di pacchetto è (empiricamente) dovuta a congestione e dato che il
timeout è (empiricamente) dovuto alla congestione, allora il segnale candidato è proprio
il timeout.
Se 𝑳𝑳𝒊𝒊 è il carico sull’i-esimo link, una rete non congestionata può essere modellata dicendo
che 𝐿𝐿𝑖𝑖 cambia molto lentamente rispetto al tempo di campionamento. Quindi:
𝐿𝐿𝑖𝑖 = 𝑁𝑁
con N costante. Se, invece, la rete è soggetta a congestioni, questo sistema di ordine zero
non funziona. La lunghezza media della coda diventa la somma di due termini: il precedente
valore N, che si riferisce al tasso medio di arrivi e al ritardo intrinseco, e a un
secondo valore che si riferisce a una porzione di traffico lasciata indietro durante il
precedente intervallo di tempo. Quindi:
𝐿𝐿𝑖𝑖 = 𝑁𝑁 + 𝛾𝛾𝐿𝐿𝑖𝑖−1
Si può notare un pattern del tutto simile a un’espansione di Taylor; c’è ragione di credere
che potrebbe essere necessario un terzo termine, per avere un sistema del secondo ordine,
ma non finché la rete non sarà cresciuta abbastanza.

9. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
Quando la rete è congestionata, 𝛾𝛾 sarà grande e la lunghezza delle code inizierà a crescere
esponenzialmente (quindi il termine N perde importanza). Il sistema si stabilizzerà solo
se le sorgenti di traffico ridurranno la trasmissione almeno alla stessa velocità di
crescita delle code. Dato che l’unico controllo sul carico che può avere una sorgente di
traffico è sulla propria finestra di trasmissione, è proprio su questa che bisogna agire.
Quindi:
𝑊𝑊𝑖𝑖 = 𝑑𝑑𝑊𝑊𝑖𝑖−1 (𝑑𝑑 < 1)
ottenendo una riduzione moltiplicativa (che diventa esponenziale se la congestione
persiste). Se non c’è congestione, 𝛾𝛾 deve essere ovviamente prossimo allo zero. Dato, inoltre,
che non viene segnalato in alcun modo se si sta utilizzando al meglio la capacità della rete,
una connessione incrementerà il suo uso di banda fino a trovarne il limite.
Si pone ora il seguente problema: se due connessioni condividono lo stesso percorso e si
converge sull’assegnare il 50% della banda ad entrambe, quando una di queste due
connessioni verrà chiusa, il 50% della banda resterà sprecato. Che politica adottare per
incrementare la banda della connessione rimanente?
Si potrebbe pensare di usare, simmetricamente al decremento, un incremento moltiplicativo.
Ciò sarebbe un errore perché il risultato oscillerà fortemente e si otterrà un throughput
povero. La ragione analitica di questo fenomeno risiede nel fatto che un incremento
moltiplicativo porta la rete a saturarsi molto velocemente e a impiegare molto
tempo per riassettarsi. È per questo che si usa un incremento piccolo e costante:
𝑊𝑊𝑖𝑖 = 𝑊𝑊𝑖𝑖−1 + 𝑢𝑢 (𝑢𝑢 ≪ 𝑊𝑊𝑚𝑚𝑚𝑚𝑚𝑚)
dove 𝑊𝑊𝑚𝑚𝑚𝑚𝑚𝑚 è detta pipesize. Questo è l’incremento additivo. Il meccanismo riduzione
moltiplicativa/incremento additivo viene già implementato nel TCP: la differenza con la
versione di Van Jacobson sta nella scelta dei coefficienti.
Una ragione per usare 0.5 come termine di decremento, sta nel fatto che, quando un
pacchetto viene perso significa che si sta iniziando (o riiniziando) una connessione oppure ci
si trova in un invio stazionario. Nel primo caso, si è a conoscenza del fatto che metà
della attuale finestra di trasmissione ha funzionato bene: in tal modo, dopo la
congestione, si imposta la finestra sulla più grande dimensione conosciuta che funzioni e la si
incrementa lentamente. Nel secondo caso, quando un pacchetto viene perso probabilmente è
perché è stata creata una nuova connessione che ha “rubato” un po’ della banda di quella
precedente. Dunque, si dovrebbe ridurre la finestra del 50% perché la banda stessa
è stata “fatta a metà” tra le due connessioni.

10. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
Invece, 1 come termine di incremento ha meno giustificazioni. Tuttavia, dato che non
sono state effettuate modifiche per la gestione dei gateway, la finestra di trasmissione a
cui si converge corrisponde al massimo che può accettare il gateway senza perdere
pacchetti.
Figura 4. Confronto tra i comportamenti di avvio senza e con congestion-
avoidance
Connessioni TCP simultanee senza l’uso del congestion-avoidance. Su 11.000 pacchetti
inviati, 4.000 sono ritrasmissioni. Il link è di 25kbps, ciascuna connessione avrebbe
dovuto ricevere 6kbps; invece, una ne ha avuti 8, due ne hanno avuti 5, una 0.5 e 6kbps sono
andati sprecati. Stesse condizioni precedenti ma con l’utilizzo del congestion-avoidance. Su
8281 trasmissioni, solo 89 pacchetti sono stati ritrasmessi. Due connessioni hanno
ricevuto 8kbps, le altre due 4.5.
Figura 5. Banda usata dal TCP senza e con il congestion-avoidance
Il grafico mostra quattro mittenti che non usano congestion-avoidance, su un link di 25kbps.
Notare che, i mittenti inviano, mediamente, il 25% in più di ciò che dovrebbe essere per
“riempire” il collegamento. La linea spessa, invece, indica lo stesso ambiente ma con l’uso del
congestion-avoidance. I primi 5 secondi sono di slow-start, poi ci sono 20 secondi di
oscillazione necessari al TCP a trovare la dimensione corretta della finestra di
trasmissione.

11. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
5. COMBINAZIONE DEGLI ALGORITMI SLOW-START E
CONGESTION-AVOIDANCE
Il mittente tiene traccia di due variabili: una per la finestra di trasmissione, cwnd, una per
la soglia, ssthresh, che viene utilizzata per spostarsi da un algoritmo all’altro.
Nel momento in cui si verifica un timeout, in ssthresh è memorizzata la metà della
dimensione della finestra di trasmissione attuale (il decremento moltiplicativo del
congestion-avoidance), quindi la cwnd viene settata a 1 (per avviare lo slow-start).
Quando viene ricevuto un nuovo ACK, il seguente algoritmo viene utilizzato:
if (cwnd < ssthresh)
/*se siamo ancora in slow-start, aumenta la finestra
esponenzialmente*/
cwnd +=1
else
/*altrimenti fai congestion-avoidance e incrementa di 1*/
cwnd += 1/cwnd
Se la finestra, su quel link, può contenere un massimo di 𝑊𝑊 pacchetti, cwnd deve avere
un range [𝟎𝟎, 𝑾𝑾], con una risoluzione di almeno
1
𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐
. Inoltre, dato che inviare pacchetti più
piccoli della MTU del percorso diminuisce l’efficienza, è necessario controllare che le
dimensioni frazionate di cwnd non comportino l’invio di pacchetti più piccoli
della MTU stessa.

12. Congestion Avoidance and Control | Van Jacobson Tandoi Antonio
6. IL CONTROLLO DI CONGESTIONE DEL GATEWAY
Gli algoritmi utilizzati sugli endpoint assicurano che la capacità della rete non venga superata
ma non danno nessuna garanzia su un equo utilizzo di tale capacità. Solo sui gateway c’è
abbastanza informazione da permettere un’allocazione equilibrata della banda tra le
diverse connessioni.
L’obiettivo di questo algoritmo è inviare un segnale ai nodi finali il più presto possibile, ma
non così presto da lasciare i gateway senza traffico. Se si vuole continuare a usare la perdita
di pacchetti come segnale di congestione, allora gli host vedranno persi molti dei loro
pacchetti non appena i gateway comunicheranno loro che stanno usando più
banda di quella che dovrebbero.
L’algoritmo sul gateway, inoltre, dovrebbe ridurre la congestione anche se nessun nodo entra
in congestion avoidance.