La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: vivien le 05 octobre 2020 à 13:13:09
-
BBR v2 est en train d'être finalisé par Google
Edit : BBRv2 ne sort pas, c'est BBRv3
BBR v2 (appelé bbr2) vise à améliorer la latence et les problèmes de jeunesse de BBR, accusé par certains d'être trop agressif vis à vis de Cubic et de générer trop de paquets perdus.
Si vous ne connaissez pas BBR, on en parle de dans le rapport sur l'état de l'internet en France 2020 : (cliquez sur la miniature ci-dessous - le document est au format PDF de 100 pages)
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020.png) (https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020.pdf#page=23)
Impact du contrôle de congestion (Cubic, BBR,...) sur la mesure de la Qos :
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020_1_qos_4.png)
Document présenté lors de l'IETF 104 : BBR v2:A Model-based Congestion Control
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/201903_bbr_v2_doc_ietf104.png) (https://lafibre.info/testdebit/linux/201903_bbr_v2_doc_ietf104.pdf)
Vidéo de l'IETF 104 : On parle de BBR v2 à partir de la 4ème minute de la vidéo :
https://www.youtube.com/watch?v=cJ-0Ti8ZlfE
-
Document présenté lors de l'IETF 105 :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/201907_bbr_v2_doc_ietf105.png) (https://lafibre.info/testdebit/linux/201907_bbr_v2_doc_ietf105.pdf)
Vidéo de l'IETF 105 : On parle de BBR v2 à partir de la 19ème minute de la vidéo :
https://www.youtube.com/watch?v=6Njd4ApRsuo
-
Document présenté lors de l'IETF 106 :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/201911_bbr_v2_doc_ietf106.png) (https://lafibre.info/testdebit/linux/201911_bbr_v2_doc_ietf106.pdf)
Vidéo de l'IETF 106 : On parle de BBR v2 à partir de la 28ème minute de la vidéo :
https://www.youtube.com/watch?v=i3CpETXwA7Q
-
Quelques liens...
Pour installer BBR v2 Alpha : https://github.com/google/bbr/blob/v2alpha/README.md
Forum pour discuter de BBR v2 : https://groups.google.com/g/bbr-dev
-
Avancement de BBRv2 en date du 23 février 2023 :
Salut,
L'état actuel du projet BBRv2 est que nous l'utilisons, que nous le réglons et que nous prévoyons de l'envoyer en amont pour Linux principal. :-) Nous attendons de mettre BBRv2 en amont sur Linux principal lorsque nous sommes convaincus, d'après notre propre expérience, qu'il correspond ou dépasse BBRv1 dans toutes les mesures importantes que nous suivons pour les cas d'utilisation des centres de données, YouTube et google.com . Nous avons récemment déployé en interne des correctifs de bogues qui semblent peut-être atteindre ce jalon, nous commençons donc à préparer une série de correctifs pour Linux en amont.
cordialement,
neal
Source : Neal Cardwell dans le Forum BBRv2 (https://groups.google.com/g/bbr-dev/c/bXKzm6ZXEPI)
-
BBRv2 est disponible depuis fin mai 2023 dans les noyaux Liunx CachyOS.
CachyOS fournit des noyaux améliorés qui offrent des performances améliorées et d'autres avantages.
=> https://github.com/CachyOS/linux-cachyos
-
A noter que Google Quiche (implémentation en C++: https://github.com/google/quiche de QUIC, HTTP/2, HTTP/3) met en oeuvre BBR v2 depuis quelques temps maintenant. Ce code est utilisé au niveau de tout les serveurs frontaux de Google et de Chrome.
Le situation qu'on peut anticiper dans les années qui viennent c'est que de plus en plus d'applications vont passer a QUIC donc ne plus utiliser la pile TCP de l'OS, pile qui implémente la congestion.
L'algo de congestion sera donc directement dans le code de l'application, statiquement ou dynamiquement via une bibliothèque QUIC, mais ne sera plus du ressort de l'OS donc sous le contrôle de l'administrateur ou d'un paramétrage au niveau OS comme c'est le cas aujourd'hui.
Outre Google, Microsoft développe très activement son implémentation de QUIC et chose rare en open source, même la version Windows: https://github.com/microsoft/msquic. Pour l'instant ils n’implémentent que BBR et pas BBR v2.
A noter aussi qu'une RFC de QUIC v2 (rfc9369 de mai 2023) est sortie dans le but est d'éviter ce qui s'est produit avec TCP: une ossification dans les middlebox (firewall, routeurs) ou aux extrémités donc éventuellement une descente du protocole dans l'OS et les drivers.
Du coup QUIC "devrait" toujours rester un niveau applicatif et par conséquence ses protocoles de congestion aussi (enfin tout cela n'est pas facile a prédire).
-
Que QUIC soit implémenté dans une lib userspace fournie par l'OS ou dans le kernel, c'est la même chose en termes d'évolutions : tant que e.g. msquic livré avec windows n'évolue pas, aucune appli l'utilisant ne bénéficiera de BBRv2.
Par contre, à la différence des sockets TCP, une application voulant utiliser une autre stack QUIC que celle fournie par l'OS peut le faire, comme tu le dis.
À mon sens, sauf besoins spécifiques, les développeurs devraient utiliser les libs fournies par l'OS. Je ne suis pas certain que le fait d'avoir 10 implémentations différentes sur le même poste soit une bonne chose, surtout si une ou deux de ces libs présente un souci de sécu ou un bug néfaste au réseau. Si il faut attendre que Mathworks sorte une nouvelle version de Matlab et que cette version soit déployée sur tous les PC d'une organisation pour retrouver un réseau fonctionnel, on est pas rendus.
-
Il y a les navigateurs et il y a le reste des applications.
Les navigateurs (sauf Safari) aiment bien intégrer directement certaines choses qui pourraient être prises en charge par l'OS.
L'intérêt, c'est que le comportement du navigateur est le même quel que soit l'OS (Sauf Safari, où beaucoup d'appels sont faits à l'OS et donc c'est la version de MacOS qui est importante plus que la version de Safari. Exemple : Pour une même version de Safari, il n'aura pas le support des images AVIF sous macOS 12 alors qu'il l'aura sous macOS 13).
-
On a aussi changé d'époque ou les devs d'application ne veulent plus devoir dépendre de l'OS.
Ils dépendent des langages et frameworks qu'ils utilisent plus que de l'OS.
Perso je ne crois pas que ce soit a Linux ou Windows de fournir une stack QUIC donc de fournir les protocoles de gestion de congestion qui vont avec.
Si Microsoft en fait une ok mais ce n'est qu'une parmi d'autres et elle en doit pas devenir le "passage obligé pour faire du QUIC" sur Windows. Ce n'est pas leur but je pense.
Ils veulent juste fournir du QUIC a ceux qui choisissent leur C++ ou C#. C'est a ce niveau que cela se passe (langage) pas au niveau de l'OS comme avec TCP.
-
On passe à BBRv3... (https://groups.google.com/g/bbr-dev/c/X3AHtx3_tG8)
-
Document présenté lors de l'IETF 117 sur BBRv3 :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/202307_bbr_v3_doc_ietf117.webp) (https://lafibre.info/testdebit/linux/202307_bbr_v3_doc_ietf117.pdf)
Vidéo d'explication : (BBRv3 commence à la 47ᵉ minute)
https://www.youtube.com/watch?v=u-91t6JfjmY&t=2820s
-
hum donc sur Linux on n'aura pas un choix de v1 ou v3 , 'bbr' (dans systctl net.ipv4.tcp_congestion_control) évoluera de la v1 a la v3 suivant la version du noyau (sauf pour les builds qui auront manuellement choisi la v3).
pour l'instant la v3 n'est pas encore dans l'upstream. Je n'ai pas l'impression que Google l'ai soumis a l'upstream.
Il faut donc suivre ce fichier pour voir à partir de quelle version du noyau il sera pris en compte:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_bbr.c
(la v3 de Google (https://github.com/google/bbr/blob/v3/net/ipv4/tcp_bbr.c#L72) contient "#define BBR_VERSION 3" a la ligne 72).
on peut aussi suivre: https://lore.kernel.org/lkml/?q=tcp_bbr.c
et https://marc.info/?l=linux-kernel&r=1&s=bbr&q=b&w=4 pour voir les demandes de patch au kernel.
-
Ah, j'étais persuadé qu'on aurait le choix entre BBR et BBRv2 (puis BBRv3, mais il n'est pas finalisé).
Le Kernel 6.2 intègre BBR ou BBRv2 ?
-
Ah, j'étais persuadé qu'on aurait le choix entre BBR et BBRv2 (puis BBRv3, mais il n'est pas finalisé).
Le Kernel 6.2 intègre BBR ou BBRv2 ?
bbrv2 n'a jamais été finalisé et était proposé 'a coté' (tcp_bbr2.c) et pas 'a la place de'.
La v3 sera dans tcp_bbr.c a la place de la v1 mais le code source de la v1 sera conservé dans tcp_bbr1.c donc il se peut effectivement que certaines distro proposent 'bbr' (v3) et 'bbr1' (v1).
L'idée est quand meme qu'a un moment, ceux qui utilisent deja bbr (v1 donc) bascule automatiquement en v3 lors d'une maj du kernel, avec éventuellement une option pour downgrader 'explicitement' en v1 (mais cela reste a confirmer et peux changer en cas de régression).
-
Merci pour l'explication.
-
Vous savez où on en est de la mise à jour de BBR dans le noyeau Linux ?
Depuis juillet, BBRv1 est considéré comme obsolète.
(https://lafibre.info/testdebit/linux/202307_bbr_v3_doc_ietf117_1.webp)
Document présenté lors de l'IETF 117 sur BBRv3 :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/202307_bbr_v3_doc_ietf117.webp) (https://lafibre.info/testdebit/linux/202307_bbr_v3_doc_ietf117.pdf)
-
dans les sources upstream du kernel c'est toujours la v1: https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_bbr.c
j'ai pas l'impression que Google est encore proposé la v3 a l'upstream (mais y'a pas de modif sur le code de la v3 depuis juillet).
Les changements listés pour le prochain kernel, la version 6.7 a venir fin decembre/debut janvier n'incluent pas bbr v3
après on peut compiler sont propre kernel avec bbr v3.
-
Oui certains kernels l'ont déjà.
J'utilise Xanmod et c'est bien indiqué.
-
Oui, l'installation est simple : https://xanmod.org/
wget -qO - https://dl.xanmod.org/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/xanmod-archive-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/xanmod-archive-keyring.gpg] http://deb.xanmod.org releases main' | sudo tee /etc/apt/sources.list.d/xanmod-release.list
sudo apt update && sudo apt install linux-xanmod-x64v3
-
Breaking News : BBRv3 devrait prochainement être intégré dans le noyau Linux.
Le noyau 6.8 est presque finalisé (on en est à la release candidate 4 actuellement), BBRv3 pourrait donc être intégré dans le noyau 6.9.
Cela serait donc trop tard pour la version initiale d'Ubuntu 24.04, qui sortira avec le noyau 6.8.
BBRv3 devrait être donc proposé dans Ubuntu 24.10 (qui sort en octobre 2024), Debian 13 (qui sort mi-2025) ou Fedora 41 (qui sort en novembre 2024).
-
On devrait pouvoir voir dimanche prochain le premier code du noyau Linux 6.9 sur https://www.kernel.org/ , pour voir si BBRv3 est bien intégré.
-
Il n'y sera pas, les features networking pour 6.9 ont déjà été mergées par Linus (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9187210eee7d87eea37b45ea93454a88681894a4), et il n'y a pas BBRv3 dedans. D'où venait l'info à l'origine ?
-
J'avais une information sur une intégration prochaine de BBRv3, sans avoir la version de noyau Linux précise concerné.
Je pensais que cela serait pour le 6.9, c'est peut-être remis au 6.10.
À noter qu'il faudra peut-être attendre BBRv4 pour que ce soit le protocole de congesiton par défault à la place de Cubic :
To make sure we're all on the same page: currently the TCP BBR code in Linux is BBRv1. We are working on getting BBRv3 upstream into Linux TCP.
BBRv1 is definitely not ready to be the default on any Linux distribution. Whether BBRv3 is ready to be a distribution default is arguable. Personally I would prefer to see BBRv3 improve with respect to Reno/CUBIC coexistence and keeping loss rates low before arguing that it is ready to be the default.
Source : Google Group Dev BBR (https://groups.google.com/g/bbr-dev/c/i-sZpfwPx-I/m/0jmNry0AAgAJ)
Traduction rapide :
Pour être sûr que nous sommes tous sur la même longueur d'onde : actuellement, le code TCP BBR sous Linux est BBRv1. Nous travaillons à intégrer BBRv3 en amont dans Linux TCP.
BBRv1 n'est certainement pas prêt à être la valeur par défaut sur une distribution Linux. La question de savoir si BBRv3 est prêt à devenir une distribution par défaut est discutable. Personnellement, je préférerais voir BBRv3 s'améliorer en ce qui concerne la coexistence Reno/CUBIC et maintenir les taux de perte à un niveau bas avant d'affirmer qu'il est prêt à être la valeur par défaut.
-
Google à écrit dans ses slides du 21 mars 2024 que
BBRv3 serait proposé "ASAP" ( As Soon As Possible ) dans le noyau Linux :
(https://lafibre.info/testdebit/linux/202403_bbr_v3_doc_ietf119_3.webp)
Le lien vers le GitHub BBRv3 : https://github.com/google/bbr/blob/v3/README.md
Document présenté lors de l'IETF 119 sur BBRv3 :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/202403_bbr_v3_doc_ietf119.webp) (https://lafibre.info/testdebit/linux/202403_bbr_v3_doc_ietf119.pdf)
BBRv3 pourrait donc être intégré dans le noyau 6.10.
(https://lafibre.info/images/logo/logo_bbrv3.webp)
-
Deux autre diapositives intéressantes :
(https://lafibre.info/testdebit/linux/202403_bbr_v3_doc_ietf119_1.webp)
(https://lafibre.info/testdebit/linux/202403_bbr_v3_doc_ietf119_2.webp)
-
Hier, le noyau Linux 6.9 est sorti en version stable.
La fenêtre d’intégration pour le noyau 6.10 vient de s'ouvrir.
Il faudra vérifier si BBRv3 est bien présent.
-
Ce ne sera pas pour cette fois non plus : net-next-6.10 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b294a1f35616977caddaddf3e9d28e576a1adbc)