Résumé

  • La RFC 1046 proposait de limiter la file « faible délai » afin de borner l'attente des datagrammes acceptés. Le débordement entraînait une perte, et la part de lien de la classe restait plafonnée pour ne pas étouffer les autres trafics.
  • Plusieurs bits TOS n'additionnaient pas plusieurs garanties. En période de contention, ils formaient un choix OR : un seul traitement immédiat, avec éventuellement un repli qui pouvait sauver l'admission tout en augmentant le désordre et la variabilité.

Imaginons que cinq places seulement restent disponibles dans une salle d'attente. Le sixième arrivant ne peut pas être servi rapidement en agrandissant magiquement la pièce ; il faut le refuser ou changer la promesse. C'est ce mécanisme que la RFC 1046 rendait explicite pour une sortie IP encombrée.

Le texte de W. Prue et J. Postel, daté de février 1988, se présentait comme un idea paper. Il cherchait à traduire les indications de Type of Service du paquet en décisions de file d'attente. Il ne relatait pas un déploiement général et laissait ouvertes les valeurs déterminantes. Son intérêt historique vient précisément de là : la qualité de service y apparaît comme une allocation contestable de délai, de pertes et de temps de transmission.

Le problème n'existait qu'au moment de choisir

La RFC 791 avait défini dans IPv4 des niveaux de précédence et trois préférences : faible délai, fort débit, grande fiabilité. Elle avertissait déjà qu'il s'agissait d'un compromis. Une amélioration sur un axe pouvait se payer sur un autre.

La RFC 1046 ajoutait une hypothèse décisive : la demande dépasse la capacité disponible. Sans accumulation notable, une discipline spéciale ne sert à rien. Le champ du paquet ne crée donc pas le conflit ; il donne au routeur une information au moment où le routeur doit répartir des ressources finies.

Cette différence sépare le signal de son effet. Une capture prouve que le bit a été transporté. Elle ne prouve pas que le nœud possédait plusieurs files, qu'il a admis le datagramme dans la bonne, ni que le délai observé venait de cette décision.

La borne résidait dans trois paramètres locaux

Le service à faible délai devait offrir un Maximum Guaranteed Delay par nœud, à condition que le datagramme traverse effectivement l'Internet. Il ne s'agissait ni d'un délai aller-retour ni d'une promesse de livraison. La classe était unidirectionnelle : une réponse ou un acquittement pouvait demander un autre traitement.

La RFC donnait la relation suivante :

Délai maximal = N / (P × R)

N désigne la taille de la file, P la part des ressources du lien affectée à la classe et R le débit du lien en datagrammes par seconde. Pour conserver la même borne avec moins de débit ou une part plus faible, il faut réduire N. Le délai propre d'une liaison, notamment satellitaire, pouvait encore diminuer le budget disponible pour l'attente.

Autrement dit, le paquet ne portait pas sa garantie. Celle-ci dépendait d'une configuration vérifiable et de conditions physiques : profondeur, ordonnanceur, allocation et vitesse.

Le débordement était le prix, pas une anomalie

La petite file devait être servie à un rythme suffisamment limité pour que la classe ne consomme pas des ressources excessives. Une fois sa capacité atteinte, les nouveaux datagrammes étaient abandonnés. La file évoluant trop vite pour que Source Quench soit utile, le mécanisme n'était pas recommandé pour cette classe dans la proposition de base.

La classe « grande fiabilité » faisait l'inverse. Sa file plus longue conservait davantage de paquets en période de congestion, envoyait Source Quench plus tôt et n'abandonnait qu'à saturation. Elle obtenait donc une meilleure résistance à la congestion en acceptant une attente potentiellement plus longue. La RFC prenait soin de ne pas étendre ce résultat aux liaisons à fort taux d'erreur ou à la correction d'erreurs.

Le fort débit recevait dans l'exemple la fréquence de service la plus élevée et une file plus vaste. Cela augmentait son délai moyen au nœud. Même l'idée de grouper un burst était donnée avec réserve, car elle pouvait supposer à tort le comportement du protocole supérieur.

Ces classes distribuaient des inconvénients différents. Le faible délai n'était pas la version premium de la fiabilité et du débit ; il en abandonnait une partie.

« Ou » signifiait qu'une décision ne pouvait en être trois

Lorsque plusieurs services étaient demandés, l'algorithme devait lire OR, et non AND. En l'absence de concurrence, les résultats pouvaient coïncider. Sous charge, un datagramme ne pouvait occuper qu'une file à la fois.

La proposition privilégiait d'abord le faible délai, puis le fort débit, puis la grande fiabilité. Si la première file était pleine, un datagramme demandant aussi la fiabilité pouvait être admis dans la seconde. Ce repli augmentait ses chances de survivre, mais changeait la nature du service.

Dans une même séquence, certains paquets pouvaient passer par la file courte et d'autres par une file plus lente. Les rythmes différents créaient alors du réordonnancement et une variation du délai aller. Le destinataire voyait encore les mêmes demandes dans les en-têtes ; il ne voyait pas le chemin de décisions qui les avait réalisées.

La priorité recevait une limite locale

Les huit niveaux de précédence ajoutaient une autre compétition. Un paquet plus prioritaire pouvait prendre place devant un paquet moins prioritaire dans la file de sa classe. Pour empêcher la famine, la RFC imaginait des points de frustration : chaque dépassement renforçait localement le paquet qui attendait, jusqu'à ce qu'il ne puisse plus être repoussé de la même manière.

Cette priorité corrigée n'était pas propagée au saut suivant. Elle ne permettait pas non plus d'éjecter un paquet déjà admis : si la file était pleine, le nouvel arrivant était abandonné, quelle que soit sa précédence.

L'effet sur la borne était considérable. Dans l'exemple du document, un paquet faible délai sans priorité élevée correspondante pouvait attendre jusqu'à 28 fois la valeur calculée sans cette discipline. Un tableau de bord qui conserve la demande mais oublie les préemptions décrit une promesse qui n'a jamais existé seule.

Les pourcentages restaient des décisions d'exploitation

La répartition illustrative — 17 % pour le faible délai, 50 % pour le débit, 33 % pour la fiabilité — n'était pas une norme. Un système de jetons proportionnels devait éviter qu'une classe toujours pleine ne bloque les autres et permettre un ajustement d'après les compteurs réels.

La section finale posait encore les questions essentielles : quel MGD choisir ? quelles parts de bande passante ? comment limiter l'usage des classes désirables et des fortes priorités ? faut-il compliquer le routage ? quelles simulations sont nécessaires ? La marque n'apportait aucune de ces réponses.

L'opérateur devait notamment compter la file réellement utilisée pour une demande multiple. Cette exigence empêche de mesurer la demande comme si elle était déjà un service rendu.

La suite de l'histoire interdit de transformer l'essai en doctrine actuelle

La RFC 1349 qualifia plus tard le TOS de mécanisme strictement consultatif, impropre à demander une garantie. « Minimiser le délai » signifiait choisir au mieux parmi les options disponibles, pas obtenir un nombre promis.

Les RFC 2474 et 2475 remplacèrent ensuite l'ancienne interprétation du champ par le DS field et séparèrent codepoint, comportement par saut, service, conditionnement et mécanisme d'implémentation. Cette architecture ultérieure ne prouve ni l'adoption de la RFC 1046 ni une filiation mécanique.

Le contexte Source Quench est lui aussi clos. La RFC 1016 documente une idée contemporaine de ralentissement de l'hôte ; la RFC 6633 impose ensuite de ne plus envoyer ni traiter le message et précise que l'approche de la RFC 1016 ne doit pas être mise en œuvre.

Sources et limites

Les sept RFC établissent les champs, la proposition de file, ses hypothèses et l'évolution normative. Elles ne montrent pas quelles machines l'ont mise en œuvre, quels paramètres ont été choisis, ni quel traitement un paquet réel a reçu. La demande, la classification, l'admission, l'attente, la perte et la livraison restent six faits différents.