Salut,

Depuis la nuit du 9/12/2022 suite à une coupure de ma ligne fibre pendant plusieurs heures (probablement une maintenance planifiée, migration PE Ericsson|Redback vers Nokia ?), je constate des soucis de débit sur toutes les sessions TCP CUBIC.
Le soucis est présent 24h/24h et 7j/7. Il ne s'agit pas de saturation temporaire aux heures de pointe.
Depuis des serveurs parisiens, je mesure environ 45Mbps en download, et 470Mbps en upload. (test iperf3 depuis/vers ping.online.net)

Je suspect très fortement un soucis de configuration sur les PE SFR concernant le policing/shaping appliqué.
Après analyse d'une capture d'un flux TCP, je pense à un soucis de buffer trop petit (cbs), ce qui engendre de la perte de paquet et empêche TCP de monter en débit.

Je pense que le buffer configuré est de l'ordre d'1ms (120ko), au lieu des 10-15ms nécessaires.

Je constate strictement le même soucis sur la ligne SFR d'un collègue (également en région Lyonnaise, mais dans un quartier différent).

Connexion SFR, Téléchargement depuis un serveur utilisant TCP Cubic (ping.online.net): 40Mbps
Connexion SFR, Téléchargement depuis un serveur utilisant TCP BBR (ipv4.scaleway.testdebit.info): 456Mbps

rtr-sfr:~$ wget -O /dev/null  http://ping.online.net/1000Mo.dat
--2023-02-13 14:53:43--  http://ping.online.net/1000Mo.dat
Résolution de ping.online.net (ping.online.net)… 62.210.18.40
Connexion à ping.online.net (ping.online.net)|62.210.18.40|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1000000000 (954M) [application/octet-stream]
Sauvegarde en : « /dev/null »
2023-02-13 14:56:53 (5,00 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]

rtr-sfr:~$ wget -O /dev/null http://ipv4.scaleway.testdebit.info/1G.iso
--2023-02-13 14:58:03-- http://ipv4.scaleway.testdebit.info/1G.iso
Résolution de ipv4.scaleway.testdebit.info (ipv4.scaleway.testdebit.info)… 62.210.156.7
Connexion à ipv4.scaleway.testdebit.info (ipv4.scaleway.testdebit.info)|62.210.156.7|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1000000000 (954M) [application/x-iso9660-image]
Sauvegarde en : « /dev/null »
2023-02-13 14:58:19 (57,0 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]
La hotline SFR ne sait pas sortir de ses scripts. Le service "expertise" dit que s'il n'y a pas 5 personnes avec le même problème, ils ne peuvent pas faire remonter un soucis généralisé. Et de toute manière comme https://www.sfr.fr/mire-test-debit/ remonte des résultats décent, il n'y a pas de problème.

Y a t-il par ici des abonnés SFR/RED qui constatent le même soucis ? 
Ou encore mieux, des gens qui aurait moyen de remonter le soucis aux bonnes personnes ?

Voila qui est fait, j'ai renseigné ma ref client ! 

Tu as testé avec le programme de notre ami Ouno ?
https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/

enlève peut être le test Freebox (-F)

Tu n'a pas le même default_qdisc que moi, et moins de tcp_mem (j'ai Debian 10 si je dis pas de connerie, rien installé dessus, juste une VM)

je ne sais pas si ça peut influencer, et le BBR fonctionne correctement (enfin si tu as une connexion 500Mb/s, sinon ce n'est pas bon non plus)

je ne sais pas si @ouno peut nous éclairer

[checkFtthFree v0.11]                            Linux 5.10.0-21-amd64 (x86_64)
-------------------------- 2023-03-10 08:57:51 +0100 --------------------------
Paramétrage réseau actuel du système:
  net.core.default_qdisc: pfifo_fast
  net.core.rmem_max: 212992
  net.core.wmem_max: 212992
  net.ipv4.tcp_adv_win_scale: 1
  net.ipv4.tcp_congestion_control: cubic
  net.ipv4.tcp_mem: 10077       13437   20154
  net.ipv4.tcp_no_metrics_save: 0
  net.ipv4.tcp_rmem: 4096       131072  6291456
  net.ipv4.tcp_sack: 1
  net.ipv4.tcp_timestamps: 1
  net.ipv4.tcp_window_scaling: 1
  net.ipv4.tcp_wmem: 4096       16384   4194304
  => Latence TCP max pour une réception à 1 Gbps: 27 ms
  => Latence TCP max pour une émission à 700 Mbps: 35 ms

Test TCP local (IPv4): téléchargement depuis la Freebox
  --> Latence: 0.77 ms                  [gigue: 0.05 ms]
  --> Débit: 116.01 Mo/s (928.11 Mbps)  [fluctuation: 2.21%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
  --> Latence: 9.14 ms                  [gigue: 0.44 ms]
  --> Débit: 106.40 Mo/s (851.22 Mbps)  [fluctuation: 5.11%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
  --> Latence: 9.06 ms                  [gigue: 0.65 ms]
  --> Débit: 109.67 Mo/s (877.33 Mbps)  [fluctuation: 0.44%]
-------------------------- 2023-03-10 08:58:29 +0100 --------------------------

Ok donc vraisemblablement un soucis au niveau de SFR ou du réseau

En effet, résultats similaires depuis les serveurs hébergés dans le réseau de Bouygues:

-------------------------- 2023-03-15 13:40:51 +0100 --------------------------
Paramétrage réseau actuel du système:
  net.core.default_qdisc: pfifo_fast
  net.core.rmem_max: 212992
  net.core.wmem_max: 212992
  net.ipv4.tcp_adv_win_scale: 1
  net.ipv4.tcp_congestion_control: cubic
  net.ipv4.tcp_mem: 10077 13437 20154
  net.ipv4.tcp_no_metrics_save: 0
  net.ipv4.tcp_rmem: 4096 131072 3574752
  net.ipv4.tcp_sack: 1
  net.ipv4.tcp_timestamps: 1
  net.ipv4.tcp_window_scaling: 1
  net.ipv4.tcp_wmem: 4096 16384 3574752
  => Latence TCP max pour une réception à 1 Gbps: 15 ms
  => Latence TCP max pour une émission à 700 Mbps: 30 ms

Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
  --> Latence: 9.91 ms [gigue: 0.11 ms]
  --> Débit: 64.02 Mo/s (512.13 Mbps) [fluctuation: 1.92%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
  --> Latence: 9.97 ms [gigue: 0.24 ms]
  --> Débit: 6.84 Mo/s (54.72 Mbps) [fluctuation: 4.67%]

[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
      (ratio débit CUBIC/BBR: 10.68%)
-------------------------- 2023-03-15 13:41:16 +0100 --------------------------