Auteur Sujet: Pourquoi certaines pertes de paquets dégradent le débit et d'autres non ? (Lu 4135 fois)

vivien · « **le:** 24 février 2015 à 17:33:15 »

Pourquoi certaines pertes de paquets dégradent le débit et d'autres non ?

Voici des tests de téléchargement d'un fichier de 100 Mo, réalisés sur une ligne 1 Gb/s avec un serveur 10 Gg/s (http://3.testdebit.info/fichiers/100Mo.dat).

Les pertes de paquets sont systématiques au début de la transmission et cela n'arrive que avec un serveur 10 Gb/s : Si le serveur est à 1 Gb/s il n'y aura pas de pertes de paquets.
Il me semble que le serveur envoi à plus de 1 Gb/s ce qui provoque des pertes de paquets (le serveur ne sait pas que le client est limité à 1 Gb/s)

Sur cette capture typique, on a 6 pertes de paquets, très rapprochées :
Perte 1 : t = 0,1304s
Perte 2 : t = 0,1309s
Perte 3 : t = 0,1315s
Perte 4 : t = 0,1320s
Perte 5 : t = 0,1325s
Perte 6 : t = 0,1331s

Voici le graphe avec les pertes représentés en rouge :

Ce que je cherche à comprendre, c'est pourquoi certaines pertes de paquets engendrent une baisse de débit de l'èmetteur (pas forcèment justifié) et d'autres non.

vivien · « **Réponse #1 le:** 24 février 2015 à 17:34:06 »

Autre capture avec 5 pertes de paquets :
Perte 1 : t = 0,1088s => pas d'impact sur le débit
Perte 2 : t = 0,1643s => impact
Perte 3 : t = 0,2621s => impact
Perte 4 : t = 0,6911s => impact
Perte 5 : t = 1,2112s => impact

Voici le graphe avec les pertes représentés en rouge :

Ici les pertes N°2 à 5 ont un fort impact sur le débit.

vivien · « **Réponse #2 le:** 24 février 2015 à 17:34:17 »

Un autre exemple avec 8 pertes de paquets :
Perte 1 : t = 0,1181s => pas d'impact sur le débit
Perte 2 : t = 0,1208s => pas d'impact sur le débit
Perte 3 : t = 0,1215s => pas d'impact sur le débit
Perte 4 : t = 0,3094s => impact
Perte 5 : t = 0,5073s => impact
Perte 6 : t = 0,7596s => impact
Perte 7 : t = 0,8107s => impact
Perte 8 : t = 1,0861s => impact

Voici le graphe avec les pertes représentés en rouge :

Ici aussi, les baisse de débit sont en lien directes avec des pertes de paquets, mais certaines pertes (les premières) n'engendre pas de baisse.

Pourquoi ?

vivien · « **Réponse #3 le:** 24 février 2015 à 18:06:34 »

Capture prise sur le client, avec un ping un peu plus important (là le serveur est celui de LaFibre.info sur le réseau Adeli)
C'est toujours un fichier de 100 Mo.

Ici, seulement 3 pertes de paquets (très rapprochées) qui cassent complètement le débit et le serveur n'èmet plus au-delà de 600 Mb/s alors que la ligne FTTH semble supporter un vrai 1 Gb/s.

Perte 1 : t = 0,3911s => impact
Perte 2 : t = 0,4031s => impact
Perte 3 : t = 0,4044s => impact

Voici le graphe avec les pertes représentés en rouge :

kgersen · « **Réponse #4 le:** 24 février 2015 à 19:01:36 »

De ce que j'étudie en ce moment sur TCP (cf post sur NDT) mais j'ai pas bien saisie toute la théorie:

Au début, ca tient au fait que TCP soit en "ready-state" ou pas.
Apres ca dépend de l'algo de congestion (reno, cubic, etc) et du temps qu'il met a remonter le débit s'il ne constate plus de perte.

100Mo a 1Gbps c'est un peu court et ca ne laisse pas le temps de remonter.

en bref:
L’èmetteur réduit la fenêtre donc le débit a chaque perte constatée mais ne remonte pas le débit aussi vite

vivien · « **Réponse #5 le:** 24 février 2015 à 19:16:35 »

L'algorithme de congestion, c'est du cubic (l'OS coté client et coté serveur, c'est Ubuntu Server 14.04 LTS 64bits avec le noyau linux 3.13)

La taille de la Rwin n'est pas modifiée après les pertes et reste très élevé (2 Mo) sachant que le ping est de l'ordre de 3ms pour les 3 premières captures et 9ms pour la dernière.

Je ne vois pas non plus phénomène TCP bizard, les paquets restent agrégés par TCP offload engine sur le client.

Quand on regarde juste après une perte coté client, je vois que immédiatement après la perte le débit est réduit alors que tout se passe bien.

Le SACK est bien évidement activé (seul le paquet perdu est re-demandé, c'est à chaque fois un paquet de 1500 octets dans un ensemble qui a été agrégé par TCP offload engine.