Résumé

  • RFC 1458 proposait, à priorité égale, de supprimer d’abord les paquets de qualité applicative la plus élevée lorsque la couche inférieure gardait une utilité autonome.
  • Ce choix ne prouvait ni la bonne déclaration des dépendances ni le résultat final : offre, demande, état MGA, routage, marquage, perte, réparation et usage formaient des preuves distinctes.

Le mot « supérieur » promet spontanément une protection accrue. RFC 1458 lui donnait un sens presque inverse. Le paquet supérieur ajoutait de la précision à une image ; le paquet inférieur rendait cette image possible. Si la file d'un routeur débordait, conserver le premier au détriment du second pouvait produire deux fragments impeccablement transportés mais incapables de former une représentation utile.

La logique ne consistait donc pas à dévaluer la qualité. Elle consistait à reconnaître une dépendance. Ce déplacement du regard — du prestige d'une couche vers la fonction du résultat — est le cœur historique du document.

L'image imposait plusieurs régimes de fiabilité

RFC 1458 fut publié en mai 1993. Sa notice du RFC Editor le classe comme document Informational et non comme norme Internet. Son point de départ était la diffusion d'images numériques de très grande taille à des centaines d'utilisateurs éloignés, sur des chemins dont les capacités pouvaient varier de six ordres de grandeur.

Le document refusait une fiabilité uniforme. Une position de souris perdue pendant une conférence pouvait ne rien changer d'important. Une image destinée à l'archivage exigeait au contraire la récupération de chaque paquet. Entre les deux, une compression hiérarchique permettait de livrer sûrement une résolution de base, puis d'accepter des pertes dans les détails que l'interpolation pouvait partiellement remplacer.

La demande complète et le minimum exigible ne coïncidaient plus. Un utilisateur pouvait souhaiter la meilleure image, tout en déclarant que seule une couche inférieure devait être transmise de manière fiable. Cette distinction devait voyager dans le système sans devenir une simple étiquette décorative.

Une autorité, un transport et des routeurs

RFC 1458 proposait trois ensembles coordonnés. La Multicast Group Authority, ou MGA, devait distribuer des adresses de groupe, enregistrer les services et compter les membres par niveau de qualité et de fiabilité. RAMP, le Reliable Adaptive Multicast Protocol, devait gérer séquence, réparation et débit. Les routeurs devaient conserver, pour chaque interface sortante, l'adresse du groupe et l'ensemble des qualités demandées.

Ces surfaces ne décrivaient pas le même fait. Un serveur enregistré pouvait rester silencieux jusqu'à l'ordre de la MGA. Une requête client pouvait être mise en attente avant l'existence du service. Un premier membre pouvait déclencher une offre. Le dernier départ pouvait arrêter un niveau sans arrêter les autres. Une route installée ne disait toujours pas qu'un paquet avait circulé.

Changer de qualité mettait cette chaîne en mouvement : diminution d'un compteur, augmentation d'un autre, propagation hiérarchique, notification du serveur, puis adaptation éventuelle des routes. La préférence d'un client devenait ainsi une modification de l'état de production et de réplication. Son succès ne pouvait être déduit du seul acquittement de la requête.

Le champ TOS ne pouvait pas porter deux autorités sans provenance

RAMP devait associer chaque paquet à un ou plusieurs niveaux de qualité. Le récepteur n'acceptait que les paquets correspondant à la fois à un groupe rejoint et à une qualité demandée. Pour les anciens environnements IPv4, le document envisageait le champ Type of Service comme un ensemble de bits de qualité.

Il indiquait lui-même l'incompatibilité avec RFC 1349. Ce texte définissait TOS comme une valeur unique permettant de demander au réseau un compromis de délai, débit, fiabilité ou coût. Il précisait que combiner plusieurs valeurs par un OU logique n'avait plus de sens. RFC 791 avait placé ce champ dans l'en-tête IP pour exprimer un traitement de réseau, non la structure sémantique d'une image.

Le conflit ne portait pas seulement sur quatre bits. Il portait sur la juridiction. Qui décidait du sens : le protocole Internet qui choisissait un chemin, ou l'application qui décrivait les dépendances de son contenu ? Une trace contenant 0100 ne répond pas à cette question. Il faut connaître le protocole, sa version, le contexte expérimental et la configuration qui a gouverné l'interprétation.

Le niveau le plus fin pouvait tomber en premier

Le routage proposé vérifiait deux dimensions : groupe et qualité. Un paquet ne devait être copié sur une interface que si cette interface avait une demande pour les deux. En cas de saturation, les paquets portant une priorité étaient protégés. À priorité identique, la qualité la plus élevée devait toutefois être éliminée avant la plus basse.

Le raisonnement était applicatif. La couche basse pouvait permettre une lecture dégradée. La couche haute pouvait n'être qu'un complément inutilisable sans le socle. En sauvant la base, le réseau conservait au moins une possibilité de résultat ; en sauvant uniquement le détail, il pouvait préserver des octets et perdre l'image.

L'exemple de RFC 1458 distingue deux cas. Lorsque Q1 et Q2 sont indépendants, chacun suit seulement le chemin de ses destinataires. Lorsque Q2 constitue un sous-ensemble requis par Q1, les paquets Q2 portent les deux marques et sont dupliqués vers les deux clientèles. Cette double marque exprime une hypothèse de dépendance. Elle ne la vérifie pas.

Une configuration erronée peut inverser le graphe. Une table de route peut être ancienne. Un équipement peut lire le champ selon RFC 1349. Un paquet de base peut arriver après son délai utile. Le récepteur RAMP peut accepter les données alors que le processus client échoue. Il faut donc conserver séparément la déclaration, l'exécution et l'effet.

La réparation dépendait de la forme de la perte

RAMP proposait des NAK portant sur des séquences manquantes. L'émetteur regroupait ces demandes pendant un délai. Au-delà d'un seuil de récepteurs affectés, il retransmettait au groupe ; en dessous, il répondait en unicast aux demandeurs. Une donnée déjà libérée des tampons pouvait ne plus être réparable.

Ce seuil empêchait deux excès. Multidiffuser pour une perte isolée imposait le correctif à des branches saines. Envoyer une copie individuelle à une foule de récepteurs reproduisait la congestion sous une autre forme. Mais le compteur de NAK ne révélait ni la cause de la perte ni le succès du correctif.

Le contrôle de débit utilisait lui aussi des indices limités : requêtes de retransmission, signaux de recul des routeurs et périodes sans nouvelle demande. Une absence de NAK pouvait autoriser une hausse prudente. Elle ne certifiait pas que chaque membre avait reçu, compris et exploité les données.

La place exacte de RFC 1458

Le document examinait le Multicast Transport Protocol de RFC 1301, reconnaissait ses jetons d'émission et sa réparation sélective, mais jugeait trop coûteux le passage de presque tout le contrôle par un maître pour ce volume d'images. Il s'appuyait aussi sur le modèle de groupes IP de RFC 1112.

Ces liens montrent un débat d'architecture, non un déploiement. RFC 1458 ne nomme pas un réseau ayant exploité RAMP. Il ne mesure pas son taux de pertes. Il dit explicitement que les questions de sécurité ne sont pas traitées. Une adhésion n'authentifiait donc pas une personne ; une inscription de service n'accordait pas une autorisation ; une marque de qualité ne garantissait ni origine ni intégrité.

L'héritage utile tient à la chaîne rendue visible. La meilleure couche ne méritait d'être protégée que si sa dépendance, sa demande et son résultat le justifiaient. Une politique de file ne pouvait pas fabriquer cette vérité seule.