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

vivien · « **Réponse #72 le:** 03 janvier 2022 à 16:40:23 »

Très intéressant.

C'est du mono-connexion ?

C'est possible de savoir la ville où sont les box ?

Les modèles de box utilisées et plus d'info sur la configuration du PC de test ?

(cela permet d'avoir des données complètes)

ouno · « **Réponse #73 le:** 03 janvier 2022 à 18:01:08 »

Citation de: vivien le 03 janvier 2022 à 16:40:23

C'est du mono-connexion ?

Oui c'est du mono-connexion (je l'avais écrit dans la première ligne de mon post et dans le titre des graphs

)

Citation de: vivien le 03 janvier 2022 à 16:40:23

C'est possible de savoir la ville où sont les box ?

Free: Orvault (ZMD)
Orange: Rennes

Citation de: vivien le 03 janvier 2022 à 16:40:23

Les modèles de box utilisées et plus d'info sur la configuration du PC de test ?

Free:
- box: Freebox Révolution r2 avec ONU v1
- système de test: NAS Synology DS214+ (Marvell PJ4Bv7 / 1GB RAM)

Code: [Sélectionner]

Linux 3.2.40 (armv7l)
--------------------------- 2022-01-03 16:02:54 GMT ---------------------------
Paramétrage réseau actuel du système:
  net.core.rmem_max: 6291456
  net.core.wmem_max: 4194304
  net.ipv4.tcp_adv_win_scale: 1
  net.ipv4.tcp_congestion_control: cubic
  net.ipv4.tcp_mem: 24384       32512   48768
  net.ipv4.tcp_no_metrics_save: 0
  net.ipv4.tcp_rmem: 4096       87380   6291456
  net.ipv4.tcp_sack: 1
  net.ipv4.tcp_timestamps: 1
  net.ipv4.tcp_window_scaling: 1
  net.ipv4.tcp_wmem: 4096       16384   4194304
  => Latence TCP max pour une réception à 1 Gbps: 27 ms

Orange:
- box: Livebox 4
- système de test: Debian GNU/Linux 10 (i5-4570 CPU @ 3.20GHz / 16GB RAM)

Code: [Sélectionner]

Linux 4.19.0-13-amd64 (x86_64)
--------------------------- 2022-01-03 16:04:16 GMT ---------------------------
Paramétrage réseau actuel du système:
  net.core.rmem_max: 212992
  net.core.wmem_max: 212992
  net.ipv4.tcp_adv_win_scale: 1
  net.ipv4.tcp_congestion_control: cubic
  net.ipv4.tcp_mem: 187191      249591  374382
  net.ipv4.tcp_no_metrics_save: 0
  net.ipv4.tcp_rmem: 4096       131072  6291456
  net.ipv4.tcp_sack: 1
  net.ipv4.tcp_timestamps: 1
  net.ipv4.tcp_window_scaling: 1
  net.ipv4.tcp_wmem: 4096       16384   4194304
  => Latence TCP max pour une réception à 1 Gbps: 27 ms

Pour info le programme utilisé pour les tests est très très léger et n'utilise bien sûr pas le système de stockage pour les tests de débit.
Des vérifications ont été faites sur les systèmes en charge et ils tiennent sans problème le 1Gbps.

De plus, je ne l'ai pas précisé dans mon post précédent pour pas surcharger, mais sur la ligne Free un test témoin de débit local entre le système de test et la Freebox a aussi été réalisé toutes les 15 minutes, juste avant les tests de débit Internet.
Ce test témoin permet de vérifier qu'à chaque fois que les tests de débit Internet sont réalisés le système est bien capable de monter à 1Gbps. Le test témoin est parfaitement stable et permet d'être vraiment sûr du système de test.

Voici le graph avec le test témoin en plus:

vivien · « **Réponse #74 le:** 30 janvier 2023 à 19:37:43 »

Une étude de Ayush Mishra et présenté à l'IETF 109 le 20 novembre 2020 a étudié la répartition des protocoles de congestion TCP sur le top 250 Alexa, les 250 sites web qui sont les plus consultés selon le classement Alexa (qui au passage n'existe plus aujourd'hui) :

BBR est l'algorithme de contrôle de la congestion TCP le plus utilisé avec 25% devant Cubic 22%.

L'évolution dans le temps des algorithmes de contrôle de la congestion TCP, sur le top 20 000 Alexa : Cubic est cette fois-ci devant BBR, car les sites les plus populaires utilisent plus BBR que les autres :

vivien · « **Réponse #75 le:** 30 janvier 2023 à 19:40:10 »

The Great Internet TCP Congestion Control Census
(cliquez sur la miniature ci-dessous - le document est au format PDF)

Les slides des mesures :

zergflag · « **Réponse #76 le:** 30 janvier 2023 à 20:35:23 »

Netflix utilise toujours du CUBIC ? Il me semble que Netflix utilise FreeBSD comme distro sur leurs serveurs vidéos, c'est en CUBIC par défaut dessus ?

vivien · « **Réponse #77 le:** 30 janvier 2023 à 20:45:43 »

Oui, c'est public, Netflix utilise du Cubic.

Peut-être, car c'est offloadé sur la carte réseau ?

Ils font faire pas mal de choses à la carte réseau pour décharger le CPU et pouvoir gérer 400 Gb/s par serveur.

Pour information, LaFibre.info, c'est BBR depuis 2020.

hwti · « **Réponse #78 le:** 30 janvier 2023 à 20:51:08 »

Ici, les tests sont effectués sur le chargement de pages, avec des petites tailles.
Rien ne dit que les CDN vidéo emploient le même algorithme.

ouno · « **Réponse #79 le:** 13 mars 2023 à 14:00:35 »

A priori BBR est aussi disponible sous Windows depuis Windows 11 22H2, il faut utiliser la commande suivante en admin pour l'activer:

Code: [Sélectionner]

netsh int tcp set supplemental Template=Internet CongestionProvider=bbr2

alain_p · « **Réponse #80 le:** 13 mars 2023 à 14:08:55 »

Ah, intéressant de le savoir. Je suppose que la version serveur, 2022, pour laquelle c'est le plus intéressant, l'a aussi.

vivien · « **Réponse #81 le:** 13 mars 2023 à 14:19:55 »

Plus intéressant, cela serait BBR2 et non BBR ?

=> BBR v2 est en train d'être finalisé par Google

kgersen · « **Réponse #82 le:** 13 mars 2023 à 17:34:52 »

Citation de: ouno le 13 mars 2023 à 14:00:35

A priori BBR est aussi disponible sous Windows depuis Windows 11 22H2, il faut utiliser la commande suivante en admin pour l'activer:
Code: [Sélectionner]
netsh int tcp set supplemental Template=Internet CongestionProvider=bbr2

a noter que la version powershell ( Set-NetTCPSetting ) n'est pas encore a jour et refuse sous Windows 11 de changer le parametre (meme en admin) mais l'affiche bien avec Get-NetTCPSetting.

J'avais fait des tests la semaine derniere avec NSpeed et 2 machines :
- une linux sous BBR qui sert a saturer la connexion en sortie
- une sous Windows Insiders canal Dev ou je changeait entre CUBIC et BBR2

bizarrement les résultats étaient en faveur de CUBIC...

(peut-etre que BBR2 est plus "faible" que CUBIC fasse a BBR ?)

exemple avec BBR2:

Code: [Sélectionner]

./nspeed get http://nspeedapi:39757/api/v1/run?args=put%20http://speedtest.milkywan.fr%201g  put -id Milky http://speedtest.milkywan.fr 1g
running...
all done
    Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
 Milky|      0 bps|  186.4 Mbps| 8.00|        0 B|      186.4 MB|put http://speedtest.milkywan.fr 1.0 GB ([2a0b:cbc0:42:1::1]:80 - 3.166 ms - )
      |           |            |     |           |              |
 Total|      0 bps|  186.4 Mbps| 8.00|        0 B|      186.4 MB|

sur plusieurs tests, ca oscille entre 180 et 250 Mbps.
avec CUBIC cela a oscille entre 360Mbs et 600Mbps.

L'ideal serait d'avoir 500Mbps , partage équitable de la ligne (qui fait 1Gbps et qu'on obtient bien quand une seule machine fait l'upload).

Quand on met l'autre machine en CUBIC on obtient a peu près le même résultat entre CUBIC et BBR2 coté Windows. Entre 400 Mbps et 500 Mbps ce qui semble normal.

Apres ma ligne en sortie n'est pas saturée au dela du 1er hop donc c'est moins critique que dans l'autre sens:

Freepro Paris 7 Gbps:

Code: [Sélectionner]

./nspeed g  -id CUBIC http://bouygues.testdebit.info/10G/10G.iso get -id BBR http://paris.testdebit.info/10G/10G.iso
running...
all done
    Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
   BBR|   6.6 Gbps|       0 bps| 8.00|     6.6 GB|           0 B|get http://paris.testdebit.info/10G/10G.iso ([2001:860:de01:1101::2]:80 - 2.155 ms - HTTP/1.1)
 CUBIC|  52.3 Mbps|       0 bps| 8.00|    52.3 MB|           0 B|get http://bouygues.testdebit.info/10G/10G.iso ([2001:860:de01:1100::2]:80 - 2.528 ms - HTTP/1.1)
      |           |            |     |           |              |
 Total|   6.7 Gbps|       0 bps| 8.00|     6.7 GB|           0 B|

saturation/pertes, énorme avantage a BBR.
idem depuis un ligne Orange Pro 1Gbps Paris. Ca sature entre Orange et Bouygues ?

on peut penser que le serveur bouygues.testdebit.info a un souci ? mais depuis une machine chez Google en Belgique :

Code: [Sélectionner]

./nspeed g -id CUBIC http://bouygues.testdebit.info/10G/10G.iso  g -id BBR http://paris.testdebit.info/10G/10G.iso
running...
all done
    Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
   BBR|   3.2 Gbps|       0 bps| 8.00|     3.2 GB|           0 B|get http://paris.testdebit.info/10G/10G.iso (89.84.1.194:80 - 6.340 ms - HTTP/1.1)
 CUBIC|   2.0 Gbps|       0 bps| 8.00|     2.0 GB|           0 B|get http://bouygues.testdebit.info/10G/10G.iso (89.84.1.186:80 - 9.894 ms - HTTP/1.1)
      |           |            |     |           |              |
 Total|   5.2 Gbps|       0 bps| 8.00|     5.2 GB|           0 B|

pas de saturation/perte, léger avantage a BBR.

ouno · « **Réponse #83 le:** 13 mars 2023 à 19:15:29 »

Citation de: kgersen le 13 mars 2023 à 17:34:52

J'avais fait des tests la semaine derniere avec NSpeed et 2 machines :
- une linux sous BBR qui sert a saturer la connexion en sortie
- une sous Windows Insiders canal Dev ou je changeait entre CUBIC et BBR2

bizarrement les résultats étaient en faveur de CUBIC... (peut-etre que BBR2 est plus "faible" que CUBIC fasse a BBR ?)

Bizarre effectivement, après ça pourrait peut-être s'expliquer en imaginant que BBR2 est fait pour rivaliser contre d'autres algos équitables et non pas contre BBR, qu'il devrait remplacer à terme ?
Et ce BBR2 de chez Microsoft est peut-être encore en test / développement, vu que je crois pas qu'ils aient communiqué là-dessus publiquement

Citation de: kgersen le 13 mars 2023 à 17:34:52

idem depuis un ligne Orange Pro 1Gbps Paris. Ca sature entre Orange et Bouygues ?

on peut penser que le serveur bouygues.testdebit.info a un souci ? mais depuis une machine chez Google en Belgique :
pas de saturation/perte, léger avantage a BBR.

De ce que j'ai constaté l'interco Orange / Bouygues est impactée par du reord non négligeable (au moins entre Orange FTTH et les serveurs de test Bouygues), ce qui peut compliquer un peu les comparaisons...