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

0 Membres et 1 Invité sur ce sujet

Thornhill

  • Client SFR fibre FTTH
  • *
  • Messages: 3 549
  • Saint-Médard-en-Jalles (33)
Algo de controle de la congestion TCP: BBR
« Réponse #36 le: 10 janvier 2020 à 17:30:18 »
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

  • Client Orange Fibre
  • *
  • Messages: 145
  • Talissieu 01
Algo de controle de la congestion TCP: BBR
« Réponse #37 le: 10 janvier 2020 à 17:33:14 »
Plutôt 110% de bénéfice.

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

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 7 448
  • FTTH 1Gb/s sur Paris (75)
Algo de controle de la congestion TCP: BBR
« Réponse #38 le: 10 janvier 2020 à 19:10:44 »
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

  • Client Orange Fibre
  • *
  • Messages: 145
  • Talissieu 01
Algo de controle de la congestion TCP: BBR
« Réponse #39 le: 10 janvier 2020 à 21:09:31 »
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

  • Administrateur
  • *
  • Messages: 36 405
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« 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)

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

  • Administrateur
  • *
  • Messages: 36 405
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« 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 ?

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

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

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 7 448
  • FTTH 1Gb/s sur Paris (75)
Algo de controle de la congestion TCP: BBR
« 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

  • Administrateur
  • *
  • Messages: 36 405
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« 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.

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 :

#!/bin/sh -e

setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

exit 0

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 7 448
  • FTTH 1Gb/s sur Paris (75)
Algo de controle de la congestion TCP: BBR
« 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

  • Administrateur
  • *
  • Messages: 36 405
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« 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

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 7 448
  • FTTH 1Gb/s sur Paris (75)
Algo de controle de la congestion TCP: BBR
« Réponse #46 le: 24 janvier 2020 à 21:44:21 »
Chaque distrib a ses modules dynamiques:
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:
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

  • Administrateur
  • *
  • Messages: 36 405
    • Twitter LaFibre.info
Algo de controle de la congestion TCP: BBR
« 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 ?

 

Mobile View