Résumé

  • Le Silly Window Syndrome n’est pas un petit segment isolé, mais une boucle stable où chaque faible avancée de fenêtre engendre le segment réduit suivant.
  • TCP rompt cette boucle des deux côtés : le récepteur retarde les minuscules mises à jour, l’émetteur attend une occasion utile d’envoyer, et une temporisation évite que cette patience ne devienne un blocage.

Le problème commence par une vérité incomplète. L’application destinataire vient de lire cinquante octets dans un tampon presque plein. Il existe donc réellement cinquante octets de place. Si TCP les annonce immédiatement, l’émetteur peut envoyer cinquante octets. Quand ceux-ci sont reçus puis consommés, la même place se libère de nouveau. Une mise à jour exacte appelle un segment exact, dont l’accusé de réception prépare une nouvelle ouverture identique. Pris séparément, chaque échange est correct. Mis bout à bout, ils enferment le transfert dans une cadence absurde.

C’est cette cadence que RFC 813 a appelée, en 1982, « Silly Window Syndrome ». David Clark y décrit une dégradation qui s’installe au cours d’un transfert long : une frontière naturelle divise une fois la fenêtre utilisable, puis les accusés de réception et les nouvelles annonces perpétuent cette division. Le flux ne retrouve plus spontanément de gros segments tant qu’une interruption ou une autre anomalie ne casse pas le cycle.

Le coût ne se limite pas à quelques en-têtes supplémentaires. RFC 813 rapporte que de mauvaises stratégies de fenêtre pouvaient alors détériorer de plusieurs facteurs le débit comme l’utilisation du processeur. Le texte cite des cas historiques où le segment moyen ne représentait qu’un dixième de la taille acceptable pour les deux hôtes et où les retransmissions se multipliaient. Ces chiffres documentent les observations du début des années 1980 ; ils ne décrivent pas automatiquement les systèmes contemporains. Ils montrent toutefois pourquoi le phénomène relevait de l’architecture du transport, pas d’une simple préférence d’optimisation.

Pour comprendre la boucle, le mémo distingue la fenêtre offerte par le récepteur de la fenêtre utilisable calculée par l’émetteur. Ce dernier doit retrancher les données déjà envoyées mais pas encore acquittées. Une fenêtre offerte de 1 000 octets ne laisse donc que 50 octets utilisables si 950 sont encore en vol. Envoyer ces 50 octets, puis recevoir une ouverture supplémentaire de 50, reproduit exactement la même occasion réduite. La petite taille se transmet d’un tour au suivant.

La solution côté récepteur consiste à ne pas confondre mémoire disponible et crédit à publier sans délai. Après avoir libéré une petite quantité, le récepteur maintient fixe le bord droit de la fenêtre annoncée. Il garde la place en réserve, puis la rend visible d’un seul coup lorsqu’un volume utile s’est accumulé. Une attente trop prudente peut laisser le pipeline se vider et ajouter un délai. Une ouverture trop empressée peut, elle, réduire le débit tout en consommant réseau et processeur. RFC 813 recommande de pencher du côté de la retenue et d’attendre au moins de quoi autoriser un segment raisonnablement grand.

RFC 1122 transforme ensuite ce principe en exigence pour les hôtes. Sa section 4.2.3.3 impose au TCP récepteur un algorithme d’évitement du SWS. La règle proposée maintient RCV.NXT + RCV.WND constant jusqu’à ce que l’espace libre encore non annoncé atteigne le plus petit de deux seuils : une fraction du tampon de réception ou un MSS d’émission effectif. La fraction recommandée vaut un demi. Avec un tampon réaliste, l’ouverture se fait ainsi souvent par unités proches d’un segment plutôt que par miettes.

L’émetteur doit exercer une retenue symétrique. RFC 1122 §4.2.3.4 lui impose également un algorithme SWS. Il peut envoyer lorsqu’un segment de taille maximale tient dans la fenêtre utilisable, lorsque toutes les données marquées pour poussée peuvent partir sous les conditions indiquées, lorsqu’au moins la moitié de la plus grande fenêtre observée peut être exploitée, ou lorsqu’une temporisation de dérogation expire. Une petite fenêtre utilisable est donc une autorisation, non une obligation d’expédier immédiatement.

Le récepteur connaît la taille de son propre tampon ; l’émetteur, non. Celui-ci estime la capacité à partir de la plus grande fenêtre qu’il a observée pendant la connexion. Or le récepteur peut modifier son tampon. Si l’émetteur attendait indéfiniment une fraction d’un ancien maximum devenu irréaliste, son souci d’efficacité pourrait créer un blocage. La temporisation de dérogation sert précisément à briser cette attente. RFC 9293 conserve une plage recommandée de 0,1 à 1,0 seconde, sans que cela permette d’affirmer ce que choisit chaque pile en production.

La spécification TCP consolidée de 2022 préserve l’architecture. RFC 9293 exige un mécanisme SWS chez l’émetteur comme chez le récepteur. Elle rappelle aussi que l’algorithme de Nagle a un rôle complémentaire, pas identique. Nagle freine les petits segments lorsque l’application fournit elle-même les données par petites quantités. L’évitement SWS côté émetteur traite les petits segments provoqués par l’avancée parcimonieuse du bord droit de la fenêtre.