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

[Jocelyn Delalande]

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.

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
>>> *
>>
>>
>>
>
>
>



-- 
   Jocelyn Delalande,
Étudiant Génie Informatique,
Université Technologique de Compiègne
tel : 06.21.96.86.99