Résumé

  • draft-ietf-ccwg-ratelimited-increase-11 autoriserait une croissance limitée de la fenêtre lorsque l’application ou le contrôle de flux du récepteur bride l’envoi.
  • La valeur maxFS rattache cette croissance au plus grand volume réellement en vol depuis la dernière réduction ; elle ne prouve ni la capacité ultérieure du chemin, ni l’ouverture du récepteur, ni la réussite du prochain envoi.

Une connexion dispose d’une fenêtre de vingt segments. L’application n’en fournit que quatre, tous acquittés. Aucun signal de congestion n’apparaît et l’algorithme conserve une marge confortable. Il serait tentant de lire cette marge comme une ressource disponible.

Or personne, dans le réseau, n’a réservé les seize segments inutilisés.

Le projet draft-ietf-ccwg-ratelimited-increase-11, publié le 6 septembre par le groupe CCWG de l’IETF, cherche à rendre cohérents des comportements aujourd’hui différents dans TCP, QUIC, SCTP, DCCP et CUBIC. Certains textes empêchent toute hausse lorsque le flux n’utilise pas sa fenêtre. D’autres peuvent laisser cwnd grandir bien au-delà du volume récemment éprouvé. Le compromis proposé accepte une hausse, mais lui impose une référence observable.

Le terme rate-limited désigne ici un émetteur qui envoie moins que ce que la congestion lui permettrait. Il peut manquer de données applicatives. Le récepteur peut aussi limiter le crédit d’une connexion ou d’un flux. Dans les deux cas, FlightSize—les données expédiées qui ne sont pas encore acquittées cumulativement—reste inférieur à cwnd. Cette sous-utilisation ne signifie pas que le réseau a refusé les paquets.

maxFS mémorise le plus grand FlightSize depuis la dernière baisse de la fenêtre. Une nouvelle mesure ne le remplace que si elle est supérieure. Toute réduction de cwnd, quelle qu’en soit la raison, remet ce souvenir à zéro. L’augmentation suivante ne doit pas dépasser limit(maxFS), c’est-à-dire le niveau que l’algorithme aurait atteint après les ACK correspondant à une fenêtre complète de cette taille. L’exemple en Slow Start donne 2*maxFS; en Congestion Avoidance, la limite devient maxFS+SMSS.

Cette règle ne récompense donc pas le vide. Elle évite qu’une application intermittente soit toujours traitée comme une nouvelle venue, sans permettre à un état jamais exercé de gonfler indéfiniment. L’ACK d’un volume effectivement parti justifie une évolution bornée du contrôle. Il ne valide pas l’espace que l’application n’a pas utilisé.

Le projet reconnaît aussi qu’une bonne mesure vieillit. Si aucun mécanisme ne réduit la fenêtre pendant une longue période de faible activité, maxFS peut ne plus représenter le chemin de bout en bout. RFC 7661 traite ce problème avec Congestion Window Validation et sa variable pipeACK, construite à partir du volume acquitté durant une période de mesure. FlightSize décrit un instant ; pipeACK consolide une observation récente. Aucun des deux ne constitue un droit sur la capacité future.

Trois commandes restent indépendantes. L’application décide si des octets existent. Le récepteur ouvre ou ferme son crédit. Le contrôle de congestion borne l’injection selon les signaux du réseau. Une grande cwnd ne produit pas de données, ne force pas le récepteur à accepter davantage et ne garantit pas que la route, les files, les policers ou les flux concurrents sont restés identiques.

Il faut également isoler le pacing. Une pile peut être autorisée à garder davantage de données en vol tout en espaçant les paquets. Le projet laisse cette technique intacte ; il ne prouve pas qu’une implémentation l’a activée ni qu’un offload n’a pas recréé une rafale. Seules la configuration effective et l’observation du trafic peuvent le montrer.

Enfin, un ACK parle de données antérieures selon les règles d’un protocole. Il peut alimenter la récupération de perte et l’estimation de congestion. Il ne prédit ni le prochain crédit du récepteur, ni l’état d’une nouvelle route, ni le résultat applicatif. Même authentifié, il n’est pas le mandataire du réseau futur.

S’il est approuvé, le projet mettra à jour les RFC 4341, 5681, 9002, 9260 et 9438. Il reste cependant un Internet-Draft modifiable et ne demande aucune action IANA. Publication du standard, présence dans le code, activation et résultat de production doivent garder des justificatifs distincts.

Sources