Résumé

  • La RFC 1106 proposait un NAK consultatif et une fenêtre de réception TCP sur 30 bits. Elle déclarait ces extensions mises en œuvre avec des ressources de la NASA, tout en les qualifiant d’expérimentales et non proposées comme norme Internet.
  • La RFC 1110 identifia deux mois plus tard une condition absente du succès local : la fenêtre grandissait sans agrandir l’espace de séquence de 32 bits. Un numéro pouvait être réutilisé après quatre allers-retours et un ancien doublon redevenir recevable.
  • Le NAK ne constatait qu’un trou au point de réception. Il ne distinguait ni retard et perte définitive, ni bruit et congestion, et n’attestait pas la retransmission, la récupération ou la livraison.

L’expérience avait un résultat, mais aussi une frontière

La RFC 1106, signée R. Fox et datée de juin 1989, emploie une formulation précise. Deux extensions de TCP avaient été implémentées et montrées en fonctionnement grâce à des ressources de la NASA. La même déclaration de statut les présentait comme protocole expérimental, point de départ pour la recherche, et non comme proposition de norme Internet.

Il n’est pas nécessaire d’affaiblir la première phrase pour respecter la seconde. Le code avait tourné. Des hôtes avaient négocié un état et produit des mesures dans l’environnement installé. La portée légitime s’arrêtait aux conditions effectivement présentes.

Le résumé du document nommait lui-même ce qui restait ouvert : bruit ou congestion, et applicabilité à l’infrastructure Internet entière plutôt qu’à des réseaux au produit bande passante-délai élevé. Le cas d’usage décrit était celui d’un réseau satellitaire isolé. Une conclusion sérieuse devait transporter cette enveloppe avec le chiffre de performance.

Aujourd’hui, la fiche du RFC Editor classe le texte Historic dans le flux Legacy, avec la RFC 6247 comme successeur de statut. L’IETF Datatracker conserve le dossier. Ce classement ultérieur renseigne l’adoption et l’autorité présentes ; il ne nie pas l’expérience bornée de 1989.

Le récepteur savait qu’il manquait quelque chose

Le premier mécanisme était un accusé négatif. Sur un trajet long, attendre l’expiration normale pouvait vider le « tuyau ». Dès qu’un segment arrivé révélait une discontinuité, le récepteur pouvait demander la retransmission des données nécessaires pour faire avancer le bord gauche de la fenêtre.

Cette rapidité s’achetait par une incertitude assumée. La RFC 1106 écrivait que le récepteur ne pouvait distinguer des données simplement tardives de données perdues pour toujours. Le même trou observé pouvait donc conduire à une retransmission utile ou à un doublon inutile.

Le NAK était consultatif et non fiable. Il n’avait pas son propre mécanisme de renvoi. L’émetteur pouvait ne rien faire ou retransmettre immédiatement ; si le NAK disparaissait, TCP devait finir par se rétablir autrement. Le journal légitime séparait alors cinq événements : trou vu, demande envoyée, demande reçue, retransmission effectuée, données finalement acceptées. Aucun ne valait preuve des suivants.

Le trou n’expliquait pas non plus le trajet. Une file congestionnée, une liaison bruitée, un réordonnancement ou un retard inhabituel donnaient la même absence locale. L’observateur qui constatait le manque ne possédait pas automatiquement l’observation nécessaire pour en attribuer la cause.

La fenêtre mesurait une disposition du récepteur

La seconde proposition voulait dépasser les 64 Kio de la fenêtre TCP sur 16 bits. Quand le produit bande passante-délai était plus grand, cette limite empêchait de conserver assez de données non acquittées en vol. RFC 1106 proposait une représentation sur 30 bits, avec les bits inférieurs dans l’en-tête ordinaire et les bits supérieurs dans une option.

Les deux extrémités devaient accepter le mécanisme dans SYN et SYN-ACK. Chaque segment suivant devait transporter les bits supérieurs. Cet accord prouvait une convention commune entre deux implémentations ; il ne prouvait pas que la convention restait sûre sous toutes les propriétés d’un chemin Internet.

Une fenêtre de réception n’était d’ailleurs pas une capacité de réseau. Elle annonçait ce que la mémoire et la politique du récepteur pouvaient accueillir. La RFC 1106 avertissait qu’une valeur arbitrairement grande pouvait épuiser les buffers, faire tomber une machine ou priver les autres travaux de ressources. Le contrôle envisagé à la NASA consistait à réserver la demande de grandes fenêtres à certains programmes. Cette restriction locale n’allouait aucune bande passante sur le trajet.

Le paquet ancien trouva une fenêtre nouvelle

La courte RFC 1110, publiée en août par A. McKenzie, déplaça l’observation hors du banc d’essai. Internet pouvait perdre, désordonner et dupliquer. Les numéros de séquence TCP sur 32 bits n’étaient pas uniques à jamais ; la petite fenêtre et une limite de durée de vie rendaient leur réutilisation effectivement sûre.

Dans le calcul de RFC 1110, une fenêtre sur 16 bits ne représente qu’un 65 536e de l’espace de séquence : un numéro ne revient qu’après 65 536 allers-retours. Avec une fenêtre sur 30 bits et le même espace, il pouvait revenir après quatre. Un NAK pouvait créer un doublon après un seul aller-retour. Un paquet retenu dans le réseau pendant environ cinq allers-retours risquait donc de réapparaître quand son numéro entrait dans un cycle ultérieur et d’être pris pour une donnée actuelle.

L’objection ne falsifiait pas le test. RFC 1110 envisageait qu’un réseau satellitaire isolé soit sans mémoire : livraison dans l’ordre ou perte, sans longue rétention suivie d’un réordonnancement. Le mécanisme pouvait y fonctionner. L’Internet général autorisait un ensemble d’états plus large, et c’est cette extension de périmètre qui échouait.

La suite sépara les remèdes au lieu de garder le paquet

La RFC 4614 qualifia plus tard RFC 1106 de défectueuse pour l’usage général et RFC 1110 de texte qui la dépréciait. Elle constata l’absence d’adoption par la communauté élargie, tout en mentionnant un usage de NAK dans SCPS-TP. Cette exception ne transformait pas l’ensemble RFC 1106 en pratique Internet.

La RFC 6247 fit passer formellement les deux textes au statut Historic en 2011 parmi des extensions qui n’avaient jamais connu d’usage répandu. « Non répandu » ne signifie pas « jamais exécuté ». Le vocabulaire permet de conserver la mise en œuvre bornée et l’échec d’adoption sans sacrifier l’un à l’autre.

La RFC 7323 normalisa ensuite une autre mise à l’échelle de fenêtre, offerte dans les SYN plutôt que répétée comme celle de RFC 1106. La description des pertes repose sur SACK ; la protection contre les anciens doublons après bouclage utilise les horodatages et PAWS. Rien ne permet d’en déduire une filiation directe. La séparation technique rappelle cependant que capacité de réception, connaissance des segments manquants et validité temporelle ne sont pas une seule variable.

Une preuve de test doit garder son monde avec elle

L’objet d’archive utile contient la version du code, la topologie, le modèle d’erreur, les durées possibles de séjour des paquets, le réordonnancement, la duplication, les buffers, les fenêtres négociées, le trafic et les points d’observation. Il contient aussi les états délibérément absents.

Réduire ce dossier à « fonctionne » donne au résultat une universalité qu’il n’a pas observée. Le réduire à « Historic » commet l’erreur inverse et efface un essai réel. L’histoire de RFC 1106 et RFC 1110 devient rigoureuse lorsqu’elle conserve ensemble le succès local et la condition qui empêchait sa généralisation.

Sources