Auteur Sujet: Algo de contrôle de la congestion TCP: BBR (Lu 53132 fois)

Thornhill · « **Réponse #36 le:** 10 janvier 2020 à 17:30:18 »

Citation de: Fyr le 10 janvier 2020 à 15:34:24

En gros en dessous de 100Mbs de bande passante et 75ms de RTT : aucun intérêt. On atteint les 10% de bénéfice au dessus de 250Mbs et 150ms de RTT.

Plutôt 110% de bénéfice.

Fyr · « **Réponse #37 le:** 10 janvier 2020 à 17:33:14 »

Citation de: Thornhill le 10 janvier 2020 à 17:30:18

Plutôt 110% de bénéfice.

Tout à fait, ils atteignent 115% sur le palier 200 ms de RTT et 500Mbs

kgersen · « **Réponse #38 le:** 10 janvier 2020 à 19:10:44 »

Citation de: Fyr le 10 janvier 2020 à 17:09:26

Le tableau

c'est le goodput relatif a cubic... pas absolu... donc quasi tout le temps bbr est meilleur sauf la case en 'bleue' a -12%

Fyr · « **Réponse #39 le:** 10 janvier 2020 à 21:09:31 »

Citation de: kgersen le 10 janvier 2020 à 19:10:44

c'est le goodput relatif a cubic... pas absolu... donc quasi tout le temps bbr est meilleur sauf la case en 'bleue' a -12%

Oui voilà, c'est équivalent à l'algo Cubic, et ca devient significativement meilleur à partir d'un certain palier de RTT/débit. Et au moins un cas où c'est moins bon.

vivien · « **Réponse #40 le:** 22 janvier 2020 à 10:36:51 »

Comparaison Cubic / BBR réalisée sur une ligne Free FTTH en monothread et multithread.

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 : Mac mini (Core i7-8700B 6 cœurs / 12 threads 3,2 GHz / 4,6 Ghz en boost PDT 65watts, 32 Go mémoire, 1 To SSD, macOS 10.15.2 - équipé d’un chip Aquantia AQC107)

Citation de: vivien le 22 janvier 2020 à 10:04:02

Les évolutions du tcp_congestion_control :
- 17 janvier 9h32 Illinois => Cubic
- 20 janvier 8h12 Cubic => BBR
- 22 janvier 10h03 BBR => Illinois (on n'avais pas de tests mono-thread en Illinois)

Actuellement :
$ cat /proc/sys/net/ipv4/tcp_congestion_control illinois

OS Serveur : Ubuntu server 18.04 LTS avec Kernel 5.3 avec taille de buffer max de 16 Mo.
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

OS Client : Mac OS
Optimisation réaisée sur le mac le 19/01/2020 sur le fichier /etc/sysctl.conf :
kern.ipc.maxsockbuf=33554432 kern.ipc.somaxconn=2048 net.inet.tcp.sendspace=4194304 net.inet.tcp.recvspace=4194304 net.inet.tcp.win_scale_factor=8 net.inet.tcp.autorcvbufmax=33554432 net.inet.tcp.autosndbufmax=33554432 net.inet.tcp.slowstart_flightsize=20 net.inet.tcp.local_slowstart_flightsize=9 net.inet.tcp.mssdflt=1432 net.inet.tcp.v6mssdflt=1452

vivien · « **Réponse #41 le:** 24 janvier 2020 à 13:44:29 »

Les versions récentes d'iPerf3 permettent de sélectionner un autre a "tcp_congestion_contro"

Est-il nécessaire de le rajouter dans "tcp_allowed_congestion_control" si bbr n'est pas l'algorithme par défaut ?

Je vais rester en cubic pour le "tcp_congestion_contro" par défaut.
"tcp_allowed_congestion_control" ne contient que reno et cubic sous Ubuntu.

Faut-il rajouter une ligne
net.ipv4.tcp_allowed_congestion_control =bbr
dans mon fichier /etc/sysctl.d/90-server-optimization.conf ?

Code: [Sélectionner]

$ cat /proc/sys/net/ipv4/tcp_congestion_control
cubic

$ cat /proc/sys/net/ipv4/tcp_allowed_congestion_control 
reno cubic

kgersen · « **Réponse #42 le:** 24 janvier 2020 à 17:58:21 »

tcp_allowed_congestion_control concerne uniquement les process non privilégiés (non root ou sans le droit CAP_NET_ADMIN).

C'est la liste des reglages de congestion qu'ils ont droits de demander au kernel pour leur flux.

Si ton process tourne en root ou a CAP_NET_ADMIN alors il peut choisir ce qu'il y a dans tcp_available_congestion_control sinon il est limité a tcp_allowed_congestion_control.

vivien · « **Réponse #43 le:** 24 janvier 2020 à 18:19:12 »

Intéressant.

Je ne laisse pas tourner iPerf en root.

Pour CAP_NET_ADMIN pour ne pas devoir le remettre à chaque mise à jour du binaire ?

Regarde mon tutoriel pour Wireshark, la seulle solution que j'ai trouvé à l'époque c'est de réappliquer
setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

A chaque démarrage de linux.

Citation de: vivien le 27 avril 2015 à 08:53:10

Utiliser Wireshark sous Linux, sans les droits "root"

Si vous démarrez Wireshark sous Linux sans les droits root, vous pouvez ouvrir des fichiers mais impossible de faire des captures.

Il n'est pas conseillé de démarrer Wireshark avec les droits root !
Une faille dans le logiciel pourrait avoir de lourdes conséquences.

La solution ?

Donner les droits à l’utilisateur courant de réaliser une capture après s'être déconnecté / reconnecté.

Copiez / collez ces 4 lignes dans un terminal, en remplacent VOTRE_LOGIN par votre login utilisateur :
sudo addgroup -quiet -system wireshark
sudo chown root:wireshark /usr/bin/dumpcap
sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap
sudo usermod -a -G wireshark VOTRE_LOGIN

L'utilisateur mentionné peut maintenant réaliser des captures.

Par contre, lors des mises à jour de Wireshark, l’exécutable /usr/bin/dumpcap est modifié, ce qui fait perdre les droits.

Le plus simple consiste à rajouter les droits à chaque démarrage du PC en éditant le fichier /etc/rc.local :

Dnas une ligne de commande tapez : sudo nano /etc/rc.local
Et rajoutez la ligne setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap après #!/bin/sh -e et avant exit 0

Un exemple de fichier /etc/rc.local :
Code: [Sélectionner]
#!/bin/sh -e setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap exit 0

kgersen · « **Réponse #44 le:** 24 janvier 2020 à 18:29:49 »

modifier tcp_allowed_congestion_control plutot que donner cap_net_admin a iperf3 me parait plus simple et sur.

vivien · « **Réponse #45 le:** 24 janvier 2020 à 21:01:53 »

C'est lequel des dossier qui me donne la bonne liste des alogo disponibles ?

Dans chacune des deux liste il y en a qui sont en "exclusivité", ceux que j'ai mis en gras.

$ ls -1 /lib/modules/5.3.0-26-generic/kernel/net/ipv4 | grep tcp
tcp_bbr.ko => BBR (Google 2016) => https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_BBR
tcp_bic.ko => BIC https://en.wikipedia.org/wiki/BIC_TCP
tcp_cdg.ko => CAIA Delay-Gradient https://en.wikipedia.org/wiki/Delay-gradient_congestion_control
tcp_dctcp.ko => Data Center TCP https://www.bortzmeyer.org/8257.html
tcp_diag.ko
tcp_highspeed.ko => High Speed https://en.wikipedia.org/wiki/HSTCP
tcp_htcp.ko => H-TCP Hamilton TCP https://en.wikipedia.org/wiki/H-TCP
tcp_hybla.ko => Hybla https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_Hybla
tcp_illinois.ko => Illinois https://en.wikipedia.org/wiki/TCP-Illinois
tcp_lp.ko => TCP-LP Low-priority https://users.cs.northwestern.edu/~akuzma/rice/TCP-LP/
tcp_nv.ko => TCP-NV New Vegas https://docs.google.com/document/d/1o-53jbO_xH-m9g2YCgjaf5bK8vePjWP6Mk0rYiRLK-U
tcp_scalable.ko => Scalable https://en.wikipedia.org/wiki/Scalable_TCP
tcp_vegas.ko => Vegas https://en.wikipedia.org/wiki/TCP_Vegas
tcp_veno.ko => Veno https://www.ie.cuhk.edu.hk/fileadmin/staff_upload/soung/Journal/J3.pdf
tcp_westwood.ko => Westwood https://en.wikipedia.org/wiki/TCP_Westwood
tcp_yeah.ko => YeAH http://www.csc.lsu.edu/~sjpark/cs7601/4-YeAH_TCP.pdf

$ ls -1 /usr/src/linux-headers-5.3.0-26-generic/include/config/tcp/cong
advanced.h
bbr.h
bic.h
cdg.h
cubic.h
dctcp.h
hstcp.h
htcp.h
hybla.h
illinois.h
lp.h
nv.h
scalable.h
vegas.h
veno.h
westwood.h
yeah.h

kgersen · « **Réponse #46 le:** 24 janvier 2020 à 21:44:21 »

Chaque distrib a ses modules dynamiques:

Code: [Sélectionner]

ls -l /lib/modules/$(uname -r)/kernel/net/ipv4/tcp_*

les .ko sont les algos chargeables dans le kernel.

ou des modules inclus directement le kernel:

Code: [Sélectionner]

cat /lib/modules/$(uname -r)/modules.builtin | grep ipv4/tcp
les algo chargés (en mémoire) sont visibles dans: tcp_available_congestion_control (ou via lsmod) mais un process qui a les droits (root ou cap) peut demander n'importe quel algo dont le module est dispo. ca fera un chargement dynamique.

donc tcp_available_congestion_control ne reflète pas tout ce qui est possible si le chargement dynamique de module est permis.

Au besoin tu peux blacklister des modules et en pré-charger au boot (dans /etc/modules-load.d/modules.conf)

vivien · « **Réponse #47 le:** 25 janvier 2020 à 12:15:07 »

Finalement je ne pense pas proposer tous les algorithmes d'évitement de congestion.

Ceux qui sont pertinents pour avoir de hauts débits et comparer avec le legacy sont :

- Cubic (algorithme par défaut sous Linux)
- BBR, le dernier né de Google
- H-TCP Hamilton TCP https://en.wikipedia.org/wiki/H-TCP
- Illinois https://en.wikipedia.org/wiki/TCP-Illinois
- Reno (lui il est déjà mis à disposition par défaut sous Linux)

Vous en voyez d'autres à mettre a disposition dans tcp_allowed_congestion_control ?

Auteur Sujet: Algo de contrôle de la congestion TCP: BBR (Lu 53132 fois)

Thornhill

Algo de controle de la congestion TCP: BBR

Fyr

Algo de controle de la congestion TCP: BBR

kgersen

Algo de controle de la congestion TCP: BBR

Fyr

Algo de controle de la congestion TCP: BBR

vivien

Algo de controle de la congestion TCP: BBR

vivien

Algo de controle de la congestion TCP: BBR

kgersen

Algo de controle de la congestion TCP: BBR

vivien

Algo de controle de la congestion TCP: BBR

kgersen

Algo de controle de la congestion TCP: BBR

vivien

Algo de controle de la congestion TCP: BBR

kgersen

Algo de controle de la congestion TCP: BBR

vivien

Algo de controle de la congestion TCP: BBR