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

vivien · « **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 · « **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)

Un résumé sur le blog du RIPE Labs: https://labs.ripe.net/Members/ranysha_ware/modelling-bbr2019s-interactions-with-loss-based-congestion-control
Le papier en question (ACM): https://dl.acm.org/authorize?N695087
La présentation lors de la conférence: https://vimeo.com/showcase/6531379/video/369121357#t=999s

Bonne lecture

vivien · « **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 :

Code: [Sélectionner]

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 :

Code: [Sélectionner]

# 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 · « **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 :

underground78 · « **Réponse #64 le:** 12 avril 2020 à 20:05:53 »

Effet de l'algorithme de contrôle de la congestion sur une connexion FTTH avec une collecte saturée (à priori) :

.\wget.exe -O NUL https://iperf.online.net/1000Mo.dat --> 37.3 Mo/s
.\wget.exe -O NUL http://scaleway.testdebit.info/1G/1G.iso --> 106 Mo/s

Esco · « **Réponse #65 le:** 01 juillet 2020 à 10:59:14 »

Hello,

J'ai un problème avec des tests de débits TCP-Cubic en Multithread.
J'ai fait quelques tests BBR vs Cubic en Local avec iPerf3 avec dégradation de la ligne (PckLoss et Latence) pour voir l'impact des pckloss et latence sur les débits.

configuration de test :

noyau client Linux : 5.5.2
noyau serveur Linux : 5.4.0
iPerf 3.7
Netem pour les dégradations (pckloss coté serveur/latence coté client)

Conf. serveur (merci Vivien)

Citer

# Reduce the swap
vm.swappiness = 1

# TCP congestion control protocol for high-speed and long-distance networks
#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

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

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

Problèmes
j'ai des valeurs incohérentes sur la conf "latence=50ms" comme vous pouvez le voir ici :

Le débit chute à 50ms (cubic) et remonte à 100ms. J'ai refais 50x le tests, j'ai inversé le client et le serveur mais les résultats sont toujours les mêmes. Je ne comprends pas.

Quelqu'un sait-il pourquoi le débit Cubic chute à 50ms pour remonter à 100ms ? comment remédier à ce problème ?

Présicion : en monothread ce comportement n'a pas lieu. Uniquement en multi.
Précision 2 : j'ai testé d'autres valeurs autour de 50ms. ça ne change rien.

kgersen · « **Réponse #66 le:** 01 juillet 2020 à 22:15:12 »

Citation de: Esco le 01 juillet 2020 à 10:59:14

Quelqu'un sait-il pourquoi le débit Cubic chute à 50ms pour remonter à 100ms ? comment remédier à ce problème ?

c'est peut-etre propre a IPerf3, test avec autre chose.

En tests multi-session TCP il y a:

- Goben : https://github.com/udhos/goben (Attention aux options sinon ca genere du traffic dans les 2 sens en meme temps)

exemple sous Linux:

Code: [Sélectionner]

# client et serveur
mkdir test
cd test
curl -L -o goben https://github.com/udhos/goben/releases/download/v0.3/goben_linux_amd64
chmod +x goben
# sur le serveur
./goben 
# sur le client
./goben -connections 16 -passiveClient -hosts ip_serveur:8080
# -passiveServer pour l'autre sens

nb: avec cette version (0.3) il n'y a pasla somme des débits des connexions donc il faut la faire a la main.
sinon compiler soit meme pour avoir la v0.4 (cf le github).

- NSpeed (en cours de développement) - version preview ici: http://nspeed.org/nspeed-client/v0.2/
C'est un client http multi session donc il faut un serveur web en face avec des fichiers de mire (comme ceux de https://bouygues.testdebit.info/ ou créer localement avec fallocate) et préférence un ssd.
exemple sous Linux:

Code: [Sélectionner]

# serveur
mkdir test
cd test
# serveur web spark ( https://github.com/rif/spark/releases )
curl -s -L https://github.com/rif/spark/releases/download/v1.7.3/spark_1.7.3_linux_amd64.tar.gz | tar xzvf - spark
# creation d'un fichier de 1G
fallocate -l 1000000000 1G.bin
# lancement serveur web répertoire courant (ajuster port si deja utilisé)
./spark  -port 8080 $(pwd)
# si on a python3 installé on peut aussi utiliser
python3 -m http.server 8080
# mais la performance n'est pas forcement top

# client
mkdir test
cd test
curl -L -o nspeed http://nspeed.org/nspeed-client/v0.2/Linux-x64/nspeed-client
chmod +x nspeed
# test mono connexion pour voir si ok (ajusté port a celui du serveur)
./nspeed http://ip_serveur:8080/1G.bin
# test multi connexion (répéter l'url autant de fois que nécessaire)
./nspeed http://ip_serveur:8080/1G.bin http://ip_serveur:8080/1G.bin http://ip_serveur:8080/1G.bin http://ip_serveur:8080/1G.bin

comme Goben 0.3, y'a pas encore la somme des débits

Dans les 2 cas, pour l'algo de congestion tcp il faut le changer au niveau système (coté émetteur).

Esco · « **Réponse #67 le:** 02 juillet 2020 à 10:12:28 »

Merci kgersen pour ton retour.

"c'est peut-etre propre a IPerf3, test avec autre chose."
En phase.

J'ai fait de nouveaux tests hier après analyse TCP (capture shark coté serveur). Je me suis aperçu que pour les tests à 50ms/0.1% loss il y avait un problème de randomisation des pertes. Je m'explique, la première salve de perte arrivait toujours en tout début de DL, ce qui bloquait dès le départ la montée en débit avec une fenêtre de congestion qui n'arrive pas à grandir "assez rapidement" avec pour conséquence un Byte In Flight (BIF) toujours bas et un débit pourri au bout du tuyau. Ce problème arrivait dans 100% des tests.

J'ai donc ajouté un paramètre sur Netem pour randomiser l'injection de PckLoss et contourner le problème de burst de pckLoss en début de téléchargement.

avant : tc qdisc add dev eth1 root netem loss 1% --> débits = 400Mbps
après : tc qdisc add dev eth1 root netem loss 1% 25% --> débit = (env)850Mbps

Cette simple modif m'a permis de retrouver une valeur plus cohérente. Je n'ai pas encore testé tous les points, mais je pense que le problème était à ce niveau.

vivien · « **Réponse #68 le:** 02 juillet 2020 à 13:14:53 »

C'est vrai que l'emplacement des pertes de paquets dans les connexions TCP n'a pas toujours les mêmes conséquences.

Les pertes de paquets au début de la connexion TCP, sur le paquet [SYN] ou sur les paquets lors de la montée en débit rapide (slow start TCP) sont bien plus impactantes que celles qui arrivent quand la connexion est régime établi.

Enfin je reste étonné du choix de choisir un noyau Linux custom, non proposé par la distribution (kernel 5.5 coté client sur une Ubuntu 20.04). Il ne me semble pas pertinent de travailler avec de vieux noyaux (sauf si c'est pour noter les progressions) mais il me semble que de prendre un noyau maison fait prendre des risques (a moins qu'il y ait une fonctionnalité intéressante rajouté entre le noyau 5.4 et 5.5)

Esco · « **Réponse #69 le:** 02 juillet 2020 à 16:55:45 »

@Vivien, J'ai juste récupéré un Ubuntu sur leur site (la 20.04) pour le serveur.

vivien · « **Réponse #70 le:** 11 septembre 2020 à 09:06:52 »

Dans le rapport sur l'état de l'internet en France : (cliquez sur la miniature ci-dessous - le document est au format PDF de 100 pages)

Citation de: vivien le 25 juin 2020 à 21:53:04

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