Auteur Sujet: Algo de controle de la congestion TCP: BBR  (Lu 3228 fois)

0 Membres et 2 Invités sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 34 646
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #60 le: 16 février 2020 à 22:24:43 »
Spotify a également fait des tests sur BBR

L'expérience

De nombreux changements de protocole Internet nécessitent des mises à jour coordonnées des clients et des serveurs (en vous regardant, IPv6!). BBR est différent, il ne doit être activé que du côté de l'expéditeur. Il peut même être activé après l'ouverture de la connexion TCP !

Pour cette expérience, nous avons configuré un sous-ensemble aléatoire d'utilisateurs pour inclure «bbr» dans le nom d'hôte de la demande audio en tant qu'indicateur, et ajouter quelques lignes à la configuration du serveur. Les autres requêtes sont traitées en utilisant la valeur par défaut, CUBIC.

Nous avons maintenant des groupes de traitement et de contrôle pour notre test A / B. Pour chaque groupe, nous mesurons:
- Latence de lecture (médiane, p90, p99)
- Stutter/Bégaiement (nombre moyen par chanson)
- Bande passante, moyenne sur le téléchargement de la chanson (médiane, p10, p01)

Résultats

En prenant des moyennes quotidiennes, le Stutter/bégaiement a diminué de 6 à 10% pour le groupe BBR. La bande passante a augmenté de 10 à 15% pour les cohortes de téléchargement plus lentes et de 5 à 7% pour la médiane. Il n'y avait pas de différence de latence entre les groupes.

Variation significative entre les régions géographiques

Nous avons constaté la plupart des améliorations en Asie-Pacifique et en Amérique latine, avec respectivement 17% et 12% de baisse du bégaiement. La bande passante a augmenté de 15 à 25% pour les téléchargements plus lents et d'environ 10% pour la médiane.

En comparaison, l'Europe et l'Amérique du Nord ont enregistré une amélioration de 3 à 5% du bégaiement et environ 5% de la bande passante.





Bonus: Incident de congestion en amont

Au cours de notre expérience, nous avons connu un événement de congestion du réseau avec un fournisseur en amont sud-américain. C'est là que BBR a vraiment pu briller!

Au Pérou, le groupe non BBR a vu une augmentation de 400 à 500% du bégaiement. Dans le groupe BBR, le bégaiement n'a augmenté que de 30 à 50%.

Dans ce scénario, le groupe BBR avait une bande passante 4x pour des téléchargements plus lents (le 10e centile), une bande passante médiane 2x plus élevée et 5 fois moins de Stutter/bégaiement!

C'est la différence entre nos utilisateurs à peine remarqués et les problèmes de lecture suffisamment graves pour contacter le service client.





Conclusion

Nos résultats sont conformes aux rapports du trafic GCP, YouTube et Dropbox. Les performances avec une perte de paquets accrue sont également en ligne avec les résultats des expériences précédentes de Google .

Il y a eu des expériences montrant que BBR peut évincer le trafic CUBIC , entre autres problèmes . Dans le cadre de notre propre trafic, nous n’avons pour l’instant rien vu de tel. Par exemple, nous utilisons quelques partenaires CDN différents pour la livraison audio, mais nous n'avons exécuté l'expérience BBR que sur un seul. Le groupe non BBR ne présente aucune baisse de performance notable par rapport aux autres CDN. Nous continuerons de suivre cela de près.

Nous sommes très satisfaits des performances de BBR jusqu'à présent. Déplacer nos mesures de qualité de lecture dans la bonne direction est diaboliquement difficile, et implique normalement des compromis, par exemple bégaiement par rapport au débit audio. Avec BBR, nous avons constaté une amélioration substantielle sans coût apparent.


Source : Lab Spotify le 31 août 2018 par Erik Carlsson et Eirini Kakogianni

munsternet

  • Client FAI autre
  • *
  • Messages: 3
Algo de controle de la congestion TCP: BBR
« Réponse #61 le: 17 février 2020 à 08:16:34 »
Pour rajouter un peu d'eau au moulin, il y'a aussi eu un papier publié lors de la conférence Internet Measurement Conference 2019 sur la modélisation de BRR lorsqu'il est en concurrence avec d'autres algorithmes de controle de congestion (malheureusement c'est tout en anglais)


Bonne lecture  :)

vivien

  • Administrateur
  • *
  • Messages: 34 646
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #62 le: 17 février 2020 à 11:26:00 »
Comparaison Cubic / BBR réalisée sur une ligne Free FTTH en monothread et multithread.

Débit descendant :


Débit montant :


Tests réalisés par Breizh29, client Freebox Delta à Ergué-Gabéric, une commune du département du Finistère (29), dans la région Bretagne sur un serveur 10Gb/s hébergé par Bouygues Telecom à Nanterre (92). L’interconnexion entre Free et Bouygues Telecom se fait sur Paris TH2 en IPv4 comme en IPv6 dans les deux sens.

Client : VM sur ESXi 4vCPU sur un Core i7-10710U @1.1 GHz avec 4 Go de ram (sur 32 Go de l’hôte)
La connectivité 10G est assurée par un Sonnet Solo 10G Thunderbolt 3 édition
La VM est montée sous ESXi (6.7u2), la configuration réseau de VMWare est laissée d'origine.
La MTU est passée à 9000 dans la conf.
OS invité : Ubuntu 19.10 (Kernel Linux 5.3) et iPerf 3.6

Protocole de congestion BBR via /etc/sysctl.conf :
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.core.optmem_max = 268435456
net.core.rmem_default = 212992
net.core.wmem_default = 212992
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_fastopen = 1
net.ipv4.tcp_tso_win_divisor = 8


OS Serveur : Ubuntu server 18.04 LTS avec Kernel 5.3 avec taille de buffer max de 16 Mo.
iPerf 3.7
Optimisation réalisée :

# Reduce the swap
vm.swappiness = 1

# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096

# TCP congestion control protocol for high-speed and long-distance networks
#net.ipv4.tcp_congestion_control=illinois
net.ipv4.tcp_congestion_control=bbr

# Disable the memorization of previous tests, in order to avoid that the server burns the tests following a limited performance
net.ipv4.tcp_no_metrics_save=1

# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216

# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000

# Increase number of incoming connections
net.core.somaxconn = 512

vivien

  • Administrateur
  • *
  • Messages: 34 646
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« Réponse #63 le: 05 mars 2020 à 21:06:43 »
Nouvelle comparaison Cubic, BBR, toujours sur la même ligne, mais là les tests Cubic et BBR sont réalisés à quelques secondes d'intervalle :


 

Mobile View