Résumé

  • La RFC 3522 compare l’horodatage du premier ACK acceptable reçu pendant la récupération à celui de la retransmission qui l’a déclenchée. Un marqueur antérieur peut montrer que l’envoi original avait survécu, sans annuler les modifications déjà appliquées au contrôle de congestion.
  • Le reçu défendable conserve l’envoi original, le déclencheur, RetransmitTS, l’ACK et ses ambiguïtés, l’état antérieur sauvegardé, l’algorithme de réponse, l’état après réponse et le résultat applicatif. Détecter n’est pas restaurer.

Une fenêtre s’est refermée avant que la preuve n’arrive. Le temporisateur ou le seuil d’ACK dupliqués avait parlé en premier, donc TCP avait retransmis et changé de régime. L’acquittement suivant révélait que le paquet original n’était pas perdu: il était seulement arrivé, ou avait été acquitté, plus tard que l’hypothèse du contrôle.

Publiée en avril 2003 comme Experimental, la RFC 3522 définit la partie détection de l’algorithme Eifel. Elle utilise l’option TCP Timestamps pour lever une ambiguïté: après une retransmission, un numéro d’acquittement ordinaire ne dit pas quelle copie a provoqué l’ACK.

Le document s’arrête volontairement avant la réparation. Son étape (RESP) ne fait rien. La réponse est un autre mécanisme, avec d’autres préconditions et un autre propriétaire opérationnel.

Le temps de la preuve est aussi une donnée

Au début d’un épisode de récupération, l’émetteur met SpuriousRecovery à faux et mémorise dans RetransmitTS le Timestamp Value de la retransmission initiale. Les retransmissions ultérieures ne doivent pas écraser cette valeur.

Il attend ensuite le premier ACK acceptable, celui qui reconnaît des données jusque-là non acquittées. Si le Timestamp Echo Reply est inférieur à RetransmitTS, l’ACK répond à une transmission originale antérieure. Sous réserve des sorties conservatrices de l’étape 5, la récupération était inutile.

La rapidité compte. Une détection sur le premier ACK acceptable peut empêcher les retransmissions go-back-N qui suivent souvent un timeout fallacieux. Une preuve arrivée après la fin de la récupération aurait encore une valeur comptable, mais moins de capacité à limiter l’action en cours.

Elle n’arrive toutefois jamais avant le déclencheur qu’elle réinterprète. Il faut donc conserver l’ordre: état initial, événement de perte supposée, mutation, retransmission, ACK, classification, puis réponse éventuelle.

Le même symptôme vient de causes différentes

Une hausse soudaine du délai peut faire expirer le RTO avant l’ACK. Le réordonnancement peut produire trois ACK dupliqués alors qu’aucun octet n’a disparu. La duplication de segments ou d’ACK peut créer la même apparence.

La conséquence commune n’autorise pas une attribution unique. Une fast retransmit fallacieuse envoie typiquement une copie inutile et réduit la fenêtre. Un timeout fallacieux peut forcer slow start, puis provoquer plusieurs copies inutiles quand reviennent les ACK des originaux.

Eifel répond à la question «la récupération était-elle nécessaire?». Il ne prouve pas «le chemin a réordonné», ne désigne pas un réseau d’accès et ne mesure pas la congestion.

La RFC distingue aussi le fast timeout: le timer peut gagner la course contre l’ACK dupliqué qui aurait déclenché fast retransmit. Si une perte réelle existait, la récupération reste justifiée. Attendre davantage ne suffit pas à rendre l’événement fallacieux.

L’égalité reste un doute

La comparaison de base est strictement «inférieur à». Si l’horloge d’horodatage est grossière ou le réseau rapide, l’original et la copie peuvent porter la même valeur. La RFC choisit alors de ne pas conclure à une récupération fallacieuse.

Cette convention borne le droit d’agir. Transformer l’égalité en preuve positive multiplierait les restaurations fondées sur une information indistincte.

Le journal doit conserver les deux valeurs brutes, la granularité, l’opérateur de comparaison et la branche. «Eifel exécuté» ne distingue pas un résultat positif, négatif ou indéterminé.

Tous les ACK perdus imitent une autre histoire

Si le segment ancien atteint le destinataire mais que toute la volée d’ACK disparaît, l’émetteur doit expirer et retransmettre. La copie est inutile du point de vue des octets; le timeout, lui, était inévitable. Réduire la fenêtre peut rester une réaction appropriée à une congestion du chemin retour.

Quand la copie arrive comme duplicata, un destinataire conforme aux anciennes règles peut renvoyer l’horodatage du dernier segment reçu en ordre. Il sera inférieur à celui de la retransmission et ressemblera à la signature recherchée.

L’étape 5 examine DSACK et la couverture de toutes les données en vol pour sortir sans déclarer une restauration. L’algorithme n’est donc pas un simple comparateur. Les sorties qui refusent d’agir font partie du contrat.

La preuve retournée peut être fabriquée

Un destinataire malveillant peut forger un Timestamp Echo Reply et faire paraître fallacieuse une retransmission réelle. La variante sûre conserve les horodatages des transmissions originales encore en vol et exige l’égalité exacte avec celui de l’original correspondant.

Ce durcissement a un prix: davantage d’état et une plus grande sensibilité à la perte ou au réordonnancement des ACK. Une granularité grossière rend aussi la valeur manquante plus facile à deviner.

La sécurité ne vient donc pas de la seule présence d’une option timestamp. Elle dépend de ce qui a été gardé secret, de la finesse de l’horloge, du comportement du pair et de la disponibilité de l’acquittement précis.

Une détection ne recrée pas ce qui n’a pas été sauvegardé

La RFC 3522 cite des réponses possibles: restaurer l’état de congestion, éviter des copies supplémentaires, adapter le seuil d’ACK ou les estimateurs RTT. Elle ne les définit pas.

La RFC 4015 formalise ensuite une réponse Eifel. Pour restaurer une fenêtre ou un seuil, l’émetteur doit en avoir conservé la valeur avant la réduction. La classification tardive ne peut déduire un état qui a été écrasé.

La prudence est également sémantique. Une copie peut être inutile tandis qu’un autre segment de la même fenêtre a réellement été perdu. La RFC 3708 souligne cette coexistence dans l’analyse DSACK. Innocenter une copie n’innocente pas tout l’épisode de congestion.

Le détecteur possède la classification qu’il calcule. Il ne reçoit pas automatiquement le mandat de restaurer toutes les variables touchées.

Fermer la chaîne au résultat promis

Après la réponse, il faut observer l’état réellement appliqué: fenêtre, seuil, timer, données nouvelles envoyées et changements ultérieurs. Il faut encore suivre pertes, réordonnancement et acquittements.

Une fenêtre restaurée ne prouve ni capacité stable ni livraison complète. Les textes plus récents sur la feuille de route TCP, RACK-TLP, QUIC et CUBIC conservent la nécessité d’une réponse prudente lorsque la capacité peut réellement avoir changé.

Si la promesse porte sur des octets, conserver les plages acquittées. Si elle porte sur la latence, mesurer l’intervalle. Si elle porte sur une transaction, exiger l’accusé authentifié de l’application. L’horodatage ne peut pas devenir ce reçu par héritage.

Un reçu conçu avant l’erreur

Enregistrer la négociation de timestamps et leur granularité, la plage originale et son marqueur, le type de déclencheur, les ACK dupliqués ou l’état du timer, ainsi que les variables de congestion avant la mutation.

Lier la première retransmission à son RetransmitTS immuable. Conserver l’ACK acceptable, sa plage, le Timestamp Echo Reply, DSACK et la décision exacte de l’étape 5. Indiquer la variante utilisée.

Pour la réponse, enregistrer version, variables sauvegardées, restaurées et volontairement laissées réduites. Relier les événements réseau ultérieurs, puis la livraison et le résultat applicatif.

Un compteur agrégé de retransmissions fallacieuses aide les tendances; il ne permet pas de reconstruire une restauration contestée.

Limite des éléments probants

Cet Article ne désigne aucune implémentation TCP, système d’exploitation, fournisseur, opérateur, réseau, chemin, destinataire, utilisateur, flux, incident ou déploiement. Il ne prétend rien sur l’adoption, l’usage des timestamps, le taux de perte, le réordonnancement, la performance, la batterie, la sécurité ou un résultat commercial actuel.

La RFC 3522 reste ici un document Experimental d’avril 2003, pas une norme Internet. Les RFC 4015, 5681, 5682, 6298 et 7323 gardent leur propre portée. Les RFC 9438, 8985 et 9002 sont des comparaisons ultérieures, non des preuves d’implémentation Eifel.

Les notes de Heng Lu sur l’autorité et le running code sont des perspectives éditoriales déclarées. Elles aident à séparer signal formel, état réel et résultat observé; elles ne documentent pas l’intention de l’IETF.

La conclusion est étroite: un ACK peut corriger le diagnostic sans corriger l’état. Seule une réponse distincte, puis son observation, autorise à parler de restauration.

Sources