Résumé

  • RFC 3448 confia au récepteur le débit reçu, le taux d’événements de perte et les éléments temporels, mais l’émetteur calcula encore le RTT et un débit modelé sur TCP.
  • Le débit final restait plafonné par l’observation du récepteur, accéléré avec prudence et réduit en l’absence de retour; aucune de ces valeurs ne prouvait capacité, équité exacte ou livraison applicative.

La régularité n’effaçait pas l’obligation de céder

Les variations de fenêtre de TCP convenaient au transfert de fichiers, moins à la téléphonie et au streaming. RFC 3448, publié en janvier 2003, proposa donc TFRC : un contrôle unicast fondé sur un débit, plus régulier à court terme, mais conçu pour partager raisonnablement le réseau avec TCP.

Le mot « raisonnablement » était essentiel. La cible était généralement un débit situé dans un facteur deux de celui d’un flux TCP placé dans les mêmes conditions. Ce n’était ni l’égalité instantanée, ni une réservation de bande passante, ni une garantie de qualité perçue.

Le texte ne définissait d’ailleurs ni fiabilité ni format complet de transport. Il pouvait être employé avec RTP ou dans une application. Le texte brut, la fiche RFC Editor, le dossier Datatracker, son historique, ses références, ses citations ultérieures et la recherche d’errata établissent le document, pas le résultat d’un réseau nommé.

Le récepteur fabriquait un événement, pas un verdict

Une perte isolée et plusieurs pertes rapprochées ne devaient pas forcément provoquer des réactions distinctes. TFRC regroupait les paquets perdus ou marqués au cours d’environ un RTT en un seul événement de perte. L’objectif était de rapprocher le signal de la manière dont TCP réagit à un épisode de congestion.

Le récepteur calculait des intervalles entre événements, leur appliquait des poids puis en tirait p, le taux d’événements. Une longue période courante sans nouvel événement pouvait réduire le poids du passé. Cette transformation conservait une information utile au contrôle tout en abandonnant le nombre exact de paquets perdus dans un épisode.

Elle n’identifiait donc ni file, ni lien, ni cause physique. RFC 3168 permettait d’inclure un marquage ECN dans le signal de congestion, sans transformer ce marquage en preuve de remise à l’application.

Le même récepteur mesurait X_recv, le débit réellement arrivé, et renvoyait des horodatages. Ces données décrivaient un passé récent. Elles ne réservaient pas le prochain intervalle.

L’émetteur gardait le calcul et les freins

À partir des temps renvoyés, l’émetteur estimait le RTT. Il alimentait ensuite l’équation issue du travail publié dans RFC 2915 avec taille de paquet, RTT, p et un terme de temporisation de retransmission. Le résultat X_calc représentait le débit qu’un modèle TCP Reno pourrait obtenir.

Mais X_calc ne devenait pas directement un train de paquets. En évitement de congestion, l’émetteur retenait une valeur bornée à la fois par l’équation et par deux fois X_recv, avec un plancher très bas lié à l’intervalle maximal de repli. Le modèle limitait l’optimisme du récepteur; l’arrivée mesurée limitait l’optimisme du modèle.

Le changement de rythme avait sa propre règle. La montée ne devait normalement pas dépasser un doublement par RTT et les paquets devaient être espacés. Une autorisation apparente se divisait ainsi en trois contrôles : équation, plafond d’arrivée, puis temporalité.

Un récepteur fautif pouvait sous-déclarer les pertes ou gonfler son débit. Les limites de l’émetteur réduisaient son influence, sans certifier la sincérité du rapport.

Le silence retirait de la marge

Quand aucun retour ne revenait, une temporisation expirait. L’émetteur abaissait alors sa marge, souvent en divisant par deux sa copie de X_recv, puis recalculait. Au démarrage, sans RTT ni rapport antérieur, une réduction directe restait possible.

Le mécanisme ne prétendait pas connaître la cause du silence. Le paquet de retour pouvait être perdu, le chemin aller pouvait être rompu, le récepteur arrêté ou l’application inactive. L’absence de preuve déclenchait une action prudente, non une histoire causale inventée.

Ce détail fixe le partage d’autorité. Le récepteur renseigne; l’émetteur assume. Même lorsque le canal d’observation disparaît, la responsabilité de ne pas surcharger le réseau demeure chez celui qui envoie.

Une spécification révisée ne devenait pas un reçu de livraison

RFC 2914 présentait le contrôle de congestion comme une responsabilité de stabilité. RFC 2581 et RFC 3390 fournissaient le contexte TCP et fenêtre initiale; RFC 3550, celui de RTP.

RFC 4342 plaça ensuite TFRC dans DCCP CCID 3. RFC 4828 étudia les petits paquets. RFC 5348 remplaça RFC 3448. Cette lignée documente une évolution, pas une adoption universelle.

Les reçus restaient distincts : p n’était pas une cause, X_recv n’était pas une capacité, X_calc n’était pas un droit, le débit choisi n’était pas l’acheminement et l’acheminement n’était pas le décodage réussi.

La discipline des couches de réalité de Heng Lu permet de conserver ces frontières. La primauté du code en fonctionnement éclaire les contrôles locaux que l’émetteur applique au lieu d’obéir à un symbole. La spécification initiale minimale aide à lire la retenue du texte : résoudre le contrôle de congestion sans usurper la fiabilité ni le contrat applicatif. C’est une lecture éditoriale ultérieure.

RFC 3448 a ainsi laissé une leçon de responsabilité distribuée. Celui qui observe ne gouverne pas seul; celui qui agit ne peut déléguer sa prudence à une mesure distante.

Sources