La convention de nommage pour les algorithmes de contrôle de congestion (CCAS) peut provenir d’un article de 1996 de Kevin Fall et Sally Floyd.

Voici une classification possible selon les propriétés suivantes:

1. le type et la quantité de rétroaction reçue du réseau
2. déployabilité incrémentale sur l’Internet actuel
3. l’aspect de performance qu’il vise à améliorer: réseaux de produits à retard de bande passante élevé (B); liens avec perte (L); équité (F); avantage aux flux courts (S); liens à débit variable (V); vitesse de convergence (C)
4. le critère d’équité qu’il utilise

Certains mécanismes d’évitement de congestion bien connus sont classés par ce schéma comme suit:

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 bande passante	Max-min
ROUGE	Perte	Routeur	Retard réduit
ECN	Signal à bit unique	Expéditeur, récepteur, routeur	Perte réduite

TCP Tahoe et RenoEdit

Les algorithmes TCP Tahoe et Reno ont été nommés rétrospectivement d’après les versions ou les saveurs du système d’exploitation 4.3BSD dans lesquelles chacun est apparu (qui ont eux-mêmes été nommés d’après le lac Tahoe et la ville voisine de Reno, Nevada). L’algorithme Tahoe est apparu pour la première fois dans 4.3BSD-Tahoe (qui a été conçu pour prendre en charge le mini-ordinateur CCI Power 6/32 « Tahoe »), et a ensuite été mis à la disposition des titulaires de licence non AT &T dans le cadre de la mise en réseau 4.3BSD Release 1; cela a assuré sa large distribution et sa mise en œuvre. Des améliorations ont été apportées à la version 4.3BSD-Reno et par la suite rendues publiques en tant que version 2 de Networking et plus tard 4.4BSD-Lite.

Bien que les deux considèrent le délai d’attente de retransmission (RTO) et les ACK en double comme des événements de perte de paquets, le comportement de Tahoe et de Reno diffèrent principalement dans la façon dont ils réagissent aux ACK en double :

• Tahoe: si trois ACK en double sont reçus (c’est-à-dire quatre ACK reconnaissant le même paquet, qui ne sont pas liés aux données et ne modifient pas la fenêtre annoncée du récepteur), Tahoe effectue une retransmission rapide, définit le seuil de démarrage lent à la moitié de la fenêtre de congestion actuelle, réduit la fenêtre de congestion à 1 MSS, et réinitialise à l’état de démarrage lent.
• Reno: si trois ACK en double sont reçus, Reno effectuera une retransmission rapide et ignorera la phase de démarrage lent en réduisant de moitié la fenêtre de congestion (au lieu de la définir sur 1 MSS comme Tahoe), en définissant le seuil de démarrage lent égal à la nouvelle fenêtre de congestion, et entrez dans une phase appelée récupération rapide.

Dans Tahoe et Reno, si un ACK expire (délai d’attente RTO), un démarrage lent est utilisé et les deux algorithmes réduisent la fenêtre de congestion à 1 MSS.

TCP VegasEdit

Jusqu’au milieu des années 1990, tous les délais d’attente définis par TCP et les retards aller-retour mesurés étaient basés uniquement sur le dernier paquet transmis dans le tampon de transmission. Les chercheurs de l’Université de l’Arizona Larry Peterson et Lawrence Brakmo ont présenté TCP Vegas (du nom de Las Vegas, la plus grande ville du Nevada) dans lequel des délais d’attente ont été définis et des retards aller-retour ont été mesurés pour chaque paquet dans le tampon de transmission. De plus, TCP Vegas utilise des augmentations additives dans la fenêtre de congestion. Dans une étude de comparaison de divers CCAs TCP, TCP Vegas semblait être le plus lisse suivi de TCP CUBIC.

TCP Vegas n’a pas été largement déployé en dehors du laboratoire de Peterson, mais a été sélectionné comme méthode de contrôle de congestion par défaut pour le firmware DD-WRT v24 SP2.

TCP New RenoEdit

TCP New Reno, défini par la RFC 6582 (qui rend obsolètes les définitions précédentes des RFC 3782 et RFC 2582), améliore la retransmission pendant la phase de récupération rapide de TCP Reno. Pendant la récupération rapide, pour garder la fenêtre de transmission pleine, pour chaque ACK en double renvoyé, un nouveau paquet non envoyé à la fin de la fenêtre de congestion est envoyé. Pour chaque ACK qui progresse partiellement dans l’espace de séquence, l’expéditeur suppose que l’ACK pointe vers un nouveau trou, et le paquet suivant au-delà du numéro de séquence ACKed est envoyé.

Comme le délai d’attente est réinitialisé chaque fois qu’il y a une progression dans le tampon de transmission, New Reno peut remplir de grands trous, ou plusieurs trous, dans l’espace de séquence – un peu comme TCP SACK. Étant donné que New Reno peut envoyer de nouveaux paquets à la fin de la fenêtre de congestion pendant la récupération rapide, un débit élevé est maintenu pendant le processus de remplissage des trous, même lorsqu’il y a plusieurs trous, de plusieurs paquets chacun. Lorsque TCP entre dans fast recovery, il enregistre le numéro de séquence de paquets non acquittés le plus élevé en circulation. Lorsque ce numéro de séquence est reconnu, TCP revient à l’état d’évitement de congestion.

Un problème se produit avec la nouvelle Reno lorsqu’il n’y a pas de pertes de paquets, mais que les paquets sont réorganisés par plus de 3 numéros de séquence de paquets. Dans ce cas, New Reno entre par erreur dans la récupération rapide. Lorsque le paquet réorganisé est délivré, la progression du numéro de séquence ACK se produit et à partir de là jusqu’à la fin de la récupération rapide, toute la progression du numéro de séquence produit une retransmission en double et inutile qui est immédiatement ACKée.

New Reno fonctionne aussi bien que SACK avec de faibles taux d’erreur de paquets, et surpasse considérablement Reno avec des taux d’erreur élevés.

TCP HyblaEdit

TCP Hybla vise à éliminer les pénalités pour les connexions TCP qui intègrent une liaison radio terrestre ou satellite à haute latence. Les améliorations d’Hybla sont basées sur une évaluation analytique de la dynamique de la fenêtre de congestion.

TCP BICEdit

Le contrôle de congestion à augmentation binaire (BIC) est une implémentation TCP avec un CCA optimisé pour les réseaux à haut débit à latence élevée, appelés réseaux fat longs. BIC est utilisé par défaut dans les noyaux Linux 2.6.8 à 2.6.18.

TCP CUBICEdit

CUBIC est une dérivée moins agressive et plus systématique de BIC, dans laquelle la fenêtre est une fonction cubique du temps depuis le dernier événement de congestion, avec le point d’inflexion défini sur la fenêtre avant l’événement. CUBIC est utilisé par défaut dans les noyaux Linux entre les versions 2.6.19 et 3.2.

Agile-SD TCPEdit

Agile-SD est un CCA basé sur Linux conçu pour le noyau Linux réel. Il s’agit d’un algorithme côté récepteur qui utilise une approche basée sur la perte utilisant un nouveau mécanisme, appelé facteur d’agilité (AF). pour augmenter l’utilisation de la bande passante sur les réseaux à grande vitesse et à courte distance (réseaux à faible PDB) tels que les réseaux locaux ou les réseaux à fibre optique, en particulier lorsque la taille de la mémoire tampon appliquée est faible. Il a été évalué en comparant ses performances à Compound-TCP (le CCA par défaut dans MS Windows) et CUBIC (le par défaut de Linux) à l’aide du simulateur NS-2. Il améliore les performances totales jusqu’à 55% en termes de débit moyen.

TCP Westwood+Edit

Westwood+ est une modification de TCP Reno réservée aux expéditeurs qui optimise les performances du contrôle de la congestion TCP sur les réseaux câblés et sans fil. TCP Westwood+ est basé sur une estimation de bande passante de bout en bout pour définir la fenêtre de congestion et le seuil de démarrage lent après un épisode de congestion, c’est-à-dire après trois accusés de réception en double ou un délai d’attente. La bande passante est estimée en faisant la moyenne du taux de retour des paquets d’acquittement. Contrairement à TCP Reno, qui réduit de moitié aveuglément la fenêtre de congestion après trois ACK en double, TCP Westwood + définit de manière adaptative un seuil de démarrage lent et une fenêtre de congestion qui prend en compte une estimation de la bande passante disponible au moment où la congestion est ressentie. Par rapport à Reno et New Reno, Westwood+ augmente considérablement le débit sur les liaisons sans fil et améliore l’équité dans les réseaux câblés.

Compound TCPEdit

Compound TCP est une implémentation Microsoft de TCP qui maintient simultanément deux fenêtres de congestion différentes, dans le but d’obtenir de bonnes performances sur les réseaux locaux sans nuire à l’équité. Il a été largement déployé dans les versions Windows depuis Microsoft Windows Vista et Windows Server 2008 et a été porté sur les anciennes versions de Microsoft Windows ainsi que Linux.

Réduction du taux proportionnel TCP

La réduction du taux proportionnel TCP (PRR) est un algorithme conçu pour améliorer la précision des données envoyées pendant la récupération. L’algorithme garantit que la taille de la fenêtre après la récupération est aussi proche que possible du seuil de démarrage lent. Dans les tests effectués par Google, la PRR a entraîné une réduction de 3 à 10% de la latence moyenne et les délais d’attente de récupération ont été réduits de 5%. PRR est disponible dans les noyaux Linux depuis la version 3.2.

TCP BBREdit

La bande passante de goulot d’étranglement et le temps de propagation aller-retour (BBR) sont un CCA développé chez Google en 2016. Alors que la plupart des CCA sont basés sur la perte, en ce sens qu’ils s’appuient sur la perte de paquets pour détecter la congestion et les taux de transmission inférieurs, BBR, comme TCP Vegas, est basé sur un modèle. L’algorithme utilise la bande passante maximale et le temps aller-retour auquel le réseau a livré le vol le plus récent de paquets de données sortants pour construire un modèle du réseau. Chaque accusé de réception cumulatif ou sélectif d’un paquet produit un échantillon de débit qui enregistre la quantité de données délivrées sur l’intervalle de temps entre la transmission d’un paquet de données et l’accusé de réception de ce paquet. Au fur et à mesure que les contrôleurs d’interface réseau évoluent de performances en mégabits par seconde à gigabits par seconde, la latence associée à la charge mémoire tampon au lieu de la perte de paquets devient un marqueur plus fiable du débit maximal, ce qui fait des CCAS basés sur des modèles qui fournissent un débit plus élevé et une latence plus faible, tels que BBR, une alternative plus fiable aux algorithmes plus populaires basés sur les pertes comme TCP CUBIC.

BBR est disponible pour Linux TCP depuis Linux 4.9. Il est également disponible pour QUIC.

La version 1 de BBR (BBRv1) est efficace et rapide, mais son équité avec les flux non BBR est contestée. Lorsqu’il est implémenté sur YouTube, BBRv1 a généré un débit réseau en moyenne supérieur de 4 % et jusqu’à 14% dans certains pays. Alors que la présentation de Google montre que BBRv1 coexiste bien avec CUBIC, des chercheurs comme Geoff Huston et Hock, Bless et Zitterbart trouvent cela injuste pour les autres flux et non évolutif. Hock et al ont également trouvé « des problèmes inhérents graves tels que des retards de file d’attente accrus, une injustice et une perte massive de paquets » dans l’implémentation BBR de Linux 4.9.

Soheil Abbasloo et coll. (auteurs de C2TCP) montrent que BBRv1 ne fonctionne pas bien dans des environnements dynamiques tels que les réseaux cellulaires. Ils ont également montré que BBR avait un problème d’injustice. Par exemple, lorsqu’un flux CUBIQUE (qui est l’implémentation TCP par défaut sous Linux, Android et macOS) coexiste avec un flux BBR dans le réseau, le flux BBR peut dominer le flux CUBIQUE et en tirer toute la bande passante de liaison (voir figure 18 dans).

La version 2 tente de résoudre le problème de l’injustice lorsqu’elle fonctionne parallèlement à la gestion de la congestion basée sur les pertes, telle que CUBIC. Dans BBRv2, le modèle utilisé par BBRv1 est augmenté pour inclure des informations sur la perte de paquets et des informations provenant de la notification de congestion explicite (ECN). Alors que BBRv2 peut parfois avoir un débit inférieur à BBRv1, il est généralement considéré comme ayant un meilleur débit.

C2TCPEdit

Cellular Controlled Delay TCP (C2TCP) a été motivé par l’absence d’une approche TCP flexible de bout en bout pouvant satisfaire diverses exigences de QoS de différentes applications sans nécessiter de modifications des périphériques réseau. C2TCP vise à satisfaire les exigences de latence ultra-faible et de bande passante élevée d’applications telles que la réalité virtuelle, la vidéoconférence, les jeux en ligne, les systèmes de communication véhiculaire, etc. dans un environnement très dynamique tel que les réseaux cellulaires LTE actuels et futurs 5G. C2TCP fonctionne comme un module complémentaire au-dessus de TCP basé sur la perte (par exemple Reno, NewReno, CUBIC, BIC,…) et rend le délai moyen des paquets limité aux délais souhaités définis par les applications.

Des chercheurs de l’Université de New York ont montré que C2TCP surpasse les performances de retard / gigue de divers schémas TCP de pointe. Par exemple, ils ont montré que par rapport à BBR, CUBIC et Westwood en moyenne, C2TCP diminue le retard moyen des paquets d’environ 250%, 900% et 700% respectivement sur divers environnements de réseau cellulaire.

C2TCP doit uniquement être installé côté serveur.

Elastic-TCPEdit

Elastic-TCP a été proposé en février 2019 par Mohamed A. Alrshah et al. pour augmenter l’utilisation de la bande passante sur les réseaux à haut PDB pour prendre en charge les applications récentes telles que le cloud computing, le transfert de Big Data, l’IoT, etc. C’est un CCA basé sur Linux qui est conçu pour le noyau Linux. Il s’agit d’un algorithme côté récepteur qui utilise une approche basée sur les pertes et les retards utilisant un nouveau mécanisme, appelé Fonction de pondération corrélée à la fenêtre (WWF). Il a un haut niveau d’élasticité pour faire face à différentes caractéristiques du réseau sans avoir besoin d’un réglage humain. Il a été évalué en comparant ses performances à Compound-TCP (le CCA par défaut dans MS Windows), CUBIC (le par défaut de Linux) et TCP-BBR (le par défaut de Linux 4.9 par Google) en utilisant le simulateur et le banc d’essai NS-2. Elastic-TCP améliore considérablement les performances totales en termes de débit moyen, de taux de perte et de délai.

PNFSA/NACubicEdit

Récemment, Soheil Abbasloo et. Al. PNFSA proposé (TCP assisté par réseau) une conception controversée de TCP ciblant les réseaux périphériques mobiles tels que MEC. L’idée clé du PNFSA est que si les caractéristiques du réseau étaient connues à l’avance, le PCT aurait été mieux conçu. Par conséquent, le PNFSA utilise les caractéristiques et propriétés disponibles dans les architectures cellulaires actuelles basées sur MEC pour rapprocher les performances du TCP des performances optimales. Le PNFSA utilise une rétroaction hors bande du réseau vers les serveurs situés à proximité. Le retour d’information du réseau, qui inclut la capacité de liaison d’accès cellulaire et la RTT minimale du réseau, guide les serveurs pour ajuster leurs tarifs d’envoi. Comme le montrent les résultats préliminaires, le PNFSA surpasse les schémas TCP de pointe en atteignant au moins 2 fois plus de puissance (définie comme Débit/retard). Le PNFSA remplace le schéma TCP traditionnel à l’expéditeur.

Pour résoudre le problème de compatibilité ascendante, ils ont proposé une autre version appelée NACubic. NACubic est une conception rétrocompatible, ne nécessitant aucun changement de TCP sur les nœuds connectés. NACubic utilise la rétroaction reçue et applique un plafond sur la fenêtre de congestion (CWND) et le taux de stimulation au besoin.

Autres algorithmes d’évitement de congestion TCP

• TCP RAPIDE
• TCP RAPIDE généralisé
• H-TCP
• TCP de centre de données
• TCP haute vitesse
• HSTCP-LP
• TCP-Illinois
• TCP-LP
• SAC DE TCP
• TCP évolutif
• TCP Veno
• Westwood
• XCP
• YeAH-TCP
• TCP-FIT
• Évitement de congestion avec Intervalle de temps normalisé (CANIT)
• Contrôle de congestion de réseau neuronal non linéaire basé sur un algorithme génétique pour les réseaux TCP/IP

TCP New Reno était le plus couramment implémenté algorithme, le support SACK est très courant et est une extension de Reno / New Reno. La plupart des autres sont des propositions concurrentes qui doivent encore être évaluées. À partir de la version 2.6.8, le noyau Linux a commuté l’implémentation par défaut de New Reno vers BIC. L’implémentation par défaut a de nouveau été changée en CUBIC dans la version 2.6.19. FreeBSD utilise New Reno comme algorithme par défaut. Cependant, il prend en charge un certain nombre d’autres choix.

Lorsque le produit par flux de bande passante et de latence augmente, quel que soit le schéma de mise en file d’attente, TCP devient inefficace et sujet à l’instabilité. Cela devient de plus en plus important à mesure qu’Internet évolue pour intégrer des liaisons optiques à très large bande passante.

TCP Interactive (iTCP) permet aux applications de s’abonner à des événements TCP et de répondre en conséquence, ce qui permet diverses extensions fonctionnelles à TCP depuis la couche TCP extérieure. La plupart des schémas de congestion TCP fonctionnent en interne. iTCP permet en outre aux applications avancées de participer directement au contrôle de la congestion, par exemple pour contrôler le débit de génération de source.

Zeta-TCP détecte les congestions à partir des mesures de latence et de taux de perte, et applique différentes stratégies de backoff de fenêtre de congestion en fonction de la probabilité des congestions pour maximiser le goodput. Il a également quelques autres améliorations pour détecter avec précision les pertes de paquets, en évitant la retransmission du délai d’attente de retransmission; et accélérer / contrôler le trafic entrant (téléchargement).