Résumé

  • RFC 5401 réduit le volume de retour en autorisant un récepteur à supprimer son NACK lorsqu'une demande déjà entendue couvre son besoin.
  • Cette suppression décrit une coordination entre demandes, pas la réception de la réparation ni l'achèvement local de l'objet.
  • L'exploitation doit conserver séparément l'historique de perte, la décision de suppression, les tours de réparation, la reconstruction et l'acceptation applicative.

Le premier plaignant représente un besoin, pas le groupe

RFC 5401, publié en novembre 2008 sur la voie des normes, remplace le RFC expérimental 3941. Son problème est celui de l'échelle : dans un groupe multicast nombreux, demander à chaque destinataire de confirmer chaque bonne réception produirait un flot de contrôle considérable. Les retours négatifs inversent la charge. Les récepteurs satisfaits se taisent ; ceux qui détectent un manque lancent un cycle de NACK.

Mais si tous les récepteurs ayant perdu le même bloc parlent en même temps, le mécanisme recrée une implosion. Le standard introduit donc un délai aléatoire. Le premier NACK utile peut décrire un besoin de réparation qui englobe celui d'autres membres. Ceux-ci suppriment alors leur propre retour.

Le serveur n'obtient pas une liste de victimes. Il obtient une représentation compacte des réparations demandées. Une demande peut couvrir mille récepteurs, dix ou un seul. L'absence des 999 autres messages n'indique pas que les 999 objets sont complets. Elle indique seulement que 999 messages ont pu être jugés redondants au moment de leur temporisation.

Cette distinction est cruciale dans un compte rendu. « Un besoin équivalent a déjà été signalé » est une observation fidèle. « Tous les destinataires sont réparés » ajoute une conclusion que le canal de NACK ne transporte pas.

La suppression intervient avant le résultat

Lorsqu'un récepteur constate que ses besoins dépassent les transmissions déjà attendues, il mémorise la position de l'émetteur et démarre son cycle. Il doit conserver un historique suffisant des contenus reçus pour calculer ce qui manque encore. La position mémorisée empêche les arrivées survenues pendant l'attente de brouiller la base de la décision.

Pendant le délai, le récepteur peut entendre le NACK d'un pair. Il peut aussi recevoir de l'émetteur une indication de l'état de réparation, ou observer un retour en arrière de l'émission qui annonce que la zone manquante va être reprise. Si ce signal couvre son besoin, il ne parle pas.

La suppression a donc lieu avant que le résultat soit connu. Le récepteur peut ensuite ne pas recevoir le paquet de réparation. Il peut le recevoir sans réunir assez de symboles. Il peut reconstruire l'objet mais échouer à le vérifier ou à le remettre à l'application. Chacune de ces étapes produit une preuve différente.

Une interface qui fait passer directement « NACK supprimé » à « récepteur complet » efface toute la partie risquée du parcours. Elle transforme une optimisation de coordination en accusé de réception. Le libellé est séduisant parce qu'il rend la campagne rapidement verte ; il est faux parce qu'il place le point de succès avant la livraison.

Plusieurs tours ne constituent pas un seul reçu

Le NACK lui-même n'a pas besoin d'être livré avec une garantie absolue lorsque la conception permet des cycles répétés. Un retour perdu peut être compensé si le récepteur conserve son historique, attend les nouvelles transmissions puis recommence lorsque son besoin subsiste.

Cette convergence progressive explique pourquoi un intervalle silencieux ne suffit pas. Le récepteur peut être dans l'attente d'un tour déjà annoncé. Son NACK peut avoir été perdu. Son temporisateur peut ne pas avoir expiré. Il peut avoir quitté le groupe ou perdu le chemin retour. Les mêmes octets de silence recouvrent des situations incompatibles.

Il faut donc numéroter les tours de réparation et relier chaque demande à l'objet, au bloc de codage, à la position de l'émetteur et au besoin restant. Le serveur peut alors dire qu'il a agrégé certaines demandes et émis telle réparation. Seul le récepteur peut attester qu'il a reçu assez de données pour reconstruire, et seule l'application peut attester qu'elle les a acceptées.

Le RFC 5740, qui définit NORM, montre comment ces briques peuvent s'insérer dans un protocole complet. Même dans ce cadre, l'état du transport ne doit pas devenir automatiquement la preuve qu'un logiciel a été activé ou qu'une donnée a produit l'effet attendu.

Le codage efface les différences de paquets, pas celles d'état

Avec la correction d'erreurs directe, deux récepteurs ayant perdu des paquets différents peuvent bénéficier du même symbole de réparation. Le RFC 5052 décrit le cadre FEC de livraison de contenu. Cette propriété permet au serveur de répondre à un besoin agrégé sans retransmettre une liste distincte pour chaque membre.

Elle rend aussi les déductions globales plus délicates. Les récepteurs n'ont pas le même historique. Un symbole supplémentaire peut achever la reconstruction chez l'un et laisser un déficit chez l'autre. Un participant tardif peut ne pas posséder les symboles sources nécessaires au bloc courant. Une réparation envoyée est donc une occasion partagée, pas un résultat partagé.

Le récepteur doit tenir compte des réparations déjà programmées avant d'émettre une nouvelle demande. Cela évite les excès, mais crée l'état « réparation attendue ». Cet état ne signifie pas « donnée reçue ». Les tableaux de bord devraient montrer séparément le volume demandé, le volume planifié, le volume reçu et les objets reconstruits.

FEC ne fournit pas non plus à lui seul le contrôle de congestion. Le RFC 5052 et le RFC 5651 replacent ce contrôle dans l'instanciation complète. Une équipe ne peut donc justifier une réparation agressive par la seule efficacité du codage ni annoncer l'achèvement à partir du nombre de symboles expédiés.

Le délai aléatoire arbitre entre bruit et attente

Plus le délai de retour est long, plus un NACK précoce a de chances de supprimer les suivants. Le réseau reçoit moins de messages, mais les récepteurs attendent davantage avant de signaler une lacune. L'émetteur et les destinataires doivent aussi conserver plus longtemps l'état nécessaire à la réparation.

RFC 5401 s'appuie notamment sur une estimation de la taille du groupe et du plus grand temps aller-retour pour régler les temporisateurs. Une estimation n'est pas un recensement. Elle peut être ancienne, ignorer un membre éloigné ou changer pendant la session. Elle aide à choisir un comportement ; elle ne certifie pas que le membre le plus faible a répondu.

L'entreprise doit rendre cet arbitrage visible. Réduire le trafic de retour peut améliorer la stabilité d'un très grand groupe tout en allongeant le délai de récupération. Une valeur moyenne flatteuse peut cacher une cohorte périphérique qui recommence plusieurs cycles. La mesure utile associe temporisation, suppression et progression de reconstruction par cohorte.

Le contrôle de congestion reste une contrainte distincte. Envoyer plus de réparation pour accélérer les retardataires peut dégrader le chemin qu'ils utilisent. La décision doit donc considérer ensemble la latence, les tampons, la perte, les tours de réparation et la capacité du réseau, sans réduire ces dimensions à un voyant unique.

« Tout le monde » doit être défini avant l'émission

Les membres peuvent rejoindre tard, partir puis revenir. Le dénominateur bouge. Un nouveau membre visible à la fin n'a peut-être jamais reçu le début de l'objet ; un membre initial peut avoir disparu sans envoyer de NACK. La seule liste des participants courants ne reconstitue pas l'obligation de livraison.

Certaines applications peuvent agir quand une fraction déterminée du groupe est prête. D'autres doivent attendre le membre le plus faible. Des récepteurs durablement mauvais peuvent être exclus ou déplacés vers un autre groupe. RFC 5401 laisse ces choix à l'instanciation du protocole et à l'application.

Ils doivent donc être gouvernés. Qui compte pour l'achèvement ? Quelle heure fixe l'appartenance ? Un participant tardif reçoit-il l'objet entier ? Une migration vers un groupe lent vaut-elle livraison, report ou échec ? Qui peut exclure un récepteur, et quel reçu garde la décision ?

Sans politique explicite, le taux de réussite peut augmenter par retrait des cas difficiles. L'amélioration est alors comptable, pas opérationnelle. Il faut conserver l'audience prévue, l'audience joignable et l'audience retenue pour le calcul comme trois ensembles distincts.

Une chaîne de preuves proportionnée

L'objectif n'est pas de remplacer tous les NACK par des accusés positifs. Ce choix annulerait l'avantage d'échelle dans les services qui n'exigent pas une preuve individuelle universelle. Il faut plutôt choisir les preuves adaptées au risque.

Pour une diffusion ordinaire, un système peut combiner statistiques de cohorte, seuil d'achèvement et file d'exceptions. Pour une mise à jour critique, il peut exiger des reçus explicites de membres nommés. Dans les deux cas, il doit garder l'identité de l'objet, la politique d'appartenance, les cycles de NACK, les motifs de suppression, les réparations émises et les résultats locaux disponibles.

Cette chaîne permet de répondre après incident. Elle montre si le récepteur n'a jamais détecté le manque, si son retour a été supprimé, si la réparation n'a pas traversé le réseau, si le décodage a échoué ou si l'application a refusé l'objet. Sans elle, le silence central ne produit qu'une hypothèse impossible à vérifier.

Les textes étudiés ne donnent ni part de marché actuelle, ni fréquence universelle des pertes, ni comportement garanti d'un fournisseur. Ces éléments doivent venir de la documentation de l'implémentation et de la télémétrie réelle. Ils suffisent toutefois à écarter l'équivalence entre un canal calme et un groupe achevé.