Mon blog

Le groupe de travail IETF sur les performances, IPPM, définit un grand nombre de métriques, de grandeurs mesurables, par exemple dans son RFC 2330. Si ce RFC avait déjà abordé le problème de la composition des métriques, il n'avait pas répondu à toutes les questions sur cette composition, ce que fait désormais notre RFC 5835. Comment combiner des mesures dans le temps et l'espace ?

Une telle demande est fréquente chez les opérateurs (section 1.1). Une mesure isolée ne sert en général pas à grand'chose et il faut donc pouvoir les composer (récolter et distribuer un ensemble de mesures) et les agréger (réduire un ensemble de mesures à une seule).

Par exemple, l'administrateur réseaux a souvent besoin de mesures immédiates, obtenues rapidement, pour résoudre un problème précis (ceux qu'on débogue avec ping...). Mais celui qui planifie les évolutions futures du réseau a besoin de mesures répétées sur une longue période, par exemple pour détecter des tendances. Les mesures utiles au premier peuvent aussi l'être au second si on les compose sur cette longue période (section 1.1.2).

Quant à l'agrégation, son but principal est de diminuer la quantité de données (section 1.1.3). Cela facilite le travail de l'humain, qui a ainsi une donnée plus simple à lire et à comprendre et on peut même mettre ces mesures agrégées dans un SLA.

Toutes les données ne se prêtent pas forcément bien à la composition et à l'agrégation. La section 2 exclut donc des métriques comme le réordonnancement des paquets (RFC 4737) et la duplication (RFC 5560). Par contre, les métriques « perte de paquets » (RFC 7680) ou « variation de délai d'acheminement » (RFC 5481) sont parfaitement composables.

La section 3 décrit les mots utilisés dans le reste du RFC. Un terme est particulièrement important, celui de « vérité de base » (ground truth, section 3.7) qui désigne la « vraie » valeur agrégée, celle qu'on va essayer d'atteindre.

Armés de ces mots, on peut alors passer aux compositions elle-mêmes (section 4). Il y a d'abord l'agrégation temporelle (section 4.1), qui consiste à combiner des mesures faites au même endroit et dans les mêmes conditions, mais à des instants différents. Par exemple, si on a mesuré les maxima et minima d'un délai d'acheminement toutes les cinq minutes, on peut agréger à une mesure toutes les soixante minutes en prenant le maximum le plus élevée d'une série de douze mesures successives (et le minimum le moins élevée de la même série, pour trouver le minimum agrégé). Attention, le RFC 2330 parlait de « composition temporelle » pour désigner une opération assez différente, de prédiction de valeurs inconnue.

L'agrégation spatiale, elle (section 4.2), agrège des mesures du même type faites à des endroits différents. Par exemple, si on a mesuré des délais d'acheminement des paquets à plusieurs endroits d'un grand réseau, et qu'on veut déterminer un délai « moyen », le calcul naïf de la moyenne serait assez faussé par quelques liens peu utilisés et la bonne façon d'agréger est donc une moyenne pondérée par l'importance du trafic sur chacun des liens mesurés.

Autre exemple d'agrégation spatiale, un opérateur réseau veut connaître le délai d'acheminement d'un paquet dans son réseau. Comme ce dernier a beaucoup de points d'entrée et beaucoup de points de sortie, la liste des délais va être longue. L'opérateur peut la raccourcir par une agrégation spatiale : garder uniquement le délai maximum (qui sera ainsi une borne supérieure du temps passé dans le réseau).

L'agrégation spatiale diminue la résolution de l'information (c'est bien son but : simplifier les données). La composition spatiale, elle (section 4.3), combine plusieurs mesures faites à des endroits différents pour trouver une mesure globale. Un exemple typique est la mesure du délai d'acheminement du point A au point D si on connait les délais de A à B, de B à C et de C à D. Une simple addition donnera alors le délai total (approximatif : par exemple, il n'est jamais garanti que les délais soient parfaitement additifs).

Une fois qu'on a combiné des mesures, on peut continuer le processus dans d'autres combinaisons (section 4.5). Par exemple, les résultats d'une agrégation temporelle (qui diminue la résolution des mesures mais les rend plus faciles à analyser et plus légères à copier sur le réseau) peuvent faire l'objet d'une nouvelle agrégation qui va encore diminuer la résolution (et le volume des données).

Le principal but de notre RFC étant de paver la voie pour de futurs RFC définissant rigoureusement des métriques composées et agrégées, la section 5 donne les exigences auxquelles ces futures métriques devront obéir, par exemple une description claire des suppositions sur lesquelles elles reposeront, une explication de leur utilité pratique, une analyse des sources d'erreur, etc. Le premier de ces RFC a été le RFC 6049.

Il y a même une mention des risques liés à l'appropriation intellectuelle, en section 5.1, qui rappelle que, si une seule des métriques est plombée par un brevet ou une appropriation similaire, alors la composition entière l'est.

Enfin, la section 6 donne des conseils sur la composition de métriques, tournant en général autour de l'idée de « vérité de base ». Ainsi, lors d'une composition temporelle (section 6.1.1), la vérité de base est la mesure effectuée sur tout l'intervalle. Si je mesure le taux de perte de paquets (RFC 7680) sur trois intervalles contigus, de durées égales, T1, T2 et T3, et que je fais une composition temporelle (en prenant la moyenne) pour trouver le taux de pertes de l'intervalle T (= T1 + T2 + T3), une mesure directe pendant T nous aurait donné la vérité de base. La composition idéale devrait donc donner une valeur proche de la vérité de base.

Qu'est-ce qui empêche une composition de s'en tenir à cet idéal ? Comme le note la section 6.2, cela peut être la propagation d'erreurs de mesure, ou bien une légère différence dans ce qui est mesuré. Par exemple, lors d'une composition spatiale, le délai d'acheminement d'un paquet entre A et C (séparés par un routeur B) n'est pas réellement la somme des délais de A à B et de B à C car il y a un temps de traitement dans B.

Autre piège dans les mesures : le trafic sur l'Internet réel dépend souvent du temps. Par exemple, des variations sur un rythme quotidien sont très courantes. Composer des mesures prises à des moments différentes peut donc donner des résultats erronés (section 6.4). À noter que certaines métriques ne dépendent quasiment pas du moment de la mesure, par exemple le délai minimum d'acheminement des paquets.