Traditionnellement, les mesures des caractéristiques d'un réseau en
labo () se faisaient avec des paquets de taille
constante, afin de bien contrôler les conditions de la mesure, de
savoir exactement ce qui était mesuré et donc de pouvoir
reproduire la mesure à volonté. C'est par exemple ce que fait
la commande ping avec son option
-s. Mais les réseaux réels sont
bien différents : ils font passer des paquets de taille très
diverses. Il est donc fréquent aujourd'hui de tester avec un mélange
de paquets de différentes tailles, ce qu'on nomme un
IMIX (Internet MIXture). De
nos jours, les
équipements de test ont souvent la possibilité d'utiliser des IMIX. Mais
les tests doivent être reproductibles, il faut donc un moyen de
caractériser un IMIX, d'indiquer sa composition (autrement que par un
vague « on a utilisé un IMIX »). C'est le but du
mini-langage présenté dans ce RFC.
En gros, les petits paquets vont tester la capacité du réseau à traiter les
en-têtes et les gros vont tester sa capacité à faire circuler des
bits. On a donc besoin des deux dans un test. L'IMIX
genome est la description, dans un langage formel, de la
répartition des tailles de paquets. (Comme un
génome décrit une espèce.)
Donc, à quoi ressemble un IMIX (section 3 du RFC) ? À une série de
lettres dont chacune code une taille de paquet donnée, en utilisant
les tailles « standard » du . Ainsi,
avec la table a = 64 octets, b = 128, c = 256, d = 512, e = 1 024, f =
1 280 et g = 1518, l'IMIX aaafg désigne une
séquence de cinq paquets, les trois premiers faisant 64 octets, le
quatrième 1 280 et le dernier ayant la taille maximale sur
Ethernet. Une lettre z est utilisée pour dire
« la MTU du lien », donc, ici, on aurait pu
utiliser aaafz. Notez bien qu'avec cette notation, les autres tailles
ne peuvent pas être représentées (il faut choisir la taille la plus
proche) et qu'un test avec des milliers de paquets est décrit par un
IMIX assez illisible...
Si on tient à utiliser des tailles non prévues par le , la section 4 prévoit un moyen de définir
localement des lettres, notées en majuscule. Avec la table locale A =
98, B = 1 020, l'IMIX BBAA indiquera deux gros
paquets puis deux petits.
Ce système manque clairement de souplesse : et si, pour un test long, une séquence de
base est répétée ? Ou bien si les tailles sont
choisies par un processus pseudo-aléatoire ? La
section 5 décrit deux fonctions utiles du mini-langage de description
des génomes IMIX. Pour les séquences répétées, on se sert simplement
d'un encodage en RLE. Le RFC ne propose pas de
syntaxe concrète pour le décrire, l'exemple est juste un tableau « 20
fois abcd puis 5 fois ggga
et enfin 10 fois dcba ». Le RFC propose également
un autre mécanisme (à nouveau sans syntaxe précise), en indiquant les
pourcentages de chaque taille (sans spécifier la séquence) : « 23 % de
64 octets, 67 % de 128 et 10 % de 1 000 ».
Le RFC prévoit aussi le cas où les tailles sont générées par un
algorithme. Dans ce cas, pas de langage particulier, il faut le
décrire en langage naturel lorsqu'on publie les résultats de la mesure
(« on part de paquets de 64 octets et on incrémente leur taille de 1 à
chaque paquet, s'arrêtant à la MTU »). Idem si l'algorithme utilisé est
un générateur pseudo-aléatoire, qui doit
également être décrit (avec la graine utilisée).
Si vous voulez lire des articles sur les IMIX, voir « "Test Methodology
Journal: IMIX (Internet Mix) », « Library:
Test Plans » ou « The
Journal of Internet Test Methodologies ». Pour une discussion sur la normalisation d'IMIX (et pas du langage qui
les décrit), voir une discussion terminologique dans le groupe de travail.