Auteur Sujet: Patch Google ou "TCP Initial Congestion Window" à 10 (Lu 5316 fois)

vivien · « **le:** 27 octobre 2011 à 16:12:35 »

Patch Google ou "TCP Initial Congestion Window" à 10

J'ai pense avoir trouvé l'explication à gain de débit avec le noyaux Linux récents coté serveur :

Les réglages par défaut de la pile TCP du noyau ont été modifiés le noyeau linux 2.6.39 et suivant.
C'est un patch proposé par Google research consistant a passer la "TCP Initial Congestion Window" de 3 à 10

Google research à publié en juillet 2010 un PDF : An Argument for Increasing TCP’s Initial Congestion Window
(cliquez sur la miniature ci-dessous - le document est au format PDF)

La RFC datait de 2002 : RFC Increasing TCP's Initial Window - October 2002

Le protocole TCP spécifie un algorithme spécial pour découvrir le débit maximum que supporte une connexion. Cet algorithme, nommé « slow start », va commencer par envoyer très peu de données et va progressivement augmenter la cadence jusqu'à la saturation du lien. C'est bien pratique d'avoir ainsi un fonctionnement qui s'adapte aux conditions réelles du réseau... Comme l'indique le nom « slow start », on va commencer en douceur et la fenêtre de congestion (initial congestion window) est très petite au début de la connexion. La limite est de 3 segments pour les noyaux 2.6.38 et inférieurs, ce qui correspond environ à 4 Ko.

Google à publié un graphe que j'ai commenté en bleu pour le rendre un peu plus lisible :

Si la durée de connexion fait mois de 3 segments, pas de souci.

Si la durée de connexion fait plus plus de 3 segments, le serveur va attendre un acquittement avant d'envoyer plus de données, ce qui fait perdre du temps si la connexion à un haut débit ou une forte latence. (Si la connexion à un haut débit et une forte latence, le gain sera encore plus important vu que les 3 segments seront transmis immédiatement et qu'il faudra attendre pour le transfert de l'acquittement).

Google préconise d'augmenter la taille de la "TCP’s Initial Congestion Window" de 3 (valeur par défaut pour tous les système d'exploitation suivant la RFC 3390 qui date de 2002) à 10 segments, afin de profiter des gain qu'on subit les réseaux ces 9 dernières années.

La figure 1 montre que la 80% des requêtes à une recherches Google font entre 3 et 10 segments. Le gain (figure 2) sur une recherche google est intéressant et on a dans certains cas 20% de gain (cf pdf de l'étude). Le gain moyen serait d'environ 10% de gain de temps de latence d'une requête HTTP.

Comment expliquer que sur un fichier de 1 gigabit, le gain soit si élevé alors qu'il dépasse largement les 10 segments ?

J'ai remarqué que la monté en débit dépend fortement du ping (normal). Le fait d'avoir une TCP’s Initial Congestion Window va permettre une montée en débit beaucoup plus rapide et le gain ne se limite pas aux 10 premiers segments. En fait la TCP’s Initial Congestion Window ferait comme une baisse de ping et permettrais d'être beaucoup plus agressif sur la monté en débit et pas uniquement sur les 10 premiers segments :

Je trouve tout de même étonnant qu'une modification censée améliorer le débit de transfert des petits fichiers offre un gain sur la monté en débit encore plus important pour les gros fichiers dans le cas de très haut débit.

vivien · « **Réponse #1 le:** 10 mars 2012 à 22:37:12 »

Nouvelle optimisation google pour améliorer les débit dans le noyau linux 3.2
Google continue d'optimiser Internet et après sa modification du slow-start TCP dans le noyau linux 2.6.39, on a le droit maintenant à une optimisation du mécanisme de réduction du débit en cas de pertes de paquets dans le noyau linux 3.2.

Le noyau linux 3.2 sera intégré dans la prochaine version d'Ubuntu Server, la 12.04 LTS qui sort dans un mois et demi et est particulièrement adapté aux entreprises avec son support de 5 ans.

La RFC : Proportional Rate Reduction for TCP draft-mathis-tcpm-proportional-rate-reduction-01.txt
Un article en anglais => http://lwn.net/Articles/458610/
3 chercheurs de Google présente des pistes d'amélioration des performances. Seule la proposition de "Réduction du débit proportionnel en cas de perte de paquets" est inclus dans le noyau Linux 3.2.

Voici ci-dessous une traduction très libre à base de Google translation modifiée un peu à la main (je n'ai gardé que ce qui est dans le noyau linux 3.2) :

Presque tous les services offerts par Google sont livrés sur Internet, il est donc logique que la société aurait un intérêt dans l'amélioration des performances sur Internet. La session réseau du "Linux Plumbers Conference 2011" a présenté (entre-autre) l'exposé de Nandita Dukkipati.

Réduction du débit proportionnel

La "fenêtre de congestion" est la quantité de données qu'il peut avoir dans le réseau d'un bout à l'autre de la connexion avant de commencer à surcharger un lien. Les paquets perdus sont souvent un signe que la fenêtre de congestion est trop grande, de sorte que les implèmentations de TCP réduisent la fenêtre de façon significative lorsque la perte se produit. Diminuer la fenêtre de congestion réduit les performances, si bien que, si la perte de paquets a été un événement ponctuel, que le ralentissement sera tout à fait inutile. RFC 3517 décrit un algorithme pour amener la connexion à accélérer rapidement après un paquet perdu, mais, Nandita Dukkipati dit que nous pouvons faire mieux.

Selon Nandita, une grande partie des sessions de réseau entraînant des pertes de Google sur des serveurs qui à un moment donné; ceux qui ne peuvent prendre 7-10 fois plus de temps pour terminer. RFC 3517 fait partie du problème. Cet algorithme répond à une perte de paquets par réduire immédiatement la fenêtre de congestion dans la moitié; cela signifie que le système d'envoi doit, si la fenêtre de congestion a été complète au moment de la perte, attendez ACK pour la moitié des paquets en transit avant transmettre à nouveau. Qui provoque l'expéditeur d'aller silencieuse pour une période de temps prolongée. Il fonctionne assez bien dans les cas simples (un seul paquet perdu dans un flux de longue durée), mais il a tendance à encrasser les travaux lorsqu'il s'agit de flux à court ou pertes de paquets étendus.

Linux n'utilise pas stricte RFC 3517 maintenant, il utilise, au lieu, une amélioration appelée «réduire de moitié le taux." Avec cet algorithme, la fenêtre de congestion n'est pas divisé par deux immédiatement. Une fois la connexion passe en recouvrement des pertes, chaque entrant ACK (qui sera généralement accuser réception de deux paquets à l'autre extrémité) provoquera la fenêtre de congestion à être réduit en un seul paquet. Au cours d'un jeu complet de paquets en vol, la fenêtre sera réduite de moitié, mais le système d'envoi continuera à transmettre (à un taux inférieur) tandis que la réduction se passe. Le résultat est une plus grande fluidité et une latence réduite.

Mais réduire de moitié le taux peut être amélioré. Les accusés de réception dont il dépend sont eux-mêmes soumis à une perte, une perte prolongée peut provoquer une réduction significative de la fenêtre de congestion et de la lente reprise. Cet algorithme ne tient même pas commencer le processus d'élévation de la fenêtre de congestion de retour à la valeur la plus élevée possible jusqu'à ce que le processus de récupération est terminée. Ainsi, il peut prendre un certain temps pour revenir à pleine vitesse.

L'algorithme de réduction de taux proportionnel adopte une approche différente. La première étape consiste à calculer une estimation de la quantité de données encore en vol, suivi par un calcul de ce que, selon l'algorithme de contrôle de congestion dans l'utilisation, la fenêtre de congestion devrait maintenant être. Si la quantité de données dans le pipeline est inférieure à la fenêtre de congestion cible, le système va juste directement dans l'algorithme de démarrage lent TCP pour amener la fenêtre de congestion en arrière vers le haut. Ainsi, lorsque la connexion subit une salve de pertes, il va commencer essayer de reconstruire la fenêtre de congestion tout de suite au lieu de ramper le long d'une petite fenêtre pendant une période prolongée.

Si, au lieu, la quantité de données en vol est au moins aussi grande que la nouvelle fenêtre de congestion, d'un algorithme semblable à division par deux taux est utilisé. La réduction réelle est calculée par rapport à la fenêtre de congestion nouvelle, bien que, plutôt que d'être un strict d'un demi-coupe. Pour les pertes à la fois grandes et petites, l'accent mis sur l'aide des estimations de la quantité de données en vol au lieu de ACKs de comptage est dit de faire la récupération aller plus en douceur et d'éviter des réductions inutiles dans la fenêtre de congestion.

Combien plus est-il mieux? Nandita dit que Google a été en cours d'exécution sur les expériences de certains de ses systèmes; le résultat a été une réduction de 3-10% de la latence moyenne. Délais d'attente de récupération ont été réduites de 5%. Ce code est en cours de déploiement plus largement sur les serveurs Google, il a également été accepté pour la fusion au cours du cycle 3.2 de développement. Plus d'informations peuvent être trouvées dans le présent document RFC projet.

Source : LWN.net Par Jonathan Corbet le 13 septembre 2011

Auteur Sujet: Patch Google ou "TCP Initial Congestion Window" à 10 (Lu 5316 fois)

vivien

Patch Google ou "TCP Initial Congestion Window" à 10

vivien

TCP Initial Congestion Window