Résumé

  • RFC 3155 distinguait le signal observé de sa cause réelle : ACK dupliqués, trou de séquence ou expiration d’un temporisateur justifiaient une réaction prudente, sans prouver congestion, erreur de transmission, réordonnancement ni perte sur le chemin retour.
  • Fast Retransmit/Fast Recovery, SACK, D-SACK et NewReno amélioraient la reprise tout en conservant le contrôle de congestion. Ils décrivaient l’arrivée et la réparation, non l’endroit ni le mécanisme de la disparition.
  • Une preuve complète relie la liaison, les files, les deux sens du trajet, l’état de la fenêtre, la retransmission, le réassemblage et le résultat applicatif. Le retour d’un flux d’octets ordonné ne suffit pas à prouver un service réussi.

La fenêtre se souvenait d’un risque qu’elle ne savait pas nommer

Le contrôle de congestion de TCP avait appris à prendre la perte au sérieux. Lorsque les accusés de réception cessaient d’avancer, l’émetteur réduisait son ambition. Ce comportement ne constituait pas une mesure directe de la file d’un routeur ; c’était une règle de sûreté bâtie pour un Internet où les pertes ordinaires provenaient surtout de la congestion.

L’élargissement de l’accès changeait la composition des chemins. Des liaisons terrestres sans fil, satellitaires ou autrement imparfaites laissaient parfois parvenir jusqu’au transport des erreurs non corrigées. Un paquet pouvait être corrompu puis supprimé avant TCP. Une reprise locale pouvait le retarder et le réordonner. Un ACK pouvait disparaître au retour. Un changement de route pouvait déplacer l’ordre d’arrivée. Une file pleine pouvait évidemment éliminer le même segment.

Vu de l’émetteur, ces histoires se recouvraient. Le prochain numéro attendu n’avançait pas, des ACK identiques revenaient ou le temporisateur expirait. RFC 3155 rappelait que les heuristiques de bout en bout étudiées n’avaient pas réussi à distinguer de façon sûre la congestion de la corruption.

Cette ignorance ne rendait pas la réaction inutile. Elle en fixait la portée. La réduction de fenêtre prouvait l’exécution d’une règle de contrôle ; elle ne prouvait pas la cause physique de la perte.

Se tromper par prudence avait un coût, l’erreur inverse en avait davantage

Prendre une erreur radio pour de la congestion sous-utilise un chemin peut-être disponible. L’émetteur réduit sa fenêtre, retransmet, puis remonte lentement alors que la file n’était pas le problème.

Prendre une congestion pour une simple erreur de transmission peut aggraver la situation de tous. Continuer à injecter au même rythme remplit davantage les files, multiplie les suppressions et menace la stabilité. RFC 3155 maintenait donc la priorité : en l’absence d’un retour fiable sur la cause, la prévention de la congestion devait l’emporter sur la réparation la plus rapide possible.

Il s’agissait d’une asymétrie de contrôle, non d’une déclaration métaphysique selon laquelle toute perte serait congestion. Le réseau commun supportait le risque collectif ; l’émetteur devait agir avant de tout savoir.

Pour l’audit, la nuance est décisive. Un compteur d’erreurs de liaison proche dans le temps renforce une hypothèse, mais il faut encore le rattacher au sens, au flux, aux séquences et à une horloge commune. Une baisse de cwnd montre la réponse du TCP ; elle ne localise aucun tampon.

Une formule pouvait délimiter le problème sans identifier un paquet

Le document reprenait une approximation du débit de TCP Reno à partir de la taille de segment, du RTT de bout en bout, du temporisateur de retransmission et de la probabilité stationnaire de perte. Le calcul servait à demander si, au taux de perte observé, la réponse de TCP limitait déjà le débit sous la capacité de la liaison.

Les précautions faisaient partie de l’outil. Le RTT n’était pas celui de la seule liaison suspecte. Max(1.0, 4*RTT) n’était qu’une substitution simplifiée pour le RTO. Une moyenne de perte pouvait masquer des rafales, précisément celles qui font disparaître plusieurs segments dans une fenêtre.

Si le modèle prédisait un débit supérieur à la vitesse de la liaison, la récupération TCP ne pouvait pas franchir cette limite physique. Si le débit prédit restait inférieur et que l’enquête constatait des erreurs de transmission importantes, les mécanismes recommandés pouvaient mieux employer la capacité disponible.

La formule ne révélait ni le routeur, ni le bit, ni la cause d’un événement. Elle établissait un seuil d’investigation. Ses entrées mesurées, ses hypothèses et l’implémentation active restaient des pièces séparées.

Trois ACK dupliqués évitaient l’attente, sans produire de certitude

Lorsqu’un récepteur obtient des segments placés après un trou, il répète immédiatement le numéro du prochain octet attendu. Après trois ACK dupliqués, Fast Retransmit permet à l’émetteur de renvoyer le segment supposé perdu sans attendre l’expiration complète du RTO.

Fast Recovery réduit la fenêtre de moitié et poursuit en évitement de congestion. Le timeout, lui, ramène vers Slow Start avec une fenêtre beaucoup plus petite. Les ACK dupliqués indiquent qu’une partie du trafic continue à traverser le chemin ; ils autorisent donc une reprise moins sévère.

Ils n’expliquent toujours pas le trou. Une livraison tardive après retransmission de liaison, un réordonnancement IP ou un changement de route peuvent produire les mêmes ACK. Le seuil de trois est un déclencheur opérationnel, pas un capteur de congestion.

Des pertes répétées avant la restauration additive de la fenêtre pouvaient créer la « spirale descendante » décrite par RFC 3155. Chaque nouvelle réduction de moitié frappait une fenêtre déjà diminuée. Sur une liaison continuellement mauvaise, la fenêtre pouvait simplement rester petite très longtemps.

En dessous de quatre segments, il pouvait même manquer assez de données ultérieures pour générer les trois ACK nécessaires à Fast Retransmit. Mais une petite fenêtre n’était pas toujours la signature d’une liaison dégradée : les courtes connexions HTTP refermaient sans cesse un TCP entraîné et en ouvraient un nouveau dans Slow Start.

SACK cartographiait les arrivées, pas l’auteur du trou

L’ACK cumulatif indique la frontière contiguë. Lorsque plusieurs segments manquent dans une même fenêtre, cette frontière décrit mal les blocs déjà reçus au-delà des trous. SACK permet au récepteur d’annoncer ces blocs et à l’émetteur de réparer plusieurs absences sans les découvrir successivement, tour aller-retour après tour aller-retour.

RFC 3155 recommandait SACK avec l’extension D-SACK de RFC 2883. Celle-ci ajoutait des indices sur les doublons, utiles face au réordonnancement, à la perte d’ACK, à la réplication de paquets ou à une retransmission trop précoce. Sur un long RTT ou lors d’une rafale d’erreurs au milieu d’une grande fenêtre, cette information économisait du temps et des transmissions inutiles.

La carte restait une carte d’arrivée. Elle pouvait dire que deux intervalles avaient été reçus et qu'un troisième manquait. Elle ne disait pas si le troisième avait rencontré une file, du bruit ou une défaillance sur un autre maillon.

Lorsque SACK ne pouvait pas être activé aux deux extrémités, NewReno améliorait le traitement des ACK partiels et des pertes multiples. Limited Transmit cherchait à aider les petites fenêtres à produire assez d’ACK dupliqués. RFC 3155 le rangeait parmi les travaux à évaluer, pas parmi les preuves d’un résultat universel.

Tous ces outils diminuaient la dette de réparation. Aucun ne fournissait un permis d’ignorer la congestion.

La taille des paquets changeait plusieurs mécanismes à la fois

Les liaisons moins fiables utilisaient souvent un MTU réduit. Puisque la fenêtre s’ouvrait en unités de segments, de petits segments pouvaient ralentir son accroissement. Réduire le MTU ne corrigeait cependant aucune erreur à lui seul.

La découverte du MTU de chemin évitait la fragmentation et permettait d’employer la plus grande unité supportée. Elle pouvait accélérer l’ouverture par rapport à un choix inutilement petit, mais plusieurs RTT restaient parfois nécessaires pour atteindre le produit délai-bande passante.

Cette question ne reprenait pas le mécanisme central de RFC 3150. Celui-ci observait la durée pendant laquelle un gros paquet occupe une liaison lente partagée. RFC 3155 observait l’effet de pertes résiduelles sur l’interprétation et la reprise de TCP. Durée d’un tour et ambiguïté d’un signal ne sont pas la même preuve.

Un paquet plus petit modifie la sérialisation, la proportion d’en-têtes, le nombre de segments par fenêtre, la fragmentation et l’exposition aux erreurs. Dire simplement « petit est plus fiable » écraserait ces relations contraires.

Rester aux extrémités préservait le chiffrement et limitait la vision

Les recommandations retenues n’exigeaient pas de nœud intermédiaire comprenant TCP. Elles continuaient donc à fonctionner avec IPsec de bout en bout et conservaient le partage de destin entre les extrémités. Ce choix avait pour contrepartie l’ignorance des événements locaux qui se produisaient entre elles.

Un Performance Enhancing Proxy placé à une frontière pouvait observer des caractéristiques particulières. Mais il ajoutait un troisième point de panne, de l’état à transférer en mobilité, une dépendance aux chemins symétriques, des problèmes d’échelle et de diagnostic, et souvent une incompatibilité avec la protection de bout en bout. Tous les PEP ne réunissaient pas tous les défauts ; la décision exigeait un examen précis.

RFC 3155 ne racontait pas à nouveau toute l’histoire des PEP, couverte par RFC 3135. Il s’en servait pour borner son choix. Une meilleure visibilité locale exigeait qu’un intermédiaire possède plus de la connexion. Les extrémités conservaient la compatibilité et acceptaient de ne pas tout savoir.

ECN signalait la congestion, non l’erreur de transmission

ECN proposait un retour explicite sur la congestion avant la suppression d’un paquet. Pour un TCP compatible et un chemin qui préservait la marque, le signal améliorait la connaissance de la congestion.

RFC 3155 refusait d’en déduire son contraire. ECN ne pouvait pas être détourné en notification explicite d’erreur de transmission. Une perte sans marque ECN ne devenait pas, par soustraction, une corruption prouvée. Si l’en-tête était lui-même endommagé, le réseau pouvait même ignorer à quelle extrémité envoyer une notification.

Le document souhaitait un meilleur signal d’erreur pour l’avenir mais n’en spécifiait pas. L’absence d’un signal n’était pas le contenu d’un autre.

Les recommandations étaient moins nombreuses que les pistes de recherche

Le noyau recommandé tenait en quelques décisions : ne pas affaiblir Slow Start ni Congestion Avoidance ; déployer Fast Retransmit/Fast Recovery ; employer SACK et D-SACK ; utiliser NewReno pour mieux traiter les pertes multiples lorsque SACK n’était pas disponible aux deux bouts.

D’autres propositions restaient ouvertes. Retarder les ACK dupliqués pouvait laisser finir la reprise de liaison, mais aucun délai sûr ne s’appliquait à toutes les topologies. Le pacing de l’émetteur et le contrôle du rythme des ACK pouvaient limiter les rafales. Appropriate Byte Counting pouvait faire croître la fenêtre selon les octets effectivement reçus, au risque d’accroître une rafale après perte d’ACK.

Les applications participaient aussi à l’histoire. Les connexions HTTP persistantes conservaient l’apprentissage du chemin. RFC 2140 et le Congestion Manager exploraient le partage d’information entre connexions, pour ne pas recommencer chaque transfert dans l’ignorance totale.

Une rubrique « travaux futurs » ne certifiait ni standard achevé, ni implémentation, ni bénéfice. Même une option annoncée par les deux extrémités ne prouvait pas que le code l’avait correctement exercée lors de la perte étudiée.

Un flux réparé n’effaçait pas le délai vécu

TCP doit livrer un flux ordonné. Tant qu’un trou persiste, le récepteur peut conserver des octets ultérieurs sans les remettre à l’application. La retransmission qui comble le trou permet au réassemblage d’avancer : cette réussite de transport est réelle.

Elle ne nomme toujours pas la cause et ne garantit pas une réussite du service. Une transaction peut finir après son échéance. Un utilisateur peut abandonner avant la reprise. Un transfert peut arriver à terme tout en restant longtemps bien au-dessous de la capacité disponible.

Le dossier doit donc conserver le contexte de l’application et du chemin ; les RTT, RTO, MSS, fenêtre et ACK ; les trous et temporisateurs ; les files et marques ECN ; les erreurs, reprises et réordonnancements de liaison ; l’algorithme choisi ; les retransmissions et la trajectoire de fenêtre ; le réassemblage ; enfin l’heure et le résultat applicatifs.

La leçon de RFC 3155 n’est pas qu’il fallait cesser de ralentir. Une décision de sûreté peut être juste alors que le diagnostic reste incomplet. TCP protégeait le bien commun avec l’information disponible. L’enquête devait encore expliquer la perte et mesurer la valeur de la réparation.

Sources