Mon blog

Deux jeux de métriques (grandeur à mesurer, définies de façon formelle) sont normalisés dans ce RFC, l'un pour des mesures « spatiales », l'autre pour la diffusion de groupe.

Dans le cadre du RFC 2330, il existe plusieurs métriques pour mesurer des « performances » d'un réseau de bout en bout. On peut ainsi mesurer le temps de trajet (RFC 7679), le taux de perte (RFC 7680), les changements d'ordre des paquets (RFC 4737), etc. Notre RFC 5644 étend ces métriques :

• aux cas où on ne mesure pas seulement de bout en bout mais également aux routeurs intermédiaires,
• aux cas où il y a plusieurs destinations pour un paquet (multicast).

Ici, je parlerais surtout des premières, les métriques dites « spatiales » (voir les sections 7 et 8 pour les autres).

Comme les précédentes, ces nouvelles métriques sont enregistrées dans le registre créé par le RFC 4148. Les définitions nécessaires figurent dans la section 2. Ainsi, métrique multipartite (multiparty metric) est définie (section 2.4) comme le cas où il existe plusieurs points de mesure, une métrique spatiale (spatial metric) est (section 2.5) celle où certains des points de mesure ne sont ni la source, ni une destination du paquet (mais des routeurs situés sur le trajet). Et la métrique de groupe est (section 2.6) celle où il existe plusieurs destinations.

La section 2.7 introduit la notion de points intéressés (points of interest). Ce sont les machines où se fait la mesure. Pour les métriques spatiales, c'est un sous-ensemble des routeurs du chemin suivi par le paquet. Pour les métriques de groupe, ce sont les machines de destination.

Autre terme important, celui de vecteur (vector), défini en section 2.9. C'est simplement une liste de valeurs obtenues en différents points. Par exemple, si on mesure le temps que met un paquet multicast pour aller de la source à N destinations, le résultat de la mesure est un vecteur dont chaque composante est le temps qu'a pris le trajet de la source à un des récepteurs.

Une fois qu'on a les vecteurs, les matrices ne sont pas loin (section 2.10). Une matrice est simplement une liste de vecteurs. Dans le contexte de notre RFC, la matrice a une dimension d'espace (mesures effectuées à différents points, comme dans le vecteur cité en exemple ci-dessus) et une dimension de temps (mesures répétées dans le temps). Si on met le temps horizontalement et l'espace verticalement, une colonne est un vecteur (mesures à différents points, d'un même paquet) et une ligne est un échantillon (mesures de paquets successifs au même point).

Les métriques elles-mêmes sont introduites dans la section 3, en reprenant les concepts des RFC 2330, RFC 2679, RFC 2680, RFC 3393 et RFC 3432. Petit rappel : Type-P indique le type du paquet (TCP ou UDP, taille du paquet, etc) car les performances peuvent en dépendre. Par exemple, Type-P-Spatial-One-way-Delay-Vector reprend la métrique Type-P-One-way-Delay du RFC 2679 et l'étend en vecteur. Elle désigne donc le temps de trajet mesuré à différents points successifs du chemin (différents routeurs).

Pourquoi avoir créé ces nouvelles métriques ? La section 4 reprend les motivations du travail du groupe ippm. Pour les métriques spatiales (section 4.1), il y avait le souhait de comprendre la contribution de chaque étape du chemin au temps total (ce que fait l'ingénieur réseaux lorsqu'il regarde ce qu'affichent traceroute ou mtr avant de dire « Ça coince à tel endroit »).

Venons-en maintenant aux définitions formelles. La section 5 le fait pour les métriques spatiales. Il faut avoir bien lu avant les définitions pour les métriques de bout en bout, les métriques spatiales étant simplement une généralisation. Type-P-Spatial-One-way-Delay-Vector est définie en section 5.1 et, comme indiquée plus haut, c'est simplement l'ensemble des délais d'acheminement d'un paquet, mesuré à plusieurs points du trajet. Je ne recopie pas ici la définition détaillée et très précise du RFC mais je dis juste un mot sur la discussion en section 5.1.5. Cette métrique peut rencontrer des cas pathologiques par exemple si le temps au point N+1 est supérieur au temps au point N. Cela peut être dû à plusieurs choses comme une désynchronisation des horloges (section 3.7.1 du RFC 2679) ou bien un changement dans le routage. Entre le moment où on a déterminé l'ordre des points de mesure (par exemple en faisant un traceroute) et le moment de la mesure, le routage a pu changer et le routeur N+1 passer avant le N.

De même qu'on peut définir Type-P-Spatial-One-way-Delay-Vector en « vectorisant » Type-P-One-way-Delay, la section 5.2 crée Type-P-Spatial-Packet-loss-Vector en vectorisant Type-P-Packet-loss, le taux de perte de paquets du RFC 2680. Et la section 5.3 crée Type-P-Spatial-One-way-ipdv-vector à partir de l'IPDV (Inter-Packet Delay Variation) du RFC 5481.

Les mesures « spatiales » posent des problèmes de méthodologie particuliers qui font l'objet de la section 5.4. Ainsi, la perte d'un paquet est définie par le RFC 2680 comme la non-arrivée de ce paquet au bout d'un temps fini. Si deux points de mesure n'utilisent pas la même valeur pour ce temps, un paquet peut être considéré comme perdu à un point de mesure... mais pas à un point situé en aval, qui utilise un délai maximum plus élevé (section 5.4.1). Il est donc important que tous les points de mesure utilisent des valeurs cohérentes.

Les vecteurs de notre RFC 5644 sont ordonnés : chaque point mesure a une place, qui est l'ordre dans lequel ils voient passer le paquet. Toutes les métriques spatiales dépendent donc de cet ordre. Or, celui-ci n'est pas constant sur l'Internet. Par exemple, une instabilité temporaire du routage peut entraîner une micro-boucle où le paquet passe plusieurs fois par le même routeur et est donc observé plusieurs fois (section 5.4.2). Les points de mesure doivent donc pouvoir détecter de pareils cas, pour les éliminer des statistiques. (La section 10.2.1 mentionne aussi l'importance d'indiquer le chemin suivi par le paquet dans les publications.)

Un vecteur désigne des mesures qui varient dans l'espace, une mesure par point d'observation. Les mesures varient aussi dans le temps, ce qui mène aux métriques de la section 6. Type-P-Segment-One-way-Delay-Stream (section 6.1) est ainsi l'observation dans le temps du délai d'acheminement entre deux routeurs.

Les vecteurs étant évidemment plus gros que les scalaires, les métriques de notre RFC posent des problèmes techniques liés à l'espace de stockage nécessaire et à la capacité du réseau pour les transporter. La section 9 discute de ces détails pratiques. Par exemple, la section 9.3 expose deux méthodes de réduction des matrices avant de les envoyer, réduction sur le temps (agréger les mesures faites à des moments différents) ou bien sur l'espace (agréger les mesures de tous les routeurs). Comme seule la première méthode de réduction peut être effectuée localement, sur chaque point de mesure, c'est elle qui permet de minimiser le trafic réseau lié à ces mesures.