Auteur Sujet: Algo de contrôle de la congestion TCP: BBR  (Lu 36699 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #48 le: 25 janvier 2020 à 16:06:39 »
Pour faire la chose proprement, j'ai crée un fichier /etc/modules-load.d/tcp_allowed_congestion_control.conf dans lequel je charge les 3 algorithme à proposer.

sudo nano /etc/modules-load.d/tcp_allowed_congestion_control.conf
# TCP congestion control protocol
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
tcp_bbr
tcp_htcp
tcp_illinois

Mais dans les 3 charcgés, seul bbr est disponible.

$ cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
$ cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
reno cubic bbr


Pourtant, les fichiers .ko sont bien présents :

# locate tcp_bbr
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_bbr.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_bbr.ko

# locate tcp_htcp
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_htcp.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_htcp.ko

# locate tcp_illinois
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_illinois.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_illinois.ko

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #49 le: 25 janvier 2020 à 17:16:03 »
ESnet a réalisé un document sur les optimisations pour les premiers serveurs qui ont des cartes Ethernet 100 Gb/s.

Le document date de septembre 2016 :
(cliquez sur la miniature ci-dessous - le document est au format PDF)


On voit pas mal de choses intéressantes sur les apports d'un kernel récent et une comparaison CentOS 7 vs CentOS 6 (sur un serveur 10 Gb/s) :




BBR est évoqué :


vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #50 le: 06 février 2020 à 07:52:49 »
Je viens de passer ce matin le serveur LaFibre.info, qui héberge également le test de débit mono-connexion de QoSi 5GMark en BBR pour voir l'impact.

$ cat /proc/sys/net/ipv4/tcp_congestion_control
bbr

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #51 le: 14 février 2020 à 20:47:59 »
J'ai déjà publié un comparatif de BBR avec Cubic.

Les résultats sont sans appels : en mono-connexion BBR est presque systématiquement devant Cubic.

Je rajoute un autre exemple avec le débit Upload sur une Freebox :

- Cubic : 76.1 Mb/s
- BBR : 503 Mb/s

Sur cet exemple, BBR permet de multiplier par 6,6 les débits !


Ci-dessous les tests en IPv6 puis en IPv4, en étant connecté directement sur la Freebox.
Les débits sont toujours merdiques, comme depuis le début... (Free ne veut rien faire, "tout est normal").


IPv6 (1 flux) :
Connecting to host bouygues.testdebit.info, port 5201
[  4] local 2a01:e0a:2d... port 49773 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.01   sec  6.12 MBytes  51.0 Mbits/sec
[  4]   1.01-2.00   sec  8.88 MBytes  75.0 Mbits/sec
[  4]   2.00-3.00   sec  8.38 MBytes  70.3 Mbits/sec
[  4]   3.00-4.00   sec  5.00 MBytes  41.9 Mbits/sec
[  4]   4.00-5.00   sec  8.62 MBytes  72.4 Mbits/sec
[  4]   5.00-6.00   sec  13.1 MBytes   110 Mbits/sec
[  4]   6.00-7.01   sec  7.00 MBytes  58.4 Mbits/sec
[  4]   7.01-8.01   sec  9.50 MBytes  80.0 Mbits/sec
[  4]   8.01-9.00   sec  8.75 MBytes  73.8 Mbits/sec
[  4]   9.00-10.00  sec  13.0 MBytes   109 Mbits/sec
[  4]  10.00-11.01  sec  6.75 MBytes  55.9 Mbits/sec
[  4]  11.01-12.01  sec  8.38 MBytes  70.7 Mbits/sec
[  4]  12.01-13.01  sec  11.6 MBytes  96.8 Mbits/sec
[  4]  13.01-14.00  sec  7.00 MBytes  59.6 Mbits/sec
[  4]  14.00-15.01  sec  11.8 MBytes  97.8 Mbits/sec
[  4]  15.01-16.01  sec  11.4 MBytes  94.8 Mbits/sec
[  4]  16.01-17.00  sec  6.88 MBytes  58.3 Mbits/sec
[  4]  17.00-18.00  sec  11.5 MBytes  96.7 Mbits/sec
[  4]  18.00-19.00  sec  7.62 MBytes  64.0 Mbits/sec
[  4]  19.00-20.00  sec  10.1 MBytes  84.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-20.00  sec   181 MBytes  76.1 Mbits/sec                  sender
[  4]   0.00-20.00  sec   181 MBytes  76.1 Mbits/sec                  receiver

IPv6 2 flux :
[SUM]   0.00-20.01  sec   281 MBytes   118 Mbits/sec                  sender
[SUM]   0.00-20.01  sec   281 MBytes   118 Mbits/sec                  receiver

IPv6 4 flux :
[SUM]   0.00-20.00  sec   470 MBytes   197 Mbits/sec                  sender
[SUM]   0.00-20.00  sec   469 MBytes   197 Mbits/sec                  receiver

IPv6 8 flux :
[SUM]   0.00-20.01  sec   651 MBytes   273 Mbits/sec                  sender
[SUM]   0.00-20.01  sec   650 MBytes   273 Mbits/sec                  receiver

IPv6 16 flux :
[SUM]   0.00-20.00  sec   798 MBytes   335 Mbits/sec                  sender
[SUM]   0.00-20.00  sec   795 MBytes   334 Mbits/sec                  receiver

IPv4 (1 flux) :
Connecting to host bouygues.testdebit.info, port 5201
[  4] local 192.168.200.22 port 49876 connected to 89.84.1.222 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.01   sec  3.50 MBytes  29.1 Mbits/sec
[  4]   1.01-2.00   sec  8.88 MBytes  75.1 Mbits/sec
[  4]   2.00-3.00   sec  12.8 MBytes   107 Mbits/sec
[  4]   3.00-4.00   sec  7.00 MBytes  58.9 Mbits/sec
[  4]   4.00-5.01   sec  5.62 MBytes  46.7 Mbits/sec
[  4]   5.01-6.01   sec  9.50 MBytes  80.1 Mbits/sec
[  4]   6.01-7.01   sec  10.9 MBytes  91.5 Mbits/sec
[  4]   7.01-8.01   sec  10.4 MBytes  86.2 Mbits/sec
[  4]   8.01-9.00   sec  5.88 MBytes  50.0 Mbits/sec
[  4]   9.00-10.00  sec  9.00 MBytes  75.4 Mbits/sec
[  4]  10.00-11.01  sec  8.25 MBytes  68.8 Mbits/sec
[  4]  11.01-12.00  sec  10.8 MBytes  90.7 Mbits/sec
[  4]  12.00-13.01  sec  6.88 MBytes  57.1 Mbits/sec
[  4]  13.01-14.01  sec  7.50 MBytes  63.0 Mbits/sec
[  4]  14.01-15.01  sec  8.38 MBytes  70.4 Mbits/sec
[  4]  15.01-16.01  sec  8.12 MBytes  68.3 Mbits/sec
[  4]  16.01-17.00  sec  9.25 MBytes  77.8 Mbits/sec
[  4]  17.00-18.01  sec  5.50 MBytes  45.9 Mbits/sec
[  4]  18.01-19.01  sec  6.62 MBytes  55.6 Mbits/sec
[  4]  19.01-20.00  sec  10.2 MBytes  86.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-20.00  sec   165 MBytes  69.1 Mbits/sec                  sender
[  4]   0.00-20.00  sec   165 MBytes  69.1 Mbits/sec                  receiver


IPv4 2 flux :
[SUM]   0.00-20.01  sec   270 MBytes   113 Mbits/sec                  sender
[SUM]   0.00-20.01  sec   270 MBytes   113 Mbits/sec                  receiver

IPv4 4 flux :
[SUM]   0.00-20.01  sec   495 MBytes   207 Mbits/sec                  sender
[SUM]   0.00-20.01  sec   494 MBytes   207 Mbits/sec                  receiver

IPv4 8 flux :
[SUM]   0.00-20.00  sec   657 MBytes   276 Mbits/sec                  sender
[SUM]   0.00-20.00  sec   656 MBytes   275 Mbits/sec                  receiver


IPv4 16 flux :
[SUM]   0.00-20.00  sec   818 MBytes   343 Mbits/sec                  sender
[SUM]   0.00-20.00  sec   815 MBytes   342 Mbits/sec                  receiver



Edit : je viens de faire le test en bbr et c'est juste hallucinant...  :o
Par contre sous Windows que ce soit en cubic, ctcp, dctcp ou newreno ça ne change strictement rien... débit de merde en upload.  :-\

Je ne sais pas ce qu'on peut en conclure... Saturation chez Free ?


1 flux :
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec  1.17 GBytes   503 Mbits/sec  89401             sender
[  5]   0.00-20.04  sec  1.17 GBytes   501 Mbits/sec                  receiver

2 flux :
[SUM]   0.00-20.00  sec  1.26 GBytes   542 Mbits/sec  122231             sender
[SUM]   0.00-20.03  sec  1.26 GBytes   539 Mbits/sec                  receiver

Avec de multi-connexion en parallèle, les débits de BBR sont souvent largement inférieurs à Cubic, comme le montre le comparatif ci-dessous (débit exprimés en Gb/s) :


vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #52 le: 14 février 2020 à 20:55:44 »
Il manque par contre un comparatif Cubic / BBR / Illinois.

J'ai exploité les tests Breizh29. Il était difficile de tirer une conclusion avec les graphiques car on a eu des coupures a plusieurs moment (panne Free puis pb du coté de mon serveur) et surtout le trafic le week-end est plus important et il est difficile de comparer une courbe de semaine avec une courbe du week-end.

J'ai donc supprimé les données du week-end et j'ai mis ça sur 24 heures (tous les tests avec un même protocole de congestion TCP et une même tranche horaire sont moyennés).
J'ai supprimé les données avant le 19 janvier vu qu'il y avait des modification de configuration.

Voici ce que cela donne pour 16 connexions TCP en parallèle.
Cubic est clairement le meilleur algorithme de congestion TCP pour ce type de test.





vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #53 le: 14 février 2020 à 20:57:42 »
Là où c'est plus intéressant, c'est pour les tests sur une seule connexion TCP, plus représentatif de ressenti réel d'un internaute.

Sans surprise, BBR est le meilleur algorithme de congestion TCP.

Illinois semble avoir une petite avance sur Cubic.





vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #54 le: 14 février 2020 à 21:00:02 »
Autre représentation avec d'autres couleurs.

IPv4 est en pointillé et IPv6 en trait plein.
On voit un petit gain de débit en IPv6, vs IPv4.

BBR est en rouge
Cubic est en vert
Illinois est en violet





vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #55 le: 14 février 2020 à 21:05:19 »
Autre représentation graphique des données avec le 1er tiers du graphique qui concerne BBR, le second Cubic et enfin Illinois sur le dernier tiers.

Les tests multi-connexions sont en violet (IPv6) et vert (IPv4)
Les tests mono-connexion sont en rouge (IPv6) et bleu (IPv4)



vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #56 le: 16 février 2020 à 15:39:18 »
Petit graphique proposé par Google pour comparer BBR à Cubic :


vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #57 le: 16 février 2020 à 15:41:02 »
Test réalisés par Andree Toonk (@atoonk) en simulant la latence et les pertes de paquets sur Ubuntu, avec iPerf pour tester le débit :

Source : Medium.com, le 15 février 2020

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #58 le: 16 février 2020 à 15:58:30 »
Geoff Huston, le scientifique en chef de l'APNIC, le registre Internet régional desservant la région Asie-Pacifique (équivalent du Ripe pour l'Europe) a fait une étude sur BBR.

Google rapporte des expériences qui montrent que les flux simultanés de BBR et de CUBIC s'équilibreront approximativement, CUBIC obtenant une part un peu plus grande de la ressource disponible, mais pas de manière scandaleuse. Il indique une conclusion raisonnable que BBR peut coexister dans un monde TCP RENO / CUBIC sans perdre ou dominer complètement tous les autres flux TCP.

Nos expériences limitées à ce jour indiquent une conclusion quelque peu différente. L'expérience était sous la forme d'un test 1: 1 avec des flux CUBIC et Reno simples simultanés passés sur un circuit de 10,2 Mbps RTT non encombré de 15,2 ms. CUBIC a été lancé initialement, et au point 20 secondes, une session BBR a été lancée entre les deux mêmes points de terminaison. L'algorithme de démarrage initial de BBR repousse CUBIC à un point où il semble incapable de rétablir une part équitable contre BBR. Il s'agit d'un résultat quelque peu inattendu, mais qui peut illustrer un résultat dans lequel les tailles de tampon interne sont bien inférieures au produit de bande passante de retard du circuit de goulot d'étranglement.




La deuxième expérience a utilisé un chemin RTT de 298 ms sur une grande étendue d'Internet entre des nœuds d'extrémité situés en Allemagne et en Australie. Il s'agit d'un chemin Internet standard à travers les FAI commerciaux, comme on pourrait s'y attendre sur Internet. Ce ne sont pas les deux seuls flux qui existent sur les 16 liaisons de composant vers l'avant et 21 dans ce chemin étendu, de sorte que les deux sessions TCP ne rivalisent pas seulement pour les ressources réseau sur toutes ces liaisons, mais rivalisent également avec cross trafic sur chaque lien de composant. Là encore, BBR semble mieux réussir à revendiquer des ressources de chemin et à les défendre contre d'autres flux pendant la durée de la session BBR.



C'est peut-être un résultat moins surprenant, dans la mesure où le RTT étendu a apparemment posé quelques problèmes pour CUBIC, tandis que BBR a été en mesure de maintenir son estimation de la bande passante du chemin pendant cette période. Ces résultats indiquent un certain niveau de coexistence entre BBR et CUBIC, mais le résultat semble biaisé pour que BBR gagne la plus grande part de la capacité du chemin.

Source : potaroo.net, article datant de mai 2017 traduit rapidement en Français.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #59 le: 16 février 2020 à 22:11:37 »
DropBox a fait des tests avec BBR en 2017 qui montrent une augmentation des vitesses de téléchargement de fichiers

Nous observons une augmentation de la vitesse à tous les centiles.

Expérience TCP BBR de 6 heures sur le POP de Tokyo :


axe x : temps
axe y : vitesse de téléchargement du client


Source : Blog Dropbox, article du 6 septembre 2017