Résumé

  • La méthode approuvée plafonne la croissance de la fenêtre d’un émetteur limité par l’application ou le récepteur à partir du plus grand volume réellement en vol depuis la dernière réduction de cwnd.
  • Un ACK recevable atteste la livraison de données émises ; il n’atteste pas qu’une capacité jamais essayée puisse devenir un crédit illimité.

Vingt-quatre dans le compteur, dix sur le chemin

L’exemple du document part d’une fenêtre initiale de dix segments. L’émetteur transmet les dix, puis s’arrête. Sans perte et avec un ACK par segment, le démarrage lent fait passer cwnd de dix à vingt.

L’application livre ensuite quatre segments. Ils partent et sont acquittés. Sans limite particulière, ces quatre ACK font monter cwnd à vingt-quatre. Or le chemin n’a jamais porté plus de dix segments durant un RTT.

Les ACK sont exacts. Ils répondent à de vrais paquets. L’erreur consiste à faire de la réussite d’un petit vol contraint une autorisation portant sur un espace que l’émetteur n’a jamais occupé.

Ce cas n’est pas un incident. Il écarte volontairement pertes, ACK différés, comptabilité en octets et variations de chemin afin d’isoler la question de pouvoir : quelle observation autorise l’hôte à accroître la quantité de données non acquittées qu’il peut injecter ?

Une approbation, pas encore un déploiement universel

L’annonce du 24 août, 17 h 57 UTC, approuve la révision 10 de « Increase of the Congestion Window when the Sender Is Rate-Limited » comme Proposed Standard. Le texte du Congestion Control Working Group met à jour DCCP CCID 2, TCP, QUIC, SCTP et CUBIC.

Au gel des preuves du 28 août, Datatracker le présentait encore comme Active Internet-Draft dans la file du RFC Editor, avec une réponse d’auteur attendue. Il ne demande aucune action IANA. L’accord de l’IESG, le numéro de RFC, l’intégration dans une version, l’activation par défaut et le résultat observé sont cinq faits distincts.

L’annonce mentionne plusieurs implémentations et une lignée Linux remontant à la version 3.16. C’est une preuve de faisabilité et d’expérience. Ce n’est pas l’inventaire des noyaux, bibliothèques QUIC ou équipements réellement actifs chez un opérateur.

Identifier celui qui retient l’émission

Un flux peut disposer d’une grande cwnd et envoyer peu. L’application peut manquer de données. Le récepteur peut réduire rwnd ou le crédit de connexion et de flux QUIC. Un mécanisme de pacing peut espacer les paquets.

Le document distingue le flux cwnd-limited, qui utilise l’autorisation offerte par cwnd, du flux rate-limited qui, au sens de RFC 7661, n’en consomme pas plus de la moitié et se trouve dans une phase non validée.

Cette distinction répartit les responsabilités. Le transport fixe la fenêtre. L’application fournit les octets. Le récepteur ouvre son crédit. Le pacer décide du moment de départ. Le chemin renvoie pertes, ECN, délai et livraison. Une métrique unique d’« utilisation » ne dit pas quelle surface a fermé le robinet.

Cwnd n’est donc pas une mesure de bande passante. Elle est une permission locale de garder un volume non acquitté en vol. Elle ne certifie ni la réserve du lien, ni la disponibilité de l’application distante, ni la permanence du trajet.

maxFS lie le crédit à un usage réel

La nouvelle méthode conserve maxFS, le plus grand FlightSize observé depuis la dernière baisse de cwnd. La valeur est initialisée à la fenêtre initiale, puis prend le maximum entre son état et chaque mesure de vol.

Toute réduction de cwnd remet maxFS à zéro. Le premier vol suivant établit une nouvelle base. Une réaction à la perte ou à ECN ne réduit donc pas seulement la permission présente ; elle clôt aussi l’autorité de l’ancienne observation maximale.

Quand FlightSize < cwnd, les ACK peuvent encore déclencher une augmentation, mais cwnd ne doit pas dépasser limit(maxFS). Cette limite correspond à la valeur que l’algorithme aurait atteinte après l’acquittement réussi d’une fenêtre complète de taille maxFS.

En démarrage lent RFC 5681, la limite d’exemple vaut deux fois maxFS. En évitement de congestion, elle vaut maxFS plus un SMSS. La méthode conserve donc le bénéfice des ACK tout en bornant leur portée.

Dans le scénario dix plus quatre, cwnd peut atteindre vingt après le premier vol. Les quatre ACK suivants ne sont pas ignorés, mais ils ne permettent pas de franchir vingt. Un vol futur supérieur à dix déplacera maxFS et donnera une base réelle à une limite plus haute.

Une convergence qui ne rend pas les codes identiques

TCP ne plafonnait pas explicitement cette croissance. DCCP CCID 2 pouvait continuer à grandir sans être limité par cwnd. QUIC déconseillait toute augmentation quand la fenêtre était sous-utilisée. SCTP et CUBIC appliquaient eux aussi des restrictions plus conservatrices dans certaines phases.

Le nouveau texte remplace ces hypothèses divergentes par un plafond commun. Il autorise davantage que l’arrêt total côté QUIC, SCTP ou CUBIC, tout en empêchant TCP et DCCP de tirer un crédit sans borne d’une petite quantité de données.

Un contrôle fondé sur un débit doit rester sous le débit soutenu maximal qu’aurait permis la méthode cwnd. Le pacing reste compatible s’il change l’espacement sans changer le volume en vol par RTT. Pour un algorithme hybride comme BBR, il faut suivre séparément estimation de débit, pacing, cwnd et échantillon limité par l’application.

Une ancienne mesure peut survivre à son chemin

Le texte reconnaît un risque : sans réduction de cwnd, maxFS peut vieillir et ne plus représenter le chemin de bout en bout. Une bascule mobile, un changement de route, de tunnel ou de politique de file peut intervenir sans réinitialisation commode.

RFC 7661 traite le problème voisin de validation d’une fenêtre devenue supérieure au vol récent et définit pipeACK. Il ne faut pas fusionner les deux mécanismes. L’un borne l’augmentation ; l’autre gère la validité d’une fenêtre sous-utilisée et la réaction à la congestion.

La conservation d’un maximum évite de réapprendre après chaque pause applicative. Mais un maximum privé de date, de chemin et d’historique de réductions devient une mémoire sans provenance.

L’ACK est une preuve limitée

Le contrôle de congestion suppose que le récepteur acquitte correctement les données. La résistance aux manipulations dépend des propriétés d’authentification et de protection du transport.

Même authentique, un ACK ne dit pas tout. Il confirme la réception des octets concernés. Il ne promet ni capacité inutilisée, ni RTT futur, ni équité, ni stabilité de route. Il faut donc journaliser séparément la recevabilité de l’ACK, les données reconnues et la croissance que l’algorithme local a autorisée.

Le code Linux actuel de Reno vérifie que le flux est cwnd-limited avant le démarrage lent ou l’augmentation additive. CUBIC utilise la même barrière avant son calcul. Ces sources montrent une discipline d’exécution ; elles ne prouvent pas la configuration d’un parc donné.

La chaîne utile relie version et transport, état de l’application, crédit du récepteur, pacing, cwnd, FlightSize, maxFS, seuil de démarrage lent, octets acquittés, perte ou ECN, plafond calculé, identité du chemin, rafale de reprise et résultat de livraison. Le document fixe une règle minimale ; l’exécution mesurée décide si la permission était prudente.

Sources