La cause cachée d’un Internet lent et comment y remédier ?

Il existe une petite histoire célèbre sur la lenteur de la connexion Internet, racontée par Jim Gettys, un programmeur informatique chevronné qui travaille actuellement chez Google.

En 2010, alors qu’il était chez lui, il téléchargeait un gros fichier sur son serveur de travail. Ses enfants sont entrés dans son bureau et lui ont dit: « Papa, Internet est lent aujourd’hui. »

Se demandant comment son activité de téléchargement pouvait affecter les téléchargements de ses enfants, il a commencé à enquêter.

En expérimentant des pings et différents niveaux de charge sur sa connexion Internet, il a découvert que les latences étaient souvent quatre à dix fois plus importantes que ce à quoi on aurait dû s’attendre. Il a appelé le phénomène « bufferbloat ». Sa conclusion était que les paquets de données critiques étaient piégés dans des files d’attentes tampons excessivement volumineuses.

Depuis le moment où Gettys a rendu son observation publique, des chercheurs d’entreprises telles que Cisco et Google, de grandes universités de recherche et des groupes de normalisation comme l’IETF ont enquêté, testé et écrit sur le bufferbloat.

Alors, qui est le plus touché par ce phénomène ?

Toute personne qui navigue activement ou utilise des moteurs de recherche. Aussi, toute personne qui utilise des applications en temps réel comme la voix ou la vidéo.Les employés travaillant à domicile, dans des hôtels ou sur des points d’accès Wi-Fi. Habituellement, les hôtels, les cafés, les restaurants Wi-Fi sont sujets à de très graves problèmes de bufferbloat.

Quel type de trafic est concerné ?

Le trafic circulant sur des connexions dont la bande passante consommée est élevée dans la direction opposée se détériorera. Les applications utilisant de petits paquets tels que VoIP, DNS et ARP peuvent également en souffrir. L’impact sur la VoIP serait une latence et une gigue accrues. Les requêtes DNS peuvent être renvoyées en deux à huit fois le temps de réponse normal.

Comment un problème affectant le fonctionnement d’internet a-t-il pu se cacher aussi longtemps ?

Il y a trois raisons principales. Premièrement, le problème est étroitement lié au fonctionnement du protocole TCP et à la gestion des files d’attentes tampons réseau. Deuxièmement, il existe une croyance largement répandue selon laquelle l’abandon de paquets sur Internet est toujours une mauvaise chose. La vérité est que la suppression de paquets est absolument essentielle au bon fonctionnement de TCP. Troisièmement, il existe une large conviction que le moyen d’éliminer presque toute détérioration des performances consiste à ajouter de la bande passante.

Alors, qu’est-ce que le bufferbloat exactement ?

Afin de réduire la perte de paquets sur Internet, les opérateurs de réseau, les développeurs et les ingénieurs ont multiplié la taille des files d’attentes tampons du réseau. Cela augmente la latence mais a peu d’effet sur le débit. Par conséquent, les petits paquets critiques tels que ceux des « accusés de réception » VoIP, DNS et TCP peuvent être piégés dans des files d’attente derrière des paquets beaucoup plus volumineux provenant de transferts de fichiers et d’autres transferts en masse, tels que la vidéo à débit binaire adaptatif.

Il y a un problème de perception lié à la gestion des files d’attentes tampons (ou Tampons). Les tests, les livres blancs décrivent souvent les tampons comme de petits morceaux de mémoire. Le plus souvent, les tampons peuvent contenir des centaines, voire des milliers de paquets à tout instant.

Et, ils ne sont pas seulement dans les périphériques réseau. Ils se trouvent également dans la pile de protocoles de la station terminale, du pilote de la carte réseau et de chaque passerelle sur le chemin entre les stations terminales.

Quel est l’impact de bufferbloat sur le fonctionnement de TCP ?

La grande majorité de notre trafic réseau utilise TCP comme protocole de transport. Comprendre le fonctionnement de TCP révèle pourquoi le bufferbloat est un problème. Lorsqu’une connexion TCP est établie, il y a une prise de contact à trois dans laquelle les entités TCP émettrice et réceptrice négocient les paramètres d’échange, y compris les numéros de séquence initiaux.

Supposons qu’un serveur FTP ait été invité à transférer un fichier volumineux. TCP commence généralement son transfert en envoyant quatre segments et en attendant l’accusé de réception de leur livraison. La politique habituelle d’accusé de réception est d’envoyer un ‘ack’ après chaque autre segment reçu.

Lorsque les quatre segments sont « acquittés », le récepteur augmente le débit d’envoi en envoyant huit segments et attend les accusés de réception. Après accusé de réception de ces segments, le débit d’envoi est augmenté à 16 et ainsi de suite.

Cette phase de livraison est appelée démarrage lent (Slow start). L’idée est de saturer le lien avec des paquets. Cependant, à un niveau appelé seuil de démarrage lent, l’expéditeur augmente le débit plus lentement en ajoutant un segment à la fois à chaque tour, plutôt que de doubler le débit.

Néanmoins, il y aura un point critique où la connexion sera surchargée parce qu’un tampon débordera. Un ou plusieurs paquets seront supprimés.

Lorsque l’expéditeur détecte que cela s’est produit, il réduit généralement son débit d’envoi de moitié et relance le démarrage lent. Finalement, le débit TCP s’adaptera à la capacité du circuit utilisé. Cet ensemble combiné d’étapes est connu sous le nom d’algorithme de contrôle de congestion TCP.

Alors, comment le bufferbloat interfère-t-il ?

Considérons une connexion entre une liaison haut débit et une liaison bas débit. Il s’agit d’une situation où les tampons sont considérés comme critiques. Par exemple, supposons que nous avons 1Gbps vers une passerelle résidentielle comme un modem câble ou DSL. Supposons également que le modem soit connecté à une connexion FAI qui fournit 10 Mbps Download et 2 Mbps Upload.

Le serveur FTP remplira la mémoire tampon entrant dans la connexion rapide plus rapidement que le taux de sortie dans la liaison plus lente. C’est la vitesse à laquelle les accusés de réception reviennent qui détermine finalement la vitesse à laquelle l’expéditeur peut transmettre.

Cependant, si ce tampon est grand, deux choses peuvent se produire. Tout d’abord, si la mémoire tampon se remplit, le dernier paquet arrivé est abandonné. C’est ce qu’on appelle la chute de la queue (Tail drop). L’accusé de réception qui informe l’expéditeur de cette suppression ne sera pas envoyé tant que le paquet suivant (après celui rejeté) n’arrive pas et soit déclaré hors service.

Cela pourrait prendre un temps considérable pour qu’il traverse le grand tampon. Certaines expériences que nous avons faites avec la vidéo à débit binaire adaptatif ont montré que près de 200 segments pouvaient être livrés avant que la station émettrice ne retransmette le segment abandonné.

De plus, si plusieurs flux y arrivent, la file d’attente peut évoluer vers une file d’attente permanente. C’est-à-dire qu’il peut atteindre un état stable dans lequel il y a un nombre fixe ou presque fixe de paquets dans la file d’attente. Si cette quantité n’est pas suffisante pour surcharger la mémoire tampon, aucun paquet n’est abandonné et le contrôle de congestion TCP est vaincu. Cependant, la latence pour tous les utilisateurs de la mémoire tampon a augmenté.

 

Gestion des tampons

Depuis un certain temps, il y a eu une prise de conscience que les files d’attente du réseau doivent être gérées. Pour ajouter la priorité à certains trafics, les bits diffserv de la couche IP peuvent être définis pour implémenter une politique qui donne la préférence à certains types de trafic, tels que le contrôle du réseau ou la VoIP. Pour ce faire, ils séparent ces types de trafic prioritaires dans des files d’attente distinctes.

Mais cela n’élimine pas le bufferbloat. Certaines files d’attente contenant le trafic non prioritaire continuent d’avoir le problème d’être trop grandes. Ceux-ci contiennent souvent de nombreux segments TCP volumineux. Donc, nous avons toujours le problème de l’impact négatif sur le mécanisme de congestion TCP.

Plusieurs techniques de gestion active des files d’attente (AQM) ont été introduites, notamment RED (Random Early Discard) et WRED (Weighted RED). Ceux-ci ont été conçus pour éliminer les paquets lorsque le tampon atteignait un niveau critique, mais n’était pas nécessairement plein. Mais ces techniques étaient imparfaites et la configuration de RED s’est avérée difficile. Par conséquent, RED et WRED ne sont pas largement mis en œuvre. Ce qu’il fallait, c’était une méthode automatique, jamais ajustée.

En 2012, Kathie Nichols et Van Jacobsen ont commencé à promouvoir une technique appelée CoDel ou Controlling Queue Delay. Cette méthode gère une file d’attente en suivant le temps qu’un paquet est dans la file d’attente, puisque le temps d’occupation dans la file d’attente est vraiment le problème crucial.

Il existe deux paramètres critiques, l’intervalle et le seuil. Si un intervalle de paquets a des retards plus longs que la cible, les paquets sont abandonnés de manière aléatoire. Notez que cette technique ne dépend pas de la taille de la file d’attente. Ce n’est pas non plus de la queue.

Le test de la procédure a montré un meilleur comportement de latence général que RED et des résultats bien meilleurs. Cela était particulièrement vrai avec les liaisons d’accès sans fil. De plus, la technique promettait d’être facile à intégrer dans le matériel.

La recommandation suivante pour l’atténuation du ballonnement tampon est venue de Dave Taht, Eric Dumazet, Jim Gettys et quelques autres. Appelé fq-codel, il est destiné à fournir un impact plus uniforme sur les différents flux traversant la file d’attente. Même Kathie Nichols et Van Jacobson préconisent l’utilisation de fq-codel.

Cette méthode sépare la file d’attente en 1024 sous-files d’attente par défaut. Ensuite, il affecte au hasard chaque nouveau flux à une file d’attente distincte. Dans chaque sous-file d’attente, Codel est appliqué pour aider au contrôle de la congestion TCP. La politique de retrait de la file d’attente est basée sur le DRR (Deficit Round Robin).

Que font Codel et fq-codel ?

Tout d’abord, ils s’assurent que le contrôle de congestion TCP fonctionne comme prévu. Deuxièmement, en mélangeant les paquets dans les files d’attente, les petits paquets critiques tels que les réponses DNS et les accusés de réception TCP ne sont pas piégés dans de grandes files d’attente. En d’autres termes, cela rend plus équitable le traitement des gros paquets et des petits paquets. Des recherches considérables ont démontré les avantages de l’utilisation de fq-codel. En fait, c’est dans les dernières distributions de Linux.

Où allons-nous à partir d’ici?

Malheureusement, la sensibilisation au ballonnement tampon n’est pas encore très répandue. Nous avons besoin de plus d’opérateurs de réseau et d’utilisateurs pour exécuter des tests facilement disponibles comme ICSI Netylyzr et le test sur www.DSLReports/speedtest/.

Ensuite, si vous détectez un problème important de bufferbloat, plusieurs alternatives s’offrent à vous :

1. Modifiez votre matériel d’accès aux périphériques utilisant une nouvelle distribution de Linux contenant fq-codel. Assurez-vous que la fonction est activée.
2. Placez un périphérique entre votre ordinateur et la passerelle/routeur dont la capacité de code fq est activée. Cela limitera l’utilisation des grands tampons du routeur.
3. Si tout le reste échoue, appliquez une limitation de débit aux liaisons montantes et des liens de téléchargement vers quelque chose juste en dessous de leur capacité nominale. Cela aidera à éliminer les grands tampons permanents. Cela vous coûtera une petite diminution du débit sous une faible charge. Cependant, il devrait améliorer considérablement les flux critiques tels que les accusés de réception DNS, ARP et TCP.

Plusieurs fournisseurs sont vivement intéressés par l’atténuation du bufferbloat. Cisco, en partenariat avec Comcast, a adopté une technique de gestion des files d’attente appelée PIE (Proportional Integral controller Enhanced) principalement développée par l’ingénieur de recherche distingué de Cisco, Rong Pan.

Time-Warner Cable semble bien connaître le sujet et est prêt à prendre des mesures pour atténuer le bufferbloat. Actiontec, un important fournisseur de passerelles résidentielles pour Verizon et Centurylink, a étudié le bufferbloat. Ils disent qu’ils prennent des mesures pour atténuer ses effets. Ruckess Wireless, un partenaire de Juniper, s’engage à poursuivre l’amélioration du problème de mise en mémoire tampon des liaisons d’accès.

Cette situation doit changer. Il est essentiel de comprendre que le débit global n’est pas le facteur préjudiciable le plus important, en particulier avec des activités telles que la navigation. Le facteur le plus important est le retard (delay).

Cette article, « La cause cachée d’un Internet lent et comment y remédier » a été initialement publiée par Network World.