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

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Tuto: Analyser les problèmes de débit avec Wireshark
Exemple avec les problématiques de faible débit montant rencontrés par certains clients sur la Freebox Delta



Le résumé en un graphique :


L'explication complète :

Voici les débits montant de Breizh29 : en moyenne 100 Mb/s, ce qui est très éloigné des débits théorique de sa box.

iperf3 -c bouygues.testdebit.info -t 20 -i 1
Connecting to host bouygues.testdebit.info, port 5201
[  7] local 2a01:e0a:1fc:xxxxxxx port 52671 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval           Transfer     Bitrate
[  7]   0.00-1.00   sec  19.5 MBytes   163 Mbits/sec                 
[  7]   1.00-2.00   sec  15.6 MBytes   131 Mbits/sec                 
[  7]   2.00-3.00   sec  15.9 MBytes   134 Mbits/sec                 
[  7]   3.00-4.00   sec  11.3 MBytes  95.3 Mbits/sec                 
[  7]   4.00-5.00   sec  18.4 MBytes   154 Mbits/sec                 
[  7]   5.00-6.00   sec  16.3 MBytes   137 Mbits/sec                 
[  7]   6.00-7.00   sec  17.2 MBytes   144 Mbits/sec                 
[  7]   7.00-8.00   sec  11.9 MBytes   100 Mbits/sec                 
[  7]   8.00-9.00   sec  11.6 MBytes  97.4 Mbits/sec                 
[  7]   9.00-10.00  sec  19.9 MBytes   167 Mbits/sec                 
[  7]  10.00-11.00  sec  12.4 MBytes   104 Mbits/sec                 
[  7]  11.00-12.00  sec  2.66 MBytes  22.3 Mbits/sec                 
[  7]  12.00-13.00  sec  8.41 MBytes  70.7 Mbits/sec                 
[  7]  13.00-14.00  sec  13.1 MBytes   110 Mbits/sec                 
[  7]  14.00-15.00  sec  2.62 MBytes  22.0 Mbits/sec                 
[  7]  15.00-16.00  sec  9.66 MBytes  81.1 Mbits/sec                 
[  7]  16.00-17.00  sec  10.2 MBytes  85.8 Mbits/sec                 
[  7]  17.00-18.00  sec  11.3 MBytes  94.6 Mbits/sec                 
[  7]  18.00-19.00  sec  3.51 MBytes  29.4 Mbits/sec                 
[  7]  19.00-20.00  sec  11.0 MBytes  92.1 Mbits/sec                 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  7]   0.00-20.00  sec   242 MBytes   102 Mbits/sec                  sender
[  7]   0.00-20.01  sec   238 MBytes  99.9 Mbits/sec                  receiver

iperf Done.

Dans de nombreux cas quand le débit est limité, c'est une problématique qui est du coté client et non du coté FAI : Utilisation du WiFi, d'un PC pas assez puissant ou présence de logiciels résidents (principalement sous Windows 10) qui limitent le débit.

La capture ci-dessous a été réalisée 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.

Breizh29 utilise iPerf3 version 3.7 pour faire ses tests de débit. Coté serveur, c'est un Ubuntu server 18.04 LTS avec Kernel 5.3 avec taille de buffer max de 16 Mo avec lui aussi iPerf3 version 3.7

Client : Mac mini (i7 3,2 GHz, 32 Go mémoire, 1 To SSD, macOS 10.15.2 - équipé d’un chip Aquantia AQC107) avc une optimisation réalisée 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

Dans tous les tests ci-dessous le protocole de congestion TCP est Cubic aussi bien sur le mac que sur le serveur Linux. On fera une parenthèse sur le protocole de congestion TCP BBR à la fin de ce sujet.

Quand on parle de problème de débit, il est important de savoir si c'est lié à une congestion du réseau, congestion qui est présente le soir sur certains réseaux.

Pour répondre à cette question, Breizh29 à automatisé un test avec iPerf3, ce qui permet d'avoir un graphique des débits sur les 7 derniers jours :

Commande utilisée pour les tests montant multi-thread :
iperf3 -c bouygues.testdebit.info -t 4 -O 4 -p $numPort -4 -P 16 -f g
iperf3 -c bouygues.testdebit.info -t 4 -O 4 -p $numPort -6 -P 16 -f g


Commande utilisée pour les tests montant mono-thread :
iperf3 -c bouygues.testdebit.info -t 4 -O 4 -p $numPort -4 -P 1 -f g
iperf3 -c bouygues.testdebit.info -t 4 -O 4 -p $numPort -6 -P 1 -f g


(cliquer sur le graphique pour zoomer)


On note que le débit mono-thread est régulièrement à moins de 100 Mb/s, même en pleine nuit. La limitation de débit n'est donc pas liée à une congestion.

Le débit multi-thread est lui stable mais reste éloigné du débit théorique de la ligne.

Le débit montant sur la Freebox Delta doit être proche de 566 Mb/s en mono-thread comme en multi-thread.

Exemple de résultat obtenu par darkmoon en mono-connexion, un client sur Saint Genis Laval (69), avec une latence trés proche de celle de Breizh29.

iperf3 -c bouygues.testdebit.info -t 20 -i 1
Connecting to host bouygues.testdebit.info, port 5201
[  5] local 2a01:e0a:1d2:d8f0::xyzb port 36766 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  66.6 MBytes   558 Mbits/sec  5589   1.96 MBytes
[  5]   1.00-2.00   sec  67.5 MBytes   566 Mbits/sec  9663   2.03 MBytes
[  5]   2.00-3.00   sec  63.8 MBytes   535 Mbits/sec  8495   1.57 MBytes
[  5]   3.00-4.00   sec  67.5 MBytes   566 Mbits/sec  4149   1.61 MBytes
[  5]   4.00-5.00   sec  66.2 MBytes   555 Mbits/sec  8657   1.66 MBytes
[  5]   5.00-6.00   sec  71.2 MBytes   598 Mbits/sec  3841   1.52 MBytes
[  5]   6.00-7.00   sec  67.5 MBytes   566 Mbits/sec  5671   1.45 MBytes
[  5]   7.00-8.00   sec  67.5 MBytes   566 Mbits/sec  2902   1001 KBytes
[  5]   8.00-9.00   sec  67.5 MBytes   566 Mbits/sec  8688   1.54 MBytes
[  5]   9.00-10.00  sec  67.5 MBytes   566 Mbits/sec  4491   1.14 MBytes
[  5]  10.00-11.00  sec  66.2 MBytes   556 Mbits/sec  2471   2.20 MBytes
[  5]  11.00-12.00  sec  70.0 MBytes   587 Mbits/sec  4959    964 KBytes
[  5]  12.00-13.00  sec  66.2 MBytes   556 Mbits/sec  3696   2.26 MBytes
[  5]  13.00-14.00  sec  70.0 MBytes   587 Mbits/sec  3885   1.88 MBytes
[  5]  14.00-15.01  sec  67.5 MBytes   561 Mbits/sec  9621   1.59 MBytes
[  5]  15.01-16.00  sec  67.5 MBytes   572 Mbits/sec  10308   1.81 MBytes
[  5]  16.00-17.00  sec  67.5 MBytes   566 Mbits/sec  6166   1.41 MBytes
[  5]  17.00-18.00  sec  67.5 MBytes   566 Mbits/sec  2273   1.61 MBytes
[  5]  18.00-19.00  sec  67.5 MBytes   566 Mbits/sec  7242   1.05 MBytes
[  5]  19.00-20.00  sec  67.5 MBytes   566 Mbits/sec  3519   1.56 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec  1.32 GBytes   566 Mbits/sec  116286             sender
[  5]   0.00-20.01  sec  1.32 GBytes   566 Mbits/sec                  receiver

iperf Done.

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Faut-il mesurer le débit en multi-thread ou en mono-thread ?

Le débit multi-thread permet d'augmenter les débits en faisant abstraction des problèmes sur un réseau, comme par exemple des pertes de paquets.
Si le multi-thread permet d'afficher de meilleurs débits, il est par contre moins représentatif d'un usage réel qui, est du mono-thread pour la quasi-totalité des usages sur Internet.
Une mesure de débit multi-thread, si elle permet de voir la taille du tuyau, est aussi une façon d'afficher un débit plus élevé, mais non représentatif de l’expérience des clients.
Il est donc pertinent de se pencher sur la problématique rencontrée en mono-thread, qui impacte directement le ressenti des utilisateurs.

La limitation pourrait-elle être liée au Mac de Mac mini de Breizh29 ? (i7 3,2 GHz, 32 Go mémoire, 1 To SSD, macOS 10.15.2)

iPerf3 à l'avantage de demander très peu de puissance processeur, contrairement à un test de débit réalisé dans un navigateur qui va demande un monstre de puissance pour faire du 10 Gb/s.

La réponse est non, car voici ses tests de débit en descendant : On observe là une saturation le soir avec une forte chute de débit en mono-thread et une chute plus faible en multi-thread.

(cliquer sur le graphique pour zoomer)


Le serveur pourrait-il être l'élément limitant ?

Les tests descendant et montant sont réalisé sur le même serveur.

Il y a peu de chance que les limitations soient liée au serveur : celui ci à un trafic "in" ("in" correspond au trafic débit montant d'un client avec le serveur) qui est très faible.
Le serveur est par contre bien plus chargé sur "out" qui correspond aux tests de téléchargements qui sont eux bon.

Trafic sur l'interface réseau du serveur utilisé :


vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Maintenant que ces éléments de contextes sont posés, on peut passer à la capture Wireshark.

Il y a un tutoriel qui explique comment faire :

Réaliser une capture Wireshark pas à pas


Il faut bien vérifier la barre d'état de Wireshark (la ligne tout en bas) : après avoir arrêté la capture, il doit y avoir marqué Perdus: 0 (0,0%). Si vous avez autre chose que 0, cela signifie que votre machine a eu un peu de mal a écrire le flux et que des paquets ont été perdus. La capture n'est pas parfaite. Il est préférable de la refaire en veillant à fermer les applications non nécessaire, car les paquets perdus peuvent compliquer fortement l'analyse, Wireshark montrant des paquets perdus qui sont en fait des paquets non capturés.


Comment faire un graphique de la connexion TCP avec Wireshark ?

Il faut sélectionner un paquet de donnée du transfert de donnée. (Si vous sélectionnez un acquittement TCP, la courbe se fera dans le sens où aucune donnée n'est transmise, il sera donc vide)

Pour être sur d'être sur la bonne connexion TCP (il peut y avoir d'autres connexions avant et après) l'astuce est de se placer au milieu de la capture et de sélectionner un paquet d'une grande taille (la taille apparaît dans la colonne Length) puis aller dans le menu Statistiques => Graphique des flux TCP => Séquence de temps (tcptrace)

Un graphique comme celui-ci apparaît :
(cliquer sur le graphique pour zoomer)


En abscisse on a le temps depuis le début de la connexion TCP, exprimé en seconde. Ici le test dure 20 secondes.
En ordonnée on a les paquets transmis, exprimés en nombre d'octets transmis depuis le début de la connexion TCP. Chaque intervalle affiché correspond à 100 Mo transféré.

Plus la pente de la courbe est raide, plus le débit est élevé.
Plus la courbe est plate, plus le débit est faible.

On voit donc que le débit monte et à chaque incident, que j'ai entouré en rouge, le débit repars d'un débit faible avant d'augmenter lentement.
On va zoomer sur les incidents.

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Détail du premier incident, qui arrive moins de 200ms après le début de la connexion : (cliquer sur le graphique pour zoomer)


On est encore dans le début de la connexion, là où le débit progresse forcement. Cette perte de paquets que nous allons observer à un impact sur le débit accentué par les suivantes.

3 éléments sont dessinés :
- une courbe en bas en gris qui indique les octet acquittés par le serveur. La capture ayant été prise sur le client qui émet les paquets, les acquittements ne sont pas reçus immédiatement, il faut attendre 12 à 13 millisecondes, qui est la temps qui sépare entre l'envoi d'un paquet et la réception de la réponse. C'est le "ping" du client vers le serveur.

- des petits traits bleus, qui correspondent aux paquets émis.

- une courbe verte en haut qui indique la limite du nombre de paquets non acquittés qu'il est permis d'envoyer. Cette courbe augmente à chaque fois que les acquittements sont reçus.

La différence verticale entre la courbe grise et celle verte est la quantité de donnée non acquitté qu'il est possible d'envoyer. Cette quantité de donnée est régulièrement augmentée, quand tout se passe bien sur une connexion. Dans notre cas, on voit que l'émission des paquets n'est pas limité par la limite de la Rwin : TCP arrête d'émettre des paquets avant que cette limite soit atteinte, car l'algorithme d’évitement de congestion utilisé, Cubic, le demande.

La différence horizontale entre les paquets bleu et la courbe grise correspond à la latence effective, dans notre cas environ 13ms.


L'incident de perte de paquets :

J'ai surligné en rose l'endroit où il y a eu des des pertes de paquets : On note qu'une même séquence de donnée est envoyé une première fois peu après l'intervalle de temps 0,135sec et que ces mêmes paquets sont émis une seconde fois, à un débit plus faible, peu après l'intervalle de temps 0,165sec

Les traits rouge sont générés par Wireshark et correspondent à des acquittements qui signalement des donnes manquantes. On note que ces acquittements interviennent un temps égal à deux fois la latence après l'émission les paquets.

- Peu de temps après l'intervalle de temps 0,14sec :

Le Mac de Breizh29 envoi un gros paquet de données à un débit très élevé (près de 10 Gb/s). En effet, il un PC envoie au débit maximum de son interface soit ici à 10 Gb/s. Les paquets seront stockés dans les buffers au niveau de l'endroit où le débit est réduit à 600 Mb/s. Ces buffers doivent être présents à chaque endroit où le débit est limité, afin de ne pas être obligé de supprimer les paquets. Il ne faut pas tomber dans l’excès inverse avec des buffers trop grands (risque de buffer bloat).

Ici selon toute vraisemblance, la quantité de donnée envoyée a été trop importante pour la taille des buffers de l'OLT ou de la Freebox.

Les buffers qui posent problème sont toujours ceux à l'endroit où le débit est limité à 600 Mb/s. Cette limitation est probablement réalisée sur l'OLT, située dans le NRO, toutefois, il est possible que les buffers de la Freebox soient eux aussi sollicités en débit montant : Le 10G-EPON (IEEE 802.3av) mis en place par Free limite le débit de l'arbre à 1244 Mb/s (débit partagé par tous les clients). Il est donc possible que le buffers trop petit soient au niveau de la Freebox, juste avant que le débit parte sur l'arbre avec une limitation physique à 1244 Mb/s, soit au niveau de l'OLT qui doit limiter le débit montant aux 600 Mb/s contractuel.

Les paquets qui arrivent alors que le buffer est plein sont supprimés. L'ensemble des derniers paquets ont donc été supprimés et c'est ce que l'on observe sur la capture Wireshark.

- Peu de temps après l'intervalle de temps 0,15sec :

La courbe grise en bas augmente car le Mac à reçu les acquittements des paquets enfin de presque tous les paquets, vu que le serveur n'a pas reçu les paquets que j'ai surlignés en rose, probablement détruits par l'OLT ou la Freebox, au niveau de l’endroit où le débit est limité à 600 Mb/s.
Immédiatement le mac se met à envoyer la suite des données.

Ni le serveur ni le client ne s’inquiète que toutes les données ne soient pas acquittés : un petit retard est possible.



- Peu de temps après l'intervalle de temps 0,152sec :

Là on reçois les acquittements envoyés par le serveur suites aux paquets envoyés peu après 0,15sec et ces acquittements, mis en rouge par Wireshark indiquent qu'il manque une plage de donnée.

Le mac va immédiatement renvoyer les paquets qu'il manque, mais à un débit plus faible.

- Peu de temps aprés l'intervalle de temps 0,164sec :

On reçois les acquittement pour les paquets surlignés en rose : la deuxième émission à bien fonctionné.

Par contre le débit va être réduit pour les prochains paquets (il va limiter le nombre de paquets envoyés d'un seul bloc pour éviter de faire exploser les buffers de l'OLT / Freebox, au niveau de l'endroit où le débit est réduit à 600 Mb/s ou 1244 Mb/s)


Ping du client vers une autres des IPv6 utilisé par le serveur :

Start: 2020-01-05T18:53:48+0100
HOST: Mac-mini-BZH.local                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS12322  monIP          0.0%   100    0.3   0.4   0.2   1.0   0.1
  2. AS12322  2a01:e03:12:f836:7e2c::ffff   0.0%   100    2.7   2.4   1.6  12.2   1.2
  3. AS12322  2a01:e03:12:1700::ffff       77.0%   100    1.8   2.9   1.7  17.1   3.1
  4. AS12322  2a01:e03:11::1                0.0%   100    3.1   4.4   3.0  21.0   2.5
  5. AS12322  2a01:e03:f::1                 0.0%   100    4.4   4.7   3.9  12.4   1.2
  6. AS12322  2a01:e03:e::5                 0.0%   100    5.5   6.1   5.2  12.6   1.3
  7. AS12322  2a01:e03:e::2                18.0%   100    9.6   8.5   6.2  10.4   1.2
  8. AS12322  2a01:e03:1::22               40.0%   100   12.4  12.3  11.7  13.0   0.3
  9. AS12322  2a01:e00:3f::5                9.0%   100   12.6  12.4  11.8  18.0   0.7
 10. AS5410   2001:860:0:81::1              0.0%   100   11.9  12.1  11.6  12.8   0.3
 11. AS5410   2001:860:bbee:b4::2           0.0%   100   12.2  12.8  12.2  13.4   0.3
 12. AS5410   2001:860:bbe0:128::2          0.0%   100   13.3  13.2  12.7  13.7   0.3
 13. AS5410   2001:860:de01:1100::2         0.0%   100   12.4  12.5  12.0  13.2   0.3

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Détail du premier incident, qui arrive moins de 200ms après le début de la connexion : (cliquer sur le graphique pour zoomer)


Il est intéressant de voir les paquets pour comprendre le fonctionnement et pouvoir analyser des cas complexes.

Sous la colonne Length on voit la taille des paquets :
- Tous les paquets de plus de 1514 octets sont des paquets de donnée, dans notre cas émis par le mac. L'élément le plus important est le numéro de séquence (Seq=xxxxx), le numéro qui identifie le paquet envoyé. Je l'ai surligné à la main en vert.
- Tous les paquets de moins de 114 octets sont des paquets d’acquittement TCP, dans notre cas, émis par le serveur. L'élément le plus important est le numéro d’acquittement (Ack=xxxxxx) qui acquitte les données reçues. Je l'ai surligné à la main en rose.

Une connexion TCP permettant de transférer des données dans les deux sens, chaque paquet de donnée est aussi un paquet d’acquittement pour un éventuel flux descendant. Ici chaque paquet de donnée acquitte Ack=1 car il n'y a aucune aucune donnée dans l'autre sens. Chaque acquittement a le numéro Seq=1 car il ne transporte aucune donnée.


Analyse : La connexion se déroule parfaitement bien jusqu'au paquet surligné en bleu.

Le paquet d’acquittement en bleu et les suivants sont spécifiques : ils ont à la fin un SLE=xxxxxx SRE=xxxxxxx, cela correspond à SACK, un acquittement sélectif (SACK = selective acknowledgement), qui autorise le destinataire TCP à acquitter des blocs de données reçus dans le désordre. SACK a été définie en 1996 dans la RFC 2018, permet au récepteur d'accuser réception d'un maximum de 3 blocs discontinus de paquets reçus correctement, en plus du numéro de séquence suivant immédiatement le dernier numéro de séquence du dernier octet contigu reçu successivement.

A droite du champ info, Wireshark indique le bord gauche du bloc (le premier numéro de séquence du bloc) et le bord droit du bloc (le numéro de séquence suivant immédiatement le dernier numéro de séquence du bloc ), un bloc étant une plage contiguë que le récepteur a correctement reçue.

Concrètement le paquet bleu acquitte jusqu'au numéro de séquence 504598, puis du numéro de séquence 506010 au numéro de séquence 547438.

Cela indique à l'émetteur que les paquets du numéro de séquence 504598 au numéro de séquence 506009 n'ont pas été reçus.
L’émetteur va analyser, pour soit laisser du temps si il pense qu'ils sont peut être dans le désordre (il peut arriver dans des cas spécifique que les paquets soient dans le désordre, ce qui va fortement limiter le débit) soit les ré-émettre.

Ici dans notre cas, le temps entre l'émission des paquets et la réception de acquittement indiquant qu'il manque des paquets est important, TCP va donc faire immédiatement une ré-émission des paquets en question. Les paquets ré-émis sont mis en rouge par Wireshark, pour indiquer qu'ils sont dans le désordre.

Seuls les paquets perdus sont ré-émis. A noter que avant l'invention de SACK, tous les paquets depuis le paquet perdu devaient être ré-émis, y compris les paquets reçus, faute de solution pour indique à l'émetteur quel paquets sont perdus et quels paquets ont été reçus.

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Détail du second incident, qui arrive 1,3 seconde après le début de la connexion : (cliquer sur le graphique pour zoomer)


TCP ayant réduit son débit après la perte de paquet, il tente lentement d'augmenter à nouveau le débit au fur et à mesure que la connexion avance.

A 1,3 seconde, on va de nouveau exploser les buffers de l'OLT / Freebox, mais l'augmentation de débit ayant été plus progressive qu'au début de la connexion, seuls quelques paquets sont supprimés.

Pour une raison que j'ignore, TCP va fortement réduire le débit, bien plus que nécessaire, on voit qu’après cette perte de paquet, le débit est presque nul et va ré-augmenter progressivement.


Les buffers qui posent problème sont toujours ceux à l'endroit où le débit est limité à 600 Mb/s. Cette limitation est probablement réalisée sur l'OLT, située dans le NRO, toutefois, il est possible que les buffers de la Freebox soient eux aussi sollicités en débit montant: Le 10G-EPON (IEEE 802.3av) mis en place par Free limite le débit de l'arbre à 1244 Mb/s (débit partagé par tous les clients). Il est donc possible que le buffers trop petit soient au niveau de la Freebox, juste avant que le débit parte sur l'arbre avec une limitation physique à 1244 Mb/s, soit au niveau de l'OLT qui doit limiter le débit montant aux 600 Mb/s contractuel. Dans tous les cas; il y a un endroit ou les buffers sont trop petits.

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Détail du troisième incident, qui arrive 1,84 seconde après le début de la connexion : (cliquer sur le graphique pour zoomer)


Le débit ayant peu à peu augmenté (TCP est persévérant), on va de nouveau avoir un dépassement de la taille des buffers de l'OLT ou de la Freebox à T=1,84 seconde.

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Détail du quatrième incident, qui arrive 2,4 seconde après le début de la connexion : (cliquer sur le graphique pour zoomer)


TCP tente de s'adapter pour ne pas faire éclater les buffers de l'OLT ou de la Freebox, mais en augmentant peu à peu le débit, il va perdre des paquets pendant que le buffer se vide et donc perdre plusieurs paquets non consécutifs.

Détail des paquets du quatrième incient :
(cliquer sur le graphique pour zoomer)


Ici on voit que l'on a atteint le maximum de la taille des option TCP : 40 octets.
SACK prend de la place et on est limité à 3 blocs qui sont tous utilisés ici.
Si l'émetteur à reçu des paquets après ceux indiqués, il ne peut le mentionner dans SACK et ils seront retransmis.

J'ai surligné en vert les numéro de séquence des paquet de donnée.

L'analyse de la situation réalisée par Wireshark est à prendre avec des pincette. En effet ce qui est inscrit entre crochet [TCP Dup ACK] [TCP Fast Retransmission] [TCP OUt-Of-Order] [TCP Retransmission] sont liés a des algorithmes qui tentent d'aider celui qui regarde la capture, mais ces commentaires ne sont pas toujours appropriés.

Certains paquets sont notés par Wireshark comme étant [TCP OUt-Of-Order] [TCP Retransmission] [TCP Fast Retransmission] alors que ce sont des paquets renvoyés suite à la même perte de paquet.

[TCP Dup ACK] est censé montrer un acquittement déjà reçu (intéressant pour voir si le réseau duplique les paquets, et oui cela s'est déjà vu) mais une analyse du SACK montre bien que ce n'est pas un acquittement identique à un déjà reçu.

Bref, il y a simplement des acquittements qui montrent que plusieurs paquets sont perdus et l'émetteur qui renvoi les paquets.

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Détail du cinquième incident, qui arrive 8,8 seconde après le début de la connexion : (cliquer sur le graphique pour zoomer)


TCP à fait attention après un début de connexion chaotique a envoyer les paquets de façon modérée pour ne pas faire éclater les buffers de l'OLT / Freebox.

Toutefois TCP ne sait pas qu'il est le seul à utiliser la box, et donc il va de temps en temps faire monter le débit pour voir si la limitation du départ est toujours présente. Si il y avait d'autres suage en parallèle, la situation évoluer, il faut donc de temps en temps tester les limites de la connexion et c'est ce qui est fait là.

On va de nouveau avoir un dépassement de la taille des buffers de l'OLT / Freebox à T=8,8 seconde.

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Détail du sixième incident, qui arrive 15,8 seconde après le début de la connexion : (cliquer sur le graphique pour zoomer)


7 seconde après le précédent problème, on est dans la même situation : TCP test les limites de la connexion et on a de nouveau un dépassement de la taille des buffers de l'OLT / Freebox à T=15,8 seconde.

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Conclusion de cette capture :

Cela montre de façon quasiment certaine que l'endroit des buffers sont trop petits pour permettre d'avoir de bon débits sur une connexion TCP. Il faudrait, si c'est possible logiciellement, augmenter cette taille des buffers.

Les buffers qui posent problème sont toujours ceux à l'endroit où le débit est limité à 600 Mb/s. Cette limitation est probablement réalisée sur l'OLT, située dans le NRO, toutefois, il est possible que les buffers de la Freebox soient eaux aussi sollicités en débit montant : Le 10G-EPON (IEEE 802.3av) mis en place par Free limite le débit de l'arbre à 1244 Mb/s (débit partagé par tous les clients). Il est donc possible que le buffers trop petit soient au niveau de la Freebox, juste avant que le débit parte sur l'arbre avec une limitation physique à 1244 Mb/s, soit au niveau de l'OLT qui doit limiter le débit montant aux 600 Mb/s contractuel.


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)

vivien

  • Administrateur
  • *
  • Messages: 34 274
    • Twitter LaFibre.info
Et cela donne quoi avec l'algorithme d'évitement de congestion BBR ?

Cryptage, qui est confronté à la même problémaique que Breizh29 a réalisé des tests avec l''algorithme d'évitement de congestion Cubic (utilisé par défault) puis en fin de message avec le nouveau BBR crée par Google :
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


Pour les abonnés Free qui ont le même genre de désagréments n'hésitez-pas à voter ici : https://dev.freebox.fr/bugs/task/29953

 

Mobile View