Résumé

  • RFC 2212 ne remplaçait pas le routeur réel par un modèle parfait : il obligeait chaque élément à borner son écart au serveur fluide par C/R + D.
  • Les termes locaux s’additionnaient en Ctot et Dtot, puis se combinaient au profil de trafic et au débit réservé pour produire une borne de retard en file.
  • Cette borne restait conditionnée par la conformité, l’admission, la taille des paquets, les ressources et la continuité du chemin ; elle ne certifiait ni gigue nulle, ni identité, ni résultat applicatif.

Le même débit ne signifiait pas la même promesse

Le modèle de référence de RFC 2212 était volontairement irréaliste : un fil privé de capacité R, servant un flux de manière continue. Pour un trafic décrit par un seau à jetons de débit r et de profondeur b, ce serveur fluide borne le retard à b/R, à condition que R ne soit pas inférieur à r.

Un réseau de paquets ne sert rien de façon continue. Il sérialise un datagramme, attend une tranche d’ordonnanceur, traverse des sous-réseaux et peut interrompre momentanément le service pour d’autres tâches. La norme n’a pas transformé ces écarts en note de bas de page. Elle les a placés dans le calcul.

C représente l’écart dépendant du débit. Son effet temporel est donc C/R. Une dette de paquetisation en est l’exemple classique. D représente l’écart indépendant du débit : une attente de créneau, une pause de traitement, un délai qui ne disparaît pas lorsque l’on réserve davantage de bande passante.

Chaque élément devait garantir un service jamais pire que le modèle fluide augmenté de C/R + D. Ces valeurs étaient des maxima, non des moyennes. Un équipement pouvait faire mieux ; il ne pouvait pas faire pire tout en conservant la même caractérisation.

Avant l’équation, il fallait décrire le trafic

Le TSpec comportait cinq paramètres. r et b décrivaient la production durable et la rafale. p limitait la vitesse de pointe. m fixait l’unité minimale comptée par le policer. M fixait la taille maximale d’un datagramme conforme.

Sur toute durée T, le trafic conforme ne pouvait dépasser :

M + min[pT, rT + b - M]

Cette forme empêchait la garantie de se détacher des octets qu’elle couvrait. Un paquet plus grand que M n’obtenait pas le même traitement par simple appartenance au flux. Si M dépassait le MTU du lien, la demande devait être refusée.

Le RSpec ajoutait le débit réservé R et une marge S. R devait rester au moins égal à r. La marge exprimait l’écart entre le retard souhaité et celui obtenu au niveau de réservation demandé. Elle appartenait au récepteur : c’était la souplesse qu’il acceptait, pas une permission générale d’affaiblir le service.

Une somme de défauts rendait la route lisible

Les termes C et D avaient une règle de composition additive. Le mécanisme d’établissement pouvait donc fournir à l’extrémité Ctot et Dtot, sommes des erreurs de tous les éléments participants.

Lorsque p > R >= r, la borne de retard en file était :

[(b-M)/R × (p-R)/(p-r)] + (M+Ctot)/R + Dtot

Lorsque r <= p <= R, elle devenait :

(M+Ctot)/R + Dtot

En ignorant le débit de pointe, on obtenait la borne conservatrice :

b/R + Ctot/R + Dtot

Le résultat séparait quatre réalités : la rafale déclarée, la ressource réservée, l’erreur qui se réduit avec cette ressource et le temps incompressible. Un chiffre de bande passante, seul, ne pouvait plus parler au nom du chemin entier.

Le retard fixe devait encore être ajouté

La garantie portait sur le retard en file. La propagation, la transmission et les délais fixes du chemin restaient distincts. Pour calculer un retard maximal de bout en bout, il fallait ajouter cette latence à la borne garantie.

Cette frontière disait aussi qui ne contrôlait pas la route. RFC 2212 ne choisissait pas le chemin et ne le gelait pas. Les valeurs promises demeuraient stables tant que le chemin ne changeait pas. Après une modification de routage, l’ancien couple Ctot/Dtot pouvait encore être correctement enregistré tout en étant devenu inapplicable au trafic courant.

La provenance n’était donc pas un décor. Sans l’identité et la version du chemin, une borne exacte perdait son objet.

La marge permettait un échange discipliné

Un élément intermédiaire pouvait utiliser une partie de S pour réserver moins de débit ou accepter davantage de délai local. Il devait toutefois préserver :

Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin

avec r <= Rout <= Rin.

La marge consommée devait suivre la réservation. Elle ne pouvait être dépensée une seconde fois lors d’un rafraîchissement. Le réseau avait une latitude, mais cette latitude était comptable.

Dans le cas où le retard demandé Dreq dépassait le maximum obtenu à R=r, RFC 2212 exprimait la marge comme la différence entre Dreq et b/r + Ctot/r + Dtot. L’écriture rendait visible le prix de la réduction de ressources : davantage de délai accepté, pas une disparition des contraintes.

Csum et Dsum répondaient à une autre question

Ctot et Dtot servaient la borne de bout en bout. Csum et Dsum accumulaient les écarts depuis le dernier point de remise en forme. Ils aidaient à dimensionner le tampon nécessaire pour ramener le trafic conforme vers son enveloppe d’origine.

Sans optimisation par le débit de pointe, une estimation conservatrice était b + Csum + Dsum × R. Ces sommes partielles n’étaient ni une mesure du paquet courant, ni une nouvelle garantie de bout en bout. Elles appartenaient au contrôle local des rafales.

Si le TSpec sous-estimait le trafic réel, la remise en forme pouvait créer une longue file et rendre des datagrammes non conformes. Au bord du réseau, ceux-ci devaient normalement retomber en best effort. Le nom du flux ne remplaçait pas la conformité.

Un maximum n’était pas une cadence régulière

La norme disait expressément qu’elle ne cherchait pas à minimiser la gigue. Elle contrôlait un maximum de retard en file, non la différence entre le meilleur et le pire retard. De nombreux datagrammes pouvaient arriver très tôt et attendre dans le tampon du récepteur avant lecture.

Le mot « garanti » ne signifiait donc pas arrivée périodique, retard moyen faible ou absence de variation. La protection contre la perte par débordement avait elle aussi des prémisses : trafic conforme, admission réussie, ressources suffisantes, éléments compatibles, taille couverte, absence de panne et chemin inchangé.

Une seule prémisse brisée ne rendait pas l’équation fausse. Elle rendait son usage actuel injustifié.

Le reçu de réservation n’était pas le reçu de l’application

RFC 2212 restait indépendant du mécanisme d’établissement. RSVP était possible, comme une configuration manuelle ou un outil de gestion. RFC 2210 décrivait séparément les objets RSVP ; l’authentification, la politique et la comptabilité demeuraient d’autres contrôles.

Il fallait donc conserver une chaîne : déclaration TSpec, requête RSpec, caractérisation C/D, décision d’admission, composition de chemin, calcul, observation de paquets, puis résultat applicatif.

Un FLOWSPEC admis ne prouvait pas la conformité future. Une borne calculée ne prouvait pas l’arrivée d’un paquet. Une arrivée ne prouvait ni l’identité de l’émetteur, ni l’autorisation, ni le décodage, ni l’action humaine recherchée.

La force historique de RFC 2212 est précisément là : rendre une étape vérifiable sans lui donner le droit de parler pour les suivantes.

Sources et limites

Ces sources établissent le contrat publié, pas le déploiement d’un réseau nommé, une mesure actuelle, une performance de produit ou une filiation vers un mécanisme QoS ultérieur.