Résumé

  • RFC 9840 sépare la capacité réelle du récepteur, fcwnd, de sa cible de transport de fond, RLWND, tout en conservant un émetteur TCP standard.
  • La limite effective est le minimum de cwnd, RLWND et fcwnd ; observer ce minimum ne suffit donc pas à attribuer le ralentissement.
  • Une expérimentation défendable doit archiver les trois candidats, la qualité des mesures d’horodatage, le facteur Window Scale et la convergence imposée par l’interdiction de rétrécir brutalement la fenêtre.

Une valeur, deux signatures locales

La lecture habituelle d’une petite fenêtre annoncée est presque réflexe : l’application distante lit trop lentement ou ses tampons sont pleins. rLEDBAT invalide ce raccourci. Le récepteur peut disposer de mémoire et de capacité applicative, mais choisir délibérément une fenêtre plus basse afin que le transfert d’arrière-plan ne construise pas de file d’attente.

Le document expérimental distingue fcwnd, fenêtre de contrôle de flux, et RLWND, fenêtre calculée par le contrôleur de faible délai supplémentaire. Le récepteur annonce leur minimum. L’émetteur, qui n’a pas été modifié pour rLEDBAT, reste aussi contraint par sa fenêtre de congestion cwnd. Au bout de la chaîne, SND.WND = min(cwnd, RLWND, fcwnd).

La formule est simple ; l’attribution ne l’est pas. cwnd représente l’autorité de congestion de l’émetteur. fcwnd protège la capacité du récepteur. RLWND exprime un choix de priorité fondé sur des observations de délai. Le nombre visible sur le réseau ne conserve pas le nom du gagnant. Un outil qui n’enregistre que la fenêtre annoncée transforme trois causes possibles en une seule apparence.

Ce défaut d’attribution devient politique lorsque plusieurs organisations partagent le flux. Le serveur peut soupçonner le réseau d’accès ; le réseau peut accuser le terminal ; le terminal peut avoir volontairement ralenti la livraison. Le débit final est compatible avec les trois récits. Seul un reçu associant chaque candidat à son origine permet de trancher.

Gouverner l’autre extrémité sans la remplacer

Le mérite de l’architecture est de permettre à un client de téléchargement, de sauvegarde ou de synchronisation de rendre le trafic moins prioritaire alors qu’il ne contrôle pas le serveur. Le mécanisme exploite une règle que tout TCP conforme respecte déjà : ne pas dépasser la fenêtre de réception annoncée. Aucun module rLEDBAT particulier n’est requis chez l’émetteur.

Cette compatibilité n’abolit pourtant ni la congestion ni la responsabilité de l’émetteur. Si cwnd est plus petit, la décision du récepteur ne lie pas le débit. Si une perte est détectée, les mécanismes TCP ordinaires restent décisifs. rLEDBAT ajoute une autorité ; il ne fusionne pas toutes les autorités dans le client.

La différence avec LEDBAT côté émetteur est essentielle. Ici, l’intention « moins que best effort » n’est pas visible comme un algorithme d’émission. Elle voyage implicitement dans une fenêtre qui servait déjà à autre chose. Les inventaires de logiciels et les captures réseau peuvent donc raconter des histoires différentes sans qu’aucun ne mente : le premier connaît la politique, la seconde ne voit que son effet.

Une promesse de séquence ne se retire pas instantanément

La fenêtre TCP définit un espace de numéros de séquence que l’émetteur est autorisé à remplir. Après avoir avancé son bord droit, le récepteur ne peut pas simplement le ramener en arrière pour appliquer une cible plus basse. RFC 9840 réduit la fenêtre annoncée au rythme des octets reçus, de sorte que le bord promis reste stable jusqu’à ce que la cible soit atteinte.

La transition peut occuper environ un RTT. Entre la décision et son expression complète, la trace montre une convergence, non une consigne instantanée. Cette latence est une propriété de sûreté du protocole, pas nécessairement une lenteur du contrôleur.

Il faut donc conserver l’heure de la décision, RLWND visée, la fenêtre annoncée successivement et les octets déjà en vol. Sans cette chronologie, un tableau de bord peut condamner un contrôleur qui respecte précisément les crédits déjà accordés.

Mesurer le délai sans fabriquer une certitude

rLEDBAT s’appuie sur les horodatages TCP. En comparant leur progression aux temps d’arrivée locaux, le récepteur peut suivre la variation du délai aller sans synchroniser les horloges : un décalage constant s’annule. Mais la résolution, la dérive, les valeurs répétées et les particularités d’implémentation subsistent.

Les ACK retardés, les retransmissions et une file sur le chemin retour peuvent brouiller l’interprétation. Certains paquets offrent de meilleurs échantillons que d’autres ; la fin d’un transfert peut masquer une perte de queue faute d’un segment ultérieur révélant le trou. Le contrôleur du récepteur ne devient pas, par magie, un oracle complet de la congestion.

Les filtres et exclusions recommandés doivent apparaître dans la preuve. Une cible RLWND sans nombre d’échantillons, motif d’exclusion, historique du délai de base et résolution d’horodatage n’est qu’un résultat invérifiable.

La granularité décidée avant le besoin

Window Scale permet de représenter de grandes fenêtres, mais chaque unité annoncée vaut davantage d’octets lorsque le facteur augmente. Un contrôleur qui voudrait corriger doucement peut être obligé de sauter entre des marches trop éloignées. RFC 9840 avertit que des facteurs supérieurs à 11 peuvent être trop grossiers et recommande une valeur inférieure à 12, tout en demandant davantage d’expérience.

Ce choix est négocié à l’ouverture de la connexion. Il ne se répare pas aisément au milieu du transfert. Une plateforme optimisée pour de très grandes fenêtres peut découvrir plus tard que sa politique de fond manque de finesse. C’est une décision précoce dont le coût apparaît tardivement ; tout résultat expérimental doit donc publier le facteur d’échelle.

Le statut expérimental porte sur les interactions

RFC 9840 provient de l’IRTF/ICCRG et n’est pas un standard Internet achevé. Le texte signale notamment les interactions entre contrôleurs d’émission et de réception, les environnements AQM et L4S, ainsi que le redémarrage après inactivité. Ce sont les variables centrales, pas des réserves décoratives.

Deux boucles réagissant à des signaux voisins mais à des rythmes différents peuvent osciller. Une file CoDel ou PIE, ou une architecture L4S, change les indices disponibles. Un état de délai de base conservé après une longue pause peut fausser la reprise. La moyenne de débit ne décrit aucun de ces phénomènes.

Une campagne sérieuse doit conserver distribution du délai de file, pertes, marquages ECN, demande applicative, trois fenêtres candidates, phases d’inactivité et famille de contrôle de congestion de l’émetteur. Elle doit aussi distinguer un constat scientifique d’une affirmation de déploiement commercial.

Les documents de Microsoft sur Delivery Optimization et la présentation Apple sur la réactivité réseau montrent que les systèmes d’exploitation arbitrent réellement des transferts de fond. Ils ne prouvent pas qu’une version précise implémente RFC 9840. Le nom du protocole exige une preuve d’implémentation ou une déclaration du fournisseur.

Sécurité d’une boucle alimentée par le temps

Les horodatages et délais d’arrivée ne sont pas des attestations authentifiées de l’état des files. Un adversaire sur le chemin qui retarde ou manipule les observations, voire injecte un ancien segment plausible, peut influencer la cible. L’extension de surface d’attaque décrite par le RFC est modeste, mais un transfert de correctifs durablement repoussé n’est pas un incident négligeable.

Il faut séparer observation brute, échantillon filtré, décision du contrôleur et fenêtre effectivement annoncée. Les modifications de cible et de filtres sont des événements du cycle de vie logiciel, donc auditables. « Trafic de fond » ne signifie pas « télémétrie facultative ».

Sources