La Fibre

Télécom => Réseau => reseau TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: kgersen le 07 janvier 2020 à 16:56:33

Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 07 janvier 2020 à 16:56:33
Hors sujet extrait de Serveur iperf3 chez Free (https://lafibre.info/1gb-free/serveur-iperf3-chez-free/)

ton client Linux a quoi comme controle de congestion TCP ?

pour l'afficher:

sudo sysctl net.ipv4.tcp_congestion_control

pour afficher les controles dispo:
sudo sysctl net.ipv4.tcp_available_congestion_control

en 2020, tout le monde devrait être en BBR mais pas mal de distro ne font pas l'effort de le mettre par défaut.

pour changer:

sudo sysctl net.ipv4.tcp_congestion_control=bbr
sudo sysctl net.core.default_qdisc=fq
(le qdisc est optionnel depuis le kernel 4.13 mais autant mettre fq dans des machines d'extrémités (serveur, client) plutot que fq_codel le défaut plutôt utile sur routeur).

il faudrait voir aussi coté serveur iperf ce qu'il y a comme réglages. si c'est les réglages par défaut d'une distro c'est pas forcement le mieux.

des tests récents que j'ai fais avec archlinux (client iperf3) et Debian (serveur iperf3) montraient pres de 100 Mbps d'écart entre les réglages par défaut des distros et bbr/fq.
Titre: BBR
Posté par: Fuli10 le 07 janvier 2020 à 17:27:29
Pour répondre à kgersen, sur un ubuntu server de base il n'y a que cubic et reno, cubic par défaut. Idem sur openWRT 19.07rc.
Autrement pas de tcp control sur IPv6 (ou du moins j'ai pas trouvé) et j'ai des resultats similaires. Et enfin je ne me suis jamais posé cette question chee Orange. J'ai toujours été au max (j'ai retenu 950 mais ça devait sûrement être moins).
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 07 janvier 2020 à 18:33:46
les options TCP sont communes IPv4/IPv6. Les sysctl de type "net.ipv4.tcp..." sont communs a IPv4 et IPv6. Oui c'est ambiguë et le sera plus encore quand on utilisera plus IPv4 ...

openwrt c'est un routeur donc pas concerné par bbr.

De toute facon c'est l'algo de congestion de l’émetteur qui compte donc du serveur pour le cas d'un download.

L'algo aide si la ligne est congestionné  ce qui n'était pas le cas avec Orange. Il est flagrant que y'a un souci chez Free mais ce n'est pas nouveau.
Titre: BBR
Posté par: vivien le 07 janvier 2020 à 21:33:35
Coté serveur, je suis en illinois

$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = illinois

La protocole de congestion par défaut est cubic mais il est moins performant.
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic

illinois est recomandé pour high-speed and long-distance networks
Titre: BBR
Posté par: kgersen le 07 janvier 2020 à 23:21:04
illinois est recomandé pour high-speed and long-distance networks

heu ca date un peu ton truc la  :P

recommandé par qui ?
Titre: Algo de controle de la congestion TCP: BBR
Posté par: esver le 08 janvier 2020 à 09:57:18
en 2020, tout le monde devrait être en BBR mais pas mal de distro ne font pas l'effort de le mettre par défaut.

Un gros gros merci !!!!
Avec curl sur test-debit.free.fr je passe de 15-20 à 50Mo/sec en upload !!!

Le graph Munin indique le changement
Titre: BBR
Posté par: Fuli10 le 08 janvier 2020 à 10:14:42
Merci kgersen !
J'ai fait un test avec bbr, et là direct 556Mbps en upload...
Du coup je ne comprend pas comment fait Orange pour ne pas avoir les mêmes problèmes de perf avec la configuration par défaut en cubic.
Idem je ne sais pas comment c'est géré côté windows (ils sont en wifi chez moi) mais je ne sais pas si c'est possible de changer l'algorithme ainsi dans windows.
Titre: BBR
Posté par: underground78 le 08 janvier 2020 à 10:18:28
Idem je ne sais pas comment c'est géré côté windows (ils sont en wifi chez moi) mais je ne sais pas si c'est possible de changer l'algorithme ainsi dans windows.
Ça m'intéresse pour Windows !
Titre: BBR
Posté par: willemijns le 08 janvier 2020 à 10:51:24
recommandé par qui ?

par les plus grandes marques de lave-linge, ca c'est bin vrai ! (blague de quadra voire plus !)

sinon
https://cloud.google.com/blog/products/gcp/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster
https://www.aplu.fr/v2/post/2017/07/24/augmenter-la-bande-passante-avec-tcp-bbr

Titre: BBR
Posté par: darkmoon le 08 janvier 2020 à 10:52:55
Ça m'intéresse pour Windows !

Vu que cela concerne des options du kernel linux, je ne pense pas que l'on puisse configurer ca dans Windows, mais je me trompe peut-être !
Titre: BBR
Posté par: underground78 le 08 janvier 2020 à 10:54:12
Il y a des options équivalentes sous Windows mais je ne suis pas sûr que l'algo BBR ait été implémenté.
Titre: BBR
Posté par: darkmoon le 08 janvier 2020 à 11:01:35
Sur mon windows 10 à jour j'ai 3 choix :
Utilisation : set global [[rss=]disabled|enabled|default]
             [[autotuninglevel=]
                disabled|highlyrestricted|restricted|normal|experimental]
             [[congestionprovider=]none|ctcp|default]

D'après quelques sites :
none: Use the built-in standard congestion control algorithm.
ctcp: Use the add-on Compound TCP congestion control algorithm.
default: Restore the selected provider to the system default.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Fuli10 le 08 janvier 2020 à 11:16:37
par les plus grandes marques de lave-linge, ca c'est bin vrai ! (blague de quadra voire plus !)

sinon
https://cloud.google.com/blog/products/gcp/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster
https://www.aplu.fr/v2/post/2017/07/24/augmenter-la-bande-passante-avec-tcp-bbr

Et sinon, pourquoi ça marche "out-of-the-box" chee Orange? Sans tripatouillage de congestion?
Titre: BBR
Posté par: Thornhill le 08 janvier 2020 à 11:32:58
Et sinon, pourquoi ça marche "out-of-the-box" chee Orange? Sans tripatouillage de congestion?

Peut-être parce que l'algo de congestion n'est utile qu'en cas de congestion.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 11:58:26
illinois est recomandé pour high-speed and long-distance networks

heu ca date un peu ton truc la  :P

recommandé par qui ?

https://en.wikipedia.org/wiki/TCP-Illinois

BBR est bien récent je t'avoue ne pas l'avoir testé quand j'ai fait mon choix.

Je n'ai pas trouvé de comparatif mentionnant TCP-Illinois et BBR, donc je ne suis pas certain que BBR soit meilleur que TCP-Illinois (Ils sont tous les deux meilleurs que Cubic ou Reno)

Toutefois BBR a l'avantage d'être plus représentatif que TCP-Illinois du fait qu'il est utilisé par Google.

Je me demande pourquoi les distributions Linux restent sur Cubic comme algorithme de congestion TCP par défaut.

Je réfléchit pour changer, mais je suis preneur d'arguments.

Des opérateurs ont demandé plein d'optimisations pour les serveurs utilisés pour les tests Arcep pour les campagnes sur https://www.monreseaumobile.fr/, mais personne n'a demandé BBR.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 08 janvier 2020 à 12:12:15
c'est juste que t'es le premier que je croise a parler d'Illinois et a utiliser Illinois... un truc de 2006 conçu avant Cubic donc ... c'est juste curieux. Je ne vois pas en quoi il est meilleur que Cubic d'ailleurs. Et par défaut quel distrib a Illinois inclus de base (juste inclus pas sélectionné)?
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Thornhill le 08 janvier 2020 à 12:13:04
Dans certains cas d'usages, BBR fait moins bien que Cubic, cf https://blog.apnic.net/2019/11/01/bbr-evaluation-at-a-large-cdn/ (https://blog.apnic.net/2019/11/01/bbr-evaluation-at-a-large-cdn/)

Based on these findings, we concluded that for our traffic patterns, it is better to use Cubic for intra-PoP and PoP-to-PoP communications where RTTs and loss are low. For client-side traffic, it is worth using BBR.

Peut-être la raison pour laquelle BBR n'est pas sélectionné par défaut.

Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 12:50:18
c'est juste que t'es le premier que je croise a parler d'Illinois et a utiliser Illinois... un truc de 2006 conçu avant Cubic donc ... c'est juste curieux. Je ne vois pas en quoi il est meilleur que Cubic d'ailleurs. Et par défaut quel distrib a Illinois inclus de base (juste inclus pas sélectionné)?

nPerf comme SpeedTest d'Ookla conseillent de changer le protocole de congestion TCP Cubic pour TCP-Illinois

"For high throughput testing increasing TCP send/receive buffer sizes and using a more aggressive TCP congestion control algorithm such as ILLINOIS can improve performance."
Source : https://support.ookla.com/hc/en-us/articles/360017436132-Server-Performance

"Using TCP Illinois module can improve speed by managing congestion diffrently."
Source : https://wiki.nperf.com/nperf-server/tcp-stack-tuning
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Breizh29 le 08 janvier 2020 à 12:54:01
Tiens... faudrait que je m'intéresse à cet algo sur MacOS aussi alors...
Titre: Algo de controle de la congestion TCP: BBR
Posté par: esver le 08 janvier 2020 à 14:03:56
Je viens de faire des tests rapide avec curl sur test-debit.free.fr sur ma connexion mini 4k (ZMD AMII Orange) :
ubuntu@ubuntu:~$ sudo sysctl net.core.default_qdisc=fq
net.core.default_qdisc = fq

ubuntu@ubuntu:~$ sudo sysctl net.ipv4.tcp_congestion_control=cubic
net.ipv4.tcp_congestion_control = cubic

ubuntu@ubuntu:~$ curl -6 -o /dev/null -F "filecontent=@1048576.rnd" test-debit.free.fr
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024M  100   196  100 1024M      2  14.0M  0:01:38  0:01:12  0:00:26 16.7M

ubuntu@ubuntu:~$ sudo sysctl net.ipv4.tcp_congestion_control=illinois
net.ipv4.tcp_congestion_control = illinois

ubuntu@ubuntu:~$ curl -6 -o /dev/null -F "filecontent=@1048576.rnd" test-debit.free.fr
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024M  100   196  100 1024M      3  16.7M  0:01:05  0:01:01  0:00:04 25.9M

ubuntu@ubuntu:~$ sudo sysctl net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_congestion_control = bbr

ubuntu@ubuntu:~$ curl -6 -o /dev/null -F "filecontent=@1048576.rnd" test-debit.free.fr
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024M  100   196  100 1024M      9  51.3M  0:00:21  0:00:19  0:00:02 51.5M

Donc chez moi, pour ce type de test il n'y a pas photo ! illinois est à peine mieux que cubic et bbr marche parfaitement.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 15:09:35
Je confirme, c'est bien TCP-Illinois qui a été demandé il y a quelques années et qui est toujours d'actualité sur les serveur de test de débit des prestataires de l'Arcep pour les tests sur le mobile (Rapport Arcep QOS Mobile 2019: Orange 1er, Bytel 2ème, SFR 3ème Free 4ème (https://lafibre.info/qos-mobile/rapport-arcep-qos-mobile-2019-orange-1er-bytel-2eme-sfr-3eme-free-4eme/))
Titre: Algo de controle de la congestion TCP: BBR
Posté par: munsternet le 08 janvier 2020 à 15:39:42
A noter que BBR est "connu" pour bouffer toute la bande passante sur un lien congestionné au détriment d'autres implémentations (Cubic, Compound etc...)

Il y'a un bel article sur le blog de Dropbox à propos de ça et du pourquoi il y'a un BBRv2 dans les tuyaux:

https://blogs.dropbox.com/tech/2019/12/evaluating-bbrv2-on-the-dropbox-edge-network/
Titre: Algo de controle de la congestion TCP: BBR
Posté par: underground78 le 08 janvier 2020 à 20:04:53
Sur mon windows 10 à jour j'ai 3 choix :
En fait tu en as plus que ça avec "netsh int tcp set supplemental Internet congestionprovider=<algo>". Par défaut chez moi ça semble être cubic, tu peux aussi mettre ctpt, dctpt et newreno.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 08 janvier 2020 à 21:00:00
A noter que BBR est "connu" pour bouffer toute la bande passante sur un lien congestionné au détriment d'autres implémentations (Cubic, Compound etc...)

Il y'a un bel article sur le blog de Dropbox à propos de ça et du pourquoi il y'a un BBRv2 dans les tuyaux:

https://blogs.dropbox.com/tech/2019/12/evaluating-bbrv2-on-the-dropbox-edge-network/

Dans certains cas c'est l'inverse. Ca dépend des conditions et circontances, d'ailleurs l'article cité dans le blog de Dropbox conclu le contraire (c'est BBR qui souffre dans un monde ou Cubic domine).

D'ailleurs Illinois a les memes soucis que BBR vis a vis de Cubic , tout les hybrides (BBR, Illinois) l'ont. C'est juste que quand Google utilise un algo hybride ca se voit sur le Net tellement y'a du volume  ;D

Le souci c'est que peu de gens s'éduquent correctement sur ces sujets, peu lisent les articles et les études (j'admet que TCP c'est déjà complexe et les algo de congestion encore plus).

La majorité dépend donc des réglages par défaut de leur distro/OS ou suivent l'influence de quelqu'un d'autre parce que 'c'est marqué sur son blog ou ses recommendations' sans pourtant ce poser la question de savoir si c'est adapté, si ses recos sont scientifiquement fondées ou de quelle époque elles sont ou si elles conviennent a son cas d'usage  ;D

Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 21:21:13
Depuis 21h15, j'ai passé le serveur paris.testdebit.info (qui correspond au serveur utilisé par les clients Free quand ils utilisent le nom de domaine anycast bouygues.testdebit.info) en BBR

$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = bbr


Pour répondre à kgersen, sur un ubuntu server de base il n'y a que cubic et reno, cubic par défaut. Idem sur openWRT 19.07rc.

Non, Ubuntu en propose plein, mais la commande sysctl net.ipv4.tcp_available_congestion_control ne liste que reno cubic + ceux qui sotn en cours d'utilisation.

Bref, pour passer à BBR (ou un autre), il n'y a rien à installer avec Ubuntu 18.04 ou plus récent (c'est  bon aussi avec Ubuntu 16.04 à condition de prendre le Kernel 4.15)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 08 janvier 2020 à 21:24:07
Depuis 21h15, j'ai passé le serveur paris.testdebit.info (qui correspond au serveur utilisé par les clients Free quand ils utilisent le nom de domaine anycast bouygues.testdebit.info) en BBR

T'es en IPerf 3.7 car y'a plein de bugs dans les versions d'avant quand meme.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 21:26:24
Non, je suis sur un vieux iPerf, mais c'est dans ma todo liste de changer d'iPerf coté serveur.

Il y a aussi le noyau Linux 5.3 qui va être déployé dans quelques jours sur Ubuntu 18.04.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: underground78 le 08 janvier 2020 à 21:31:16
J'ai l'impression qu'il y a un soucis, en tout cas je n'arrive plus à faire de tester en utilisant l'adresse bouygues.iperf.fr
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 22:02:42
Le port est déjà occupé ? Un seul test peut être fait simultanément sur chaque port.

Les ports en écoute sont 5200 à 5209, il ne faut pas hésiter à tester un autre port.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: underground78 le 08 janvier 2020 à 22:20:07
Fausse alerte, visiblement j'ai juste pas eu de chance, j'ai essayé à plusieurs reprises sur 5 min environ mais toujours sur le même port (pas celui par défaut) et ça n'a jamais fonctionné.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 09 janvier 2020 à 14:50:11
Depuis 14h44, j'ai passé le serveur paris.testdebit.info (qui correspond au serveur utilisé par les clients Free quand ils utilisent le nom de domaine anycast bouygues.testdebit.info / bouygues.iperf.fr) en cubic

$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic

- avant 8 janvier 21h15 => illinois
- entre 8 janvier 21h15 et 9 janvier 14h44 => bbr
- depuis 14h44 => cubic (algorithme par défaut)

BBR a fait chuter fortement les débits, comparés à Illinois :
(https://lafibre.info/images/free_debit/202001_free_debit_illinois_vs_bbr.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 09 janvier 2020 à 16:44:22
BBR a fait chuter fortement les débits, comparés à Illinois :

on a d'autres exemples ? ou tu conclus sur un seul cas, un Mac qui plus est ?
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 09 janvier 2020 à 17:07:18
ps: avec IPerf3  v3.7 le client peut specifier l'algo a utiliser avec l'option -C.
Ca permet donc de faire des tests sans changer a chaque fois le mode par défaut du serveur (cubic étant généralement le défaut autant le laisser). Faut juste mettre a jour ton binaire IPerf.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Fyr le 10 janvier 2020 à 15:34:24
Blog de l'APNIC suite à une conf Google "When to use and not use BBR" https://blog.apnic.net/2020/01/10/when-to-use-and-not-use-bbr/ (https://blog.apnic.net/2020/01/10/when-to-use-and-not-use-bbr/)

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.

Le paragraphe sur la cohabitation BBR/Cubic est intéressant.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 10 janvier 2020 à 16:12:51

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.


tu sort d'ou ces chiffres ? on en trouve aucune trace/mention ni dans le blog, ni l'article ni la conf.

Ensuite quel conf Google ?

C'est une étude indépendante fait dans un labo avec IPerf3 ("640 iperf3 experiments in our LAN network") et présentée a l'ICM' 19 (sponsorisée par Facebook principalement).
Google a des millions de serveurs, des milliards de clients, sur la planète entière et pourtant continu d'utiliser BBR.

Les conclusions de l'étude:

Citer
Takeaways:
 - In terms of goodput, BBR is well suited for networks with shallow buffers, despite its high retransmissions
 - Unfairness between BBR and Cubic depends on the bottleneck buffer size
 - The maximum pacing_gain parameter is the root cause for the goodput “cliff point”

"suited for networks with shallow buffers" me semble le point important d'ailleurs c'est pour cela que BBR a été concu a l'origine. duh

L'article suivant dans la conf, https://conferences.sigcomm.org/imc/2019/presentations/p282.pdf, me semble plus intéressant et pointu d'ailleurs.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Fyr le 10 janvier 2020 à 17:09:26
tu sort d'ou ces chiffres ? on en trouve aucune trace/mention ni dans le blog, ni l'article ni la conf.

Le tableau

Titre: Algo de controle de la congestion TCP: BBR
Posté par: Thornhill 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.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Fyr 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
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen 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%
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Fyr 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.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien 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


(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_1.png)

(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_2.png)

(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_3.png)

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
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien 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
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen 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.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien 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
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen 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.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien 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
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen 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  (https://wiki.archlinux.org/index.php/Kernel_module#Blacklisting)des modules et en pré-charger au boot (dans /etc/modules-load.d/modules.conf)

Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien 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 ?
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 25 janvier 2020 à 16:06:39
Pour faire la chose proprement, j'ai crée un fichier /etc/modules-load.d/tcp_allowed_congestion_control.conf dans lequel je charge les 3 algorithme à proposer.

sudo nano /etc/modules-load.d/tcp_allowed_congestion_control.conf
# TCP congestion control protocol
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
tcp_bbr
tcp_htcp
tcp_illinois

Mais dans les 3 charcgés, seul bbr est disponible.

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


Pourtant, les fichiers .ko sont bien présents :

# locate tcp_bbr
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_bbr.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_bbr.ko

# locate tcp_htcp
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_htcp.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_htcp.ko

# locate tcp_illinois
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_illinois.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_illinois.ko
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 25 janvier 2020 à 17:16:03
ESnet a réalisé un document sur les optimisations pour les premiers serveurs qui ont des cartes Ethernet 100 Gb/s.

Le document date de septembre 2016 :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/201609_esnet_100g_tuning.png) (https://lafibre.info/testdebit/linux/201609_esnet_100g_tuning.pdf)

On voit pas mal de choses intéressantes sur les apports d'un kernel récent et une comparaison CentOS 7 vs CentOS 6 (sur un serveur 10 Gb/s) :
(https://lafibre.info/testdebit/linux/201609_esnet_100g_tuning_1.png)

(https://lafibre.info/testdebit/linux/201609_esnet_100g_tuning_2.png)

BBR est évoqué :

(https://lafibre.info/testdebit/linux/201609_esnet_100g_tuning_3.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 06 février 2020 à 07:52:49
Je viens de passer ce matin le serveur LaFibre.info, qui héberge également le test de débit mono-connexion de QoSi 5GMark en BBR pour voir l'impact.

$ cat /proc/sys/net/ipv4/tcp_congestion_control
bbr
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 14 février 2020 à 20:47:59
J'ai déjà publié un comparatif de BBR avec Cubic.

Les résultats sont sans appels : en mono-connexion BBR est presque systématiquement devant Cubic.

Je rajoute un autre exemple avec le débit Upload sur une Freebox :

- Cubic : 76.1 Mb/s
- BBR : 503 Mb/s

Sur cet exemple, BBR permet de multiplier par 6,6 les débits !


Ci-dessous les tests en IPv6 puis en IPv4, en étant connecté directement sur la Freebox.
Les débits sont toujours merdiques, comme depuis le début... (Free ne veut rien faire, "tout est normal").


IPv6 (1 flux) :
Connecting to host bouygues.testdebit.info, port 5201
[  4] local 2a01:e0a:2d... port 49773 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.01   sec  6.12 MBytes  51.0 Mbits/sec
[  4]   1.01-2.00   sec  8.88 MBytes  75.0 Mbits/sec
[  4]   2.00-3.00   sec  8.38 MBytes  70.3 Mbits/sec
[  4]   3.00-4.00   sec  5.00 MBytes  41.9 Mbits/sec
[  4]   4.00-5.00   sec  8.62 MBytes  72.4 Mbits/sec
[  4]   5.00-6.00   sec  13.1 MBytes   110 Mbits/sec
[  4]   6.00-7.01   sec  7.00 MBytes  58.4 Mbits/sec
[  4]   7.01-8.01   sec  9.50 MBytes  80.0 Mbits/sec
[  4]   8.01-9.00   sec  8.75 MBytes  73.8 Mbits/sec
[  4]   9.00-10.00  sec  13.0 MBytes   109 Mbits/sec
[  4]  10.00-11.01  sec  6.75 MBytes  55.9 Mbits/sec
[  4]  11.01-12.01  sec  8.38 MBytes  70.7 Mbits/sec
[  4]  12.01-13.01  sec  11.6 MBytes  96.8 Mbits/sec
[  4]  13.01-14.00  sec  7.00 MBytes  59.6 Mbits/sec
[  4]  14.00-15.01  sec  11.8 MBytes  97.8 Mbits/sec
[  4]  15.01-16.01  sec  11.4 MBytes  94.8 Mbits/sec
[  4]  16.01-17.00  sec  6.88 MBytes  58.3 Mbits/sec
[  4]  17.00-18.00  sec  11.5 MBytes  96.7 Mbits/sec
[  4]  18.00-19.00  sec  7.62 MBytes  64.0 Mbits/sec
[  4]  19.00-20.00  sec  10.1 MBytes  84.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-20.00  sec   181 MBytes  76.1 Mbits/sec                  sender
[  4]   0.00-20.00  sec   181 MBytes  76.1 Mbits/sec                  receiver

IPv6 2 flux :
[SUM]   0.00-20.01  sec   281 MBytes   118 Mbits/sec                  sender
[SUM]   0.00-20.01  sec   281 MBytes   118 Mbits/sec                  receiver

IPv6 4 flux :
[SUM]   0.00-20.00  sec   470 MBytes   197 Mbits/sec                  sender
[SUM]   0.00-20.00  sec   469 MBytes   197 Mbits/sec                  receiver

IPv6 8 flux :
[SUM]   0.00-20.01  sec   651 MBytes   273 Mbits/sec                  sender
[SUM]   0.00-20.01  sec   650 MBytes   273 Mbits/sec                  receiver

IPv6 16 flux :
[SUM]   0.00-20.00  sec   798 MBytes   335 Mbits/sec                  sender
[SUM]   0.00-20.00  sec   795 MBytes   334 Mbits/sec                  receiver

IPv4 (1 flux) :
Connecting to host bouygues.testdebit.info, port 5201
[  4] local 192.168.200.22 port 49876 connected to 89.84.1.222 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.01   sec  3.50 MBytes  29.1 Mbits/sec
[  4]   1.01-2.00   sec  8.88 MBytes  75.1 Mbits/sec
[  4]   2.00-3.00   sec  12.8 MBytes   107 Mbits/sec
[  4]   3.00-4.00   sec  7.00 MBytes  58.9 Mbits/sec
[  4]   4.00-5.01   sec  5.62 MBytes  46.7 Mbits/sec
[  4]   5.01-6.01   sec  9.50 MBytes  80.1 Mbits/sec
[  4]   6.01-7.01   sec  10.9 MBytes  91.5 Mbits/sec
[  4]   7.01-8.01   sec  10.4 MBytes  86.2 Mbits/sec
[  4]   8.01-9.00   sec  5.88 MBytes  50.0 Mbits/sec
[  4]   9.00-10.00  sec  9.00 MBytes  75.4 Mbits/sec
[  4]  10.00-11.01  sec  8.25 MBytes  68.8 Mbits/sec
[  4]  11.01-12.00  sec  10.8 MBytes  90.7 Mbits/sec
[  4]  12.00-13.01  sec  6.88 MBytes  57.1 Mbits/sec
[  4]  13.01-14.01  sec  7.50 MBytes  63.0 Mbits/sec
[  4]  14.01-15.01  sec  8.38 MBytes  70.4 Mbits/sec
[  4]  15.01-16.01  sec  8.12 MBytes  68.3 Mbits/sec
[  4]  16.01-17.00  sec  9.25 MBytes  77.8 Mbits/sec
[  4]  17.00-18.01  sec  5.50 MBytes  45.9 Mbits/sec
[  4]  18.01-19.01  sec  6.62 MBytes  55.6 Mbits/sec
[  4]  19.01-20.00  sec  10.2 MBytes  86.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-20.00  sec   165 MBytes  69.1 Mbits/sec                  sender
[  4]   0.00-20.00  sec   165 MBytes  69.1 Mbits/sec                  receiver


IPv4 2 flux :
[SUM]   0.00-20.01  sec   270 MBytes   113 Mbits/sec                  sender
[SUM]   0.00-20.01  sec   270 MBytes   113 Mbits/sec                  receiver

IPv4 4 flux :
[SUM]   0.00-20.01  sec   495 MBytes   207 Mbits/sec                  sender
[SUM]   0.00-20.01  sec   494 MBytes   207 Mbits/sec                  receiver

IPv4 8 flux :
[SUM]   0.00-20.00  sec   657 MBytes   276 Mbits/sec                  sender
[SUM]   0.00-20.00  sec   656 MBytes   275 Mbits/sec                  receiver


IPv4 16 flux :
[SUM]   0.00-20.00  sec   818 MBytes   343 Mbits/sec                  sender
[SUM]   0.00-20.00  sec   815 MBytes   342 Mbits/sec                  receiver



Edit : je viens de faire le test en bbr et c'est juste hallucinant...  :o
Par contre sous Windows que ce soit en cubic, ctcp, dctcp ou newreno ça ne change strictement rien... débit de merde en upload.  :-\

Je ne sais pas ce qu'on peut en conclure... Saturation chez Free ?


1 flux :
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec  1.17 GBytes   503 Mbits/sec  89401             sender
[  5]   0.00-20.04  sec  1.17 GBytes   501 Mbits/sec                  receiver

2 flux :
[SUM]   0.00-20.00  sec  1.26 GBytes   542 Mbits/sec  122231             sender
[SUM]   0.00-20.03  sec  1.26 GBytes   539 Mbits/sec                  receiver

Avec de multi-connexion en parallèle, les débits de BBR sont souvent largement inférieurs à Cubic, comme le montre le comparatif ci-dessous (débit exprimés en Gb/s) :

(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_3.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 14 février 2020 à 20:55:44
Il manque par contre un comparatif Cubic / BBR / Illinois.

J'ai exploité les tests Breizh29. Il était difficile de tirer une conclusion avec les graphiques car on a eu des coupures a plusieurs moment (panne Free puis pb du coté de mon serveur) et surtout le trafic le week-end est plus important et il est difficile de comparer une courbe de semaine avec une courbe du week-end.

J'ai donc supprimé les données du week-end et j'ai mis ça sur 24 heures (tous les tests avec un même protocole de congestion TCP et une même tranche horaire sont moyennés).
J'ai supprimé les données avant le 19 janvier vu qu'il y avait des modification de configuration.

Voici ce que cela donne pour 16 connexions TCP en parallèle.
Cubic est clairement le meilleur algorithme de congestion TCP pour ce type de test.


(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_multi-connexion_1.png)

(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_multi-connexion_2.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 14 février 2020 à 20:57:42
Là où c'est plus intéressant, c'est pour les tests sur une seule connexion TCP, plus représentatif de ressenti réel d'un internaute.

Sans surprise, BBR est le meilleur algorithme de congestion TCP.

Illinois semble avoir une petite avance sur Cubic.


(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_mono-connexion_1.png)

(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_mono-connexion_2.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 14 février 2020 à 21:00:02
Autre représentation avec d'autres couleurs.

IPv4 est en pointillé et IPv6 en trait plein.
On voit un petit gain de débit en IPv6, vs IPv4.

BBR est en rouge
Cubic est en vert
Illinois est en violet


(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_multi-connexion_3.png)

(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_mono-connexion_3.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 14 février 2020 à 21:05:19
Autre représentation graphique des données avec le 1er tiers du graphique qui concerne BBR, le second Cubic et enfin Illinois sur le dernier tiers.

Les tests multi-connexions sont en violet (IPv6) et vert (IPv4)
Les tests mono-connexion sont en rouge (IPv6) et bleu (IPv4)


(https://lafibre.info/images/free_debit/202002_tcp_congestion_control.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 16 février 2020 à 15:39:18
Petit graphique proposé par Google pour comparer BBR à Cubic :

(https://lafibre.info/testdebit/linux/202002_google_tcp_bbr.gif)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 16 février 2020 à 15:41:02
Test réalisés par Andree Toonk (@atoonk) en simulant la latence et les pertes de paquets sur Ubuntu, avec iPerf pour tester le débit :
(https://lafibre.info/testdebit/linux/202002_comparaison_reno_cubic_westwood_bbr.png)
Source : Medium.com (https://medium.com/@atoonk/tcp-bbr-exploring-tcp-congestion-control-84c9c11dc3a9), le 15 février 2020
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 16 février 2020 à 15:58:30
Geoff Huston, le scientifique en chef de l'APNIC, le registre Internet régional desservant la région Asie-Pacifique (équivalent du Ripe pour l'Europe) a fait une étude sur BBR.

Google rapporte des expériences qui montrent que les flux simultanés de BBR et de CUBIC s'équilibreront approximativement, CUBIC obtenant une part un peu plus grande de la ressource disponible, mais pas de manière scandaleuse. Il indique une conclusion raisonnable que BBR peut coexister dans un monde TCP RENO / CUBIC sans perdre ou dominer complètement tous les autres flux TCP.

Nos expériences limitées à ce jour indiquent une conclusion quelque peu différente. L'expérience était sous la forme d'un test 1: 1 avec des flux CUBIC et Reno simples simultanés passés sur un circuit de 10,2 Mbps RTT non encombré de 15,2 ms. CUBIC a été lancé initialement, et au point 20 secondes, une session BBR a été lancée entre les deux mêmes points de terminaison. L'algorithme de démarrage initial de BBR repousse CUBIC à un point où il semble incapable de rétablir une part équitable contre BBR. Il s'agit d'un résultat quelque peu inattendu, mais qui peut illustrer un résultat dans lequel les tailles de tampon interne sont bien inférieures au produit de bande passante de retard du circuit de goulot d'étranglement.


(https://lafibre.info/testdebit/linux/202002_geoff_huston_partage_bbr_cubic_1.png)

La deuxième expérience a utilisé un chemin RTT de 298 ms sur une grande étendue d'Internet entre des nœuds d'extrémité situés en Allemagne et en Australie. Il s'agit d'un chemin Internet standard à travers les FAI commerciaux, comme on pourrait s'y attendre sur Internet. Ce ne sont pas les deux seuls flux qui existent sur les 16 liaisons de composant vers l'avant et 21 dans ce chemin étendu, de sorte que les deux sessions TCP ne rivalisent pas seulement pour les ressources réseau sur toutes ces liaisons, mais rivalisent également avec cross trafic sur chaque lien de composant. Là encore, BBR semble mieux réussir à revendiquer des ressources de chemin et à les défendre contre d'autres flux pendant la durée de la session BBR.

(https://lafibre.info/testdebit/linux/202002_geoff_huston_partage_bbr_cubic_2.png)

C'est peut-être un résultat moins surprenant, dans la mesure où le RTT étendu a apparemment posé quelques problèmes pour CUBIC, tandis que BBR a été en mesure de maintenir son estimation de la bande passante du chemin pendant cette période. Ces résultats indiquent un certain niveau de coexistence entre BBR et CUBIC, mais le résultat semble biaisé pour que BBR gagne la plus grande part de la capacité du chemin.

Source : potaroo.net (http://www.potaroo.net/ispcol/2017-05/bbr.html), article datant de mai 2017 traduit rapidement en Français.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 16 février 2020 à 22:11:37
DropBox a fait des tests avec BBR en 2017 qui montrent une augmentation des vitesses de téléchargement de fichiers

Nous observons une augmentation de la vitesse à tous les centiles.

Expérience TCP BBR de 6 heures sur le POP de Tokyo :
(https://lafibre.info/testdebit/linux/201709_dropbox_tcp_bbr_experimentation.png)

axe x : temps
axe y : vitesse de téléchargement du client


Source : Blog Dropbox (https://blogs.dropbox.com/tech/2017/09/optimizing-web-servers-for-high-throughput-and-low-latency/), article du 6 septembre 2017
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien 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.


(https://lafibre.info/testdebit/linux/201808_spotify_stutters_by_region.png)


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.


(https://lafibre.info/testdebit/linux/201808_spotify_stutters.png)


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 (https://labs.spotify.com/2018/08/31/smoother-streaming-with-bbr/) le 31 août 2018 par Erik Carlsson et Eirini Kakogianni
Titre: Algo de controle de la congestion TCP: BBR
Posté par: munsternet 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  :)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien 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 :
(https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_1.png) (https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_1.png)

Débit montant :
(https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_2.png) (https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_2.png)

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
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien 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 :

(https://lafibre.info/images/free_debit/202002_comparatif_bbr_cubic.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: underground78 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) :

Titre: Algo de controle de la congestion TCP: BBR
Posté par: Esco 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 :


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 :
(https://zupimages.net/up/20/27/3th2.png) (https://zupimages.net/viewer.php?id=20/27/3th2.png)

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.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 01 juillet 2020 à 22:15:12

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:
# 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:
# 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).
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Esco 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.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien 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)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Esco 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.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien 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)
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020.png) (https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020.pdf#page=23)

Impact du contrôle de congestion (Cubic, BBR,...) sur la mesure de la Qos :
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020_1_qos_4.png)