Résumé

  • RFC 3208 supprimait les accusés positifs de chaque récepteur et rendait les NAK fiables saut par saut ; les éléments réseau mémorisaient les interfaces où une perte avait été signalée.
  • Le NAK Confirmation attestait qu’une demande de réparation avait été prise en charge à cet endroit. Il n’attestait ni l’émission de RDATA, ni son arrivée, ni la récupération de tous les membres d’un groupe inconnu.

Le problème du multicast fiable n’était pas seulement de remplacer un paquet perdu. Il fallait aussi empêcher les preuves de bonne réception de devenir plus nombreuses que les données. Une source envoyant le même paquet à plusieurs milliers de récepteurs ne pouvait pas raisonnablement recevoir un ACK de chacun après chaque succès.

Pragmatic General Multicast a donc choisi l’asymétrie. La source envoyait des paquets ODATA numérotés. Le récepteur restait silencieux tant que la séquence ne révélait pas de trou. Lorsqu’un numéro manquait, il produisait un accusé négatif sélectif, le NAK.

En supprimant les ACK positifs, RFC 3208 supprimait aussi la possibilité de connaître tous les membres par leurs réponses. PGM n’avait pas de registre d’appartenance au groupe. Un membre pouvait arriver ou partir sans que la source l’apprenne. Le protocole n’était pas destiné aux applications exigeant une livraison acquittée à une liste connue, ni un ordre total entre plusieurs sources.

Sa promesse était locale au récepteur : pendant sa présence et dans la fenêtre d’émission de la source, il recevait les paquets originaux et les réparations, ou il pouvait détecter une perte devenue irrécupérable. Cette formulation ne donnait pas à la source une quittance globale. Elle donnait au récepteur un état connaissable.

Le chemin du NAK était lui-même rendu fiable. Le récepteur envoyait sa demande en unicast au dernier élément PGM rencontré sur l’arbre de distribution de la source. Tant qu’il ne recevait pas un NAK Confirmation correspondant, il répétait la demande.

L’élément réseau diffusait alors un NCF sur l’interface d’arrivée. Il transmettait le NAK vers l’élément PGM amont et recommençait jusqu’à recevoir à son tour un NCF. La même chorégraphie remontait jusqu’à la source. Les confirmations étaient multicast localement, mais elles ne voyageaient pas comme un reçu de bout en bout.

Un NCF disait donc quelque chose de précis : cette demande négative a été reconnue à cette étape du chemin inverse. Il ne disait pas que la source possédait encore le paquet. Il ne disait pas qu’un réparateur local l’avait envoyé. Il ne disait pas que RDATA avait traversé les branches aval, ni que le récepteur l’avait accepté.

Après réception du NAK, l’élément réseau créait un état de réparation. Cet état associait la session et le numéro manquant aux interfaces aval d’où la demande était venue. Lorsque le NAK était confirmé, le routeur pouvait jeter le paquet de demande. Ce n’était pas le NCF qui portait l’obligation jusqu’au retour des données ; c’était l’état conservé.

Quand RDATA revenait, le routeur ne l’envoyait que sur les interfaces enregistrées. La réparation n’inondait donc pas les branches où aucune perte n’avait été rapportée. Sans état de réparation correspondant, le comportement par défaut était de ne pas acheminer RDATA. Une retransmission pouvait exister et rester inutilisable sur une branche dont l’autorité de réparation n’avait pas été construite.

Cette construction dépendait des Source Path Messages. La source intercalait des SPM avec ODATA. Les éléments PGM y inscrivaient l’adresse du voisin amont afin de bâtir un chemin virtuel vers la source. Le récepteur savait ainsi où envoyer son NAK, et chaque routeur pouvait le faire remonter dans le sens inverse de la diffusion originale.

Les SPM annonçaient aussi les limites de la fenêtre d’émission. Le bord arrière indiquait le plus ancien paquet encore réparable ; le bord avant suivait les données récentes. Si un trou était découvert après le retrait d’un paquet de cette fenêtre, la répétition du NAK ne recréait pas une copie disparue. Le protocole pouvait rendre la perte explicite sans la rendre réparable.

RFC 3208 renforçait les NAK parce qu’ils étaient l’unique déclencheur de réparation. Les SPM donnaient de nouvelles occasions de constater une lacune même lorsque la source n’envoyait plus beaucoup de données. Des temporisateurs séparaient la confirmation de la demande et l’attente de RDATA. Un NCF sans réparation pouvait conduire à un nouveau cycle.

Mais plusieurs récepteurs pouvaient manquer le même paquet. S’ils parlaient tous immédiatement, le protocole remplaçait l’implosion des ACK par celle des NAK. Chaque récepteur attendait donc un délai aléatoire. S’il entendait un NAK ou un NCF correspondant durant ce délai, il supprimait sa propre émission tout en agissant comme si sa demande avait été représentée.

Les routeurs fusionnaient à leur tour les doublons. Lorsque l’état de réparation existait déjà, un NAK identique ajoutait éventuellement une interface concernée mais n’avait pas besoin de remonter une nouvelle copie. Dans le cas habituel, la source ne voyait qu’un NAK pour une perte partagée par beaucoup de membres.

La réduction était efficace et irréversible. Un NAK observé ne révélait pas combien de récepteurs avaient attendu, parlé ou supprimé leur message. Une interface dans l’état de réparation ne révélait pas le nombre d’hôtes situés derrière elle. Un NCF pouvait calmer un récepteur qui n’avait jamais émis de NAK personnel.

La réparation elle-même pouvait changer de dépositaire. La source originale ou un Designated Local Repairer pouvait émettre RDATA. Le DLR reprenait le Transport Session Identifier de la source afin que la réparation rejoigne la bonne séquence. Cette continuité d’identité de session ne faisait pas du DLR la source originale des octets.

Les procédures de découverte et de redirection des DLR ajoutaient d’autres états intermédiaires. Un réparateur pouvait annoncer sa disponibilité et les NAK pouvaient lui être redirigés. Ces signaux rendaient un chemin possible ; ils ne prouvaient pas que le DLR possédait encore le paquet, qu’il avait répondu, ni que sa réponse avait atteint le demandeur.

Le choix de la politique de fenêtre déterminait le prix de la fiabilité. Dans une stratégie pilotée par les données, des NAK récents pouvaient retarder l’avancement de la fenêtre. La source gardait les données plus longtemps et acceptait le délai. Dans une stratégie pilotée par le temps, elle avançait sans attendre les demandes encore actives pour préserver un débit régulier.

Le même NCF apparaissait dans les deux régimes, mais sa valeur opérationnelle changeait avec la durée de conservation. La confirmation ne contenait pas la promesse que la source avait choisi la complétude plutôt que la ponctualité.

La correction d’erreurs directe ne supprimait pas cette frontière. Une réparation pouvait être une copie du paquet ou un fragment de parité permettant de le reconstruire. Un NCF de parité pouvait confirmer le nombre demandé. Le récepteur devait encore recevoir assez de fragments, découvrir la taille correcte du groupe et réussir le décodage.

L’état Experimental du RFC bornait également l’interprétation historique. Le texte qualifiait encore de prototypiques le contrôle de congestion, l’assistance des routeurs, la retransmission locale et l’API. RFC 2357 avait décrit les critères d’examen des protocoles multicast fiables. RFC 3208 proposait une mécanique à expérimenter, pas la preuve de son adoption ni de ses performances réelles.

La section de sécurité montrait que les états utiles étaient aussi des surfaces d’attaque. Un faux SPM pouvait dévier les NAK. Un faux NAK pouvait remplir la mémoire de faux états. Un faux NCF pouvait arrêter trop tôt la remontée d’une demande. Un faux RDATA pouvait faire supprimer l’état légitime avant l’arrivée de la vraie réparation.

Ces attaques n’avaient pas besoin de falsifier le contenu final. Elles falsifiaient les représentations qui gouvernaient le chemin : où se trouvait la source, quelle branche avait perdu, quelle demande restait active et quel paquet pouvait clôturer l’état. Le texte reconnaissait que seule une authentification étendue des voisins aurait renforcé toutes ces transitions.

La réussite de PGM était donc une discipline de limites. Il rendait la demande négative plus fiable, fusionnait les plaintes et dirigeait la réparation sans prétendre connaître le groupe. Le NCF avait de la valeur parce qu’il confirmait un événement étroit. Le transformer en reçu de livraison aurait annulé cette précision.