Mon blog

Le RFC 3393 normalise une métrique de variation du délai d'acheminement des paquets. Cette métrique est assez souple pour que, en pratique, plusieurs formules aient été utilisées. Ce RFC en discute deux et précise leur usage.

Souvent, le délai moyen d'acheminement d'un paquet (ce que peut mesurer, dans une certaine mesure, la commande ping) n'est pas la seule métrique de délai intéressante. Il est souvent utile de connaître la variation de ce délai d'acheminement. Les applications « temps-réel » par exemple en vidéo sont en effet très sensible à la gigue, c'est-à-dire à cette variation, par exemple parce qu'elle va nécessiter de stocker les données dans un tampon, avant de commencer leur affichage, pour garantir que celui-ci reste lisse pendant toute la session (voir le RFC 3550 et la section 3 de notre RFC 5481). Outre le RFC 3393, cette gigue fait l'objet de la norme ITU Y.1540. En anglais, le mot jitter (gigue) est souvent utilisé mais le RFC préfère « variation de délai ».

Cette variation se mesure par rapport au délai d'acheminement d'un paquet (métrique définie dans le RFC 7679). Comme le rappelle la section 1, il y a deux grandes formulations possibles pour la variation de délai :

• Variation entre paquets ou IPDV (Inter-Packet Delay Variation), où on mesure par rapport au paquet précédent. C'est celle qui est utilisée dans le RFC 3550.
• Variation par rapport à un paquet ou PDV (Packet Delay Variation), où on mesure par rapport à un paquet donné, en général celui avec le plus petit délai de voyage.

Toutes les deux sont compatibles avec le RFC 3393.

La section 3 détaille les usages qui sont raisonnables pour cette métrique. Par exemple, la section 3.2 discute des « tampons de suppression de gigue », ces structures de données où les applications audio et vidéo gardent les données, pour compenser les variations du réseau. Les formules pour calculer leur taille optimale dépendent de la variation de délai d'acheminement. Ou bien la section 3.4 explique que cette variation peut être pertinente pour comparer les offres de deux opérateurs et qu'elle peut même faire l'objet d'un SLA.

Enfin la section 4 donne les définitions exactes pour les deux formules, IPDV et PDV. IPDV est en 4.1 et se définit simplement comme la différence entre le délai d'acheminement du paquet i et celui du paquet i-1 (l'IPDV peut donc être négatif). PDV, en section 4.2, est défini comme la différence entre le délai d'acheminement du paquet i et celui du paquet au délai le plus faible. Il est donc toujours positif (ou nul). (La section 12 revient sur le calcul de ce délai minimum, par rapport auquel tout est mesuré.)

Pour les érudits, la section 5 détaille la littérature existante sur la question et les comparaisons déjà faites entre IPDV et PDV. Ces comparaisons ont utiles pour estimer la « meilleure » formule pour un problème donné.

Le point de vue des auteurs du RFC est en section 7, consacrée à l'étude de l'applicabilité de chaque formule à divers problèmes. Ainsi, la question de la taille des tampons de suppression de gigue, en section 7.1.2 est tranchée en faveur de PDV, car le tampon est calculé pour que le paquet de délai maximum n'attende pas et que le paquet de délai minimum attende pendant toute la longueur du tampon. Même chose si on est en présence de nombreuses pertes de paquets (section 7.2.3) : IPDV se comporte mal dans ce cas car chaque perte fait aussi perdre la mesure qui aurait pu être faite au paquet suivant. Par contre, si on désire utiliser la variation de délai pour mesurer des changements de route sur le réseau, IPDV est préféré, pour les raisons expliquées en section 7.2.2 (meilleure isolation des effets de chaque changement).

La section 8 couvre les problèmes pratiques que pose la mesure. Par exemple, comme notre métrique est dérivée d'une métrique uni-directionnelle, la synchronisation des horloges des machines est cruciale. C'est ce qu'explique la section 8.5, qui recommande le GPS et déconseille NTP.

Pour mesurer la gigue avec du logiciel libre, voir le bon article de NicoLargo.