[projet-agregation] linkagreg (était Format des paquets reçus dans un TUN)

[Fernando ALVES]

Salut,

Le 12/11/2011 14:54, Jocelyn Delalande a écrit :
> Salut,
>> Avec la fragmentation des paquets il ne devrait plus y avoir de
>> problème de MTU/MSS entre le client et serveur, théoriquement devrait
>> même accepter
>> un MTU > 1500 (a tester).
>
>
> Prenons un cas concret, un programme veut transmettre via TCP 2000 
> octets sur une interface TUN
>
>
> 1) Cas avec une MTU volontairement plus faible (ex: 1400) sur 
> l'interface TUN (sans frag. de la part de linkagreg) :
>
>  - TCP découpe les données en 2 segments et les passe à la couche IP ;
>  - les 2 paquets sont lus par l'application de tunnel et sont injectés 
> dans le tunnel UDP, la pile réseau rajoute tous ses headers (UDP+IP+MAC);
>  - vu qu'on a choisi une MTU volontairement plus faible pour le tun, 
> lorsque la pile réseau envoie ces paquets encapsulés via l'interface 
> physique, ils ne sont pas redécoupés une fois de plus. 2 trames 
> seulement sortent par l'interface réseau
>
>
> 2) Cas où linkagreg gère la fragmentation et où l'on laisse la MTU du 
> tun à 1500
>
>  - TCP découpe son flux le paquets en 2 segments et les passe à la 
> couche IP ;
>  - les 2 paquets sont lus par l'application de tunnel, le premier est 
> découpé en 2. Les 3 paquets obtenus sont injectés dans le tunnel UDP, 
> la pile réseau rajoute tous ses headers (UDP+IP+MAC);
>  - la non plus, vu que le tunnel gère la fragmentation, aucune 
> fragmentation supplémentaire n'est faite pour transmettre le paquet 
> sur l'interface physique.
>
> Ce dont je ne suis pas convaincu là c'est que pour moi
>  - si on set la MTU du tun/tap correctement, on transmet 2 paquets
>  - si on utilise de la fragmentation, on transmet 3 paquets, et on 
> ajoute un délai/coût de traitement/source d'erreurs.
>
> On peut y voir une question de vitesse (on splite les gros paquets 
> pour les envoyer en parallèle). Ceci-dit entre ça et faire la 
> répartition paquet/paquet, je ne suis pas persuadé que le bénéfice 
> soit énorme, et je suppose qu'il est négatif lorsque le lien est 
> chargé  ou qu'il y a des écarts de latence entre les deux liens.
tu as raison pour TCP.

Sur notre réseau aujourd'hui les 5 liens ppp montés sur la Gateway ont 
une MTU de 1462 alors que tout le reste du réseau local a une MTU de 
1500 (valeur par défaut des routeurs et poste des adhérents), et avec la 
mise en place d'un tunnel sans fragmentation je vais encore devoir 
réduire cette MTU, j'ai peur que certaines applications qui n'utilisent 
pas TCP se retrouvent avec des problèmes de MTU.

alix:~# ip link | grep ppp
83: ppp2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1462 qdisc htb 
state UNKNOWN qlen 3
     link/ppp
124: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1462 qdisc htb 
state UNKNOWN qlen 3
     link/ppp
144: ppp4: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1462 qdisc htb 
state UNKNOWN qlen 3
     link/ppp
153: ppp3: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1462 qdisc htb 
state UNKNOWN qlen 3
     link/ppp
155: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1462 qdisc htb 
state UNKNOWN qlen 3
     link/ppp

Un autre avantage aussi de la fragmentation c'est que l'on diminue le 
temps de latence des gros paquets.

alix:~# ping -s 1400 -I ppp4 www.fdn.fr
PING yoda.fdn.fr (80.67.169.18) from 80.67.176.237 ppp4: 1400(1428) 
bytes of data.
1408 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=1 ttl=61 time=64.8 ms
1408 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=2 ttl=61 time=63.2 ms
1408 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=3 ttl=61 time=63.6 ms
1408 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=4 ttl=61 time=63.1 ms

alix:~#
alix:~# ping -s 700 -I ppp4 www.fdn.fr
PING yoda.fdn.fr (80.67.169.18) from 80.67.176.237 ppp4: 700(728) bytes 
of data.
708 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=1 ttl=61 time=56.2 ms
708 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=2 ttl=61 time=55.8 ms
708 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=3 ttl=61 time=55.6 ms
708 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=4 ttl=61 time=56.3 ms

L’inconvénient c'est que l'on diminue un peu le débit max des liens.

Je verrai bien lors des tests, j'ai prévu que la fragmentation des 
paquets soit une option activable/désactivable.

A+
Fernando

>
> Je ne demande qu'à être convaincu ceci-dit, quelque-chose m'échappe 
> sûrement :-)
>
> Bonne journée,
>
> Jocelyn
>
>>
>> Exemple:
>> 1) coté serveur le "network Kernel" écrit un paquet de 1500 octets sur
>> l'interface tun/tap créé par linkagreg,
>> 2) linkagreg lit ce paquet de 1500 octets le divise en 2
>> (2*(750+header linkagreg)) et les transmets a travers 2 tunnel UDP a
>> l'appli linkagreg coté client.
>> 3) coté client linkagreg reçoit 2 paquets de 750 octets + header
>> linkagreg, il ré-assemble ces 2 paquets en un paquet de 1500 octet et
>> l’écrit sur l'interface tun/tap qu'il a créé.
>
> Quel est le bénéfice réel de couper tous les paquets en 2 ?
>
>>
>> Coté client et serveur le "network Kernel" pense avoir à faire à une
>> interface de 1500 octets de MTU (comme pour une interface ethernet).
>>
>> http://irp.nain-t.net/doku.php/140pppoe:070_mtu_mss_etc
> Bon lien, merci :) Ok pour le PMTU qui se foire dans la plupart des 
> cas à cause du filtrage d'ICMP. J'avais oublié ce point.
>
>
>>
>> Fernando
>>
>>>
>>>
>>> Jocelyn
>>>
>>>
>>>>
>>>>
>>>> si vous voulez essayer, voila comment je l'utilise:
>>>>
>>>> ##############################
>>>> # VM Serveur eth0= 192.168.1.1
>>>> ##############################
>>>> *./linkagreg -s -d -i tun10&
>>>> ip addr add 10.0.0.1/24 dev tun10
>>>> ip link set up dev tun10*
>>>>
>>>> ##############################
>>>> # VM Client eth0=192.168.1.2
>>>> # eth1=192.168.1.3
>>>> # ouverture de 2 tunnel UDP:
>>>> # 192.168.1.2<--> 192.168.1.1
>>>> # 192.168.1.3<--> 192.168.1.1
>>>> ##############################
>>>> *./linkagreg -c 192.168.1.1 -f 192.168.1.2,192.168.1.3 -d -i tun10&
>>>> ip addr add 10.0.0.2/24 dev tun10
>>>> ip link set up dev tun10
>>>> *
>>>
>>>
>>>
>>
>>
>>
>
>
>

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.tetaneutral.net/pipermail/projet-agregation/attachments/20111113/0ee73ae5/attachment.html>