Résumé

  • La RFC 1363 proposait une fiche par sens de circulation pour demander au réseau un service adapté, par exemple à une conférence multimédia. Son champ de délai exprimait une préférence : il ne fixait pas une limite absolue.
  • Le réseau devait distinguer une indication, un service prédit, une garantie imparfaite et une garantie ferme. Une liaison Ethernet pouvait bien fonctionner un jour et saturer le suivant ; les deux promesses n’avaient donc pas la même portée.

« 100 millisecondes » a l’air d’une réponse précise jusqu’au moment où l’on demande entre quels points. Craig Partridge posait ce problème dans la RFC 1363, publiée en septembre 1992 : cent millisecondes entre les États-Unis et le Japon pouvaient satisfaire une application, alors que la même attente à l’intérieur d’une ville pouvait l’irriter. Ce sont des exemples de raisonnement, pas des mesures prises sur deux lignes. Ils suffisent à faire tomber l’idée qu’un logiciel connaîtrait, avant de voir le trajet, le délai maximal acceptable pour tout appel.

Le document cherchait à préparer des communications distribuées exigeantes : visioconférence, visualisation et autres applications auxquelles la livraison ordinaire ne garantissait ni rythme ni qualité. L’hôte pouvait négocier avec le réseau avant d’émettre, pendant l’établissement ou alors que les données circulaient déjà. Partridge ne choisissait pas la procédure de négociation ; il définissait les informations qu’un hôte devait apporter pour qu’une réponse ait un sens.

Le champ Minimum Delay Noticed donnait au réseau le point à partir duquel réduire encore le délai n’apporterait plus grand-chose. C’était une instruction sur l’effort utile, pas une échéance de livraison. La géographie était souvent inconnue du réseau et les terminaux mobiles compliquaient le calcul. Partridge contestait aussi la règle commode selon laquelle une conversation deviendrait impossible passé 100 millisecondes. Un échange retardé de plusieurs secondes restait possible ; une personne pouvait le préférer à une communication refusée pour avoir manqué une cible arbitraire.

Avant même de parler de délai, l’application devait décrire ce qu’elle allait injecter : débit soutenable par seau à jetons, débit maximal et taille approximative des rafales. Un routeur cherchant un chemin a besoin de cette charge. La RFC prend l’exemple d’un flux supérieur à 10 mégabits par seconde : une liaison T1 de 1,5 mégabit par seconde ne saurait le porter. L’exigence de délai la mieux formulée ne change pas la capacité physique.

À l’autre extrémité, les paquets ne gardent pas toujours le rythme de leur départ. Les files d’attente les décalent ; le récepteur doit parfois les retenir pour retrouver la cadence d’une voix. La variation de délai demandée dans la fiche représentait la place que ce récepteur consentait à consacrer au tampon. Partridge reliait dans son calcul l’étendue des retards au débit du flux. La tolérance aux pertes avait deux formes supplémentaires : combien de paquets pouvaient manquer dans un intervalle, et combien pouvaient disparaître d’affilée. Une moyenne rassurante ne raconte pas la seconde histoire.

Reste à nommer ce que le réseau promet. Le champ Quality of Guarantee séparait une simple indication, une garantie imparfaite, un service prédit et une garantie ferme. L’exemple de l’Ethernet final était décisif. Partridge rappelait des expériences de conférence de l’IETF où ce type de liaison donnait souvent un résultat acceptable ; il pouvait malgré tout saturer pendant l’appel. Une route comportant cet îlot d’incertitude n’offrait pas la même assurance qu’un parcours contrôlé à chaque saut. Le service prédit relevait encore d’un autre calcul : des équipements coopérants pouvaient admettre une légère dégradation sous charge, tandis qu’une liaison qui ne coopérait pas risquait de casser la promesse sans borne statistique.

Pour une garantie demandée fermement, la réponse attendue était oui ou non. L’application annonçait le minimum qu’elle pouvait accepter ; le réseau cherchait un chemin qui le tenait, ou refusait. Partridge ne voulait pas transformer le début de chaque appel en marchandage prolongé sur tous les chemins possibles. Une fiche renvoyée après refus pouvait suggérer une configuration plus plausible, sans devenir une offre déjà garantie.

La proposition de 1992 était un langage de demande, et non un mécanisme de réservation déployé. Son intérêt demeure dans la facture qu’elle obligeait chacun à présenter : l’application déclarait sa charge et ses seuils ; le réseau devait dire de quelle garantie il parlait et où elle pouvait céder. Cent millisecondes sans trajet, sans tampon et sans type de promesse restaient un chiffre séduisant sur un formulaire.

Sources : RFC 1363, A Proposed Flow Specification ; fiche officielle de la RFC 1363.