Résumé

  • RFC 2354 ne proposait pas une réparation universelle : il comparait quatre familles dont les coûts de délai, de débit, de calcul et de fidélité différaient.
  • L’avertissement central reste actuel : augmenter le trafic de secours après une perte peut charger davantage le goulot d’étranglement et provoquer la perte suivante.

Une conversation ne peut pas attendre que le réseau reconstitue parfaitement le passé. Une diffusion enregistrée, elle, peut accepter quelques secondes de mémoire pour améliorer le résultat. Cette différence de temps, plus que le nom de la technique, organisait le raisonnement de RFC 2354.

Colin Perkins et Orion Hodson publièrent ce document en juin 1998 dans la catégorie Informational. Il s’agissait d’une introduction, non d’une norme Internet ni d’un inventaire exhaustif. Le périmètre était volontairement limité aux mécanismes auxquels l’émetteur participait. La dissimulation locale par le récepteur restait hors champ.

Le texte commençait par séparer l’unité média du paquet. Une unité correspondait à un intervalle temporel produit par le codeur ; un paquet pouvait en regrouper plusieurs. Cette distinction empêchait de confondre quatre résultats : retrouver exactement les octets perdus, reconstruire une version dégradée de l’unité, disperser un grand défaut en petits défauts, ou recevoir une copie parfaite trop tard pour la lire.

RTP apportait deux repères. Le numéro de séquence révélait l’ordre d’émission et permettait de détecter les absences. L’horodatage plaçait les unités sur la ligne de lecture. Comme certaines réparations réordonnaient volontairement les unités, le récepteur devait utiliser le temps RTP pour la restitution. Un trou dans la séquence était une preuve de perte ; il ne fixait ni l’échéance de lecture ni le meilleur remède.

La perte observée n’était pas uniforme

RFC 2354 s’appuyait sur des mesures du Mbone. Dans une grande session citée par le document, beaucoup de récepteurs connaissaient environ 2 à 5 % de perte, tandis qu’un groupe plus petit subissait davantage. Les pertes isolées dominaient ; les rafales de plusieurs paquets étaient moins fréquentes et les longues rafales rares. Ces chiffres décrivaient un contexte historique, pas une distribution universelle.

Ils donnaient toutefois une règle d’ingénierie : traiter efficacement la perte d’un seul paquet avant de payer pour les événements exceptionnels. Un code conçu pour de longues rafales pouvait ajouter en permanence un coût disproportionné. À l’inverse, ignorer les rafales courtes laissait une part visible des dégradations sans réponse.

Quatre dépenses, quatre résultats

La retransmission attendait le constat de perte, demandait l’élément manquant puis l’envoyait de nouveau. Elle pouvait restaurer exactement les données, mais consommait un aller-retour et du trafic dans les deux sens. Dans une grande session multicast, presque chaque paquet pouvait manquer chez au moins un participant. Sans suppression ou regroupement des demandes, la précision locale créait une charge collective.

Le document réservait donc surtout la retransmission aux usages capables d’accepter le délai. Il envisageait aussi une combinaison : une FEC corrigeait les pertes isolées courantes ; les récepteurs touchés par une rafale et prêts à attendre demandaient un secours supplémentaire. La fiabilité devenait une politique par récepteur, non une propriété globale du flux.

La FEC indépendante du média payait avant la perte. L’émetteur ajoutait des paquets de parité ou des données codées ; le récepteur pouvait reconstruire des paquets originaux sans revenir vers la source. Des opérations XOR simples limitaient le calcul. Des codes plus puissants amélioraient la résistance aux rafales, au prix de davantage de complexité et souvent de latence. L’assurance occupait la liaison même lorsqu’aucun paquet n’était perdu.

La redondance propre au média utilisait la connaissance du codec. Une copie de qualité inférieure pouvait préserver une syllabe avec moins de débit qu’une copie exacte. Un format vidéo pouvait dupliquer seulement ses éléments structurants ; un autre mécanisme protégeait les bits les plus sensibles. Cette efficacité changeait le sens du mot réparation : le récepteur obtenait quelque chose d’exploitable, mais pas nécessairement l’original.

L’entrelacement ne créait ni parité ni copie. Il redistribuait de petites unités entre plusieurs paquets. La perte d’un paquet devenait alors plusieurs lacunes brèves plutôt qu’une interruption continue. Certains décodeurs les masquaient mieux. Le coût était l’attente nécessaire pour remettre les unités dans l’ordre. La technique économisait le débit et dépensait le temps.

Le choix dépendait de la lecture

Pour une transmission unidirectionnelle non interactive, proche de la radio ou de la télévision, la latence comptait moins que la qualité reçue. Entrelacement, retransmission et FEC pouvaient y trouver leur place. Si une reconstruction approximative suffisait, l’entrelacement avait l’avantage de ne pas augmenter le débit.

Dans une session interactive, le raisonnement s’inversait. L’aller-retour de la retransmission et la mémoire de l’entrelacement menaçaient directement la conversation. Une FEC à faible latence restait possible, mais le choix entre protection générique et connaissance du codec dépendait encore du format, du calcul disponible et du degré d’approximation acceptable.

Puis venait le piège. Une application détectait une perte, ajoutait des données de réparation, augmentait la congestion, provoquait de nouvelles pertes et produisait un nouveau motif de réparation. La section de sécurité allait jusqu’à signaler qu’un excès pouvait devenir un déni de service. La preuve qu’une unité manquait ne constituait jamais une autorisation illimitée d’émettre.

En l’absence d’un contrôle de congestion standard pour les médias continus, RFC 2354 proposait une estimation de comportement « raisonnable » par comparaison approximative avec le débit TCP. Le texte en reconnaissait les limites : une relation moyenne entre perte, RTT, taille de paquet et débit ne reproduisait pas la dynamique de TCP ; le RTT d’un groupe multicast n’était lui-même qu’une moyenne incertaine.

Les RFC ultérieurs ont formalisé des surfaces différentes. RFC 4588 a défini un format RTP de retransmission ; RFC 5109 un format FEC générique. RFC 8085 a rappelé que UDP ne possédait aucun contrôle de congestion intrinsèque et que l’application devait réguler l’ensemble de son trafic. Cette postérité confirme la séparation des mécanismes ; elle ne transforme pas RFC 2354 en norme pour chacun d’eux.

L’héritage essentiel est une comptabilité. Perte détectée, trafic de secours admis, unité reconstruite, unité disponible avant l’échéance et qualité perçue doivent rester des événements différents. Un tableau de bord qui affiche seulement « réparation activée » masque précisément le risque que le document rendait visible.