La convenzione di denominazione per gli algoritmi di controllo della congestione (CCAS) potrebbe aver avuto origine in un documento del 1996 di Kevin Fall e Sally Floyd.

La seguente è una possibile classificazione secondo le seguenti proprietà:

1. il tipo e la quantità di feedback ricevuti dalla rete
2. incrementale dispiegabilità su Internet corrente
3. l’aspetto di mira a migliorare: ad alta larghezza di banda e ritardo di prodotti di reti (B); lossy collegamenti (L); equità (F); vantaggio per brevi tratti (S); a tasso variabile link (V); velocità di convergenza (C)
4. il criterio di equità che utilizza

Alcuni noti meccanismi di prevenzione della congestione sono classificati da questo schema come segue:

Variant	Feedback	Required changes	Benefits	Fairness
(New) Reno	Loss	—	—	Delay
Vegas	Delay	Sender	Less loss	Proportional
High Speed	Loss	Sender	High bandwidth
BIC	Loss	Sender	High bandwidth
CUBIC	Loss	Sender	High bandwidth
C2TCP	Loss/Delay	Sender	Ultra-low latency and high bandwidth
NATCP	Multi-bit signal	Sender	Near Optimal Performance
Elastic-TCP	Loss/Delay	Sender	High bandwidth/short & long-distance
Agile-TCP	Loss	Sender	High bandwidth/short-distance
H-TCP	Loss	Sender	High bandwidth
FAST	Delay	Sender	High bandwidth	Proportional
Compound TCP	Loss/Delay	Sender	High bandwidth	Proportional
Westwood	Loss/Delay	Sender	L
Jersey	Loss/Delay	Sender	L
BBR	Delay	Sender	BLVC, Bufferbloat
CLAMP	Multi-bit signal	Receiver, Router	V	Max-min
TFRC	Loss	Sender, Receiver	No Retransmission	Minimum delay
XCP	Multi-bit signal	Sender, Receiver, Router	BLFC	Max-min
VCP	2-bit signal	Sender, Receiver, Router	BLF	Proportional
MaxNet	Multi-bit signal	Sender, Receiver, Router	BLFSC	Max-min
JetMax	Multi-bit signal	Sender, Receiver, Router	High larghezza di banda	Max-min
ROSSI	Perdita	Router	ritardo Ridotto
ECN	Singolo bit del segnale	Mittente, destinatario, Router	la Riduzione della perdita

TCP Tahoe e RenoEdit

TCP Tahoe, Reno algoritmi sono stati chiamati dopo le versioni o sapori di BSD 4.3 del sistema operativo in cui ogni prima apparizione (che sono stati loro stessi chiamato dopo il Lago Tahoe e la vicina città di Reno, in Nevada). L’algoritmo Tahoe è apparso per la prima volta in 4.3 BSD-Tahoe (che è stato realizzato per supportare il minicomputer CCI Power 6/32 “Tahoe”), ed è stato successivamente reso disponibile ai licenziatari non-AT&T come parte della 4.3 BSD Networking Release 1; questo ha assicurato la sua ampia distribuzione e implementazione. Miglioramenti sono stati fatti in 4.3 BSD-Reno e successivamente rilasciato al pubblico come Networking Release 2 e successive 4.4 BSD-Lite.

Mentre entrambi considerare retransmission timeout (RTO) e duplicate ACKs come perdita di pacchetti, gli eventi, il comportamento di Reno Tahoe e si differenziano principalmente per come reagiscono al duplicate Ack:

• Tahoe: se tre duplicate Ack ricevuti (vale a dire quattro Ack riconoscendo che lo stesso pacchetto, che non sono piggyback su dati e non modificare il ricevitore è pubblicizzato finestra), Tahoe esegue una ritrasmissione veloce, imposta l’avvio lento soglia di metà dell’attuale finestra di congestione, riduce la finestra di congestione a 1 MSS, e ripristina avvio lento di stato.
• Reno: se vengono ricevuti tre ACK duplicati, Reno eseguirà una ritrasmissione veloce e salterà la fase di avvio lento dimezzando invece la finestra di congestione (invece di impostarla su 1 MSS come Tahoe), impostando la soglia di avvio lento uguale alla nuova finestra di congestione e inserendo una fase chiamata recupero rapido.

In Tahoe e Reno, se un timeout ACK (timeout RTO), viene utilizzato un avvio lento ed entrambi gli algoritmi riducono la finestra di congestione a 1 MSS.

TCP VegasEdit

Fino alla metà degli anni 1990, tutti i timeout impostati da TCP e i ritardi di andata e ritorno misurati erano basati solo sull’ultimo pacchetto trasmesso nel buffer di trasmissione. I ricercatori dell’Università dell’Arizona Larry Peterson e Lawrence Brakmo hanno introdotto TCP Vegas (dal nome di Las Vegas, la più grande città del Nevada) in cui sono stati impostati i timeout e sono stati misurati i ritardi di andata e ritorno per ogni pacchetto nel buffer di trasmissione. Inoltre, TCP Vegas utilizza aumenti additivi nella finestra di congestione. In uno studio di confronto di vari TCP CCA, TCP Vegas sembrava essere il più liscio seguito da TCP CUBIC.

TCP Vegas non è stato ampiamente distribuito al di fuori del laboratorio di Peterson, ma è stato selezionato come metodo di controllo della congestione predefinito per il firmware DD-WRT v24 SP2.

TCP New RenoEdit

TCP New Reno, definito da RFC 6582 (che osserva le precedenti definizioni di RFC 3782 e RFC 2582), migliora la ritrasmissione durante la fase di recupero rapido di TCP Reno. Durante il ripristino rapido, per mantenere la finestra di trasmissione piena, per ogni ACK duplicato restituito, viene inviato un nuovo pacchetto non inviato dalla fine della finestra di congestione. Per ogni ACK che fa progressi parziali nello spazio sequenza, il mittente assume che l’ACK punti a un nuovo buco e il pacchetto successivo oltre il numero di sequenza ACKed viene inviato.

Poiché il timeout viene resettato ogni volta che c’è un progresso nel buffer di trasmissione, New Reno può riempire grandi fori, o fori multipli, nello spazio sequenza – proprio come TCP SACK. Poiché New Reno può inviare nuovi pacchetti alla fine della finestra di congestione durante il ripristino rapido, durante il processo di riempimento dei fori viene mantenuto un throughput elevato, anche quando ci sono più fori, di più pacchetti ciascuno. Quando TCP entra in fast recovery registra il più alto numero di sequenza di pacchetti non riconosciuti. Quando questo numero di sequenza viene riconosciuto, TCP ritorna allo stato di prevenzione della congestione.

Si verifica un problema con New Reno quando non ci sono perdite di pacchetti, ma invece, i pacchetti vengono riordinati da più di 3 numeri di sequenza di pacchetti. In questo caso, New Reno entra erroneamente nel recupero veloce. Quando viene consegnato il pacchetto riordinato, si verifica l’avanzamento del numero di sequenza ACK e da lì fino alla fine del recupero rapido, tutto l’avanzamento del numero di sequenza produce una ritrasmissione duplicata e inutile che viene immediatamente ACKed.

Nuovo Reno esegue così come SACK a bassi tassi di errore dei pacchetti, e sostanzialmente sovraperforma Reno a tassi di errore elevati.

TCP HyblaEdit

TCP Hybla mira ad eliminare sanzioni per le connessioni TCP che incorporano un ad alta latenza collegamenti radio terrestri o satellitari. I miglioramenti di Hybla si basano sulla valutazione analitica delle dinamiche della finestra di congestione.

TCP BICEdit

Binary Increase Congestion control (BIC) è un’implementazione TCP con un CCA ottimizzato per reti ad alta velocità con alta latenza, note come reti fat lunghe. BIC è usato di default nei kernel Linux da 2.6.8 a 2.6.18.

TCP CUBICEdit

CUBIC è una derivata meno aggressiva e più sistematica di BIC, in cui la finestra è una funzione cubica del tempo dall’ultimo evento di congestione, con il punto di flesso impostato sulla finestra prima dell’evento. CUBIC è usato di default nei kernel Linux tra le versioni 2.6.19 e 3.2.

Agile-SD TCPEdit

Agile-SD è un CCA basato su Linux progettato per il vero kernel Linux. Si tratta di un algoritmo lato ricevitore che impiega un approccio basato sulla perdita utilizzando un nuovo meccanismo, chiamato agility factor (AF). per aumentare l’utilizzo della larghezza di banda su reti ad alta velocità e a breve distanza (reti a basso BDP) come reti locali o reti in fibra ottica, soprattutto quando la dimensione del buffer applicata è piccola. È stato valutato confrontando le sue prestazioni con Compound-TCP (il CCA predefinito in MS Windows) e CUBIC (il default di Linux) utilizzando NS-2 simulator. Migliora le prestazioni totali fino al 55% in termini di throughput medio.

TCP Westwood+Edit

Westwood+ è una modifica solo mittente di TCP Reno che ottimizza le prestazioni del controllo della congestione TCP su reti cablate e wireless. TCP Westwood + si basa sulla stima della larghezza di banda end-to-end per impostare la finestra di congestione e la soglia di avvio lento dopo un episodio di congestione, ovvero dopo tre conferme duplicate o un timeout. La larghezza di banda è stimata facendo una media del tasso di restituzione dei pacchetti di riconoscimento. In contrasto con TCP Reno, che dimezza ciecamente la finestra di congestione dopo tre ACK duplicati, TCP Westwood + imposta adattivamente una soglia di avvio lento e una finestra di congestione che tiene conto di una stima della larghezza di banda disponibile al momento della congestione. Rispetto a Reno e New Reno, Westwood + aumenta significativamente il throughput sui collegamenti wireless e migliora l’equità nelle reti cablate.

Compound TCPEdit

Compound TCP è un’implementazione Microsoft di TCP che mantiene contemporaneamente due diverse finestre di congestione, con l’obiettivo di ottenere buone prestazioni su LFNS senza compromettere l’equità. È stato ampiamente distribuito nelle versioni di Windows da Microsoft Windows Vista e Windows Server 2008 ed è stato portato alle versioni precedenti di Microsoft Windows e Linux.

TCP Proportional Rate ReductionEdit

TCP Proportional Rate Reduction (PRR) è un algoritmo progettato per migliorare l’accuratezza dei dati inviati durante il ripristino. L’algoritmo assicura che la dimensione della finestra dopo il ripristino sia il più vicino possibile alla soglia di avvio lento. Nei test eseguiti da Google, il PRR ha comportato una riduzione del 3-10% della latenza media e i timeout di ripristino sono stati ridotti del 5%. PRR è disponibile nei kernel Linux dalla versione 3.2.

TCP BBREdit

Bottleneck Bandwidth and Round-trip Propagation time (BBR) è un CCA sviluppato da Google nel 2016. Mentre la maggior parte dei CCA sono basati sulla perdita, in quanto si basano sulla perdita di pacchetti per rilevare la congestione e tassi di trasmissione più bassi, BBR, come TCP Vegas, è basato sul modello. L’algoritmo utilizza la larghezza di banda massima e il tempo di andata e ritorno in cui la rete ha consegnato il volo più recente di pacchetti di dati in uscita per creare un modello della rete. Ogni riconoscimento cumulativo o selettivo della consegna dei pacchetti produce un campione di frequenza che registra la quantità di dati consegnati nell’intervallo di tempo tra la trasmissione di un pacchetto di dati e il riconoscimento di quel pacchetto. Poiché i controller di interfaccia di rete si evolvono da megabit al secondo a prestazioni gigabit al secondo, la latenza associata a bufferbloat invece della perdita di pacchetti diventa un marker più affidabile del throughput massimo, rendendo i CCA basati su modelli che forniscono un throughput più elevato e una latenza inferiore, come BBR, un’alternativa più affidabile agli algoritmi basati su

BBR è disponibile per Linux TCP da Linux 4.9. È disponibile anche per QUIC.

BBR versione 1 (BBRv1) è efficiente e veloce, ma la sua correttezza verso i flussi non BBR è contestata. Quando implementato su YouTube, BBRv1 ha prodotto in media un throughput di rete superiore del 4% e fino al 14% in alcuni paesi. Mentre la presentazione di Google mostra BBRv1 coesistere bene con CUBIC, ricercatori come Geoff Huston e Hock, Bless e Zitterbart trova ingiusto ad altri flussi e non scalabile. Hock et al hanno anche riscontrato “alcuni gravi problemi intrinseci come l’aumento dei ritardi di accodamento, l’ingiustizia e la massiccia perdita di pacchetti” nell’implementazione BBR di Linux 4.9.

Soheil Abbasloo et al. (autori di C2TCP) mostrano che BBRv1 non funziona bene in ambienti dinamici come le reti cellulari. Hanno anche dimostrato che BBR ha un problema di ingiustizia. Ad esempio, quando un flusso CUBICO (che è l’implementazione TCP predefinita in Linux, Android e macOS) coesiste con un flusso BBR nella rete, il flusso BBR può dominare il flusso CUBICO e ottenere l’intera larghezza di banda del collegamento da esso (vedere figura 18 in ).

La versione 2 tenta di affrontare il problema dell’ingiustizia quando si opera insieme alla gestione della congestione basata sulle perdite come CUBIC. In BBRv2 il modello utilizzato da BBRv1 è aumentato per includere informazioni sulla perdita di pacchetti e informazioni dalla notifica esplicita di congestione (ECN). Mentre BBRv2 può a volte avere un throughput inferiore rispetto a BBRv1, è generalmente considerato avere un goodput migliore.

C2TCPEdit

Cellular Controlled Delay TCP (C2TCP) è stato motivato dalla mancanza di un approccio TCP end-to-end flessibile in grado di soddisfare vari requisiti QoS di diverse applicazioni senza richiedere alcuna modifica nei dispositivi di rete. C2TCP mira a soddisfare requisiti di latenza ultra-bassa e larghezza di banda elevata di applicazioni come realtà virtuale, videoconferenza, giochi online, sistemi di comunicazione veicolare, ecc. in un ambiente altamente dinamico come l’attuale LTE e le future reti cellulari 5G. C2TCP funziona come un add-on in cima alla perdita basata su TCP (ad esempio Reno, NewReno, CUBIC, BIC, …) e rende il ritardo medio dei pacchetti limitato ai ritardi desiderati impostati dalle applicazioni.

I ricercatori della NYU hanno dimostrato che C2TCP supera le prestazioni di ritardo / Jitter di vari schemi TCP all’avanguardia. Ad esempio, hanno dimostrato che rispetto a BBR, CUBIC e Westwood in media, C2TCP diminuisce il ritardo medio dei pacchetti di circa il 250%, il 900% e il 700% rispettivamente su vari ambienti di rete cellulare.

C2TCP deve essere installato solo sul lato server.

Elastic-TCPEdit

Elastic-TCP è stato proposto nel febbraio 2019 da Mohamed A. Alrshah et al. per aumentare l’utilizzo della larghezza di banda su reti ad alta BDP per supportare applicazioni recenti come cloud computing, big data transfer, IoT, ecc. Si tratta di un CCA basato su Linux che è stato progettato per il kernel Linux. È un algoritmo lato ricevitore che impiega un approccio basato sulla perdita di ritardo utilizzando un nuovo meccanismo, chiamato Window-Correlated Weighting Function (WWF). Ha un alto livello di elasticità per affrontare diverse caratteristiche di rete senza la necessità di sintonizzazione umana. È stato valutato confrontando le sue prestazioni con Compound-TCP (il CCA predefinito in MS Windows), CUBIC (il default di Linux) e TCP-BBR (il default di Linux 4.9 da Google) utilizzando NS-2 simulator e testbed. Elastic-TCP migliora significativamente le prestazioni totali in termini di throughput medio, rapporto di perdita e ritardo.

NATCP / NACubicEdit

Recentemente, Soheil Abbasloo et. al. proposto NATCP (Network-Assisted TCP) un progetto TCP controverso targeting reti mobili bordo come MEC. L’idea chiave di NATCP è che se le caratteristiche della rete fossero conosciute in anticipo, TCP sarebbe stato progettato in un modo migliore. Pertanto, NATCP utilizza le funzionalità e le proprietà disponibili nelle attuali architetture cellulari basate su MEC per spingere le prestazioni di TCP vicino alle prestazioni ottimali. NATCP utilizza un feedback out-of-band dalla rete ai server situati nelle vicinanze. Il feedback dalla rete, che include la capacità di collegamento di accesso cellulare e il minimo RTT della rete, guida i server per regolare le loro tariffe di invio. Come mostrano i risultati preliminari, NATCP supera gli schemi TCP all’avanguardia raggiungendo almeno una potenza 2 volte superiore (definita come Throughput/Delay). NATCP sostituisce lo schema TCP tradizionale al mittente.

Per affrontare il problema della retrocompatibilità, hanno proposto un’altra versione chiamata NACubic. NACubic è un design retrocompatibile, che non richiede alcuna modifica del TCP sui nodi collegati. NACubic utilizza il feedback ricevuto e applica un limite alla finestra di congestione (CWND) e al tasso di stimolazione come richiesto.

Altre TCP per evitare la congestione algorithmsEdit

• FAST TCP
• Generalizzata FAST TCP
• H-TCP
• Data Center TCP
• TCP ad Alta Velocità
• HSTCP-LP
• TCP-Illinois
• TCP-LP
• TCP SACK
• TCP Scalabile
• TCP Veno
• Westwood
• XCP
• Sì-TCP
• TCP-FIT
• Evitare la Congestione con Normalizzata Intervallo di Tempo (CANIT)
• Non-lineare di rete neurale controllo della congestione, basato su algoritmo genetico per reti TCP/IP

TCP New Reno è stato il più comunemente implementato algoritmo, il supporto SACK è molto comune ed è un’estensione di Reno / New Reno. La maggior parte delle altre sono proposte concorrenti che devono ancora essere valutate. A partire da 2.6.8 il kernel Linux ha cambiato l’implementazione predefinita da New Reno a BIC. L’implementazione predefinita è stata nuovamente modificata in CUBIC nella versione 2.6.19. FreeBSD usa New Reno come algoritmo predefinito. Tuttavia, supporta una serie di altre scelte.

Quando il prodotto per flusso di larghezza di banda e latenza aumenta, indipendentemente dallo schema di accodamento, TCP diventa inefficiente e soggetto a instabilità. Questo diventa sempre più importante come Internet si evolve per incorporare molto alta larghezza di banda collegamenti ottici.

TCP Interactive (iTCP) consente alle applicazioni di sottoscrivere eventi TCP e rispondere di conseguenza consentendo varie estensioni funzionali a TCP dal livello TCP esterno. La maggior parte degli schemi di congestione TCP funziona internamente. iTCP consente inoltre alle applicazioni avanzate di partecipare direttamente al controllo della congestione, ad esempio per controllare la velocità di generazione della sorgente.

Zeta-TCP rileva le congestioni dalle misure di latenza e tasso di perdita e applica diverse strategie di backoff della finestra di congestione in base alla probabilità delle congestioni per massimizzare il goodput. Ha anche un paio di altri miglioramenti per rilevare con precisione le perdite di pacchetti, evitando la ritrasmissione timeout ritrasmissione; e accelerare/controllare il traffico in entrata (download).