Résumé

  • IntServ gagnait en précision grâce à l’état par flux ; DiffServ gagnait en échelle grâce aux agrégats, au prix d’un résultat plus approximatif.
  • La RFC 2990 a identifié deux interfaces manquantes : du cœur vers la frontière pour la disponibilité des ressources, puis de la frontière vers l’application pour le résultat de l’admission.
  • Sans découverte, mesure de livraison et comptabilité attribuable, une classe premium restait une demande technique, pas une promesse vérifiable.

La facture imaginaire

Imaginons une application qui marque ses paquets pour obtenir un meilleur service. Le domaine d’accès reconnaît la marque, le cœur affecte l’agrégat à un traitement particulier et un compteur enregistre les octets. À première vue, tout existe pour facturer. Pourtant, quatre questions restent ouvertes : la capacité était-elle disponible sur le trajet, la demande a-t-elle été admise, la qualité a-t-elle été livrée et le client en a-t-il bénéficié ?

La RFC 2990 a placé ces questions au centre de l’architecture. Une qualité de service n’était pas produite par un marquage isolé. Elle résultait d’une règle d’admission, d’une charge offerte et d’un comportement appliqué aux ressources limitées du réseau.

Cette distinction rendait visible une faiblesse commerciale autant que technique : compter une demande n’était pas encore mesurer une prestation.

Deux manières de payer la précision

Le modèle Integrated Services faisait porter le coût dans l’état du réseau. Une application annonçait son profil de trafic et demandait une réservation. Les éléments du trajet conservaient l’état de cette réservation, classaient les paquets et mesuraient leur conformité. La demande pouvait recevoir une réponse, y compris un refus.

Cette exactitude avait un prix. Le calcul, la mémoire, la classification et l’ordonnancement croissaient avec le nombre de réservations. Ce qui était soutenable à une extrémité devenait problématique dans un cœur très rapide où convergeaient d’innombrables flux.

DiffServ choisissait une autre dépense. Le cœur voyait un nombre limité d’agrégats, déclenchés par un code dans le paquet. Les frontières classaient et conditionnaient le trafic. Le nombre de clients pouvait croître sans imposer une nouvelle ligne d’état à chaque routeur intérieur.

L’économie d’échelle provenait d’une perte d’information. Le cœur ne connaissait plus le contrat individuel dont chaque paquet pouvait être l’expression.

Le silence était un état possible

Dans le modèle sans état par flux, expliquait la RFC 2990, un réseau incapable d’honorer une demande pouvait simplement ne pas l’honorer. Aucune règle générale ne l’obligeait à avertir l’application. Celle-ci devait constater elle-même que le service attendu n’avait pas été livré.

Ce silence n’était pas un message de refus. Il pouvait ressembler à une panne du serveur, à une congestion ordinaire, à un mauvais trajet ou à un profil de trafic mal estimé. Une application adaptative risquait de corriger la mauvaise variable. Une application non adaptative pouvait continuer comme si la promesse existait.

DiffServ était ainsi « centré sur la frontière ». La frontière pouvait appliquer la politique ; l’intérieur pouvait fournir efficacement des comportements agrégés. Mais le modèle ne définissait ni la remontée de l’état des ressources du cœur vers les conditionneurs de frontière, ni la transmission de cette décision jusqu’à l’application.

La RFC demandait donc deux retours, pas un : l’un pour rendre l’admission consciente de la capacité, l’autre pour rendre l’application consciente de l’admission.

Une route n’était pas une capacité

Avant même l’admission, la découverte restait incomplète. IntServ et DiffServ supposaient généralement le trajet choisi par le routage best effort. Or un déploiement progressif pouvait produire plusieurs chemins : certains équipés pour un service, d’autres non.

La meilleure métrique de routage ne disait pas nécessairement quel trajet pouvait porter un profil de qualité. Aucun mécanisme robuste ne permettait alors à l’application d’interroger plusieurs chemins sur cette capacité potentielle.

La RFC 2990 proposait une lecture dynamique. La grandeur utile n’était pas seulement la bande passante inutilisée, mais la possibilité d’ajouter un trafic à une qualité donnée, éventuellement en déplaçant un trafic moins prioritaire. Cette « capacité de déplacement » contenait déjà une décision de politique. Elle disait qui pouvait céder la ressource à qui.

Le routage choisissait un chemin. La découverte évaluait une possibilité. L’admission accordait ou refusait une ressource. Aucun de ces actes ne pouvait témoigner seul pour les deux autres.

Le chemin inverse de TCP

La discussion sur TCP montrait pourquoi une QoS à sens unique était trompeuse. L’émetteur rythme ses envois grâce aux accusés qui reviennent. Si les données bénéficient d’une classe et les accusés d’une autre, le débit obtenu dépend des deux traitements.

De la gigue sur le retour peut concentrer les accusés, puis provoquer une rafale de données. Le mécanisme de retour détériore alors le comportement du chemin aller. Une classe symétrique pouvait limiter ce risque, mais posait à son tour une question comptable : comment demander et mesurer les deux directions sans facturer deux fois une seule expérience ?

La prestation devait donc être observée à la frontière pertinente pour l’application, et pas seulement dans la file où le paquet aller avait été classé.

Prouver la livraison avant de compter l’usage

La RFC 2990 distinguait deux mesures. La mesure des ressources disponibles devait informer l’admission. La mesure du service effectivement livré devait permettre à l’opérateur de justifier sa conformité à la spécification et au client de vérifier que le supplément de prix améliorait l’application.

Ce second regard transformait un traitement interne en affirmation opposable. Une configuration, un codepoint ou une réservation réussie restaient des faits utiles, mais situés en amont du résultat.

Le texte anticipait des tarifs additionnels pour les services premium. Un prix pouvait financer des ressources supplémentaires et limiter la demande. Mais aucune architecture de comptabilité QoS ni méthode de collecte attribuant l’usage à un client n’était encore définie.

Il fallait donc distinguer identité, droit au service, demande, décision, ressources consommées, qualité observée, attribution et facturation. Sinon la comptabilité risquait d’être exacte sur les paquets et fausse sur la promesse.

L’agrégat avait besoin d’un interprète

La combinaison IntServ–DiffServ offrait une voie possible. RSVP pouvait préserver le dialogue par flux aux extrémités. Une frontière pouvait traduire la réservation en comportement agrégé dans un domaine DiffServ. Le cœur gardait son échelle ; l’application conservait un interlocuteur.

Cette composition ne fonctionnait que si la frontière était un interprète honnête entre deux modèles. Une capacité statique pouvait être configurée. Une capacité variable devait être signalée. Et tout échec d’admission dans la région DiffServ devait revenir jusqu’à l’application afin qu’elle réduise sa demande ou s’arrête.

La traduction d’un profil en classe ne suffisait pas. Il fallait aussi traduire l’indisponibilité en décision exploitable.

Une architecture volontaire mais observable

La RFC 2990 n’attendait pas une technologie universelle. Elle prévoyait des déploiements hétérogènes, des ponts imparfaits et des combinaisons adaptées : agrégation dans le cœur, précision par flux aux bords lorsque son coût restait soutenable.

Cette conclusion rejoint le principe de spécification initiale minimale de Lu Heng. La coordination commune peut définir les interfaces indispensables sans absorber les choix futurs des opérateurs. Mais une décision locale n’est compatible avec l’interopérabilité que si les autres acteurs peuvent connaître sa portée, sa durée et son résultat.

Les couches de réalité restent séparées : la marque demande ; la frontière admet ; le cœur possède ou non la capacité ; les files traitent ; l’application observe ; la mesure compare ; la comptabilité attribue ; la facture réclame. Le code en fonctionnement doit produire les preuves qui relient ces couches.

Le réseau pouvait refuser. Le défaut architectural était de pouvoir le faire sans le dire.

Sources