Auteur Sujet: Effondrement progressif du débit TCP (CUBIC cwnd) entre deux Freebox Pop FTTH (Lu 348 fois)

jrom1973 · « **le:** **Aujourd'hui** à 00:21:14 »

Bonjour à tous,

Je constate un problème de débit reproductible entre deux abonnés Freebox Pop FTTH distants d'environ 18 km, et j'aimerais savoir si d'autres ont le même comportement ou si quelqu'un peut m'aider à creuser davantage.

Configuration

- Deux abonnés Freebox Pop FTTH
- Distance géographique : ~18 km
- RTT stable entre les deux extrémités : 29–34 ms
- Serveurs Synology DS218+ des deux côtés (noyau Linux 4.4.59)
- Tampons TCP correctement dimensionnés des deux côtés (net.core.wmem_max = 67108864)

Symptôme

Les transferts rsync/scp entre les deux NAS plafonnent à 15–20 MB/s en moyenne, avec un profil en cloche caractéristique : montée à ~45 MB/s puis descente progressive jusqu'à ~15 MB/s. Avec 4 flux parallèles, on atteint ~60 MB/s agrégés sans problème.

Diagnostic iperf3

Flux unique TCP — forte variance entre deux tests consécutifs :

Test 1 : 341 MBytes 286 Mbits/sec 6 retrans (mauvaise passe)
Test 2 : 857 MBytes 719 Mbits/sec 380 retrans (bonne passe)

4 flux parallèles TCP — stable :

[SUM] 0.00-30.00 sec 2.45 GBytes 702 Mbits/sec 329 retrans

Analyse ss -tin en temps réel pendant rsync

Le cwnd de CUBIC s'effondre régulièrement toutes les 4 à 6 secondes, sans aucune augmentation du RTT — signe caractéristique d'un routeur intermédiaire avec un buffer très faible pratiquant le tail-drop :

22:43:27 cwnd:869 ssthresh:800 296 Mbps retrans:0/2
22:43:29 cwnd:668 ssthresh:651 244 Mbps retrans:0/3 ← perte
22:43:32 cwnd:764 ssthresh:539 272 Mbps retrans:1/4 ← perte
22:43:36 cwnd:471 ssthresh:450 181 Mbps retrans:0/5 ← perte
22:43:41 cwnd:403 ssthresh:379 156 Mbps retrans:0/6 ← perte
22:43:45 cwnd:330 ssthresh:322 128 Mbps retrans:0/7 ← perte
22:43:55 cwnd:295 ssthresh:288 113 Mbps retrans:0/9 ← perte

Le RTT reste parfaitement stable à 29–34 ms tout au long — la perte se produit sans latence accrue.

Topologie du chemin

traceroute -T -p 34123 <IP publique distante>
1 192.168.1.1 (Freebox locale) 0.8 ms
2 192.168.10.1 (ONT/OLT) 1.2 ms
3 * * *
4 * * *
...
10 <IP distante> 30.5 ms

8 sauts intermédiaires entièrement opaques (ICMP et TCP SYN bloqués). Le routeur problématique se trouve quelque part dans cette séquence.

Ce qui ne fonctionne pas comme solution

- Ajuster les tampons TCP : sans effet (déjà à 64 MB des deux côtés)
- Changer de congestion control : seuls cubic et reno sont disponibles sur le noyau 4.4.59 de DSM — BBR n'est pas disponible
- WireGuard : non viable sur ce matériel (pas de support ChaCha20 hardware sur J3355)

Questions

- Est-ce que d'autres abonnés Freebox Pop FTTH observent ce comportement sur des transferts TCP longue durée flux unique ?
- Y a-t-il un moyen d'identifier lequel des 8 sauts opaques est responsable ?
- Ce comportement vous semble-t-il lié à un changement récent dans l'infrastructure Free ?

Merci d'avance pour vos retours.

vbernat · « **Réponse #1 le:** **Aujourd'hui** à 06:03:03 »

Ce serait pas mal de passer en IPv6. Cela va faire chuter le RTT sur ce usecase.

vivien · « **Réponse #2 le:** **Aujourd'hui** à 10:10:46 »

Le trafic en IPv4 doit passer par l'Île-de-France (encapsulé dans de l'IPv6) alors que l'IPv6 peut peerer localement.

Il faudrait comprendre l'origine des pertes de paquets Cela peut être une saturation des buffers à un endroit (lié soit à trop de paquet envoyé en local, soit à une saturation sur un segment où il y a d'autres flux) ou une perte liée à un média défectueux (ex: câble Ethernet défectueux).

Sur chaque Synology, tu peux tenter de lancer un ping ICMP vers l'autre Freebox. Normalement, tu dois avoir 0,00% de perte de paquets. Attention si tu lances des ping en même temps qu'il y a un transfert important, cela peut générer des pertes de paquets.

Pour l'hypothèse d'une saturation, le test à faire est simple : faire des transferts en heure de pointe (19h00 ⇒ 23h00) et en heure creuse (1h00 ⇒ 9h00) : Si les débits sont identiques, la piste de la saturation n'est pas la bonne.

jrom1973 · « **Réponse #3 le:** **Aujourd'hui** à 18:36:35 »

Merci pour ces précisions — l'encapsulation IPv4-dans-IPv6 avec transit par l'IDF explique enfin pourquoi passer en IPv6 pourrait faire une différence. Ce n'est pas ce que j'avais compris de la réponse initiale (qui évoquait une réduction du RTT), mais la logique de peering local en IPv6 est cohérente avec le symptôme.

Test ping ICMP dans les deux sens (20 paquets, hors transfert) :

20 paquets transmis, 20 reçus, 0% perte
RTT min/avg/max/mdev = 29.9/30.7/31.4/0.4 ms

Chemin parfaitement sain au repos — aucune perte de fond, gigue quasi nulle.

4 tests iperf3 consécutifs (18h21) — lancés à ~12 secondes d'intervalle :

Test #1 : 779 Mbps 224 retr cwnd_max=7,11 MB ← bonne passe
Test #2 : 788 Mbps 285 retr cwnd_max=7,12 MB ← bonne passe
Test #3 : 785 Mbps 278 retr cwnd_max=4,46 MB ← bonne passe
Test #4 : 277 Mbps 5 retr cwnd_max=1,34 MB ← mauvaise passe

Le test #4 est particulièrement révélateur : très peu de retransmissions (5 seulement contre 224–285 sur les autres), mais cwnd écrasé à ~1 MB dès le slow-start et qui ne récupère jamais sur 10 secondes. Ce n'est pas le même régime — le buffer de l'équipement intermédiaire était probablement déjà saturé au moment où ce flux est arrivé, bloquant toute croissance du cwnd.

Sur les heures de pointe vs creuses : honnêtement, je doute que l'heure soit le facteur déterminant. Avec iperf3 en flux unique, ça passe ou ça ne passe pas à n'importe quelle heure — les bonnes et mauvaises passes s'alternent de façon imprévisible en l'espace de quelques secondes (tests #1–#4 ci-dessus). Avec rsync ou scp en flux unique, en revanche, ça ne passe jamais correctement — le débit plafonne systématiquement à ~15 MB/s. Il faut agréger 4 flux parallèles pour retrouver les ~700 Mbps attendus. Ce n'est pas un comportement d'heure de pointe — c'est un comportement permanent.

Sur le test IPv6 : impossible à réaliser pour l'instant — le firewall IPv6 de la Freebox Pop ne permet aucune ouverture de port entrant sélective (on/off uniquement), et les équipements côté distant n'ont pas IPv6 activé. Je reviendrai sur cette piste ultérieurement.

vivien · « **Réponse #4 le:** **Aujourd'hui** à 19:23:23 »

Citation de: jrom1973 le Aujourd'hui à 18:36:35

20 paquets transmis, 20 reçus, 0% perte
RTT min/avg/max/mdev = 29.9/30.7/31.4/0.4 ms

Il faudrait réaliser des tests sur 10 000 paquets pour pouvoir avoir qq chose de représentatif.

0,01 % de taux de perte cela peut être la cause de ce que tes problèmes. Une perte de paquet pendant le slow start (période ou TCP cherche à savoir de quelle bande passante, il dispose et où le débit monte exponentiellement) peu avoir des impacts énormes avec le protocole de congestion Cubic (pas avec BBR).

Pour les tests iPerf3, peut-être voir le débit moyen sur une durée plus longue afin que cela soit stable et voir s'il y a une différence selon les heures ?

jrom1973 · « **Réponse #5 le:** **Aujourd'hui** à 20:30:04 »

Merci — c'est exactement ce que montrent les 4 tests iperf3 consécutifs que j'ai postés plus haut : une perte dès le slow-start dans le test #4 (5 retrasmissions à t=0) bloque le cwnd à ~1 MB pendant 10 secondes entières, alors que les tests #1, #2, #3 montrent une perte un peu plus tard dans la montée et récupèrent à ~800 Mbps.
Le mécanisme est donc clair — la question reste : d'où vient cette perte sporadique qui frappe aléatoirement certains flux et pas d'autres, à quelques secondes d'intervalle, avec un chemin parfaitement sain au repos ?
Sur les 10 000 pings : c'est faisable mais je ne peux pas immobiliser les deux NAS pendant 3 heures. Je ferai ce test dès que possible en heure creuse.