Résumé

  • La RFC 3742 ralentit la croissance de la fenêtre TCP après le seuil max_ssthresh, car le démarrage lent exponentiel peut ajouter des milliers de segments en un RTT.
  • L’erratum 236, vérifié, corrige la plage annoncée par RTT : atteindre 83 000 paquets prend au moins 836 RTT dans l’exemple, et non exactement ce nombre.

« Limité » ne signifiait pas « à débit fixe ». La RFC 3742 était une proposition expérimentale facultative pour des connexions dont la fenêtre pouvait atteindre des milliers de tailles maximales de segment. Jusqu’à max_ssthresh, elle conservait l’augmentation classique d’un MSS par accusé de réception. Au-delà, la règle calculait K = int(cwnd / (0.5 * max_ssthresh)) et ajoutait environ un Kᵉ de MSS par ACK. Ce paramètre supplémentaire ne remplaçait pas ssthresh : une fois ce dernier dépassé, le démarrage lent prenait fin.

La présentation des calculs était plus catégorique que ne le justifiait l’algorithme. Le texte initial de la section 2 disait que la croissance au-dessus de max_ssthresh ne dépassait pas la moitié de ce seuil par RTT. Mais la règle appliquée à chaque ACK, avec un K qui augmente par paliers, impliquait une plage. L’erratum 236, vérifié par l’éditeur des RFC, a corrigé l’invariant : la hausse ne dépasse pas max_ssthresh MSS par RTT et n’est pas inférieure à la moitié. Il a aussi remplacé une estimation unique du temps nécessaire par deux bornes. Avec un seuil de 100 MSS et une cible de 83 000 paquets, les 836 RTT souvent cités sont devenus un minimum.

Il s’agit d’une correction de la description, pas d’un nouvel algorithme de contrôle de congestion. Le texte publié en 2004 reste inchangé ; l’erratum constitue un document distinct à lire en parallèle. Il élargit la plage de croissance possible et la durée estimée, sans transformer ses bornes en résultats mesurés universels.

Le plafond visait à la fois le comportement de l’émetteur et ses externalités. Une forte hausse pendant le démarrage lent pouvait provoquer de nombreuses pertes groupées, des expirations du temporisateur de retransmission et le retour de la fenêtre à une valeur faible. Les autres flux empruntant le lien pouvaient eux aussi subir cette rafale. La RFC donnait un exemple à 100 MSS et rapportait des expériences préliminaires sur un noyau Linux 2.4.16 Web100. Ce constat historique ne prouve ni un déploiement généralisé aujourd’hui, ni un gain Internet universel, ni le maintien d’une file sous une taille donnée.

Les documents TCP ultérieurs ont adopté d’autres signaux de contrôle. Pour CUBIC, la RFC 9438 recommande généralement HyStart++ au démarrage lent et cite la Limited Slow-Start comme solution expérimentale. La RFC 9406 utilise plutôt l’augmentation du RTT comme indice de sortie, puis une phase conservatrice qui vérifie si cette sortie était prématurée. Ce signal diffère de l’incrément dépendant de la fenêtre dans la RFC 3742 ; les mécanismes ne sont pas interchangeables.

Pour l’exploitant, l’erratum rappelle qu’un chiffre mis en avant ne dit pas toujours ce qu’un algorithme borne réellement. Une hausse de fenêtre par RTT n’est ni un plafond de débit en octets, ni une mesure de file, ni une preuve d’équité sur un chemin partagé. Le seuil, les ACK, le pacing, le tampon, le RTT et les flux concurrents déterminent ensemble l’effet réel. La correction rend l’incertitude plus visible ; elle ne la supprime pas.

Sources