BBR : fonctionnement et limites de l’algorithme de contrôle de congestion TCP
BBR (Bottleneck Bandwidth and Round-trip propagation time) est un algorithme de contrôle de congestion TCP développé par Google et publié en 2016. Contrairement aux algorithmes historiques fondés sur la perte de paquets, BBR estime en continu la bande passante disponible et le RTT minimal du chemin réseau. Comprendre son fonctionnement permet d’évaluer ce que peut réellement apporter son déploiement dans l’infrastructure d’un fournisseur VPN, dans le cadre plus large de la vitesse des VPN.
BBR fonctionnement : Sommaire
Pourquoi les algorithmes de contrôle de congestion existent
TCP garantit la livraison ordonnée des données. Pour ce faire, il doit réguler son débit d’émission en fonction de la capacité du chemin réseau, sous peine de saturer les buffers intermédiaires et de provoquer des pertes conséquentes. C’est le rôle du contrôle de congestion.
Pendant trois décennies, les algorithmes dominants (Reno, puis CUBIC depuis Linux 2.6.19) ont utilisé la perte de paquets comme signal de congestion : quand un paquet est perdu, l’émetteur réduit sa fenêtre de congestion, puis la réaugmente progressivement. Cette logique réactive fonctionne dans un grand nombre de cas, mais elle présente deux défauts structurels documentés dans la littérature réseau.
D’abord, sur des liens à buffers peu profonds, des pertes peuvent survenir même lorsque le lien est loin d’être saturé, simples rafales transitoires sur des commutateurs à faible capacité de mise en mémoire tampon. CUBIC interprète ces pertes comme un signal de congestion et réduit inutilement son débit utile (goodput).
Ensuite, sur des liens à buffers profonds sans gestion active de file d’attente (AQM — Active Queue Management, comme CoDel ou PIE), CUBIC peut maintenir la queue constamment remplie sans jamais déclencher de perte. Le débit est élevé, mais la latence explose, c’est le phénomène de bufferbloat. La cause est autant la profondeur des buffers et l’absence d’AQM que le comportement de CUBIC lui-même.
BBR est une réponse à ces deux problèmes. Il ne réagit pas à la perte après coup : il modélise le chemin réseau en permanence.
Ce que BBR mesure et comment il régule
BBR cherche à atteindre le point de fonctionnement optimal défini par Kleinrock (1979) : taux d’émission égal à la bande passante disponible au goulot d’étranglement, sans queue persistante. Il modélise le chemin réseau à partir de deux paramètres mesurés en continu.
BtlBw (Bottleneck Bandwidth), estimation de la bande passante disponible au goulot d’étranglement, calculée à partir du débit de livraison mesuré (delivery rate).
RTprop (Round-trip propagation time), RTT minimal observé sur une fenêtre temporelle (historiquement ~10 secondes dans BBRv1), représentant la latence de propagation pure sans contribution des queues. BBRv2 et BBRv3 utilisent des mécanismes de probing du RTT différents.
À partir de ces deux estimations, BBR dérive un produit bande passante-délai (bandwidth-delay product, BDP) et maintient le volume de données en transit (inflight data) proche de ce BDP. Il contrôle le taux d’émission par du pacing, espacement des paquets dans le temps, plutôt que par une simple limite de fenêtre.
Pourquoi le BDP est la clé du problème
Le BDP représente le volume de données qu’un flux TCP doit maintenir en transit pour saturer un lien. Il se calcule directement :
BDP = bande passante × RTT
Exemple : 1 Gbit/s × 150 ms = 18,75 Mo
Sur ce lien, TCP doit maintenir environ 18 Mo de données en vol simultanément pour l’utiliser pleinement. CUBIC y parvient si la fenêtre de congestion est dimensionnée en conséquence, mais sur des chemins à RTT long, la fenêtre peut ne pas atteindre ce seuil avant qu’une perte (réelle ou spurious) ne la réduise de 30 %. BBR contourne ce problème en pilotant directement le pacing rate plutôt qu’en attendant les signaux de perte.
Les quatre états de la machine à états BBR
STARTUP : Croissance exponentielle (×2/RTT) jusqu’à saturation du BtlBw.
DRAIN : Vidange de la queue créée en STARTUP (pacing_gain inférieur à 1).
PROBE_BW : Cycle de 8 phases (5/4, 3/4, 1×6) pour maintenir une estimation BtlBw fraîche. C’est l’état dans lequel BBR passe la quasi-totalité du temps. Sur 8 RTTs, BBR sonde à +25 % pendant 1 RTT, draine à −25 % pendant 1 RTT, puis croise à débit nominal pendant 6 RTTs. Ce cycle lui permet de détecter une augmentation de la bande passante disponible sans maintenir de queue persistante.
PROBE_RTT : Toutes les 10 secondes : réduction du volume inflight pour mesurer un RTprop propre.
CUBIC vs BBR : deux philosophies du contrôle de congestion
CUBIC est spécifié dans la RFC 9438 (2023). Cette RFC indique que CUBIC a été adopté comme algorithme TCP de contrôle de congestion par défaut par les piles Linux, Windows et Apple. Il utilise une fonction cubique pour gouverner la croissance de la fenêtre de congestion, indépendamment du RTT.
Signal de congestion
CUBIC : perte de paquet (réactif).
BBR : modèle BtlBw + RTprop (proactif).
Comportement sur buffer profond
CUBIC : queue maintenue pleine (bufferbloat).
BBR : tendance à mieux contenir la file d’attente via pilotage par modèle, pacing et contrôle de l’inflight.
Équité inter-flux homogènes
CUBIC : bonne (convergence documentée).
BBR : bonne entre flux BBR.
Mécanisme de régulation
CUBIC : fenêtre de congestion (CWND).
BBR : pacing rate + CWND.
Comportement sur buffer peu profond
CUBIC : correct (les pertes déclenchent le recul).
BBR : retransmissions élevées (voir section suivante).
Équité envers CUBIC concurrent
BBR : problématique selon la topologie (voir section BBRv1 vs BBRv2).
Comportement sur perte aléatoire
CUBIC : réduction systématique de −30 %.
BBR : pas de réduction si BtlBw stable.
RTT long (supérieur à 100 ms)
CUBIC : peut sous-utiliser les liens à haut BDP.
BBR : moins sensible au RTT long.
Déploiement par défaut
CUBIC : Linux (depuis le noyau 2.6.19), Android.
BBR : opt-in côté serveur.
Pertinence de BBR dans un contexte VPN
Ce sur quoi BBR agit et ce sur quoi il n’agit pas
BBR est un algorithme de contrôle de congestion TCP. Cette précision est essentielle dans un contexte VPN, car la plupart des protocoles de tunnelisation modernes utilisent UDP comme couche de transport :
- WireGuard® → UDP uniquement
- OpenVPN → UDP (mode recommandé) ou TCP
- IKEv2/IPsec → UDP (ports 500/4500)
Dans ces configurations, BBR ne s’applique pas au tunnel lui-même. Il agit sur les flux TCP qui transitent à l’intérieur du tunnel, c’est-à-dire sur les connexions TCP que le serveur VPN établit vers les destinations finales, une fois le paquet décapsulé.
Le chemin effectif d’un flux HTTPS encapsulé dans WireGuard® est le suivant :
- Client → TCP (HTTPS) : soumis aux règles TCP habituelles côté client
- Encapsulé dans UDP (WireGuard) : BBR ne s’applique pas ici
- Serveur VPN : décapsule, rétablit le flux TCP
- TCP vers destination : c’est ici que BBR peut agir, côté serveur
Dans l’architecture mise en avant ici, et dans le contexte de fonctionnalités comme l’accélérateur VPN de Proton, le gain potentiel lié à BBR concerne surtout le segment TCP sortant du serveur VPN vers la destination finale. Le tunnel lui-même, lorsqu’il repose sur UDP (WireGuard, IKEv2, OpenVPN UDP), n’est pas piloté par BBR. D’autres segments TCP d’une chaîne transport/applicative pourraient également être concernés selon l’architecture, mais ce cas n’est pas l’objet de cette page.
Conditions favorables sur le segment sortant du serveur VPN
Augmentation du RTT effectif. Sur des connexions longue distance, typiquement Europe→Amérique du Nord ou Europe→Asie, le RTT du segment sortant du serveur VPN peut dépasser 100 à 200 ms, plage où CUBIC peut sous-utiliser le lien disponible si la fenêtre de congestion n’est pas suffisamment dimensionnée.
Pertes aléatoires sur le chemin sortant. Les pertes non corrélées à une congestion réelle (rafales sur commutateurs à buffer peu profond, pertes radio sur certains chemins) amènent CUBIC à réduire sa fenêtre de −30 % (RFC 9438, §5.8), dégradant le goodput de manière disproportionnée. BBR, modélisant le réseau à partir du delivery rate, est moins sensible à ce mécanisme.
En revanche, sur des connexions locales ou régionales (RTT inférieur à 20 ms, pertes proches de zéro), l’effet de BBR est marginal à nul : CUBIC atteint déjà les limites physiques du lien sans les frictions qu’exploite BBR. C’est notamment le cas typique du gaming en réseau local, pour lequel d’autres leviers sont plus pertinents (voir améliorer la vitesse d’Internet pour les jeux).
BBRv1 vs BBRv2 : les correctifs apportés sur l’équité et les retransmissions
BBRv1, tel que publié en 2016 et intégré dans Linux depuis le noyau 4.9, présente deux limites documentées par plusieurs groupes de recherche indépendants.
Équité réduite envers les flux CUBIC concurrents
L’APNIC a publié en janvier 2020 une analyse formelle (APNIC Blog, 24 jan. 2020) montrant que BBRv1, bien que conçu comme un algorithme à débit fixe (rate-based), devient limité par sa fenêtre (window-limited) en situation de compétition avec CUBIC. Mécaniquement, lors de la phase ProbeBW, BBR remplit la queue du goulot d’étranglement, forçant CUBIC à réduire sa fenêtre, alors que BBR, lui, ne recule pas. Un seul flux BBRv1 peut ainsi s’approprier une fraction fixe du lien quelle que soit le nombre de flux CUBIC concurrents.
Des expériences menées par l’APNIC sur un circuit à 15,2 ms de RTT ont montré que BBRv1 pousse CUBIC à un point où ce dernier ne parvient pas à rétablir sa part équitable. Sur un chemin à 298 ms (Allemagne→Australie), l’asymétrie est également observable, quoique moins prononcée.
Limite documentée, BBRv1 : l’étude présentée à l’IMC 2019 (Stony Brook University, publiée sur APNIC Blog en jan. 2020) conclut que l’équité de BBRv1 envers CUBIC dépend fortement de la taille du buffer du goulot d’étranglement : avec un buffer réduit (10 Ko), BBRv1 peut s’accaparer plus de 90 % de la bande passante totale ; avec un buffer étendu (10 Mo), CUBIC récupère environ 80 %. Ce déséquilibre est topologie-dépendant, il ne se manifeste pas de la même façon sur tous les chemins.
Retransmissions élevées sur buffers peu profonds
La même étude (APNIC Blog, 10 jan. 2020) mesure que BBRv1 peut provoquer jusqu’à 100 fois plus de retransmissions que CUBIC sur des équipements à buffers peu profonds (100 Ko dans leur setup). BBR atteint un goodput élevé, mais au prix d’un taux de perte applicative potentiellement problématique pour des transferts sensibles à la perte.
Ce que BBRv2 corrige
BBRv2 intègre explicitement les signaux de perte et d’ECN (Explicit Congestion Notification) dans le modèle réseau de BBR, en plus des estimations de bande passante et de RTT. Cela réduit l’agressivité de la phase ProbeBW en présence de flux CUBIC concurrents et diminue le taux de retransmissions sur buffers peu profonds. Google a présenté BBRv2 comme répondant directement aux problèmes d’équité identifiés dans les travaux de 2019–2020.
BBRv2 est disponible côté serveur pour les opérateurs qui choisissent de l’activer, mais il n’est pas intégré dans les noyaux Linux grand public par défaut au moment de la rédaction de cette page.
Le débat dans la communauté réseau
Les comportements de BBRv1 décrits ci-dessus, agressivité envers CUBIC, retransmissions élevées sur certaines topologies, ont alimenté un débat persistant dans la communauté réseau sur ce que la littérature appelle la TCP-friendliness : la capacité d’un algorithme à coexister équitablement avec les flux utilisant d’autres algorithmes de contrôle de congestion. BBR a été explicitement critiqué pour ne pas satisfaire ce critère dans certaines conditions. Ces préoccupations ont contribué à la création du groupe de travail IETF CCWG (Congestion Control Working Group), chargé notamment de standardiser BBR et d’adresser ses problèmes d’équité inter-algorithmes dans les versions successives.
BBRv3 : état au moment de la rédaction (mars 2026)
BBRv3 est la version la plus récente de l’algorithme. Google a présenté ses fondements à l’IETF 117 (juillet 2023) puis son déploiement public à l’IETF 119 (mars 2024). Un Internet Draft formel, draft-ietf-ccwg-bbr-05, spécifie BBRv3 et est en révision active à l’IETF au moment de la rédaction. Aucun RFC n’a été publié à ce stade.
Les apports de BBRv3 documentés par Google comprennent une réduction d’environ 12 % du taux de retransmissions et une légère amélioration de la latence, notamment sur les chemins à haut BDP. Sur les questions d’équité avec CUBIC en présence de buffers profonds, BBRv3 présente encore des dégradations selon les mesures publiées dans l’ACM Computing Surveys (2024/2025).
Statut au moment de la rédaction : BBRv3 est documenté dans un Internet-Draft actif du CCWG (draft-ietf-ccwg-bbr) et présenté publiquement par Google à l’IETF comme la version courante de l’algorithme (slides IETF 117, 119). Le dépôt Google/BBR publie du code Linux TCP BBRv3. L’intégration dans le noyau Linux mainline reste, à cette date, un objectif annoncé par les auteurs plutôt qu’un état achevé.
BBR au-delà de TCP : QUIC
BBR n’est pas conceptuellement limité à TCP. Le draft IETF actuel (draft-ietf-ccwg-bbr) le présente comme applicable à tout protocole de transport disposant d’acquittements de livraison, et mentionne des implémentations open source existant pour TCP et QUIC, le dépôt Google/BBR publie notamment du code QUIC BBR. En pratique, les stacks QUIC ne partagent pas toutes le même algorithme de congestion : certaines utilisent NewReno par défaut, d’autres CUBIC, d’autres encore des variantes de BBR. Il n’existe pas d’algorithme QUIC universel. Ce point est pertinent dans un contexte VPN car certains fournisseurs expérimentent avec QUIC (comme Mullvad par exemple) comme couche de transport alternative pour leurs tunnels.
Dans quelles conditions BBR apporte un gain réel dans un contexte VPN
Sur la base des données disponibles, BBR, déployé côté serveur par un opérateur VPN, peut apporter un gain de goodput mesurable dans les configurations suivantes.
Congestion réelle, buffer profond : peut mieux contenir la file d’attente selon le chemin et la topologie. BBR pilote par modèle (delivery rate, RTT, pacing, inflight) plutôt que par réaction à la perte.
Ce que l’utilisateur ne peut pas vérifier
BBR est un algorithme de contrôle de congestion opéré côté serveur, sur les connexions TCP sortantes que le serveur VPN établit vers les destinations finales. L’utilisateur n’a aucune visibilité directe sur l’algorithme actif à l’extrémité distante du tunnel. Le client réseau privé virtuel (application sur le terminal) n’expose pas cette information.
Des outils comme ss -i (Linux) permettent de vérifier l’algorithme actif sur une connexion TCP locale, mais pas sur le segment sortant d’un serveur VPN distant. Des heuristiques indirectes existent, analyse des patterns de pacing TCP, du taux d’ACK, de la croissance de la fenêtre de congestion, mais elles nécessitent un accès aux métriques côté serveur, hors de portée de l’utilisateur final. La vérification fiable est impossible depuis le client.
Certains fournisseurs VPN mentionnent dans leur documentation technique l’utilisation de BBR côté infrastructure. Proton indique, dans sa documentation sur son accélérateur VPN, utiliser BBR comme algorithme de contrôle de congestion TCP pour réduire la latence et contourner certaines congestions. Dans l’architecture décrite sur cette page, cela correspond principalement au segment TCP sortant du serveur VPN vers la destination finale après décapsulage du tunnel, interprétation cohérente avec leur discours, mais non détaillée à ce niveau de granularité dans leur documentation publique. Ce type d’information relève de la communication fournisseur : elle n’est pas vérifiable indépendamment par l’utilisateur final, et son impact réel dépend des conditions spécifiques de chaque connexion.
Ce que cela implique : la mention de BBR dans la documentation d’un fournisseur VPN est un indicateur technique crédible, pas une garantie de résultat. L’effet dépend du chemin réseau effectif sur le segment serveur→destination, de la topologie des buffers intermédiaires, de la proportion de flux CUBIC concurrents, et de la version de BBR déployée. Ces variables sont hors de portée de l’utilisateur final.
Ce qu’on peut affirmer sans extrapoler
À partir des sources citées sur cette page :
- BBR n’est pas « meilleur partout » : ses avantages sont conditionnels à des paramètres réseau spécifiques (RTT élevé, pertes aléatoires, topologie des buffers).
- Selon l’APNIC (études 2019–2020), BBRv1 présente des problèmes documentés d’équité envers CUBIC et de retransmissions sur certaines topologies. BBRv2 corrige partiellement ces défauts ; BBRv3 y travaille encore.
- Selon le draft IETF CCWG, les versions récentes cherchent explicitement à corriger les problèmes de coexistence de BBRv1, en intégrant signaux de perte et ECN dans le modèle.
- La mention de BBR par un fournisseur VPN ne prouve pas à elle seule un gain mesurable pour tous les utilisateurs, l’effet dépend du chemin réseau effectif, de la version déployée, et de la topologie des équipements intermédiaires.
- BBR est déployé côté serveur. L’utilisateur final ne peut pas vérifier de manière fiable quel algorithme est actif sur le segment sortant d’un serveur VPN distant.
FAQ
Qu'est-ce que BBR exactement ?
BBR est un algorithme de contrôle de congestion utilisé par certains serveurs pour gérer la vitesse d’envoi des données sur le réseau. Au lieu d’attendre qu’un paquet soit perdu pour ralentir (ce que font les méthodes classiques), BBR estime en continu la bande passante disponible et le temps de trajet des paquets. Cela permet d’ajuster le débit plus rapidement et de réduire le gaspillage de bande passante dans certaines conditions.
Est-ce que BBR va accélérer mon VPN ?
Pas forcément. BBR peut améliorer les performances surtout lorsque la connexion présente un temps de trajet élevé (RTT) ou des pertes de paquets, par exemple sur certaines connexions longue distance ou sur des réseaux instables.
Sur une connexion courte et stable, la différence est souvent faible voire inexistante.
Est-ce que je dois activer BBR quelque part ?
Non. Dans un contexte VPN, BBR est généralement configuré côté infrastructure du fournisseur, sur les serveurs. Si votre fournisseur l’utilise, cela fonctionne automatiquement sans réglage dans l’application.
Mon fournisseur dit qu'il utilise BBR. C'est une garantie de vitesse ?
Non. C’est un indicateur technique crédible, mais pas une promesse de performance.
L’effet réel dépend du chemin réseau entre le serveur VPN et le site que vous consultez.
BBR, c'est nouveau ?
L’algorithme initial a été publié par Google en 2016. Depuis, plusieurs versions ont été développées (BBRv2 puis BBRv3) pour corriger certains problèmes identifiés dans la première version.
La version la plus récente est actuellement en cours de standardisation à l’IETF, l’organisme qui définit de nombreux standards techniques d’Internet.
Sources supplémentaires
Cardwell et al. (2016) : BBR: Congestion-Based Congestion Control, ACM Queue
https://queue.acm.org/detail.cfm?id=3022184
draft-ietf-ccwg-bbr-05 : BBR Congestion Control, Internet Draft actif (IETF CCWG)
https://datatracker.ietf.org/doc/draft-ietf-ccwg-bbr/
IETF 119 CCWG, mars 2024 : BBRv3: Algorithm Overview and Google’s Public Internet Deployment
https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00