Résumé

  • L’hôte n’avait pas à diagnostiquer tout l’Internet. Il devait surtout reconnaître la mort de sa passerelle immédiate, seule panne dont l’auteur ne pouvait plus renvoyer de conseil.
  • Un ICMP isolé pendant la convergence restait une observation datée. Les retransmissions et le délai d’abandon signalaient la gravité ; le message d’erreur proposait une cause probable.
  • L’accusé TCP ne prouvait ni la réponse SMTP ni la survie d’une session inactive. L’application devait donc conserver son propre mécanisme de fin et de présence.

Une topologie vraie après une période de désaccord

Le texte de David D. Clark partait d’une architecture dans laquelle les passerelles échangeaient leur opinion la plus récente sur leurs voisines. Après une rupture, leurs cartes pouvaient diverger. Une fois la négociation terminée, elles devaient retrouver une représentation cohérente et un autre chemin.

Cette période rendait les erreurs délicates. ICMP Redirect indiquait une meilleure passerelle immédiate. Destination Unreachable déclarait qu’au moment de l’émission aucune route ne paraissait utilisable. Mais une indication produite au milieu de la convergence pouvait devenir fausse avant même que l’application décide quoi faire.

Rompre une connexion TCP sur un seul Unreachable revenait à interdire au réseau de se réparer sous les extrémités. RFC 816 demandait donc du scepticisme face au message isolé. Il ne prescrivait pas l’ignorance : à l’ouverture d’une connexion, l’erreur pouvait révéler une mauvaise adresse ; après l’expiration d’un délai, elle pouvait expliquer la cause vraisemblable ; Parameter Problem pouvait signaler un défaut d’implémentation.

La valeur dépendait du contexte, du temps et des autres observations. L’erreur avait une provenance et une durée de pertinence, non une souveraineté.

La première passerelle créait un angle mort

Une panne éloignée appartenait principalement aux passerelles qui l’entouraient. Elles pouvaient la détecter et la contourner sans demander à chaque hôte de comprendre toute la topologie. La première passerelle de l’hôte échappait à ce modèle.

Si cette machine s’arrêtait, elle ne pouvait envoyer ni Redirect ni Unreachable. Les paquets continuaient à lui être remis et disparaissaient. Le reste de l’Internet pouvait déjà disposer d’une route correcte : le trafic n’atteignait jamais ce reste du réseau.

RFC 816 identifiait ainsi une tâche spécifique pour l’hôte : détecter la mort de la passerelle à laquelle il remettait effectivement ses datagrammes et essayer une autre passerelle directement accessible. Il ne devenait pas routeur mondial. Il corrigeait un choix local que personne d’autre ne pouvait corriger à travers le composant mort.

La conclusion restait étroite. Une première passerelle muette justifie son remplacement. Elle ne prouve pas que la destination, le service ou l’opération distante ont disparu.

Essayer un autre chemin pouvait être réversible

Le document examinait plusieurs détecteurs. Certains réseaux fournissaient eux-mêmes un signal de machine morte. L’hôte pouvait aussi interroger continuellement sa passerelle avec ICMP Echo. Pour réagir vite, il aurait toutefois fallu produire une charge considérable. Sans analyse explicite de cette charge, cette stratégie était interdite.

L’interrogation déclenchée attendait un indice du niveau supérieur : plusieurs retransmissions TCP pouvaient amener IP à sonder la passerelle. Elle dépensait moins, mais la confirmation pouvait arriver après le délai TCP.

La resélection déclenchée supprimait le sondage préalable. Lorsqu’un niveau supérieur se plaignait, IP essayait la passerelle suivante. Si l’ancienne était morte, la reprise commençait immédiatement. Si elle fonctionnait encore, la nouvelle passerelle pouvait acheminer le paquet et renvoyer un Redirect vers le meilleur choix. L’erreur de sélection avait donc une procédure de retour.

Ce mécanisme faisait de l’incertitude une expérience bornée. Une décision locale rapide restait possible, sans transformer un soupçon en politique définitive.

RFC 1122 a ensuite exigé qu’IP détecte la défaillance d’un prochain saut présent dans le cache de routes et choisisse une solution de remplacement. Il reconnaissait pourtant l’absence d’algorithme universellement satisfaisant, interdisait toujours le ping continu de la première passerelle et préférait les avis positifs ou négatifs provenant de TCP, d’ARP, de la liaison ou d’ICMP.

Le délai disait « assez », pas « pourquoi »

TCP retransmettait un segment jusqu’à son acquittement ou jusqu’à l’expiration de la limite fixée pour la connexion. Les retransmissions pouvaient fournir un avis négatif à IP. En sens inverse, IP transmettait les erreurs ICMP et les rapports du réseau attaché.

Ces faits ne se remplaçaient pas. La retransmission constatait l’absence de progrès. Le délai utilisateur fixait le moment où le client cessait d’attendre. Le message réseau suggérait une explication. RFC 816 voulait que ces éléments remontent jusqu’au module qui connaissait le but de la connexion.

Il distinguait notamment le programme d’envoi de courrier et la personne devant Telnet. Le programme avait besoin d’une règle de fin. La personne pouvait accepter d’attendre longtemps ou interrompre plus tôt selon les détails visibles. D’où la nécessité d’un signal asynchrone plutôt que d’une décision cachée au fond de TCP.

RFC 1122 a formalisé le traitement des erreurs dites souples : certains Destination Unreachable ne devaient pas faire interrompre la connexion et leur information devait être accessible à l’application. RFC 5461 a décrit le compromis. Attendre préserve les connexions lors d’une reconstruction transitoire ; attendre sur une première adresse définitivement inaccessible retarde l’essai de la suivante. Les raccourcis documentés pour l’établissement restaient non standards.

RFC 9293 distingue toujours le délai de retransmission, qui renvoie un segment, du délai utilisateur, qui vide les files, signale l’abandon et ferme. Le mot « délai » ne désigne pas une autorité unique.

Deux échecs que TCP ne pouvait pas conclure

Le courrier offrait un premier contre-exemple. Des récepteurs précoces pouvaient obtenir tout le texte, donc l’acquitter au niveau TCP, puis s’arrêter avant l’accusé SMTP. Aucun octet n’était en attente ; le minuteur de retransmission ne voyait rien. Seul l’expéditeur SMTP savait quelle réponse finale manquait.

Un minuteur applicatif était nécessaire, mais sa valeur dépendait de l’opération. Trop court, il punissait les gros messages envoyés normalement vers un hôte lent. Trop long, il révélait tardivement la panne. Plusieurs programmes liaient alors la durée à la taille du message. L’enseignement n’est pas le nombre retenu, mais la compétence du niveau qui le retenait.

Telnet montrait le cas inverse. La liaison pouvait mourir pendant que l’utilisateur réfléchissait. Sans donnée à envoyer, le serveur ne possédait aucun segment non acquitté et pouvait attendre indéfiniment. Une interrogation périodique de l’application aidait, à condition de ne pas recréer une tempête de sondages pour tous les utilisateurs inactifs.

Dans un cas, tous les octets étaient acquittés sans achèvement. Dans l’autre, aucune activité n’existait pour provoquer l’alarme. TCP répondait correctement à sa question ; l’application devait encore répondre à la sienne.

La limite donnait sa force au conseil

RFC 816 assemblait donc plusieurs vérités partielles. Le routage corrigeait les pannes éloignées. L’hôte remplaçait sa première passerelle silencieuse. TCP rendait visibles retransmissions et fin de patience. L’application attestait l’opération.

Un signal ne gagnait pas en précision parce qu’il était le premier disponible ou le plus facile à automatiser. L’architecture conservait au contraire sa provenance et transmettait l’incertitude au niveau capable de décider.

Le message d’erreur restait précieux parce qu’il ne tranchait pas tout. Il permettait une reprise locale, une explication probable et une décision informée, tout en laissant au réseau le temps de converger et à l’application l’obligation de prouver sa propre promesse.

Sources