Journal Une bosse sur la ligne pour combattre le bufferbloat ?

30
10
août
2018

Sommaire

Salut nal,

T'as rien compris au titre ? C'est normal.

ATTENTION: Je vais pas te faire un cours de réseau complet. Déjà, parce que c'est pas mon domaine. Et puis parce que j'ai juste assez de connaissances pour faire « oui-oui » de la tête quand j'ai lu l'article original en anglais, mais pas assez pour avoir vraiment bien tout compris de A jusqu'à Z (et donc te réexpliquer).

apenwarr a récemment publié un article (en anglais) sur son blog nommé « A little bump in the wire that makes your Internet faster », soit « Une petite bosse dans le fil qui rend ton Internet plus rapide ».

En gros, ça part du constat que les routeurs xDSL fournis par nos escrocs préférés (les FAI) sont optimisés dans leur config pour une connexion correspondant au débit théorique maximum, celui que les départements marketing nous foutent sous le nez à longueur de temps.

Or, quand on atteint pas en pratique ce débit pour lequel les queues sur le routeur ont été optimisées, cela amène à une grande augmentation de la latence sur les sessions TCP. Si ça ne t'est jamais arrivé sur ta connexion, tant mieux !!!!! Moi perso, ça m'arrive souvent (plusieurs heures par jour) de même pas pouvoir poster un formulaire HTTP (genre ouvrir une issue sur Github) tellement la connexion est saturée (une connexion ADSL pour 40 personnes). D'où mon intérêt pour la solution présentée…

Du coup, notre amiE propose de mettre en place un petit appareil sur le réseau qui va mettre en place un certain nombre de queues et de règles de façonnage de trafic (trafic shaping en VO). Cet appareil sera placé entre la box ADSL et le réseau local. De son côté, ça se passe sur un routeur D-Link DIR-825… mais tout ça peut se faire sur n'importe quelle machine avec en gros deux ports ethernet à disposition.

Logiciellement, la solution mise en place est fq_codel. C'est un mélange entre FQ et CoDel :

  • FQ (Fair Queuing) met en place une queue par flux réseau et alterne équitablement entre elles, en privilégiant les petits flux réseaux. Par exemple, une session interactive SSH (petit flux) sera privilégiée par rapport à un transfert de fichier en scp (gros flux)
  • CoDel (Controled Delay) ralentit les flux réseaux (en jetant des paquets) en fonction du temps que le flux met à traverser le réseau, sans attendre que la queue soit pleine (souvent, un routeur ne jette des paquets que quand sa queue est pleine)

Il paraît que tout ça est intégré à nos distros préférées, et qu'il existe un paquet SQM sur OpenWRT/LEDE (← les deux projets ont refusionné). Il faut juste spécifier manuellement la capacité de ta ligne, et c'est parti :

Interface de SQM sur OpenWRT

Après, l'article original décrit comment configurer son routeur pour séparer clairement le WAN, un port qui donne accès uniquement en LAN pour la configuration du routeur, et un port bridgé avec le WAN qui donne accès à Internet passant par la "bosse" fq_codel. Mais comme j'ai dit que je ferais pas un cours de réseau, je vais pas détailler tout ça.

Si tu parles anglais, je te renvoie vers l'article original, sinon j'espère que d'autres libristes qui s'y connaissent bien en réseau sauront francophoniquement éclairer ta lanterne dans un autre journal.

Conclusion

Voici les résultats de test de débit que apenwarr a pris avant et après la mise en place de sa bosse.

Situation Download (Mbit/s) Upload (Kbit/s) Latence (ms)
Avant 4.6 72 80
Après 3.2 360 31

On voit que si la vitesse en download a été réduite de plus de 1Mbit/s, la latence est passée de 80ms à 30ms, et l'upload de 70Kb/s à 360Kb/s. Ce qui en pratique permet des connexions beaucoup plus rapides ! Car de nombreuses applications et de nombreux protocoles (dont le web) requièrent de faire un certain nombre d'allers-retours (roundtrips) et dans ces cas là la latence devient souvent le facteur limitant.

En gros, pour un usage moyen d'internet (d'autres usages sont possibles !) une connexion en fibre optique en gigabit ne te servirait à rien du tout si elle avait la latence d'une connexion satellite.

Bon, moi je vais essayer de me trouver un routeur compatible OpenWRT pour mettre en place ça chez moi. Si t'as une idée d'où trouver un routeur comme ça (gratuit ou d'occas) autour de Paris, fais moi signe dans les commentaires :)

Après la Brique Internet, voici donc venue la Bosse Internet. Peut-être ce concept peut-il intéresser des camarades de la FFDN pour intégrer ce genre de solutions à leur brique ? Ou pour prendre en considération dans la configuration des routeurs des abonnéEs ? N'hésite pas à en parler à l'équipe de ton FAI local, que ça soit autour d'une bière ou d'un jus de pomme !

Est-ce que t'en as besoin ?

Au final, j'ai tellement gratté du français que j'ai même oublié de glisser le mot « bufferbloat » (en anglais) dans le journal. C'est le terme générique qui désigne les queues et buffers mal configurées causant des problèmes de latence sur le réseau. D'après Wikipedia, la première étude sur les bufferbloats remonte à 1985… Autant dire que si beaucoup de choses ont changé sur le réseau depuis, ce problème est toujours omniprésent. D'où le projet bufflerbloat.net qui regroupe des gens travaillant sur la question, des routeurs aux drivers wifi de nos laptops.

Alors, est-ce que tu es toi aussi victime de bufferbloat? Le projet bufflerbloat.net propose des tests. En gros, le plus simple pour tester ça en deuspi c'est de lancer en arrière-plan un ping, et en même temps un test de connexion (par exemple sur speedtest.net). Si le test de connexion fait monter ton ping (dans mon cas passant de 25ms à plus de 100ms), alors tu peux toi aussi te lancer dans la chasse au bufferbloat !

  • # Mais pourquoi j'ai fait le test :S

    Posté par . Évalué à 8 (+8/-0).

    Voila voila, je viens de faire le test du ping et mon ping passe de 12 a 90ms pendant un speedtest…
    Du coup maintenant je vais devoir passer mes nuits a réparer mon réseau…. :S

    • [^] # Re: Mais pourquoi j'ai fait le test :S

      Posté par . Évalué à 2 (+0/-0).

      J'ai lu en diagonal, mais on dirait un boîtier qui va bufferiser les connexions TCP et essayer d'avoir la meilleure fenêtre TCP possible (TCP window). Du coup, ping n'est pas impacté par cette méthode.

      • [^] # Re: Mais pourquoi j'ai fait le test :S

        Posté par (page perso) . Évalué à 0 (+1/-2). Dernière modification le 16/08/18 à 16:13.

        qui va bufferiser les connexions TCP

        Je crois pas. En fait il s'agit d'optimiser les queues sur le réseau ce qui impacte tous les flux et pas que TCP. Après le fait que TCP a besoin de faire des allers-retours pour confirmer que l'information est bien arrivée fait que tu verras en pratique de plus grandes différences de performances sur des flux TCP (genre formulaires HTTP).

  • # Terminologie

    Posté par . Évalué à 8 (+6/-0). Dernière modification le 10/08/18 à 15:41.

    Le terme « bump-in-the-wire » devrait plutôt être traduit, je pense, par « élévation sur la ligne », ou un truc du genre. Ça vient du monde IPsec, cf. https://en.wikipedia.org/wiki/Bump-in-the-wire qui référence la RFC 4301 https://tools.ietf.org/html/rfc4301 mais on peut remonter à la RFC 2767 https://tools.ietf.org/html/rfc2767 qui cite un papier de 1996 (sur une implémentation MS-DOS d'IPsec !!). On en parle par opposition au « bump-in-the-stack », ou « élévation dans la pile », dans lequelle c'est la pile logicielle qui est modifiée pour inclure l'amélioration ; de sécurité dans le cas d'IPsec, ici de réactivité, même si le « bump » est lié à l'ajout d'un header IPsec AH/ESP dans le premier cas et n'a pas ici vraiment de sens. On en parle également dans les différentes méthode de transition IPv4/IPv6.

    Quant au bufferbloat, on pourrait éventuellement dire « ballonnements dû aux tampons » ; bon, je suis vraiment mauvais en francisation je crois.

    Le pire est que l'industrie des télécoms toute entière refuse toujours obstinément de reconnaître ce problème, et le poids de l'existant est tellement énorme qu'il est en effet aujourd'hui impossible d'avoir une infrastructure DSL avec des tailles de buffer correctes, tellement c'est enraciné dans les équipements et les gens.

    • [^] # Re: Terminologie

      Posté par (page perso) . Évalué à 5 (+4/-1).

      Le terme « bump-in-the-wire » devrait plutôt être traduit, je pense, par « élévation sur la ligne »

      Je dirais dos d'âne ou ralentisseur, ce qui semble correspondre à la signification originale.

      • [^] # Re: Terminologie

        Posté par . Évalué à 2 (+0/-0).

        Je dirais dos d'âne ou ralentisseur, ce qui semble correspondre à la signification originale.

        Non, c'est l'inverse, le but n'est pas de dire qu'un ralentisseur ralentit ton trafic, mais qu'un mécanisme « élève » (du verbe « to bump ») ton trafic réseau (le titre original est « A little bump in the wire that makes your Internet faster »). Ça a moyennement du sens ici pour la modification de scheduling, mais à l'origine c'était pour l'ajout d'un header IPsec (qui élève le contenu du paquet original).

        • [^] # Re: Terminologie

          Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 16/08/18 à 17:59.

          un mécanisme « élève » (du verbe « to bump ») ton trafic réseau

          to bump signifie faire une bosse, toucher, heuter. Pas de trace d'élévation à ma connaissance.

          Pour IPSec, le bump dont tu parles est le bump-in-the-stack qui consiste à garder le code de la pile IP, et de n'ajouter qu'une partie qui va gérer le cas spécifique d'IPSec lors que son en-tête est détecté.
          La partie ajoutée est qualifiée de bump, une sorte de greffon sans mécanisme de greffon.

      • [^] # Re: Terminologie

        Posté par (page perso) . Évalué à 0 (+1/-2).

        J'avoue que a posteriori, cela a beaucoup plus de sens que « bosse ». Je n'avais pas pensé à interpréter « bump » comme un « speed bumb » (ralentisseur), mais de fait cela me semble correspondre à ce que la solution accomplit… C'est un dos d'âne numérique pour éviter les embouteillages sur les petites routes des Internets :D

    • [^] # Re: Terminologie

      Posté par . Évalué à 5 (+3/-0). Dernière modification le 10/08/18 à 16:44.

      J'aurais plutôt traduit "bump" par "dos d’âne" ou "nid de poule" ou "cahot" ?

      edit : grilled by Kerro<

  • # I got that reference

    Posté par . Évalué à 3 (+1/-0).

    He said, uh, "The answer's not in the box, it's in the band."

  • # Pour les décideurs pressés

    Posté par . Évalué à 6 (+5/-0).

    Bon, je me suis tapé l'article, et voila petit résumé pas trop technique :

    • Les fournisseurs d'accès au Canada communiquent beaucoup sur la bande passante et pas beaucoup sur la latence.
    • Ils cherchent donc à privilégier la bande passante sur le "ping".
    • Leurs routeurs sont configurés de cette façon.
    • Quand tu surfes, ton impression de vitesse d'affichage de la page dépend beaucoup plus des latences sur le réseau que de ta bande passante. Bô schéma
    • Il propose de rajouter un composant sur la ligne pour ralentir ton débit mais diminuer ta latence. Le fameux "dos d'âne" ou ralentisseur pour câble.

    Après, j'ai l'impression qu'en France, certains opérateurs pensent aux joueurs et proposent déjà des modes pour améliorer le ping (Fastpath ou Patate chez free, le profil "Jeux" chez SFR…) et que cela fait longtemps qu'il n'y a plus de course à la plus grosse bande passante en ADSL (au final le réseau est le même, et donc il n'y a rien à comparer). Donc je ne sais pas si c'est vraiment efficace ou si ce n'est pas déjà implémenté .

    • [^] # Re: Pour les décideurs pressés

      Posté par (page perso) . Évalué à 6 (+4/-0).

      Il y a aussi la solution de bloquer les traqueurs et la publicité : https://greboca.com/La-securite-la-pub-et-le-traqueur.html

      Cela fait une très grosse différence, en terme de résolution DNS, de download etc.

      Ci après un exemple pour la page d'accueil du site Libération:

      Impact de la publicité et des traqueurs sur la vitesse de chargement des pages

      • [^] # Re: Pour les décideurs pressés

        Posté par . Évalué à 1 (+1/-1).

        Cela fait une très grosse différence, en terme de résolution DNS, de download etc.

        La résolution DNS ne se fait pas en parallèle ? Pour le download, le sujet c'est justement que le débit n'est pas forcément le plus important.

        Ton graphe est intéressant, mais j'irais bien voir un chronographe pour voir pourquoi ça se retarde.

        • [^] # Re: Pour les décideurs pressés

          Posté par (page perso) . Évalué à 5 (+2/-0). Dernière modification le 13/08/18 à 10:41.

          Parallèle ou pas, plus y a de résolutions DNS, plus la réponse la plus lente est lente, plus tu attends la fin du chargement de ta page. Et sur les sites bloatware, y a beaucoup de résolutions à faire (souvent en dizaine(s) de fois plus).

          Et si non parallèle c'est encore pire, évidemment.

          • [^] # Re: Pour les décideurs pressés

            Posté par . Évalué à 2 (+2/-1).

            Mais du coup 1, 2 ou 3000, c'est toujours la requête la plus longue et rien ne me pousse à croire que c'est plus rapide pour les domaines de libé que ceux de nos amis publicitaires. D'une part ils ont des infra qui sont probablement plus costauds mais en plus ils ont des chances d'être dans les caches.

            J'ai pas trouvé de moyen d'exporter les chronogrammes (c'est nul c'était possible avec firebug…), donc c'est assez relou pour faire une analyse.

            Avec la pub, en 4.44s j'ai bien 2s sans aucun accès réseau.

            Rien à voir mais c'est assez marrant, je perds pas mal de temps sur des requêtes bloquées vers leur CDN. Ils font une trentaine de requêtes (2 fois 15 requêtes). Ils gagneraient à passer à HTTP2 pour multiplexer ça.

            • [^] # Re: Pour les décideurs pressés

              Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 13/08/18 à 23:20.

              Ils font une trentaine de requêtes (2 fois 15 requêtes)
              

              Oui et non, ils veulent savoir quelle partie de la page tu affiches, et, avec du javascript peuvent même savoir comment tu déplaces ton pointeur.
              Ici, il n'est question que de ce qui est téléchargé, et pas envoyé.

              • [^] # Re: Pour les décideurs pressés

                Posté par . Évalué à 0 (+1/-2).

                Hein ? Les domaines md0.libe.com et md1.libe.com retournent des images. Bien sûr ça n'empêche pas pas de faire du tracking, mais le faire avec son domaine static (que j'ai appelé à tord CDN en effet, je ne connais pas leur infra). Ça n'est pas du tracking et si c'était ça ce serait très mal fait, la moitié de leur requêtes sont bloquées pendant un temps par firefox juste parce que firefox limite le nombre de connexions parallèles à un domaine donné. Donc oui ça gagnerait à être multiplexé.

                Je comprends que j'ai pas étais assez précis, mais t'a quand même était bien imaginatif. C'est rigolo comme des mots sont tabous et dès que j'ai écris CDN, tu as pensé tracking et drak pattern… De ce que j'ai pu voir les annonceurs de libé n'utilisent pas des masses de CDN, j'ai vu un cloudfront passer (en rapport avec https://www.sharethefacts.co, je sais pas ce que c'est).

                Ici, il n'est question que de ce qui est téléchargé, et pas envoyé.

                Le moniteur réseau de firefox (ce que je tente d'utiliser) te montre toutes les connexions. Pas que ce qui descends.

                • [^] # Re: Pour les décideurs pressés

                  Posté par (page perso) . Évalué à 2 (+0/-0).

                  Alors, certes, j'ai été rapide en conclusion, mais je parlais d'une manière générale.

                  Et, avec traqueurs activés, il y a toujours un petit flux qui passe, et qui ne permet pas de savoir de combien d'éléments la page est faite, sauf en l'arrêtant volontairement après un certain délai.

                  Pourquoi autant d'éléments différents, de toutes petite taille sur cette page d'accueil? Je n'ai pas cherché à savoir. C'est souvent utilisé pour du tracking. En autorisant qu'une toute petite part des connexions, on a le texte et les images, nickel!

    • [^] # J'ai testé

      Posté par (page perso) . Évalué à 2 (+3/-2).

      Donc je ne sais pas si c'est vraiment efficace

      J'ai mis ça en place lundi midi dans un gros bâtiment ou plusieurs dizaines de personnes partagent une connexion ADSL. Résultat 100% heureux. Depuis lundi, finis les embouteillages et la QoS gérée par Bouygues qui permet à trois personnes de regarder une vidéo Youtube/Whatsapp et empêcher les autres d'envoyer un simple formulaire HTTP.

      Au final, je ne vois pas tant que ça de différence au niveau du ping (en heure de pointe il continue de monter autour de 100ms), mais en terme d'utilisabilité c'est juste sans comparaison. Avant, pour pouvoir poster un journal ou envoyer un mail, il me fallait soit passer par ma 3G, soit attendre une heure d'accalmie. Depuis lundi, je n'ai rencontré aucune erreur de timeout sur un envoi de formulaire HTTP. Ça fait plaisir :)

  • # Test

    Posté par (page perso) . Évalué à 1 (+0/-0).

    Je viens de faire le test: je passe de 17ms à plus de 300ms de ping quand je fais un Speedtest en parallèle (config: laptop en wifi n, connexion «fibre» Numericable).

    Un LUG en Lorraine : https://enunclic-cappel.fr

  • # latence ou debit en upload

    Posté par . Évalué à 2 (+1/-0).

    on parle beaucoup de la latence dans cet article, la latence est prépondérante et incontounable surtout pour les jeux.
    Pour le web tant qu'à ajouter un boitier sur le réseau ne pas hésiter à faire tourner un cache DNS local, voir un cache web … c'est quasiment magique.
    Enfin ne pas sous-estimer l'importance du debit en upload. Depuis que je suis passé en vdsl et que j'ai 6Mbps en upload tout va bien mieux…

    • [^] # Re: latence ou debit en upload

      Posté par (page perso) . Évalué à 2 (+1/-0).

      Un cache Web à l'heure où l'HTTPS est majoritaire, quelle est l'utilité ?

      Mes messages engagent qui je veux.

      • [^] # Re: latence ou debit en upload

        Posté par . Évalué à 3 (+3/-1).

        sur la latence c'est surtout le cache DNS qui joue.
        si t'es tout seul sur ta liaison ADSL le cache web de ton navigateur suffit. Sinon aujourd'hui on cache encore pas mal d'info dans les proxy le tout https n'est pas en place … et les proxy savent faire du man in the middle.

  • # Anciens algos

    Posté par (page perso) . Évalué à 1 (+0/-0).

    Ça me rappelle un projet sur lequel j'avais travaillé pour l'INRIA. Le projet portait plutôt sur le wifi, pour justement gérer de façon plus efficace les cas où on est utilisateurs par borne (typiquement dans une école, quand un prof demande d'aller chercher le pdf du tp sur son site). Le but était donc d'implémenter des solutions pour améliorer l'usage de ce wifi.
    De mémoire on avait 2 algo. Un premier visait justement à privilégier les sessions transférant de petites données par rapport aux grosses. Comme ça on gagne justement un peu de latence. On a donc l'illusion d'une connexion plus rapide, même si le voisin profite du tp pour faire ses mises à jours. Et il me semble que le second algo visait à faire, en gros, une file de donnée par utilisateur pour alterner équitablement entre eux. En bref, on a travaillé sur le FQ décrit dans l'article. C'est sympa de voir qu'une solution utilisant ces algos est commercialisée, je suis curieux de savoir si ca améliore vraiment les choses !

    Opera le fait depuis 10 ans.

  • # Possible aussi avec OpenBSD

    Posté par . Évalué à 2 (+1/-0).

    Salut,

    Ce journal me rappelle un billet récent sur undeadly.org qui présente comment régler ce problème sous OpenBSD. Il référence à ce sujet un article intéressant.

  • # En vrai derrière c'est du cake

    Posté par . Évalué à 10 (+11/-0).

    Si l'auteur original en parle dans l'article, mais le journal n'en fait pas mention, donc je me permet de compléter.

    Cake est un projet pour rendre (notamment) la QoS facilement configurable sous Linux. Du coup d'ailleurs c'est pas le même algorithme fq_codel qui est utilisé que celui « classique » du noyau Linux, mais une variante (cobalt). Et cake a pour objectif de faire beaucoup de choses, notamment :

    • ne pas prendre la tête lors de la configuration en cas de NAT (ce qui a été un problème pour son inclusion dans le noyau)
    • garantir l'équité entre les utilisateurs/équipements (et là on sort du problème de bufferbloat). C'est d'ailleurs la raison de l'utilisation de cobalt vs fq_codel
    • simplifier les configurations pour les différents types de liens WAN (voir la partie « Extensive framing compensation » de la page du projet)
    • gestion de différentes classes de trafic
    • filtrage des ACK inutiles de TCP

    Cake a été mergé récemment (après 18 versions proposées des patchs !), et sera en version 4.19. Si vous voulez un peu d'histoire, lwn en parle.

    Également sur lwn, c'est relié mais pas complètement, un article sur les problèmes de latence en WiFi avec Linux.

    • [^] # Re: En vrai derrière c'est du cake

      Posté par (page perso) . Évalué à -1 (+0/-2).

      Effectivement, cake était mentionné dans l'article mais tellement brièvement que cela ne me semblait être qu'une forme de packaging autour de fq_codel. Merci pour ce complément d'information ! :)

    • [^] # Re: En vrai derrière c'est du cake

      Posté par (page perso) . Évalué à 2 (+0/-0).

      Également sur lwn, c'est relié mais pas complètement, un article sur les problèmes de latence en WiFi avec Linux.

      Pas lu l'article encore, mais un premier truc qui peut réduire la latence en WiFi c'est de désactiver la mise en veille de la carte : iw dev wlan0 set power_save off.

  • # ack sur serveur carracho

    Posté par . Évalué à 3 (+2/-0).

    On utilisait http://www.carracho.com pour faire des "échanges de fichiers" dans les années 2000, c'est un genre de FTP et il y avait un chat intégré, c'était comme Hotline HQ mais en bien plus rapide au niveau réseau. Trop rapide qu'il y avait un étranglement des paquets ack (les paquets qui disaient en gros "j'ai bien reçu" en retour d'un paquet de données envoyé)

    Une "connaissance" à finit pas faire un logiciel pour limiter les envois pour laisser passer les paquets de retour, http://intrarts.com/throttled.html
    Activer ou désactiver le soft avait un effet immédiat comme on peut le voir sur les graphiques.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.