La fenêtre qui apprit la retenue : comment TCP évita l’effondrement sans police du trafic

Résumé

• En octobre 1986, le débit utile entre le Lawrence Berkeley Laboratory et l’UC Berkeley passa de 32 Kbit/s à 40 bit/s : le réseau travaillait encore, mais surtout à transporter des copies inutiles.
• Jacobson, Karels et leurs collaborateurs modifièrent le TCP de 4BSD autour d’un principe de conservation des paquets : horloge des accusés de réception, démarrage lent, meilleurs temporisateurs, recul exponentiel et fenêtre de congestion.
• RFC 1122 transforma ensuite cette discipline éprouvée en obligation pour les hôtes TCP. La décentralisation fut préservée par une règle commune étroite, non par l’absence de règles.

Une distance minuscule, une chute gigantesque

Les deux sites n’étaient séparés que d’environ 400 yards. Pourtant, en octobre 1986, le transfert de données du Lawrence Berkeley Laboratory vers l’université de Californie à Berkeley, par deux sauts IMP, s’effondra de 32 Kbit/s à 40 bit/s. Ce chiffre, publié par Van Jacobson et Michael J. Karels, ne décrit pas un Internet entièrement arrêté. Il révèle quelque chose de plus instructif : une ligne pouvait rester saturée tout en ne livrant presque plus de données nouvelles.

L’engorgement ordinaire ralentit le service. L’effondrement de congestion détruit le travail utile. Des temporisateurs mal adaptés prenaient des paquets retardés pour des paquets perdus. L’émetteur renvoyait alors une copie dans des files déjà pleines. Ce surcroît augmentait délais et pertes, donc déclenchait de nouvelles copies. Le mécanisme de réparation entretenait la panne.

John Nagle avait donné un nom et une première analyse à ce cercle vicieux dans RFC 896, en 1984. Mais ce texte appelait à la discussion ; il ne constituait pas un remède complet et normalisé. L’épisode de 1986 donna aux ingénieurs de Berkeley une expérience mesurable. Leur question ne fut pas « qui doit gouverner tout le trafic ? », mais « que fait réellement notre TCP lorsqu’un chemin va très mal ? ».

Le récepteur ne connaissait pas la route

La fenêtre de contrôle de flux de TCP protégeait le tampon du destinataire. Elle disait combien de données ce dernier pouvait accepter, pas combien le chemin intermédiaire pouvait absorber. Une machine rapide reliée à un réseau local pouvait donc expédier d’un coup toute la fenêtre vers une liaison longue distance beaucoup plus lente. La première passerelle recevait une rafale hors de proportion avec son débit de sortie.

Jacobson et Karels ont relié plusieurs corrections, plutôt que de chercher un bouton unique. Le calcul du délai aller-retour intégrait sa variation, afin de ne plus retransmettre des données simplement en retard. Les tentatives répétées s’écartaient par recul exponentiel. Au démarrage, une petite fenêtre de congestion s’ouvrait à mesure que les accusés de réception revenaient. Ce « slow start » n’était d’ailleurs pas lent : la fenêtre croissait rapidement sur plusieurs allers-retours, mais chaque augmentation reposait sur une preuve fournie par le chemin.

Le principe commun était la conservation des paquets. À l’équilibre, un nouveau paquet n’entre que lorsqu’un ancien est sorti. Les accusés de réception servent d’horloge : leur espacement reflète le passage des données par le goulot. L’émetteur obtient ainsi un rythme sans connaître la topologie et sans demander une allocation à un centre.

La congestion ajoutait une autre limite locale. Après un signal de perte, la fenêtre était réduite de façon multiplicative ; en l’absence de congestion, elle augmentait par petits pas additifs. L’envoi restait borné par la plus petite des deux fenêtres, celle du récepteur et celle de congestion. Le contrôle se trouvait donc principalement à la périphérie, là où la décision d’émettre était prise.

Le code avant le MUST

L’article de 1988 énumère sept changements introduits dans TCP 4BSD. Outre les algorithmes les plus célèbres, il mentionne la politique d’ACK du récepteur, le fast retransmit et le travail de Phil Karn. Il crédite John Nagle pour le nom slow start et indique que la politique de fenêtre s’inspire d’une proposition de Raj Jain. La bonne histoire n’est donc pas celle d’un héros solitaire, mais celle d’un programme d’implémentation qui rassembla des idées, les mit en code et les soumit à des traces.

Les mesures furent parlantes. Dans un essai à quatre flux sans évitement de congestion, 4 000 des 11 000 paquets transmis étaient des retransmissions et une part importante du débit utile disparaissait. Avec le contrôle, seules 89 transmissions sur 8 281 étaient des reprises, soit environ 1 %, et la capacité de la liaison était retrouvée. Le résultat comptait davantage qu’un vote sur la beauté de l’algorithme.

RFC 1122 arriva en octobre 1989. Il déclara insuffisant le temporisateur de RFC 793 et exigea que TCP mette en œuvre l’algorithme combinant slow start et congestion avoidance. Le recul exponentiel des délais de retransmission devint lui aussi obligatoire. Une pratique ayant prouvé sa valeur dans le réseau en fonctionnement fut ainsi élevée au rang d’attente commune entre hôtes.

Une liberté qui ne facture pas les autres

Le mot MUST empêche de raconter cette histoire comme un pur volontarisme. Un TCP conforme ne pouvait plus choisir librement d’ignorer la congestion. Cette contrainte restait pourtant très différente d’une administration épaisse. Elle visait un mécanisme précis par lequel un émetteur faisait payer aux autres ses propres rafales et ses copies.

Un flux agressif peut gagner quelques instants tandis que les flux disciplinés reculent. Si les fabricants vendent cette agressivité comme un TCP « plus rapide », chacun a intérêt à tricher. RFC 2914 décrira plus tard le risque d’une spirale : protocoles toujours plus offensifs, multiplication des connexions parallèles, puis retour à l’engorgement chronique.

La règle commune protégeait donc une vaste zone de choix. Systèmes, applications, routes et nouveaux algorithmes restaient divers. Ce qui n’était pas libre était la création d’une instabilité partagée. L’interopérabilité incluait une obligation de réciprocité : écouter un signal crédible et diminuer sa pression.

La frontière du modèle

Les auteurs n’ont pas prétendu régler l’équité. Les hôtes peuvent empêcher une surcharge persistante, écrivaient-ils, mais seules les passerelles voient les flux converger et disposent d’assez d’informations pour agir sur leur partage. La détection côté passerelle était présentée comme l’étape suivante.

Les décennies suivantes ont ajouté ECN, la gestion active des files et de nombreux contrôleurs. Une perte n’indique pas toujours une congestion, notamment sur des liens radio. L’algorithme de 1988 ne doit donc pas être figé en orthodoxie. Son enseignement tient à sa méthode : isoler la boucle qui détruit le service, modifier la plus petite surface efficace, mesurer le code et ne normaliser que ce dont la stabilité commune a besoin.

Sources et limites des preuves

Les faits centraux viennent de Congestion Avoidance and Control et de l’index du LBNL Network Research Group. La généalogie normative passe par RFC 896, RFC 1072, RFC 1122, RFC 2001, RFC 2914 et RFC 5681. Les échanges d’époque sont recensés par les archives NRG.

La chute de 32 Kbit/s à 40 bit/s concerne un chemin documenté, non chaque liaison. Dire que Jacobson « sauva seul l’Internet » écraserait les collaborations et les travaux ultérieurs ; cet article retient le mécanisme vérifiable plutôt que la légende.