Pourquoi CUBIC nous amène-t-il à reprendre le contrôle de goulets d’étranglement TCP ?

Contrôle de goulets d’étranglement TCP : schéma de base et algorithme TCP CUBIC

Le contrôle de goulets d’étranglement TCP est une partie fondamentale de ce protocole et au fil des années, il a subi un processus d’amélioration constante grâce à la génération de différentes versions, telles que TCP Tahoe, Reno, Vegas, etc.

Le cas de la version TCP CUBIC est intéressant, qui est depuis quelques années de contrôle de goulets d’étranglement appliqué par défaut par les systèmes Linux / Unix.

TCP CUBIC devient encore plus intéressant puisque Microsoft a décidé que cette version soit un élément fondamental de produits tels que Windows 10 et Windows Server 2019, comme lu dans ce document sur les nouveautés de Windows Server 2019 et dans celui-ci sur Windows 10.

Le fait d’avoir la même distribution dans les environnements Linux et Windows a conduit les administrateurs réseau à revoir l’idée derrière le contrôle de goulets d’étranglement TCP et ce que TCP CUBIC implique.

C’est précisément pour les soutenir dans cette tâche que nous avons rédigé cet article. Commençons par revoir l’idée fondamentale du contrôle de goulets d’étranglement TCP.

Gestion des fenêtres comme base du contrôle de goulets d’étranglement TCP

TCP introduit le concept de « fenêtres » pour établir un contrôle de flux de trafic et gérer les connexions entre deux équipements : un émetteur et un récepteur.

Ainsi, l’implémentation de base est connue sous le nom de fenêtre glissante ou rwnd (fenêtre de réception), dans laquelle, par connexion, une taille de fenêtre est définie qui représente le nombre de paquets que l’expéditeur peut envoyer au récepteur sans attendre les paquets d’accusé de réception (paquets ACK).

Cependant, le protocole de fenêtre glissante gère la connexion en fonction des capacités de tampon de l’équipement récepteur, mais ne reconnaît pas les problèmes de goulot d’étranglement associés au réseau.

Afin d’adapter la transmission en fonction du niveau de goulets d’étranglement, TCP introduit une autre fenêtre.

C’est la fenêtre de goulets d’étranglement ou cwnd avec laquelle il prétend réguler le nombre de paquets envoyés en fonction de la perception de goulets d’étranglement de TCP.

Mais, comment TCP perçoit-il les goulets d’étranglement réseau et que fait-il en conséquence ?

L’idée de base est la suivante :

1. S’il y a des paquets perdus, on suppose qu’il y a un goulet d’étranglement dans le réseau et la perte de paquets est évaluée sur la base des paquets d’accusé de réception reçus et non reçus.
2. S’il est déterminé qu’il y a des goulets d’étranglement, la fenêtre de goulet d’étranglement est modifiée pour que l’expéditeur ralentisse l’envoi de ses paquets.
3. S’il est déterminé qu’il n’y a pas des goulets d’étranglement, la fenêtre de goulets d’étranglement sera modifiée afin que l’expéditeur puisse envoyer plus de paquets.

Sur cette procédure de base, nous trouvons plusieurs algorithmes qui l’implémentent.

Les algorithmes proposent des choses comme le nombre de paquets ACK non reçus qui impliquent des goulets d’étranglement, combien diminuer ou augmenter la fenêtre cwnd, comment calculer le taux de transfert à partir de la fenêtre de goulet d’étranglement, etc.

Ensuite, nous vous suggérons de revoir l’évolution de ces algorithmes afin d’être clair sur la portée de ceux qui sont actuellement utilisés.

Evolution des algorithmes de contrôle de goulets d’étranglement TCP

L’évolution du contrôle de goulets d’étranglement TCP commence au milieu des années 1980.

Jusque-là, le contrôle de la diffusion en continu basé sur une fenêtre coulissante fonctionnait assez bien, mais avec la popularisation d’Internet, les goulets d’étranglement sont devenus un problème.

Entre 1986 et 1988, Van Jacobson a proposé le schéma de contrôle de base des goulets d’étranglement et a développé le premier protocole de mise en œuvre, connu sous le nom de TCP Tahoe.

Ici, il est proposé que le rapport de transmission considère la valeur des fenêtres de réception et de goulets d’étranglement, en laissant l’expéditeur limité à un rapport de transmission dont la valeur minimale est rwnd et son maximum est cwnd.

En 1990 avec TCP Reno l’application de l’algorithme AIMD (additive increase / multiplicative decrease) a été introduite selon laquelle :

1. La vitesse de transmission augmentera progressivement jusqu’à ce qu’une perte de paquets se produise.
2. L’augmentation sera réalisée en augmentant linéairement la fenêtre de goulet d’étranglement, c’est-à-dire en ajoutant une valeur.
3. Dans le cas où un goulot d’étranglement est déduit, le rapport de transmission sera diminué, mais dans ce cas une diminution sera faite en multipliant par une valeur.

Après TCP Reno, d’autres algorithmes et versions de TCP sont apparus qui ont tenté de prendre les préceptes du contrôle de goulets d’étranglement TCP et de l’affiner, en subissant une grande diversification des versions et des portées.

Ainsi, TCP Vegas soulève pour prêter attention aux valeurs de délai pour déduire les goulets d’étranglement ou le cas de ECN (Explicit Congestion Notification) qui introduit la possibilité que les routeurs réseau notifient à l’équipement émetteur des conditions du goulet d’étranglement.

Le développement d’un grand nombre de mécanismes permettant la mise en œuvre d’AIMD a également été promu, comme Slow Start, Fast Retransmission, Fast recovery, Adaptive timeout ou ACK clocking.

En tout cas, il est intéressant de préciser la situation que nous avions jusqu’à récemment.

Le monde Linux avait opté pour TCP CUBIC, qui est un héritier de TCP Reno et BIC TCP, il repose donc sur la perte de paquets et non sur les valeurs de retard pour déterminer les goulets d’étranglement.

Alors que le monde Windows utilisait un algorithme appelé TCP Compound, qui provient de TCP Fast, qui à son tour est l’héritier de TCP Vegas, ils sont donc basés sur des retards pour déduire le goulet d’étranglement.

Comme nous l’avons mentionné au début de cet article, cette situation a changé au moment où Microsoft a décidé d’introduire TCP CUBIC dans ses nouveaux produits.

TCP CUBIC

TCP CUBIC est un algorithme de contrôle de goulets d’étranglement TCP né de l’idée de tirer parti du fait que les liaisons de communication ont aujourd’hui tendance à avoir des niveaux de bande passante croissants.

Dans un réseau constitué de liaisons à large bande passante, un algorithme de contrôle de congestion qui augmente lentement le débit de transmission peut finir par gaspiller la capacité des liaisons.

L’intention est d’avoir un algorithme qui fonctionne avec des fenêtres de goulets d’étranglement dont les processus d’incrémentation sont plus agressifs, mais qui ne peuvent pas surcharger le réseau.

Pour ce faire, il est proposé que le schéma d’augmentation et de diminution du rapport de transmission soit établi selon une fonction cubique. Voyons la figure suivante :

Description : fonction cubique qui régule la fenêtre d’encombrement selon l’algorithme Cubic
Pris à partir de : IEEE Xplore Digital Library :
https://ieeexplore.ieee.org/document/8368259

La procédure suivie par l’algorithme est, en résumé, la suivante :

1. Au moment de subir un événement de goulot d’étranglement, la taille de la fenêtre pour cet instant sera enregistrée comme Wmax ou la taille de fenêtre maximale.
2. La valeur Wmax sera définie comme le point d’inflexion de la fonction cubique qui régira la croissance de la fenêtre de goulet d’étranglement.
3. La transmission sera alors redémarrée avec une valeur de fenêtre inférieure et, si aucun goulet d’étranglement n’est constatée, cette valeur augmentera en fonction de la partie concave de la fonction cubique.
4. À mesure que la fenêtre approche Wmax, les augmentations ralentiront.
5. Une fois le point d’inflexion atteint – c’est-à-dire Wmax-, la valeur de la fenêtre continuera d’augmenter discrètement.
6. Enfin, si le réseau ne subit toujours pas d’encombrement, la taille de la fenêtre continuera d’augmenter en fonction de la partie convexe de la fonction.

Comme nous pouvons le voir, CUBIC implémente un schéma de grands incréments au début, qui diminuent autour de la taille de la fenêtre qui a provoqué le dernier goulet d’étranglement, puis continuent d’augmenter avec de grands incréments.

Si vous souhaitez approfondir les détails techniques de l’algorithme CUBIC, vous pouvez commencer par lire l’ouvrage suivant: https://www.cs.princeton.edu/courses/archive/fall16/cos561/papers/Cubic08.pdf

Le contrôle de goulets d’étranglement TCP et les outils de supervision

Un point intéressant à propos du contrôle de goulets d’étranglement TCP est qu’il implique des processus avec les caractéristiques suivantes :

1. Ces processus s’exécutent uniquement sur les ordinateurs émetteurs.
2. Ils ne génèrent pas de trafic
3. Ils favorisent une répartition équitable de la capacité de transport du réseau. Comme chaque équipe décide de sa capacité de transmission, en ne prêtant attention qu’au comportement du réseau qu’elle observe, elle ne favorise ni ne nuit en aucune circonstance à aucune équipe émettrice.

Maintenant, il est facile de comprendre qu’il n’est pas juste de comparer les capacités des algorithmes de contrôle de goulets d’étranglement TCP avec les capacités d’un outil de supervision, car ceux sont deux univers complètement différents.

Cependant, nous proposons de repenser la portée d’un outil de supervision à usage général comme Pandora FMS sous l’angle de ces algorithmes.

Ainsi, les points suivants se posent :

1. L’objet d’étude d’un outil de supervision est beaucoup plus large : Un outil de supervision doit prendre en compte tous les protocoles présents sur la plateforme, pas seulement TCP.
2. L’idée d’un outil de supervision est d’intégrer tous les composants sous son schéma, offrant toujours une vision globale de la plateforme.
3. Les mécanismes utilisés par un outil de supervision, tels que ceux associés à la gestion réseau tel que SNMP ou au contrôle de flux de trafic tel que NetFlow, sont des protocoles qui impliquent l’envoi de paquets associés à leurs fonctions. Mais, bien sûr, les outils de supervision visent à établir un schéma qui interfère juste ce qu’il faut avec les performances globales de la plateforme.
4. La cause fondamentale du goulet d’étranglement : L’approche que les outils de supervision mettent en œuvre vise à trouver la cause première du goulet d’étranglement. Peut-être que la cause d’un état d’encombrement est dans la mauvaise configuration d’un protocole de routage, qui ne sera pas corrigée si l’équipement émetteur modifie sa capacité de transmission.
5. Enfin, il faut dire que l’un des objectifs des outils de supervision est de générer des informations permettant de prédire une situation de congestion avant son apparition.

Aussi, si vous ne disposez pas encore d’outil de supervision pour votre plateforme, sachez que vous êtes au bon endroit. En fait, si vous avez plus de 100 appareils, nous vous suggérons d’évaluer Pandora FMS Enterprise ici.