Résumé

  • Le RFC 2140, mémorandum informatif paru en avril 1997, proposait que certaines observations d'un bloc de contrôle TCP soient réutilisées entre connexions au même couple de machines. Il ne définissait aucune norme Internet ni un gain de débit mesuré.
  • Après la fermeture d'une connexion, le partage temporel pouvait reprendre MSS et estimation de RTT. Entre connexions simultanées, le partage d'ensemble imposait une autre comptabilité : recopier une fenêtre de congestion à chaque flux augmenterait la charge totale.
  • Une valeur périmée ou altérée pouvait pénaliser d'autres échanges courts. Le texte demandait des bornes de validation, écartait les états modifiés par une application sans autorisation explicite et excluait les numéros de séquence du partage.

Le chiffre survit à la conversation

Une requête brève arrive à son terme. Son bloc de contrôle TCP disparaît, alors que la machine vient de mesurer un aller-retour et de recevoir une option indiquant la taille maximale d'un segment. La requête suivante, dirigée vers le même hôte, pourrait tirer parti de ces observations. Dans le RFC 2140, Joe Touch ne proposait pas de prolonger artificiellement la première session : il cherchait à distinguer ce que la session avait appris du chemin de ce qui appartenait à la conversation elle-même.

Cette distinction traverse le bloc de contrôle. Pointeurs de tampons, files de retransmission, ports, état de la machine et temporisateurs servent une connexion donnée. MSS et RTT peuvent renseigner plusieurs connexions du même couple de machines. Les fenêtres d'envoi et de congestion, en revanche, décrivent aussi l'ensemble du trafic que ces connexions injectent. Les placer dans une cache commune ne leur donne pas le même sens que copier une simple mesure.

Le texte répondait à une difficulté de l'époque : de nombreuses connexions courtes ou simultanées pouvaient passer l'essentiel de leur vie dans la phase d'apprentissage. Il espérait améliorer cette phase initiale sans changer le comportement à long terme d'une connexion établie. Espoir et constat doivent rester distincts : le mémorandum est classé Informational et ne livre pas de mesure prouvant une accélération générale du Web.

Deux horloges pour une cache

Le partage temporel intervient lorsqu'une connexion précédente est déjà fermée. Le RFC cite les extensions T/TCP de SunOS 4.1.3 et leur portage FreeBSD comme exemples limités de cache MSS/RTT. Une option MSS reçue pouvait mettre à jour la valeur conservée immédiatement ; RTT et sa variance étaient agrégés à la fermeture. La réutilisation de snd_cwnd était alors discutée, mais non implémentée dans cet exemple. Même pour RTT, le RFC prévenait que la moyenne entre connexions ne reproduisait pas l'estimation calculée à l'intérieur d'une connexion et pouvait devenir inadaptée.

Le partage d'ensemble concerne plusieurs connexions encore actives. Si la cache n'est écrite qu'à la fermeture, aucune des connexions ouvertes presque en même temps ne bénéficie des observations des autres. Le texte envisage donc des mises à jour plus précoces. Cette avance crée le problème de la fenêtre : chaque nouvelle connexion ajoute déjà sa fenêtre initiale à la somme ; lui donner une copie de la fenêtre d'un flux établi augmente encore la charge possible. Le RFC suggère de répartir une fenêtre agrégée entre N+1 connexions, en réduisant aussi la part des N anciennes. Ses auteurs disent expressément que l'hypothèse d'un partage égal peut ne pas être appropriée et demandent de l'étudier. Ce n'est ni un algorithme de justice validé ni un relevé de déploiement.

Une erreur qui change de propriétaire

Une cache n'apporte pas seulement de l'information ; elle propage aussi ses défauts. Une petite fenêtre falsifiée ou un zéro peuvent ralentir les connexions suivantes, en particulier celles qui se terminent avant de pouvoir corriger leur départ. Le RFC prescrivait une comparaison des valeurs partagées avec les minimums par défaut lors de l'initialisation, des limites pour les données qui modifient l'état partagé en cours de route, et une séparation des valeurs directement modifiées par une application ou transmises sans authentification.

Il rappelait que les numéros de séquence TCP ne sont pas des paramètres de performance à partager.

Le couple de machines reste une approximation du chemin ; il ne certifie ni route inchangée ni capacité disponible. Le RFC 9040 a remplacé le RFC 2140 en 2021 et précisé ultérieurement les champs et leurs limites. Il ne faut pas prêter rétroactivement ces développements à la proposition de 1997. Celle-ci mettait d'abord au jour une question d'attribution : quelle connexion a produit la mesure, quand l'a-t-elle déposée, et quel autre échange peut s'en servir ?

Sources et portée

Ces sources étayent une proposition historique et quelques exemples nommés. Elles ne démontrent ni performance chiffrée, ni identité permanente du chemin, ni adoption universelle ou présente.