Auteur Sujet: Tuto:Analyser les problèmes de débit avec Wireshark (exemple avec Freebox Delta)  (Lu 30207 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
C'est quoi cet algorithme BBR qui permet de passer le débit montant sur une connexion de 69 Mb/s à 503 Mb/s ? (multiplication du débit par 7,3)

BBR, (Bottleneck Bandwidth and Round-trip propagation time) est un algorithme de contrôle de congestion TCP développé chez Google en 2016.

Alors que la plupart des algorithmes de contrôle de la congestion sont basés sur la perte (ils s'appuient sur la perte de paquets comme signal pour réduire le débit), BBR utilise la bande passante maximale et le temps d'aller-retour pour construire un modèle explicite du réseau. Chaque accusé de réception de paquets produit un échantillon de débit qui enregistre la quantité de données livrées sur l'intervalle de temps entre la transmission d'un paquet de données et l'accusé de réception de ce paquet. Alors que les débits augmentent, la latence associée au bufferbloat au lieu de la perte de paquets devient un marqueur plus fiable du débit maximal, ce qui fait que BBR fournit, en mono connexion, un débit plus élevé et une latence inférieure, face aux algorithmes basés sur la perte de paquet, comme le populaire CUBIC.

A noter :

o Peu représentatif de l’Internet, BBR est principalement utilisé par Google. Une fois implémenté dans YouTube, BBR a permis en moyenne un débit de réseau supérieur de 4% et jusqu'à 14% dans certains pays (source Google).

o BBR est efficace et rapide, mais son équité vis-à-vis des flux non BBR est contestée. Alors que la présentation de Google montre que BBR coexiste bien avec CUBIC, des chercheurs le trouvent injuste par rapport aux autres flux et non évolutif. Ils montrent que BBR ne fonctionne pas bien dans des environnements dynamiques tels que les réseaux cellulaires. Ils ont également montré que BBR avait un problème d'injustice. Par exemple, lorsqu'un flux CUBIC coexiste avec un flux BBR dans le réseau, le flux BBR peut dominer le flux CUBIC et en obtenir toute la bande passante.


Comparatif Cubic / BBR, réalisé en débit descendant sur la même Freebox Delta de Breizh29, utilisée pour ce tutoriel sur l'analyse avec Wireshark :


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








vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Comment passer à BBR ?

C'est l’émetteur qui doit changer de protocole de congestion.
Pour le débit descendant, il est donc impossible de le changer.

Ici on s'intéresse au débit montant, voici le tutoriel que pour Linux :

Je recommande de faire un fichier :
sudo nano /etc/sysctl.d/90-optimization.conf

Il suffit de mettre la ligne suivante :
net.ipv4.tcp_congestion_control=bbr

Redémarrez votre PC.

Pour vérifier l'algorithme de contrôle de congestion TCP utilisé :
cat /proc/sys/net/ipv4/tcp_congestion_control

Cela affiche "bbr" si la modification a bien été prise en compte ou "cubic" autrement.

Vous pouvez en profiter pour augmenter les buffer TCP afin d'être sur de ne pas limiter le débit quand la latence et le débit est élevé.

Insérer dans le même fichier les lignes suivantes :

# 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

Cryptage

  • Abonné Free fibre
  • *
  • Messages: 297
  • Dijon
Merci pour cette analyse, c'est très instructif.
T'as dû passer un moment pour la rédiger !

Ça met en évidence un problème de buffers pour lequel on a du mal à imaginer que Free n'en sache rien...

Personne n'aurait un contact chez Free pour faire remonter le problème ? L'analyse de Vivien doit pouvoir aider.

Mettre en place BBR ça aide mais ce n'est pas forcément une solution viable et surtout les Windowsiens restent sans contournement.

Une remarque pour ton tuto Vivien : pour appliquer la modification du sysctl.conf on peut s'éviter le reboot en passant la commande "sysctl -p".

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Oui pour appliquer les modifications sans reboot : sudo sysctl -p permet de charger les fichiers /etc/sysctl.conf et /etc/sysctl.d/* et donc d'appliquer les paramètres.

Avant de contacter Free, il me semble important de poursuivre l'analyse pour voir où est le problème :

Comment savoir si c'est plutôt coté OLT ou coté Freebox que le débit est trop faible ?

Le test serait de faire un comparatif avec une connexion 1 Gb/s (connecter le PC sur port 1 Gb/s de la Freebox est suffisant).

Si le débit montant est nettement meilleur avec une connexion 1 Gb/s, la limitation est du coté Freebox.

Si le débit n'est pas meilleur, il est plus difficile de tirer une conclusion, mais le buffer trop petit est probablement coté OLT, là où est fait la limitation du débit montant. Dans le cas (possible également mais peu probable) où la limitation de débit à 600 Mb/s est réalisé coté Freebox, alors ce sera le buffer coté Freebox, au niveau de la limitation à 600 Mb/s)


ubune

  • Abonné Orange Fibre
  • *
  • Messages: 315
Oui pour appliquer les modifications sans reboot : sudo sysctl -p permet de charger les fichiers /etc/sysctl.conf et /etc/sysctl.d/* et donc d'appliquer les paramètres.

Avant de contacter Free, il me semble important de poursuivre l'analyse pour voir où est le problème :

Salut Vivien et merci pour l'analyse !

Pour le test en 1gbps, il y a un topic complet qui en parle, on a en effet un meilleur upload en 1gbps qu'en 10gbps => https://lafibre.info/1gb-free/debit-upload-x520-da1/
Un ticket a été ouvert par Roncamma => https://dev.freebox.fr/bugs/task/28327

Cryptage

  • Abonné Free fibre
  • *
  • Messages: 297
  • Dijon
@Vivien : pour ma part je suis en Freebox Révolution donc forcément en 1 Gbps.

Du coup ça orienterait plutôt sur l'OLT car l'ONU n'est pas le même entre Delta et Révolution.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Si tu es avec la Freebox révolution ton PC ne dépasse pas 1 b/s en upload et donc le premier endroit où les buffer se remplissent, c'est là ou le débit est limité à 600 Mb/s.

La limitation de débit est généralement réalisée coté OLT (donc dans les équipements au NRO), mais c'est possible, bien que peu probable, que la limitation de débit à 600 Mb/s soit réalisé coté Freebox. Si on est dans ce dernier cas, alors ce sera le buffer coté Freebox, au niveau de la limitation à 600 Mb/s.

Les équipements étant différents pour les clients en point à point, il serait intéressant de savoir si ils sont également touché par ce problème de petits buffers.

Breizh29

  • Abonné Free fibre
  • *
  • Messages: 408
  • Ergué-Gabéric (29)
Impressionnant le tuto !
Merci Vivien.
Je vous fais le test en 1 gbps asap.

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
@vivien : il y a quelques "SLACK" à la place de "SACK".

Sinon l'analyse est intéressante, en revanche elle n'explique pas pourquoi Fuli10 voit toujours des pertes sur un test en UDP avec débit limité : https://lafibre.info/1gb-free/serveur-iperf3-chez-free/msg725969/#msg725969.
Normalement, si le PC envoie plus lentement que la capacité de la ligne, il ne devrait pas y avoir de pertes au niveau des endroits où le débit est limité, même si les buffers sont petits (sauf si l'arbre est saturé bien sûr, ce qui ne semble pas être le cas).

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
J'ai corrigé les SACK mal écrits.

J'ai rajouté un résumé en un graphique :


Thornhill

  • Abonné SFR fibre FttH
  • *
  • Messages: 3 976
  • Saint-Médard-en-Jalles (33)
Normalement, si le PC envoie plus lentement que la capacité de la ligne, il ne devrait pas y avoir de pertes au niveau des endroits où le débit est limité, même si les buffers sont petits (sauf si l'arbre est saturé bien sûr, ce qui ne semble pas être le cas).

Même sans parler de saturation de l'arbre, en xPON le débit upload est en permanence (125 us) renégocié (algo DBA, timeslots, TDMA) entre ONT et OLT, en fonction des demandes de trafic de tous les acteurs de l'arbre.
Ceci peut conduire à des variations de capacités dans le temps pour une ligne donnée, qui peut provoquer, si c'est mal géré au niveau bufferisation, des pertes de paquets.
 

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Oui, Il faut prévoir des buffers au niveau de l'interface wan upload de la box, une saturation au niveau de l'arbre, entrainant pour l'utilisateur une limitaiton de débit plus forte que l'outil qui limite à 600 Mb/s coté OLT est possible.

Dans notre cas, on a vu que les débits étaient mauvais la nuit, or il y a de forte chance d'avoir l'arbre très peu chargé en upload la nuit.

Ce graphique a été un élément décisif pour fermer la porte à certaines possibilités, le graphe Wireshark n'est pas suffisant à lui seul. (cliquer sur le graphique pour zoomer)