Optimisation MTU

In article <3f9706ea$0$229$626a54ce@news.free.fr>, Moris@nullepart.fr
says...

Auriez-vous joué avec un utilitaire de MTU auparavant ?

oui !
avec TCPOptimizer, qui m'avais trouvé 1500 pour ma connexion cable

depuis, je suis repassé en 56k, mais le MTU de 1500 est resté !

Pour régler le MTU avec le ping, il ne faut pas que la clé MaxMTU existe
pour cette connexion dans la BdR

Moris wrote:

[...]
depuis, je suis repassé en 56k, mais le MTU de 1500 est resté !
et le problème, c'est que TCPOptimizer refuse de régler mon 56k, il
voit pas le modem...

Bonsoir,

Normalement, c'est pas le modem qu'il faut cibler, mais l'adaptateur réseau
qui le représente (la fâmeuse "Carte d'accès distante" pour les connexions
en PPP par modem)

Via l'utilitaire DrTCP (http://www.dslreports.com/front/drtcp.html, la
dernière version - 21 actuellement-), je n'ai pas encore rencontré de
difficultées à lister cet adaptateur et à vérifier ou modifier ce réglage...
C'est à essayer...

je sens que ça va se finir à coup de bidouilles dans la base de
registres... (dommage que sous Win2000 le nom du modem apparaisse en
GUID, pas super pratique...)

C'est clair !

[MTU à 576 ]

pourtant les mêmes appareils relaient bien des paquets de 1500 pour
les connec cable et ADSL ?
(et aussi ceux de mon 56k d'ailleurs :-) )

Mais absolument !

Ce qui est différent, c'est le coût en temps de la perte d'un paquet, mais
aussi le gain en nombre d'octets économisés par la diminution du nombre des
en-têtes...

Si un paquet se perd, il doit être transmis au minimum deux fois (en
espérant qu'il ne se reperde pas encore une fois !), dont une fois
inutilement. Perte = temps de transfert d'un paquet.

A) En réception :

Modem "56K" connecté à 50 000 bps (une bonne moyenne...) :
* Paquet 576 octets de MTU :
(576 + 2 (PPP)) * 8 (conversion en bits) / 50 000 = 0,09248 s
soit *92,5 ms*
* Paquet 1500 octets de MTU :
(1500 + 2) * 8 / 50 000 =0,24032 s
soit *240 ms*

ADSL "512 kbps" (608 kbps ATM) en PPPoA VCMUX.
* Paquet 1500 octets de MTU :
(1500 + 2 (PPP) + 8 (CPCS) + 0 (VCMUX) = 1510)
+ ( (32*48) - (1500+2+8) = 26 (Remplissage) )
+ (32 * 5 (en-têtes des cellules ATM) = 160 )
= 1696 octets en taille finale.
1696 * 8 (conversion en bits) / 512 000 = 0,0265 s
soit *26,5 ms*

En ADSL, on peut se payer le luxe d'utiliser de gros paquets, la perte en
temps est acceptable (c'est toujours trop, mais bon...), alors qu'en RTC
56K, le temps perdu explose vite avec la taille du paquet !

B) En émission

Ici, les choses sont pires ! En RTC V90, la vitesse tombe à 33600 bps, en
Numéris, ça reste à 64000 bps, et en ADSL "classique" 128 000 bps.

RTC "56K" V90
* Paquet 576 octets de MTU :
(576 + 2 (PPP)) * 8 (conversion en bits) / 33 600 = 0,13761... s
soit *137,6 ms*
* Paquet 1500 octets de MTU :
(1500 + 2) * 8 / 33 600 =0,35761 s
soit *357,6 ms*

ADSL "512 kbps" (160 kbps ATM émission) en PPPoA VCMUX.
* Paquet 1500 octets de MTU :
(1500 + 2 (PPP) + 8 (CPCS) + 0 (VCMUX) = 1510)
+ ( (32*48) - (1500+2+8) = 26 (Remplissage) )
+ (32 * 5 (en-têtes des cellules ATM) = 160 )
= 1696 octets en taille finale.
1696 * 8 (conversion en bits) / 128 000 = 0,106 s
soit *106 ms*

En MTU 1500 sur ligne RTC V90, la perte d'un paquet en émission, nécessitant
une retransmission, est une perte de temps enorme ...

Quel est le gain en bande passante d'utiliser 1500 octets au lieu de 576 ?

Sachant que les en-têtes IP et TCP font 40 octets à eux-deux, le premier
permet de transporter 1460 octets de données alors qu'il ne reste que 536
octets dans l'autre (en jargon TCP, c'est le MSS).

Mettons un transfert de 195640 octets de données (pour que ça tombe juste),
sur une ligne idéale...

Il faut :
* 134 paquets de MSS 1460 / de MTU 1500.
Octets consommés en IP over PPP : 134*(1500+2) = 201268 octets
* 365 paquets de MSS 536 / de MTU 576.
Octets consommés en IP over PPP : 365*(576 + 2) = 210970 octets

Gain du MTU 1500 par rapport à 576 : *4,59%*

Toute la question est : Cela en vaut-il le coup ? Sur une ligne parfaite,
sans aucune perte de paquet ni de corruption des données : sûrement... Mais
sur une ligne où il peut y avoir des pertes de paquets ... hum... 250 ms à
plus de 350ms de perdu par retransmission, c'est enorme...

j'ai effectivement qqs paquets de perdus, mais rien de grave
ça peut avoir un impact sur des déconnexions ?

La RFC 1661 de PPP en Version Francaise est dispo ici :
http://www.eisti.fr/res/res/rfc1661/1661tm.htm)

Cette RFC ne parle pas des cas critiques, évitant soigneusement tout
discours sur une session dont les échanges de paquets deviendrait
impossible... Il ne me paraîtrait pas déraisonnable de penser que des
implémentations de PPP existent où la session est close si le nombre de
retransmission est trop important, ou s'il y a un temps d'inactivité du lien
atteint...

Et plus les paquets sont gros, plus il y a de risque qu'un bit soit transmis
en erreur, mécaniquement, plus il y a de retransmissions (de plus, une
retransmission n'est jamais à l'abri d'une ... erreur de transmission !)

mais ce qui est bizarre, c'est que 1500 correspond à une encapsulation
minimale (ethernet ou cable)
je croyais que les 56k avaient une encapsulation due à PPP, et ne
pouvaient donc pas avoir 1500 ?

La limite des 1500 est une limite pûrement Ethernet. Elle est tellement
utilisée que ce MTU peut être maintenant considéré comme un MTU "standard"
ou "normal".

Sur un réseau local avec routeur faisant la connexion PPP, les paquets IP
Internet transitent sur Ethernet sans encapsulation particulière, et ont un
MTU à 1500. L'en-tête PPP n'est ajouté que dans le routeur, pour une taille
de trame "IP over PPP" de 1500 + 2. Ces octets de PPP s'ajoutent.

Ceux qui utilisent le protocole PPPoE, eux, voient leur MTU réduit : ici, la
liaison ordinateur-modem est Ethernet, mais PPP est géré par l'ordinateur,
donc, les en-têtes PPP circulent sur le lien Ethernet. Comme PPP ne connaît
pas les réseaux à diffusion, il faut de plus faire transiter PPP dans un
autre protocole qui lui ouvre la voie : PPPoE. Avec 6 octets d'en-tête PPPoE
plus 2 octets d'en-tête PPP, on "perds" 8 octets par trame Ethernet, il ne
reste plus que 1492 octets de MTU exploitable pour IP.

Avec un modem RTC sur liaison série, on est soumis à aucune limite de
taille, excepté la limite d'IP qui est de 65535 octets, en-tête compris. On
pourrait avoir des trames PPP faisant 65537 octets (65535 + 2)... Mais la
RFC de PPP indique ceci :

§2. Encapsulation PPP
Champ Information (autrement dit, la 'charge utile' de la trame PPP)

"La longueur maximum du champ Information, y compris le bourrage, mais hors
champ Protocole, est limité à l'Unité de Réception Maximale (URM), par
défaut 1500 octets. Par négociation, des implémentations de PPP plus
"libérales" pourront utiliser d'autres valeurs d'URM."

En bref, la valeur "normale" est de 1500, mais c'est pas interdit de faire
plus !

En haut débit, on peut se permettre d'améliorer encore les vitesses de
transfert en augmentant la taille des paquets, puisque le coût en temps des
retransmissions est réduit...

La RFC 1626 (http://www.faqs.org/rfcs/rfc1626.html) préconise la taille de
transport à 9180 pour l'IP over ATM (donc, une MTU à 9180 si IP sur ATM
direct, sans PPP).

Voici ce que m'affiche mon routeur, en connexion IP sur PPP sur ATM (PPPoA)
:

=>ip iflist
Interface GRP MTU RX TX TX-DROP STATUS HWADDR
0 loop 1 1500 32 0 0 UP
1 eth0 2 1430 6740 19697 0 UP
00:90:d0:xx:xx:xx
2 Club-Int 0 9178 3435 744 0 UP

MTU de ma connexion = 9178, +2 octets de PPP = 9180 octets dispo ! C'est pas
un hasard ...

(Nota : le MTU du lien Eth0 = Ethernet, c'est un forçage volontaire de ma
part...)

En fait, peu importe, c'est un routeur Ethernet, le MTU max exploitable au
travers de l'appareil ne dépassera donc jamais les 1500 octets.

Mais si j'avais un réseau ATM branché sur la prise ATM-F de l'appareil, les
grandes tailles de paquets seraient théoriquement possible...

C'est côté Opérateur Téléphonie // FAI que ça bloque. Chez moi, le maximum
possible n'est que de 1460 octets... (Et je me limite à 1430 car cela tombe
sur un nombre entier de cellules ATM, et évite un petit gaspillage d'octets,
en connexion PPPoA).

--
Herm
Pardon pour la longueur, c'est une rechute :-D

Remy Moulin <niluomr*ReverseLetters*@club-internet.fr.invalid> wrote:

Normalement, c'est pas le modem qu'il faut cibler, mais l'adaptateur
réseau qui le représente (la fâmeuse "Carte d'accès distante" pour
les connexions en PPP par modem)

TCPOptimizer ne voit que 2 choses :
-ma carte réseau
-mon ancien modem cable, pourtant désinstallé "proprement" depuis

Via l'utilitaire DrTCP (http://www.dslreports.com/front/drtcp.html, la
dernière version - 21 actuellement-), je n'ai pas encore rencontré de
difficultées à lister cet adaptateur et à vérifier ou modifier ce
réglage... C'est à essayer...

DrTCP m'affiche :
-ma carte réseau
-"Microsoft TV/Video Connection" !

mais pas de "Carte d'accès distante" en vue

Par contre, le fait de mettre "Dial Up (RAS) MTU" à 576 a bien marché
La méthode du "ping -f -l" et le "Tweak Test" de DslReports me confirment
que je suis bien à 576 maintenant

[paquet d'explications et calculs !]

En fait, peu importe, c'est un routeur Ethernet, le MTU max
exploitable au travers de l'appareil ne dépassera donc jamais les
1500 octets.

le modem/routeur n'est pas capable de recomposer les morceaux ?
Recevoir du port ethernet 5-6 morceaux de taille < à 1500 et en envoyer un
< à 9180 ?
(dans le cas où le FAI accepterait de tels morceaux)

sinon, faut passer à l'USB :-)

C'est côté Opérateur Téléphonie // FAI que ça bloque. Chez moi, le
maximum possible n'est que de 1460 octets... (Et je me limite à 1430
car cela tombe sur un nombre entier de cellules ATM, et évite un
petit gaspillage d'octets, en connexion PPPoA).

un cellule ATM fait 48 octets si j'ai bien compris ? ou 32 ?
(1430 + 8 + 2 = 1440 = 32 *45 = 48*30)

sinon merci pour tes réponses fort détaillées :-)

Moris wrote:

le modem/routeur n'est pas capable de recomposer les morceaux ?
Recevoir du port ethernet 5-6 morceaux de taille < à 1500 et en
envoyer un < à 9180 ?
(dans le cas où le FAI accepterait de tels morceaux)

Bonsoir,

Non, normalement les routeurs savent fragmenter, mais ils ne défragmentent
habituellement pas.

En règle général, c'est au destinataire au final (à l'ordinateur
destinataire) de recomposer les paquets IP depuis les différents morceaux
qui arrivent...

sinon, faut passer à l'USB :-)

Oui... Enfin, s'ils émulent un véritable adaptateur ATM ! Parce que les
pilotes qui émulent des adaptateurs Ethernet ... c'est 1500 là encore !

un cellule ATM fait 48 octets si j'ai bien compris ? ou 32 ?
(1430 + 8 + 2 = 1440 = 32 *45 = 48*30)

C'est 53 octets décomposé en 5 d'en-têtes et 48 de données utiles...

La taille de 48 octets utiles, c'est un compromis entre 32 et 64 (c'est pile
poil (32+64)/2)... Quand Américains et Européens ont du mal à se mettre
d'accord, ça finit en normes un peu bâtardes ;-)

sinon merci pour tes réponses fort détaillées :-)

Ça, c'est à force de trainer dans ce forum... :-D

(Alors, y'a moins de déconnexions sauvages en MTU 576 ?)

--
Herm

Remy Moulin <niluomr*ReverseLetters*@club-internet.fr.invalid> wrote:

(Alors, y'a moins de déconnexions sauvages en MTU 576 ?)

pour l'instant, aucune !
comme quoi les winmodem ne sont pas tous mauvaix (un 1er prix d'il y a 5-6
ans pourtant)