A. Morton (AT&T Labs)G. Ramachandran (AT&T Labs)G. Maguluri (AT&T Labs)August20122012-08-24
Le groupe de travail IPPM de
l'IETF a défini de nombreuses
métriques, des définitions rigoureuses de
grandeurs qu'on peut mesurer sur un réseau. Ce nouveau
RFC porte sur un problème un peu différent : une
fois qu'on a ces métriques, comment publier les résultats ? Quels sont
les pièges de la publication ? Parmi les paramètres de la mesure, que
mettre en évidence ? Ce RFC est loin de traiter en détail toutes ces
questions, il décrit surtout les conséquences de deux points
de vue différents : celui de l'ingénieur réseaux, intéressé
surtout par les performances de son réseau, et celui du programmeur,
intéressé par les performances de son application.
Il y a bien sûr un lien entre les deux : si le réseau perd beaucoup
de paquets, par exemple ( et ), les applications auront de moins bonnes
performances. Mais, dans certains cas, les deux points de vue ne
s'intéressent pas exactement à la même chose. Voyons en quoi. (À noter
aussi que ce ne regarde que les analyses sur le
relativement long terme, au moins plusieurs heures. Et il ne se penche
pas sur le problème, bien plus difficile, de la publication vers
M. Toutlemonde, par exemple pour lui communiquer la QoE.)
Toute présentation de mesures nécessite évidemment de connaître
l'audience. On ne va pas communiquer de la même façon vers le
management et vers les techniciens, par
exemple. Et, même parmi les techniciens, il existe plusieurs
catégories. Ce RFC s'intéresse à la différence entre « les gens du
réseau » (qui pensent planification des investissements, dépannage,
SLA, etc) et « les gens des applications » qui
se demandent quel va être l'effet du réseau sur les applications. Les
premiers mesurent des métriques comme le taux de pertes de paquets
() ou comme le délai d'acheminement
(), avec l'idée de modifier le réseau
(par des investissements ou bien des changements de la configuration),
si les chiffres sont défavorables. Les seconds vont ajuster les
applications pour s'adapter à ces résultats, qu'ils ne peuvent pas
changer.
Les recommandations de notre RFC occupent la section 3. Lorsqu'on
publie des mesures, on doit notamment :
Inclure au minimum le taux de pertes de paquets () et le délai
d'acheminement (). On notera que c'est ce que fait la commande
ping, même si elle ne suit pas exactement les
métriques IPPM. Notons aussi que la norme UIT Y.1540 donne une
définition assez proche de celle de l'IETF.Indiquer la moyenne et la
médiane (ce que ping ne fait hélas pas). Les deux statistiques
sont utiles (et les deux ont des limites, par exemple aucune des deux
ne gère proprement les distributions bimodales).
C'est le minimum. Mais on peut l'enrichir, avec d'autres métriques
comme la variation du délai d'acheminement (), le réordonnancement des paquets (), la capacité ( et , le premier RFC décrivant la capacité utile
et le second celle mesurée au niveau IP). Et on
peut ajouter d'autres statistiques, pour ne pas être bloqués par les
limites de la moyenne et de la médiane. Par exemple, minimum, maximum,
« 95 percentile ».
Bon, et les deux points de vue différents dont je parlais au début,
que deviennent-ils ? La section 4 du RFC examine les différentes
métriques selon ces deux points de vue. Par exemple, le taux de pertes
du a un paramètre important : le délai
d'attente avant qu'on renonce à attendre un paquet. Le ne donne pas de valeur quantitative. Intuitivement, on
pourrait penser que des durées de l'ordre de la demi-seconde
suffisent. Après tout, on n'a jamais vu ping signaler un délai plus
long, non ? Mais ce n'est pas idéal. En cas de boucle de routage, par
exemple, avant que l'IGP ne converge enfin, un
délai de plusieurs secondes est possible (cf. « A Fine-Grained View
of High Performance Networking » à NANOG
22 ou « Standardized Active Measurements on a Tier 1 IP
Backbone » dans IEEE Communications Mag.
de juin 2003). Un délai long est donc recommandé. En modélisant le
pire cas dans le réseau, notre RFC arrive à une recommandation de 50
secondes, qui devrait couvrir tous les cas. Revenons maintenant aux
deux point de vue. L'homme (ou la femme) du réseau veut déterminer le
vrai taux de perte, en étant sûr que les paquets sont vraiment perdus
et pas simplement très en retard. Mais la femme (ou l'homme) des
applications n'a pas besoin de tels délais d'attente : l'application
ne patientera jamais autant. Pour la plupart des applications, si ça
n'arrive pas en quelques secondes, c'est comme si c'était perdu.
Faut-il alors faire deux mesures pour nos deux points de vue ?
C'est une possibilité. Le RFC en suggère une autre : ne faire qu'une
mesure, avec le délai long, mais noter le moment où le paquet arrive
et calculer le taux de pertes avec deux délais différents, pour faire
deux rapports.
Et le cas des paquets erronés (par exemple car ils ont une
somme de contrôle invalide) ? Pour le , ils sont à compter comme perdus (si le
paquet est erroné, on ne peut même pas être sûr qu'il était bien pour
nous). C'est le point de vue des gens du réseau. Mais les gens des
applications ne sont pas toujours d'accord. Certaines applications,
notamment dans le domaine de l'audio et de la
vidéo temps-réel préfèrent que l'application
reçoive les paquets erronés, dont on peut parfois tirer quelque
chose. Notre RFC suggère donc de publier deux résultats, un en
comptant les paquets erronés comme perdus, l'autre en les
acceptant.
Et la métrique « délai d'acheminement des paquets », en quoi les
deux points de vue l'affectent (section 5) ? Notre RFC s'oppose
surtout à l'idée de présenter les paquets qui, lors de la mesure,
n'arrivent pas, avec une valeur artificielle comme un nombre très
grand ou comme l'infini. Quel que soit le point
de vue, l'infini n'est pas une valeur utile et il vaut donc mieux
considérer que le délai, pour un paquet qui n'arrive pas, est
« indéfini ».
Maintenant, la capacité (sections 6 et 7). Notre introduit un nouveau vocabulaire, « capacité brute »
(raw capacity) pour celle du (qui n'intègre pas les effets de la retransmission des
paquets perdus ou erronés) et « capacité restreinte »
(restricted capacity) pour celle du , qui intègre les actions du protocole de transport
(retransmettre les données manquantes, par exemple). La capacité
restreinte est donc inférieure ou égale à la capacité brute, et elle
est plus proche de ce qui intéresse les utilisateurs.
D'abord, un rappel, la capacité n'est définie que pour un
Type-P donné, c'est-à-dire () un type de paquets (protocole,
port, etc). Ensuite, le définit trois métriques pour la capacité brute :
capacité IP maximum (ce que le système peut faire passer), utilisation (ce qui
passe effectivement, et qu'on pourrait appeler « débit » mais le RFC
évite ce terme, trop galvaudé), et enfin capacité disponible
(certaines applications, par exemple, voudraient simplement savoir si
la capacité disponible est suffisante - supérieure à une certaine valeur). Les
trois métriques sont liées : en en connaissant deux, on peut calculer
la troisième. L'utilisation (et donc la capacité disponible) peut
varier rapidement sur un réseau réel. Notre
recommande donc de moyenner sur une longue période, par exemple une
minute (en notant que cinq minutes est plus fréquent, en pratique,
mais peut-être trop long). D'autre part, il suggère de publier
plusieurs chiffres : miminum, maximum et un intervalle (par exemple,
le pourcentage de temps pendant lequel la métrique vaut entre telle et
telle valeur, comme « la capacité est de X Mb/s pendant
au moins 95 % du temps »). Maximum et minimum peuvent aussi être publiés sous
forme d'un seul chiffre, leur ratio : (max/min = 1) => grande
stabilité, (max/min = 10) => forte variabilité, etc.
Pour la capacité restreinte, un autre problème se pose : elle est
dépendante des algorithmes de contrôle de
congestion. Par exemple, avec certaines mises
en œuvre de TCP anciennes, la capacité
restreinte (celle réellement accessible aux applications) pouvait être
très inférieure à la capacité brute, par exemple parce que TCP
réagissait mal en cas de perte de paquets et ralentissait trop son
débit. Notre RFC introduit donc un nouveau concept, le « Type-C » qui
est l'ensemble des algorithmes du protocole de transport et leurs
paramètres (). Il est nécessaire de
publier le Type-C utilisé, avec les résultats. (Un exemple, sur
Linux, est la valeur du paramètre
sysctlnet.ipv4.tcp_congestion_control.)
Autre piège, le temps d'établissement de la connexion TCP. Si on
mesure la capacité restreinte avec quelque chose comme (sur
Unix) time wget
$GROSFICHIER, le délai pour la triple poignée de mains qui
commence toute connexion TCP peut sérieusement affecter le
résultat. Même chose avec le « démarrage en douceur » que fait TCP
avant d'atteindre l'équilibre. Il peut diminuer la capacité mesurée
(d'un autre côté, l'ignorer serait irréaliste puisque les « vraies »
connexions l'utilisent). Bref, toutes ces informations doivent être
publiées avec le résultat de la mesure.
Enfin (section 8), deux détails qui peuvent avoir leur importance : la
distribution des paquets lors d'une mesure active
(Poisson ?
Périodique, ce que fait ping ?). Et la taille de l'échantillon
(par exemple le nombre de paquets envoyés.) Ces détails doivent
également être publiés.