Résumé

  • Le signalement d’un doublon peut établir qu’une retransmission précise était inutile sans montrer que tous les segments de la même fenêtre sont arrivés sans perte.
  • La RFC 3708 ne permet de conclure à l’annulation d’un changement de contrôle de congestion qu’après confirmation de toutes les unités retransmises de la fenêtre précédente, sous réserve de ses conditions d’arrêt.

Voici le cas qui piège l’interprétation. L’émetteur retransmet les segments N et N+1. Seul N a été perdu ; N+1 était simplement retardé. Lorsque le récepteur signale N+1 comme doublon, l’émetteur apprend que cette retransmission de N+1 ne servait à rien. Il n’apprend pas que le réseau n’a rien perdu : N reste une vraie indication de perte. Rétablir l’état de congestion de toute la fenêtre ferait disparaître une preuve encore pertinente.

La RFC 3708, publiée en février 2004 au statut expérimental, formalise cette distinction. Elle décrit des méthodes prudentes pour exploiter les notifications de doublons : le DSACK de TCP et les notifications de TSN dupliqué de SCTP. Elle sépare deux usages. Une pile peut compter ces notifications pour la comptabilité ou la surveillance. Pour annuler des changements de contrôle de congestion, l’émetteur doit appliquer l’algorithme de désambiguïsation, bien plus exigeant.

L’algorithme vérifie d’abord si la plage de séquence ou le TSN signalé a été retransmis. Si la retransmission a eu lieu plus d’une fois dans la fenêtre, le traitement s’arrête : l’émetteur ne rétablit pas l’ancien état de congestion. Si l’émetteur ne l’a jamais retransmis, le doublon peut plutôt venir d’une réplication dans le réseau. La RFC 3708 demande alors de cesser d’utiliser son algorithme pour le reste de la connexion, car les rapports suivants seraient plus difficiles à attribuer aux retransmissions inutiles de l’émetteur.

Même un doublon correspondant à une retransmission ne suffit pas. L’émetteur examine toutes les unités retransmises pendant la fenêtre précédente. Il ne conclut que si chacune a été acquittée et marquée comme doublon. Si une retransmission reste sans marque de doublon, le rapport ne permet aucune conclusion. Une autre protection couvre un tableau SACK TCP vide et un DSACK qui commence à SND.UNA, configuration compatible avec la perte de toute une fenêtre d’ACK. Dans ce cas, continuer à réduire le débit reste le choix prudent.

Il faut donc de la mémoire d’état : au-delà de celui de la récupération SACK, l’implémentation suit les numéros de séquence ou TSN déjà acquittés comme doublons. Cette mémoire autorise une inférence précisément délimitée, pas une certitude sur l’honnêteté du récepteur ni sur tous les événements du chemin. La section sécurité avertit qu’un récepteur pourrait qualifier à tort des données réordonnées de doublons pendant une vraie perte et provoquer une modification dangereuse de l’état de congestion.

La RFC 2883 définit l’encodage des données dupliquées dans les blocs D-SACK de TCP, sans imposer la réaction de l’émetteur. La RFC 3522 suit une autre piste : Eifel peut détecter plus vite une retransmission inutile grâce aux horodatages TCP, au prix de l’option Timestamp dans chaque paquet. La RFC 3708 est plus lente, mais impose une distinction utile : constater une retransmission inutile, puis vérifier séparément si les preuves blanchissent toute la fenêtre. Elle ne prescrit pas la réaction à adopter après détection.

Sources : RFC 3708, statut de la RFC 3708, RFC 2883, RFC 3517, RFC 3522, RFC 2960, RFC 4960.