Résumé

  • RFC 3133 mesurait séparément les octets utiles et les trames livrés, dans un seul sens et sur une seule connexion virtuelle Frame Relay, en distinguant la charge engagée du trafic excédentaire.
  • Le texte avertissait qu’un petit accusé de réception perdu pouvait provoquer de nombreuses retransmissions : le calcul restait exact, mais ne suffisait pas à décrire la performance de l’application.

Le cadre était vert, la transaction ne l’était pas

Le paradoxe tient dans une asymétrie. Une application envoie beaucoup de grandes trames de données. Dans l’autre sens revient une petite trame d’acquittement. Si presque toutes les données passent mais que cet acquittement disparaît, le nombre d’octets livrés reste excellent. Le nombre de trames livrées aussi. Pourtant, l’émetteur peut attendre, expirer son temporisateur et répéter une partie importante du transfert.

RFC 3133 ne présentait pas cette scène comme une attaque contre la mesure. Il l’inscrivait dans la discussion de deux indicateurs, le Data Delivery Ratio et le Frame Delivery Ratio. Le texte disait que ces taux pouvaient ne pas représenter l’efficacité de livraison ressentie par une application. Un bon résultat pouvait donc coexister avec une mauvaise performance pour l’utilisateur.

La formule n’était pas fausse. Elle répondait à sa question : combien d’octets utiles, ou combien de trames, avaient franchi une frontière déterminée ? L’application posait une autre question : le message de contrôle dont dépendait la suite avait-il été reçu à temps ? Le passage de l’une à l’autre exigeait une preuve supplémentaire.

Avant de compter, il fallait nommer le contrat

Dans un réseau Frame Relay, le débit physique n’était pas à lui seul le service acheté. Le canal d’accès donnait la vitesse maximale à laquelle un équipement pouvait injecter des données. Mais cette vitesse pouvait dépasser ce que le contrat engageait réellement à transporter.

Le Committed Information Rate, CIR, exprimait le débit que le réseau devait maintenir entre deux sites quand des données étaient présentées. La taille de rafale engagée, Bc, fixait la quantité de bits promise dans l’intervalle Tc. Be désignait la rafale excédentaire que le réseau pouvait tenter d’acheminer, avec une probabilité plus faible.

Tc n’était pas un créneau périodique qui s’ouvrait à heure fixe. RFC 3133 le décrivait comme une fenêtre glissante déclenchée par l’arrivée des données et calculée à partir de Bc et du CIR. Il fallait donc connaître le rythme d’émission, et pas seulement lire la vitesse du port, pour déterminer ce qui appartenait au contrat.

Le bit DE indiquait qu’une trame était éligible à l’abandon en cas de congestion. Il n’attestait pas qu’elle avait été abandonnée. Le document opposait clairement discardable et discarded. Une trame marquée pouvait être livrée si la congestion se dissipait. Une trame sans ce bit pouvait devenir sacrifiable à cause d’une politique appliquée au circuit virtuel ou à des critères de couche supérieure. Une trame erronée pouvait, elle, être rejetée pour protéger l’intégrité du flux.

Ce vocabulaire séparait l’intention de l’événement. Être moins prioritaire, être classé hors engagement, être corrompu et être effectivement perdu n’étaient pas quatre noms pour le même fait.

Un sens, une connexion virtuelle, une population

RFC 3133 reprenait le format de définition de RFC 1242. Il distinguait aussi les documents de terminologie, qui nomment les grandeurs, des documents de méthodologie, qui décrivent comment les recueillir. Une formule ne valait donc pas à elle seule protocole de test complet.

Le DDR rapportait les octets de charge utile livrés aux octets de charge utile proposés. L’adresse et le FCS n’entraient pas dans cette charge. Le taux de livraison des trames comparait, lui, les trames reçues avec les tentatives d’émission. Dans les deux cas, le périmètre était un seul sens d’une seule connexion virtuelle.

Un lien duplex possédait par conséquent deux ensembles d’indicateurs. Le bon résultat du chemin aller n’effaçait pas le mauvais résultat du retour. C’est précisément sur le retour que pouvait circuler l’accusé dont dépendait la progression du transfert.

Le texte séparait en outre la part engagée de la part excédentaire. DDR_c portait sur les données situées dans le CIR ; DDR_e sur l’excédent. Leur agrégation pouvait être correcte tout en masquant une différence importante entre ce que le réseau avait promis et ce qu’il avait transporté à titre opportuniste.

Chaque taux constituait donc une juridiction étroite. Il fallait donner le DLCI ou la connexion virtuelle, la direction, l’intervalle, les points d’observation, le type de charge, la longueur des trames et la définition exacte de la population. Sans cela, le pourcentage avait une apparence de précision mais pas de portée vérifiable.

L’importance d’une trame ne se mesure pas à sa longueur

L’exemple de l’acquittement révèle une limite commune aux deux unités. Un taux par octets donne davantage de poids aux grandes trames. Un taux par trames donne le même poids à une trame de contrôle et à une trame de données. Aucun ne mémorise la fonction causale de l’acquittement.

Ce petit message peut libérer une fenêtre d’envoi, confirmer une progression, éviter une expiration ou supprimer la nécessité d’une retransmission. Sa valeur pour le système ne vient pas de son nombre d’octets. Elle vient de l’état qu’il permet de changer.

On pourrait construire un exemple où une seule trame perdue sur mille laisse un taux de 99,9 %. Mais RFC 3133 ne publiait pas un tel essai et il serait trompeur de transformer cette illustration en résultat historique. Le point démontré est plus sobre : la perte d’un petit acquittement peut entraîner la retransmission de nombreuses trames de données. Le nombre précis dépend du transport, de la fenêtre, des temporisateurs et de la suite des acquittements.

La conclusion n’est donc pas « un taux élevé cache toujours un échec ». C’est « un taux élevé ne prouve pas la réussite applicative ». La preuve de cette réussite doit conserver l’état de transport, les retransmissions, le temps d’achèvement et le résultat visible.

La moyenne du délai ne comptait que les survivantes

Le même problème de population apparaît dans le Frame Transfer Delay. RFC 3133 fixait deux événements précis : la première partie de la trame qui quitte un point, puis la fin de la trame qui entre au point suivant. La moyenne était calculée pour les trames reçues.

Les trames émises pendant la période mais jamais reçues n’entraient pas dans ce délai moyen. Cette convention est cohérente, mais elle oblige à lire le délai avec la perte. Une moyenne basse peut décrire uniquement les survivantes, tandis que les éléments absents portent la conséquence la plus grave.

La variation de délai utilisait l’écart entre le maximum et le minimum observés. Le RFC expliquait qu’une forte variation pouvait perturber le calcul du temps aller-retour de TCP et son débit. Il mentionnait aussi les effets d’un délai excessif sur la voix sur IP. Ce sont des relations techniques, pas des mesures d’un réseau nommé.

Toutes les trames abandonnées n’avaient pas la même histoire

Le document énumérait des erreurs pouvant justifier un rejet : longueur invalide, nombre de bits incorrect, DLCI inconnu, séquence d’abandon, délimitation fautive ou échec du FCS. Dans ce cas, ne pas transmettre une trame corrompue pouvait améliorer le comportement par rapport à sa propagation.

Cette observation empêche d’utiliser un compteur d’abandons comme verdict unique. Une police de trafic qui retire une charge hors contrat, une priorité qui choisit une victime pendant la congestion et un contrôle d’intégrité qui bloque une trame illisible ne racontent pas la même décision. Ils peuvent tous provoquer une récupération à un niveau supérieur, mais n’appellent ni la même correction ni la même responsabilité.

Un dossier sérieux doit donc conserver la cause, et pas seulement le total. Où la trame a-t-elle été vue pour la dernière fois ? Était-elle engagée ou excédentaire ? Le bit DE était-il positionné ? Quelle règle l’a classée ? A-t-elle été rejetée pour erreur ? L’acquittement inverse a-t-il manqué ? Le transport a-t-il retransmis ? L’application a-t-elle finalement terminé ?

Un dictionnaire technique, pas un palmarès

Publié en juin 2001, RFC 3133 était un document Informational du Benchmarking Methodology Working Group. Il étendait les termes de RFC 1242, RFC 1944 et RFC 2285 et mobilisait des notions du Frame Relay Forum et de la MIB Frame Relay.

Il ne comparait aucun produit. Il ne démontrait pas qu’un opérateur exposait tous ces compteurs, qu’un contrat les utilisait correctement ou qu’une application avait obtenu une qualité donnée. Le dernier Internet-Draft montre l’histoire éditoriale du texte, pas l’adoption de ses indicateurs.

Les RFC voisines ont d’autres rôles. RFC 1944, RFC 2544 et RFC 2889 portent sur des méthodologies. RFC 2761 traite des mesures ATM utiles au contexte d’interfonctionnement. RFC 2954 définit des objets gérés pour le service Frame Relay. RFC 6349, plus tardif, encadre des essais de débit TCP. Aucun ne transforme les définitions de RFC 3133 en résultat de production.

Ce qui reste est une discipline de preuve. Le taux doit être conservé parce qu’il décrit bien sa population. Mais il faut lui interdire de parler à la place du transport, de l’application ou de l’utilisateur.

La mesure gagne en crédibilité lorsqu’elle s’arrête

Un enregistrement exploitable conserverait le canal et son débit, le DLCI, la direction, l’intervalle, CIR, Bc, Be et Tc, les octets et trames proposés et livrés, les composantes engagées et excédentaires, le bit DE, la règle de police, l’erreur éventuelle, la raison d’abandon et les points exacts de mesure.

Puis il ouvrirait un second dossier : quel message de contrôle a manqué, quel état du transport en dépendait, combien de trames ou d’octets ont été retransmis, quel événement a déclenché la reprise et combien de temps l’opération a duré. Enfin, un troisième dossier dirait si l’application a accompli son travail et ce que l’utilisateur a constaté.

Ces étages ne doivent pas être remplis par déduction automatique. Le DDR prouve un rapport entre octets utiles. Le taux de trames prouve un rapport entre trames. Ils ne prouvent ni l’achèvement, ni la satisfaction du contrat, ni l’expérience humaine.

L’époque de Frame Relay paraît lointaine, mais son piège statistique ne l’est pas. Les organisations continuent de choisir l’indicateur le plus facile à agréger, puis d'oublier ce qu’il ne voyait pas. RFC 3133 offre un antidote : garder le nombre, garder son périmètre, et exiger une autre preuve avant de déclarer le service bon.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3133.txt
  2. https://www.rfc-editor.org/info/rfc3133
  3. https://www.rfc-editor.org/rfc/rfc3133.html
  4. https://www.rfc-editor.org/rfc/rfc1242.html
  5. https://www.rfc-editor.org/rfc/rfc1944.html
  6. https://www.rfc-editor.org/rfc/rfc2285.html
  7. https://www.rfc-editor.org/rfc/rfc2544.html
  8. https://www.rfc-editor.org/rfc/rfc2761.html
  9. https://www.rfc-editor.org/rfc/rfc2889.html
  10. https://www.rfc-editor.org/rfc/rfc2954.html
  11. https://www.rfc-editor.org/rfc/rfc6349.html
  12. https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-fr-term-06