Mon blog

Tiens, le groupe de travail ippm n'avait pas encore normalisé toutes les métriques possibles ? Il restait encore des indicateurs de performance et de qualité de service qui n'avaient pas de RFC. En voici une nouvelle, le taux de pertes de paquets sur un trajet aller-retour.

La plupart des applications ont besoin d'envoyer et de recevoir des paquets. Un exemple typique est la connexion TCP, qui requiert que le paquet SYN du demandeur soit transmis dans un sens et le SYN+ACK du demandé dans l'autre sens. Sans liaison bidirectionnelle, pas de TCP. Le taux de pertes sur le trajet aller-retour est donc certainement utile. Il est même déjà mis en œuvre dans le protocole TWAMP (Two-way Active Measurement Protocol, RFC 5357) mais sans que la métrique correspondante n'ait été définie proprement, selon les règles du RFC 2330. Notre RFC 6673 comble ce manque (le RFC 7680 définissait la métrique pour le taux de pertes en aller-simple). Attention toutefois en interprétant le résultat : si le taux de pertes aller-retour est plus significatif pour l'utilisateur (plus proche de son problème), il est moins adapté pour le diagnostic car il ne dit pas dans quel sens a eu lieu la perte.

Donc, maintenant, les détails. Suivant le principe du RFC 2330, la métrique est définie pour un certain type de paquets (on n'aura pas forcément le même taux de pertes en UDP et en TCP, par exemple, surtout si l'opérateur viole la neutralité du réseau), le « Type-P ». La section 3.2 donne la liste complète des paramètres de la mesure. À noter le Tmax qui indique le temps maximum pendant lequel on attend la réponse (un paquet peut donc être marqué comme perdu alors qu'il est simplement très en retard). À noter également que la métrique est définie en termes booléens : 0, le paquet arrive, 1, il n'arrive pas.

Première définition (section 4), Type-P-Round-trip-Loss. La source envoie un paquet, la destination répond et la source reçoit la réponse. Si cette réponse arrive avant Tmax, le résultat est 0 (succès) sinon 1 (échec). Naturellement, les problèmes habituels de mesure se posent ici, dont les RFC 7680 et RFC 2681 ont déjà discuté. À noter que la destination doit répondre « le plus vite possible » (une des grosses faiblesses de cette métrique, qui ne dépend pas que du réseau mais également du « réflecteur »). La section 4.4 discute plus en détail ce problème et suggère que la destination réponde en moins d'une seconde, ce qui ne devrait pas être trop difficile (cela suppose que Tmax soit très supérieur à une seconde). Notez aussi que, en l'absence de réponse, on ne peut pas savoir si le paquet a été perdu entre source et destination, ou bien entre destination et source (ou, pourquoi pas, si la destination était défaillante et n'a pas renvoyé le paquet).

Ça, c'était pour un seul paquet. Pour un ensemble de paquets, la section 5 définit Type-P-Round-trip-Loss-<Sample>-Stream. <Sample> doit être remplacé par le type de la distribution des paquets (RFC 3432). Deux exemples typiques : une distribution de Poisson ou une distribution périodique (où les paquets sont simplement envoyés à intervalles réguliers, comme le fait la commande ping, dont l'option -i permet de choisir cet intervalle). Cette grandeur sera un tableau de valeurs logiques, 0 pour le succès et 1 pour l'échec.

On pourra ensuite dériver de ce tableau des statistiques comme Type-P-Round-trip-Loss-<Sample>-Ratio (section 6), qui est la moyenne du tableau (« X % des paquets ont été perdus »). Notez que, sur des vrais réseaux de bonne qualité (qui perdent peu de paquets), il faudra envoyer des dizaines de milliers de paquets pour mesurer le taux de pertes de manière significative.

Comment mesure-t-on en pratique ces grandeurs ? La section 8 donne quelques indications. Par exemple, il aura fallu configurer les deux machines pour envoyer et recevoir (pour la source) et réfléchir (pour la destination) les paquets du Type-P choisi (qui peut être ICMP, auquel toutes les machines TCP/IP doivent répondre, mais pas forcément). Le protocole TWAMP du RFC 5357 peut être utilisé pour cela. La machine de destination ne doit pas, autant que possible, être elle-même une cause de perte de paquets et doit donc avoir notamment des tampons suffisamment larges.

Il faut aussi se préoccuper de sécurité (section 9) : comme il s'agit de mesures actives, il faut faire attention à ne pas écrouler le réseau sous la charge (option -f de ping...) Et, lorsqu'on mesure sur un vrai réseau, il faut se rappeler que des décisions de l'opérateur (par exemple de prioritiser certains flux) peuvent fausser la mesure (c'est une des raisons pour lesquelles il est essentiel de publier le Type-P utilisé par exemple « Ces tests ont été faits avec des paquets TCP SYN, port de destination 80 »).

Et les implémentations ? Le célèbre logiciel ping mesure et affiche un taux de pertes aller-retour, sans toutefois suivre rigoureusement la définition de notre RFC. Voici un exemple (la Freebox étant tombée en panne pendant la mesure, ce qui explique le taux élevé de 34 % de pertes) :

% ping -i 0.2 ns2.nic.fr
...
--- ns2.nic.fr ping statistics ---
9085 packets transmitted, 5981 received, +128 errors, 34% packet loss, time 1843752ms
rtt min/avg/max/mdev = 25.068/27.514/156.796/3.477 ms, pipe 3

ping est toutefois très limité : il n'utilise qu'un seul protocole, ICMP, qui peut être filtré ou limité en débit. Autrement, toutes les implémentations de TWAMP mesurent le taux de pertes aller-retour d'une manière compatible avec ce RFC. Même chose pour Cisco IP-SLA. L'auteur du RFC note que son employeur, AT&T, a mille points de mesure TWAMP, mille points IP-SLA et mesure ce taux de pertes cent mille fois par jour (chaque point mesure toutes les quinze minutes).