Groupe de travail Métrologie. Les métriques IPPM.

Groupe de travail Métrologie

http://gt-metro.grenet.fr

Les métriques IPPM

[email protected]

Une métrique réseau ?

 Contributions :

– Bernard Tuy, RENATER – Simon Muyal, RENATER – Catherine Grenet, UREC

Une métrique réseau ?

 Une métrique est une caractéristique du comportement d'un réseau

 Elle est exprimée dans une unité standard et permet de faire des comparaisons

– Dans le temps :

➔ Après un changement de configuration

➔ Après une panne, un changement de route

– Dans l'espace

➔ Entre 1 poste et deux autres postes, afin de comparer des situations

– Entre deux réseaux

➔ Dont les topologies sont proches mais les performances différentes

Limitations physiques

 Certaines métriques sont liées à des limites physiques

 La vitesse de la lumière dans le vide est une limite absolue :

c = 299 792 458 m/s

 Paris – Nice 900 km ≃

➔

Limite basse absolue (dans le vide) : 3 ms pour qu'un signal aille de Paris à Nice

➔

Il ne sert à rien d'espérer

mieux

Limitations au niveau des équipements

 Les équipements traversés imposent leurs propres limitations

 Files d'attente

 Charge sur des liens

 Décisions de routage

– Tous les paquets d'un même flux n'empruntent pas le même chemin

 Filtrage

 Équilibrage de charge

 Programmation de QoS avec du traffic policing ou la mise en oeuvre

d'algorithmes de gestion de la congestion

Les métriques physiques 1/3

 Temps de propagation/Propagation delay

– Temps mis par le signal pour traverser le lien physique – 0,66c 200 000 000 m/s sur une FO (fibre optique)≃ – De 0,66c à 0,95c sur des liens cuivres

– Délai pour faire 1000 km = 1000/200 000 = 0,005 soit 5 ms – Paris – Nice 900 km≃

➔ Sur une FO un signal optique va de Paris à Nice en 4,5 ms

Les métriques physiques 2/3

 Temps d'insertion/Serialization delay

– Temps d'insertion d'un paquet sur une ligne physique – Pour insérer 1500 octets sur une ligne de 1Gbits il faut :

1500x8 / 10⁹ = 0,000012 s = 12 µs

– Pour insérer 1500 octets sur une ligne de 10Mbits il faut : 1500x8 / 10⁷ = 0,0012 s = 1,2 ms

Les métriques physiques 3/3

 Temps de mise en paquet/Packetization delay

– Temps pris par une application pour remplir un paquet IP – Il s'agit d'un délai variable et configurable

 Autres délais : – Codec

– Queuing

Les métriques IPPM

 IPPM = IP Performance Metrics

 Il s'agit d'un travail (réalisé par le groupe IETF du même nom) qui décrit très précisément la terminologie mais aussi les méthodes et les unités à utiliser pour la définition de métriques

 RFC 2330

Les métriques IPPM:

les critères à respecter

 Les métriques doivent être concrètes et bien définies

 Les résultats d'une mesure avec une métrique donnée doivent être reproductibles : une mesure effectuée de multiples fois dans des conditions identiques doit donner des résultats identiques

 Les métriques doivent être utiles, pour les fournisseurs d'accès et

les utilisateurs afin qu'ils comprennent les performances qu'ils

perçoivent ou fournissent

Les métriques IPPM

 Une métrique IPPM est une quantité relative à la performance ou à la fiabilité d'Internet qui a été spécifiée avec beaucoup d'attention

 Les unités de mesures utilisées sont celles du Système International d'Unités

 L'unité d'information est le bit. 1 kbits = 1000 bits, pas 1024.

 Le temps utilisé est le temps UTC

 Toutes les mesures qui ont étés définies sont des mesures directes, par injection de trafic

 par ex mesure du RTD d'un paquet IP d'une taille donnée sur un chemin donné à une heure donnée

Les métriques IPPM : vocabulaire

 Host/Hôte : un ordinateur capable de communiquer en utilisant les protocoles de l'Internet. Ça inclut les routeurs

 Link/Lien : Une connexion simple de niveau 2 entre deux hôtes ; ça inclue les liaisons louées ou ethernet, les nuages Frame Relay, etc.

 Router/Routeur : un hôte qui facilite la communication au niveau 3 entre des hôtes en acheminant des paquets IP

 Path/Chemin : une séquence de la forme <h

, l

, h

, ..., l

, h

> où

n >= 0, chaque h

est un hôte et chaque l

est un lien entre h

et h

.

Chaque h

...h

est un routeur. Une paire <l

, h

> est nommée un

hop/saut. Un chemin est un concept unidirectionnel.

Les métriques IPPM : vocabulaire

 Cloud/Nuage : un graphe non orienté dont les sommets sont des routeurs et les arêtes des liens qui connectent des paires de routeurs

 Subpath/sous-chemin : Pour un chemin donné, un sous-chemin est n'importe quelle sous-séquence d'un chemin qui est elle-même un chemin. (Débute et se termine par un hôte).

– <h0, l1, h1, l2, h2, l3, h3, l4, h4> est un chemin

• <h0, l1, h1, l2, h2> est un sous-chemin

• <h2, l3, h3> est un sous-chemin

• <l1, h1, l2, h2> n'est pas un sous-chemin

• <h₀> est un sous-chemin

Les métriques IPPM : vocabulaire

 Exchange/Un point d'échange : un cas particulier de lien. Un exchange interconnecte soit

• Un hôte à un nuage et/ou

• Un nuage à un autre nuage

 Cloud subpath/Sous-chemin de nuage : le sous-chemin d'un

chemin dont tous les routeurs appartiennent à un nuage

L'incertitude temporelle

 Synchronisation entre deux horloges

– IPPM → Clock Offset : décalage entre une horloge et le temps UTC

 Exactitude : par rapport à une norme

– IPPM → Accuracy : plus l'offset est proche de zéro, plus l'horloge est précise

 Résolution : la valeur minimale de temps qu'une horloge sait mesurer – IPPM → Resolution : la plus petite unité de temps par laquelle une

horloge est mise à jour

 Écart de fréquence : différence de fréquence entre deux horloges

– IPPM → Skew : différence de fréquence entre l'horloge et le temps UTC

 Variation de l'écart : variation de l'écart de fréquence

– IPPM → Drift : variation du skew au cours du temps

Les métriques IPPM : NTP

 NTP a une précision liée au réseau, si c'est précisément le réseau dont on mesure les performances qui relie les horloges aux extrémités d'une mesure, ça peut conduire à des résultats spécieux

➔ On a besoin que la synchronisation des horloges soit hors-bande, externe à l'objet mesuré

 NTP fait un focus sur la précision de l'horloge sans trop s'occuper du skew et du drift.

– Il fait soit, de temps en temps, des mises à jour de l'horloge quand le décalage devient trop important

– soit il accélère la fréquence de l'horloge pour rattraper le retard...

➔ dans les deux cas, les conséquences sont désastreuses sur les mesures en cours

Les métriques IPPM : Wire time

 Il serait inadéquat que les mesures de temps soient faites au niveau du système ou au niveau applicatif

– Les interruptions matérielles introduisent des délais inacceptables

– La gestion du temps partagé entre les applications par les OS introduit aussi des délais trop importants

➔ Le RFC recommande que la mesure du temps de réception ou d'émission d'un paquet soit réalisée le plus près possible du fil

Les métriques IPPM : Wire time

 Le RFC IPPM définit la notion de « wire time / temps filaire » de la façon suivante :

– P est un paquet – H est un hôte

– L est l'endroit où H observe un lien Internet

Le temps d'arrivée filaire de P sur H au niveau de L est le premier instant T où un bit quelconque de P est apparu en L

Le temps de départ filaire de P de H est le premier instant T où tous les bits de P sont apparus en L

Les métriques IPPM : Wire time

 La mesure du wire time se fait au niveau d'un hôte → cela veut dire que le RFC ne prévoit pas de mesures via des boîtiers spécialisés en des points d'un lien où un hôte ne pourrait pas être

 Le RFC prévoit des difficultés avec la notion de wire time en cas de fragmentation : les fragments sont des paquets IP légitimes avec des wire time alors que le paquet agrégé n'en a pas → il renvoie à une époque ultérieure une définition plus précise, si nécessaire

➔

Il faut dire qu'auparavant la notion de wire time était couramment

utilisée mais jamais définie (premier ou dernier bit, à l'arrivée, au

départ ?) ce qui induisait des erreurs de l'ordre des délais de

sérialisation et de propagation. La norme définie élimine le délai de

sérialisation de la mesure.

Les métriques IPPM : types de métriques

 Singleton

 Métrique atomique

• par exemple temps de transit à sens unique à un instant donné pour des paquets de taille N

 Sample

 Métrique dérivée d'une métrique de type singleton, en prenant plusieurs instances temporelles ou spatiales.

• Par exemple, un ensemble de temps de transit à sens unique pour des instants répartis selon une loi de Poisson dans un intervalle de temps donné

 Statistical

 Métrique calculée à partir des valeurs des singleton pris dans un sample.

• Par exemple, la valeur moyenne du temps de transit sur une période de temps donné, calculée en faisant la moyenne du sample précédent

Les métriques IPPM : collecte d'échantillons

 La collecte de sample sert surtout à observer les variations d'une métrique donnée. Variations en fonction du point d'observation ou en fonction du temps

 La mesure doit être impartiale : le processus de collecte ne doit pas avoir introduit de biais dans les mesures

 Pour cela, elle doit éviter d'être périodique :

– Si le phénomène mesuré a un comportement périodique et s'il arrivait que les périodes soient liées (l'une multiple de l'autre) alors la mesure n'arriverait à observer qu'une partie du comportement

– Les mesures elles-mêmes peuvent induire des perturbations

cycliques qui vont conduire le réseau à se synchroniser et à

amplifier artificiellement un comportement mineur sinon

Les métriques IPPM : collecte d'échantillons

 Le RFC recommande l'utilisation d'un échantillonnage suivant une loi de Poisson



L'arrivée de paquets ne peut pas être prédite



L'échantillonnage n'est pas biaisé (→ impartial), même si la mesure affecte l'état du réseau



La mesure n'induit pas de synchronisation



Elle peut-être utilisée pour collecter des mesures sur des

comportements cycliques

Les métriques IPPM : EDF

 EDF = Empirical distribution function

 EDF est la fonction F(x) qui indique la proportion de mesures dont la valeur est inférieure ou égale à x

 Si on a l'échantillon des 6 mesures suivantes : -2, 7, 7, 4, 18, -5 Alors :

 F(-8) = 0

 F(-5) = 1/6

 F(-5.0001) = 0

 F(-4.999) = 1/6

 F(7) = 5/6

 F(18) = 1

Les métriques IPPM : percentile

 X

percentile = plus petite valeur p de l'échantillon telle que F(p)

>= X%

Exemple :

-2, 7, 7, 4, 18, -5 Alors :

 50^th percentile = 4 → F(4) = 3/6 = 50%

 25^th percentile = -2 → F(-5) = 1/6 < 25% et F(-2) = 2/6 >= 25%

 100^th percentile = 18

 0^th percentile is ∞

Les métriques IPPM : Type-P

 Introduction de la notion du Type-P

 La plupart les métriques d'Internet sont dépendantes du type de paquet utilisé (protocole, taille, ports src/dst)

 Quand une métrique dépend du type de paquet utilisé, son nom doit contenir l'expression Type-P pour la rendre générique

 Un métriques générique n'est pas directement utilisable

 Pour faire une mesure, il faut d'abord spécifier plus précisément le type de paquet qui sera utilisé :

générique → spécifique

type-P-metric → TCP-src1550-dst80-size800-metric

Les métriques

IPPM NMWG

Connectivity

Network Capacity

One-way Packet Duplication

Packet Reordering Delay

Variation One-way Packet Loss

One-way Delay

Les métriques IPPM : les métriques définies

 Framework for IP Performance Metrics : RFC 2330

 IPPM Metrics for Measuring Connectivity : RFC 2678 (2498)

 A One-way Delay Metric for IPPM : RFC 2679

 A One-way Packet Loss Metric for IPPM : RFC 2680

 One-way Loss Pattern Sample Metrics (RFC 3357)

 A Round-trip Delay Metric for IPPM : RFC 2681

 IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) : RFC 3393

 Packet Reordering Metric for IPPM: RFC 4737

Les métriques IPPM : les RFC compagnons

 A Framework for Defining Empirical Bulk Transfer Capacity Metrics : RFC 3148

 Network performance measurement for periodic streams : RFC 3432

 A One-way Active Measurement Protocol Requirements : RFC 3763

 IP Performance Metrics (IPPM) metrics registry : RFC 4148

 A One-way Active Measurement Protocol

(OWAMP) : RFC 4656

Les métriques IPPM : drafts en cours

 Defining Network Capacity (draft-ietf-ippm-bw-capacity-05 → 1/12/2007)

 A Two-way Active Measurement Protocol (TWAMP) (draft-ietf-ippm- twamp-04 → 11/2007)

 IP Performance Metrics (IPPM) for spatial and multicast (draft-ietf- ippm-multimetrics-04 → 7/1/2008)

 Spatial Composition of Metrics (draft-ietf-ippm-spatial-composition-04

→ 8/1/2008)

 Framework for Metric Composition (draft-ietf-ippm-framework- compagg-04 → 8/1/2007)

 A One-Way Packet Duplication Metric for IPPM (draft-ietf-ippm-

duplicate-02.txt → 7/2/2008)

 La mesure dont l'utilité est la plus évidente : est-ce qu'un paquet partant d'une machine A est reçu de la machine B ?

 Mais quand on y réfléchit bien, cette notion n'est pas si simple à décrire que ça :

– Parle-t-on de connectivité instantanée ? – De connectivité sur une période de temps – Unidirectionnelle ou bi-directionnelle ? – Pour quel type de paquets ?

Les métriques IPPM :

Connectivité 1/5

Les métriques IPPM : Connectivité 2/5

 Type-P-Instantaneous-Unidirectional-Connectivity(Src, Dst, T) = Booléen

– Src et Dst ont une connectivité à sens unique instantanée de type-P à l'instant T si un paquet de type-P transmis de Src à l'instant T arrive à Dst

– Singleton

 Type-P-Instantaneous-Bidirectional-Connectivity(A1, A2, T) = Booléen

– A1 et A2 ont une connectivité bi-directionnelle instantanée de type-P à l'instant T si un paquet de type-P transmis de A1 à l'instant T arrive à A2 et si un paquet de type-P transmis de A2 à T+dT arrive à A1

– dT est le temps de transit d'un paquet de type-P de A1 vers A2

Les métriques IPPM : Connectivité 3/5

 Type-P-Interval-Unidirectional-Connectivity(Src, Dst, T, dT) = Booléen

– Singleton

 Type-P-Interval-Bidirectional-Connectivity(A1, A2, T, dT) = Booléen

– Singleton

➔

Pour les deux métriques ci-dessus il suffit que la métrique instantanée correspondante soit vraie pour un seul instant dans l'intervalle [T, T+dT] pour que la métrique soit vraie

➔

Pas très utile dans les faits d'avoir le même type de paquets dans

les deux sens...

Les métriques IPPM : Connectivité 4/5

 Type-P1-P2-Interval-Temporal-Connectivity(Src, Dst, T, dT) = Booléen

– Sample

– Pour N instants T1 répartis selon une loi de Poisson dans l'intervalle [T, T+dT], s'il existe au moins un T1 tel que :

• Src a une connectivité unidirectionnelle instantanée de type-P1 avec Dst à l'instant T1

• Dst a une connectivité unidirectionnelle instantanée de type-P2 avec Src à l'instant T1+dT1 où dT1 est le temps de transit entre Src & Dst pour un paquet de type P1

➔ Alors il y a une connectivité bi-directionnelle de type-P1-P2 entre Src et Dst dans l'intervalle [T, dT]

Exemple de mesure de connectivité 5/5

 TCP-port-N1-port-N2-Interval-Temporal-Connectivity(A1, A2, T, dT)

– Envoi par A1 d'un paquet SYN vers A2

– Réception par A1 d'un paquet SYN-ACK en provenance de A2 ⇒ VRAI

– Réception par A1 d'un paquet RST en provenance de A2 ⇒ VRAI

– Réception par A1 d'un paquet ICMP Port unreachable en provenance de A2 ⇒ VRAI

– Réception par A1 d'un paquet ICMP host unreachable ou

network unreachable en retour du paquet aller ⇒ FAUX

Les Métriques IPPM : OWD 1/6

 Définition d'un Type-P-One-Way-Delay générique

– Le temps de transit entre deux machines peut varier en fonction du type de paquets

– Par exemple, ICMP est considéré comme moins prioritaire que TCP par les routeurs, plus susceptible d'être retardé en file d'attente.

 Le temps de transit impacte énormément les applications temps-réel

 Des temps de transit importants impactent fortement la bande passante des applications TCP (bandwidth delay product, à taille égale de RWIN, plus le temps de transit est important, plus la bande passante est faible)

Bandwidth Delay Product = OWD x Bandwidth = nombre de bits en transit sur le média

La borne inférieure du One-Way Delay est la somme des temps de propagation et de sérialisation le long du chemin

Les valeurs de cette métrique au-dessus de la borne inférieure donnent une indication de la charge du chemin

 Le calcul du OWD nécessite une grande précision dans la synchronisation des horloges

Les Métriques IPPM :

OWD 2/6

 Le OWD donne une indication plus fine que le Round Trip Delay

– Routage asymétrique

– Il peut y avoir du queuing asymétrique (charge des liens différentes dans un sens et dans l'autre)

– La performance d'une application peut être impactée par le temps de transit dans un sens, pas par celui dans l’autre (Transfert sur TCP)

– Dans un réseau avec de la qualité de service, les marquages ne sont pas forcément symétriques

Les Métriques IPPM :

OWD 3/6

 Type-P-One-way-Delay(Src, Dst, T) = dT

– T = wire time émission

– T+dT = wire time réception

 Singleton

 Si le paquet est dupliqué sur le chemin, dT est calculé au wire time de l'arrivée du premier paquet

 Si le paquet est fragmenté et non réassemblé, il est estimé perdu

 Une synchronisation GPS est souhaitable pour calculer cette métrique

Les Métriques IPPM :

OWD 4/6

 Type-P-One-way-Delay-Poisson-Stream(Src, Dst, T

, T

, ) = ({T

, dT

}, {T

, dT

}, ..., {T

, dT

})

– T₀, T₁, ... T_f : générés selon une loi de Poisson T_N-T_N-1 = en moyenne 1/

– Sample

 Type-P-One-way-Delay-Percentile(Stream, X) = dT

– Valeur de dT qui sépare les échantillons en 2 parties (X% et (100-X)%) – Stream₀ = ({T₀, 100ms},{T₁, 110ms},{T₂, indéfini},{T₃, 90ms},{T₄,

500ms} ⇒ TPOWDP(Stream₀, 50%) = 110ms – Statistical

Les Métriques IPPM :

OWD 5/6

 Type-P-One-way-Delay-Median(Stream) = dT

– La valeur médiane de l'échantillon. Diffère du 50ème percentile seulement sur un flux avec un nombre pair d'échantillons (moyenne des deux échantillons du milieu)

– Stream₀ = ({T₀, 100ms},{T₁, 110ms},{T₂, indéfini},{T₃, 90ms},{T₄, 500ms} => TPOWDM(Stream₀) = 105ms ((100+110)/2)

– Statistical

 Type-P-One-way-Delay-Inverse-Percentile(Stream, treshdold) = X %

– Le pourcentage des échantillons dont la valeur dT est <= threshold – Stream₀ = ({T₀, 100ms},{T₁, 110ms},{T₂, indéfini},{T₃, 90ms},{T₄,

500ms} ⇒ TPOWDIP(Stream₀, 100) = 2/5 = 40%

– Statistical

Les Métriques IPPM :

OWD 6/6

Les Métriques IPPM : Round-trip Delay 1/1

 Type-P-Round-trip-Delay(Src, Dst, T) = dT

– T = wire time émission du paquet au départ de Src – T+dT = wire time réception du paquet retour par Src

 Type-P-Round-trip-Delay-Poisson-Stream(Src, Dst, T

, T

, )

 Type-P-Round-trip-Delay-Percentile(Stream, X%) = dT

 Type-P-Round-trip-Delay-Median(Stream) = dT

 Type-P-Round-trip-Delay-Minimum(Stream) = min(dT)

 Type-P-Round-trip-Delay-Inverse-Percentile(Stream, dT) = X%

Les Métriques IPPM : One-way Packet Loss 1/3

 La métrique One-way Packet Loss est plus précise que le Round Trip Packet Loss, le chemin aller n'est pas forcément le même que le chemin retour

 Certaines applications sont plus sensibles aux pertes de paquets dans un sens que dans l'autre, les transferts de fichiers, par exemple :

– Données dans un sens, gros volumes de données – ACK dans l'autre sens, quelques paquets seulement

 Queuing asymétrique

 Marquage DSCP asymétrique

 Type-P-One-way-Packet-Loss(Src, Dst, T) {0, 1} ∈

– Singleton

 La synchronisation d'horloge nécessaire entre Src et Dst dépend du seuil déterminé au-delà duquel on estime que le packet est perdu

 Une application Real Time a besoin d'un seuil très bas ⇒ synchronisation fine des horloges nécessaire

Les Métriques IPPM :

One-way Packet Loss 2/3

 Type-P-One-way-Packet-Loss-Poisson-Stream(Src, Dst, T

, T

, )

= ({T

, L

}, {T

, L

}, ..., {T

, L

})

– T₀, T₁, ... T_f : générés selon une loi de Poisson T_N-T_N-1 = en moyenne 1/

– L_N ∈ {0, 1}

– Sample

 Type-P-One-way-Packet-Loss-Average = Avg(L

...L

)

– Stream₁ = ({T₀, 0},{T₁, 1},{T₂, 0},{T₃, 1},{T₄, 0},{T₅, 0},{T₆, 0}) = 0,286 = 28% de pertes

– Statistical

Les Métriques IPPM :

One-way Packet Loss 3/3

Les Métriques IPPM : Delay Variation 1/3

 Type-P-One-way-ipdv(Stream(Src, Dst, I

, I

, ), L, F) = ddT, T

, T

– F : fonction de sélection de deux paquets émis à T₁ et T₂

• Paquets consécutifs

• Délai min et délai max dans l'intervalle

• Paquets envoyés à des indices donnés

• etc

– L : longueur des paquets émis

– Si dT₁ est le OWD(Src, Dst, T₁) et dT₂ = OWD(Src, Dst, T₂) alors ddT = dT₂ – dT₁

– Singleton

 Type-P-One-way-ipdv-Poisson-stream(Stream(Src, Dst, T

, T

,

, L), F) = ({T

, T

, ddT}, {T

, T

, ddT}, ..., {T

, T

, ddT})

– Sample

 Type-P-One-way-ipdv-percentile(IPdv, X%) = ddT

– Type-P-One-way-ipdv-percentile(IPdv, 50%) = médiane – Statistical

 Type-P-One-way-ipdv-inverse-percentile(IPdv, ddT) = X%

– Statistical

Les Métriques IPPM :

Delay Variation 2/3

 Type-P-One-way-ipdv-jitter(Stream(Src, Dst, T

, T

, , L))

– Statistical

– F = sélection des paquets consécutifs – L'estimation du jitter =

– On applique le filtre exponentiel :

 Type-P-One-way-peak-to-peak-ipdv(Stream(Src, Dst, T

, T

, , L))

j

= 15

16 j

 1

16 e  j



e  j _n = ∣ ^ipdv n ∣

Les Métriques IPPM :

Delay Variation 3/3

 Les paquets peuvent arriver dans un ordre différent de l'ordre d'émission

 Par exemple :

– Quand les paquets d'un même flux empruntent des chemins avec des durées différentes d'acheminement des paquets (load balancing, par ex) – Équipements réseaux avec plusieurs processeurs par ports

– Retransmission par un protocole de niveau 2

– Algorithme de gestion de files réordonnançant les paquets

– Assignation de paquets successifs dans des buffers différents avec des taux d'occupation différents

IPPM : Réordonnancement

de paquets 1/11

 Type-P-Reordered(Src, Dst, SrcTime, s, NextExp) = Booléen

– Singleton

SrcTime : Temps d'émission du paquet – s : numéro de séquence

– NextExp : Le numéro de séquence attendu – if s >= NextExp, then /* s est dans l'ordre */

if s > NextExp then

SequenceDiscontinuity = True;

SeqDiscontinuitySize = s - NextExp;

else

SequenceDiscontinuity = False;

NextExp = s + 1;

Type-P-Reordered = False;

else /* quand s < NextExp */

Type-P-Reordered = True;

SequenceDiscontinuity = False;

IPPM : Réordonnancement

de paquets 2/11

 Type-P-Reordered-Ratio-Stream(Src, Dst, T

, T

, K, L) = R

– T₀, T_f temps de début et de fin

– dT = temps de transit max (au-delà de dT, le paquet est déclaré perdu) – K le nombre de paquets envoyés de Src

– L, le nombre de paquets reçus parmi K ⇒ L <= K

– R = le ratio du nombre de paquets réordonnancé par rapport au nombre de paquets reçus :

R=Count Type−P−Reordered=True

L

IPPM : Réordonnancement

de paquets 3/11

 Type-P-Packet-Reordering-Extent-Stream(Src, Dst, T

, T

, K, L)

= { e

, ... e

}

– Les paquets sont numérotés à l'émission 1..K

– Le numéro de séquence de départ du paquet arrivé en position i, avec i ∈ [1, L] est noté s[i] ∈[1, K].

 Si s[i] est réordonnancé, alors il existe des indices j avec 1 <= j <= i tels que s[j] > s[i]

– un ensemble de paquets arrivés avant, mais émis après

 e

= i-j pour j = min(1 <= j <= i tels que s[j] > s[i])

– e

IPPM : Réordonnancement

de paquets 4/11

 Type-P-Packet-Late-Time-Stream(Src, Dst, T

, T

, K, L) = {lT

, ...

lT

}

– On utilise l'horloge de la destination – DstTime(i) = Wire time du paquet i

– Pour tous les paquets avec un reordering extent défini (réordonnancés) – lT_s[i] = DstTime(i) – DstTime(i-e_i)

– Retard du paquet s[i]

IPPM : Réordonnancement

de paquets 5/11

 Type-P-Packet-Byte-Offset-Stream(Src, Dst, T

, T

, K, L) = {bO

, ... bO

}

–

– Décalage en nombre d'octets du paquet s[i] par rapport à la position qu'il aurait du occuper

n

∑

PayloadPaquet n

IPPM : Réordonnancement

de paquets 6/11

 Type-P-Packet-Reordering-Gap-Stream(Src, Dst, T

, T

, K, L) = {G

, ... G

}

 Type-P-Packet-Reordering-GapTime-Stream(Src, Dst, T

, T

, K, L) = {gT

, ... gT

}

– Pour le calcul des GapTime, on utilise l'horloge de la destination

– Écart entre deux discontinuités correspondant à des paquets réordonnés

IPPM : Réordonnancement

de paquets 7/11

 Type-P-Packet-Reordering-Free-Run-x-numruns-Stream(Src, Dst, T₀, T_f, K, L) = x

 Type-P-Packet-Reordering-Free-Run-q-squruns-Stream(Src, Dst, T₀, T_f, K, L) = q

 Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream(Src, Dst, T₀, T_f, K, L) = p

 Type-P-Packet-Reordering-Free-Run-a-accpkts-Stream(Src, Dst, T₀, T_f, K, L) = a

 Dans ces métriques un reordering-free run est une séquence de paquets consécutifs sans réordonnancement

 x, le nombre de run (et aussi le nombre de paquets réordonnancés)

 a, le compteur de paquets dans l'ordre.

 p, le nombre de paquets (quand le flux est complet, p=(x+a)=L).

 q, la somme des carrés des longueurs de run

IPPM : Réordonnancement

de paquets 8/11

 Algorithme :

r = x = a = p = q = 0;

while(des paquets arrivent avec le numéro de séquence s)

{ p++;

if (s >= NextExp) /* s est dans l'ordre */

then r++;

else /* s est réordonnancé */ a++;

q+= r*r;

r = 0;

} x++;

IPPM : Réordonnancement

de paquets 9/11



% de paquets dans l'ordre =

 La longueur moyenne des runs sans réordonnancement :

100 × a p

a x

x, le nombre de run

 a, le compteur de paquets dans l'ordre.

IPPM : Réordonnancement

de paquets 10/11

 q donne une idée de la variation autour de la moyenne :

 q a 

 a x 

=  q × x  a

 x, le nombre de run

 a, le compteur de paquets dans l'ordre.

IPPM : Réordonnancement

de paquets 11/11

Métriques IPPM vs NMWG 1/2

 NMWG = Network Monitoring Working Group de l'Open Grid Forum, cherche à développer un dictionnaire commun de

métriques

• Availability

• Capacity

• Utilization

• Available Bandwidth

• Achievable Bandwidth

• One Way Delay

• Jitter

• Round Trip Delay

• One Way Loss

• Roundtrip Loss

• One-Way Reordering

Connectivity Availability

Pas d’équivalent Available BW

Pas d’équivalent Utilization

Network Capacity Capacity

One-Way and Round Trip _(NMWG) Loss + Loss pattern_(IPPM) Round Trip Delay

One-Way-Delay

IPPM NMWG

Métriques IPPM vs

NMWG 2/2