Explication du Datacenter TCP

La mise en réseau moderne contient un certain nombre d'améliorations par rapport à la pile TCP / IP de base. L'un de ceux-ci, particulièrement utile à l'intérieur du datacenter, a été développé par Microsoft Research en 2010 et appelé, de manière surprenante, DataCenter TCP (DCTCP).

DCTCP est un ensemble de modifications apportées à TCP, visant à remplir deux propriétés:
1. Améliorez la latence pour les petits messages sensibles à la latence
2. Ne pas diminuer le débit pour les gros flux sensibles au débit

La latence à l'intérieur du réseau provient de la mise en file d'attente à l'intérieur des routeurs. Par conséquent, DCTCP essaie de garder la file d'attente petite. La file d'attente reste petite lorsque sa taille est inférieure à K messages.

L'algorithme proposé réduit de manière adaptative la fenêtre de congestion TCP de sorte que la file d'attente reste petite.

Les améliorations par rapport à TCP nécessitent la modification des trois composants: routeur, récepteur, expéditeur:
1. Marquage des paquets avec l'indicateur Congestion Experienced (CE) pendant que la file d'attente devient plus longue que K par un routeur.
2. Transformer un flux de drapeaux CE en un flux de paquets TCP ACK par un récepteur. Plus précisément, le récepteur envoie immédiatement un ACK si l'indicateur CE dans le paquet actuel est différent du précédent. Pendant que l'indicateur CE est inchangé, il envoie des accusés de réception différés normaux. Le paquet ACK contient toujours la dernière valeur de l'indicateur CE.
3. Adapter la taille de la fenêtre d'encombrement en fonction du flux de paquets ECN-Echo agrégé par l'expéditeur. Tout d'abord, l'expéditeur calcule le taux de congestion (CR) - la moyenne mobile exponentielle parmi les indicateurs CE. DCTCP réduit la taille de la fenêtre proportionnellement à CR. Si CR est égal à 1 (chaque paquet avait le drapeau CE), la taille de la fenêtre serait divisée par deux, tout comme TCP.

L'évaluation montre que la latence des requêtes est nettement meilleure pour les transferts courts. Les performances des requêtes sensibles au débit ne sont pas moins bonnes.

Cependant, depuis 2010, plusieurs articles ont fait l'objet d'un examen et d'améliorations du DCTCP.

"Faciliter l'oscillation de la file d'attente: analyse et amélioration du DCTCP" de 2013 fait une expérience et découvre que le DCTCP est soumis à une oscillation sévère de la taille réelle de la file d'attente. Cela se produit car entre le premier paquet avec l'indicateur CE et la réaction de l'expéditeur, il y a au moins un délai RTT. L'article propose de diviser un seul seuil K en deux seuils K1 <K <K2 de sorte que la définition des indicateurs CE commence lorsque la taille de la file d'attente est égale à K1, avant que la congestion réelle ne se produise, et s'arrête à K2, avant que la taille de la file d'attente ne soit trop réduite.

Un autre article est «Un premier système de rétroaction sur la congestion et d'ajustement des tarifs pour les communications à plusieurs dans les données basées sur le cloud» publié en 2015, qui propose NewDCTCP - qui comprend deux améliorations:
1. Les drapeaux CE sont définis même pour les paquets arrivés avant la congestion
2. Schéma différent d'ajustement de la taille des fenêtres

L'un des derniers articles est "Multiple Congestion Points and Congestion Reaction Mechanisms for Improving DCTCP Performance in Data Center Networks" publié en juin 2018, qui montre que le sujet reste à jour et que le problème n'est pas encore résolu. Quoi qu'il en soit, le document combine l'approche à double seuil et introduit une nouvelle idée - l'ajustement de la fenêtre de congestion. Il prend en compte le nombre de colis envoyés et les ACK reçus lors du changement de taille de fenêtre.

Source: https://habr.com/ru/post/fr474282/


All Articles