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)

Impact du contrôle de congestion (Cubic, BBR,...) sur la mesure de la Qos :

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)


Vidéo de l'IETF 104 : On parle de BBR v2 à partir de la 4ème minute de la vidéo :

Document présenté lors de l'IETF 106 :
(cliquez sur la miniature ci-dessous - le document est au format PDF)


Vidéo de l'IETF 106 : On parle de BBR v2 à partir de la 28ème minute de la vidéo :

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

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).

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).