Aller au contenu principal

3.2. Retransmission Rapide/Récupération Rapide

Un récepteur TCP DEVRAIT (SHOULD) envoyer immédiatement un accusé de réception duplicata lorsqu'un segment hors séquence arrive. Le but de cet ACK est d'informer l'émetteur qu'un segment a été reçu hors séquence et quel numéro de séquence est attendu. Du point de vue de l'émetteur, les ACK duplicata peuvent être causés par un certain nombre de problèmes réseau. Premièrement, ils peuvent être causés par des segments perdus. Dans ce cas, tous les segments suivant le segment perdu déclencheront des ACK duplicata jusqu'à ce que la perte soit réparée. Deuxièmement, les ACK duplicata peuvent être causés par la réorganisation des segments de données par le réseau (ce n'est pas un événement rare sur certains chemins réseau [Pax97]). Enfin, les ACK duplicata peuvent être causés par la duplication de segments ACK ou de données par le réseau. En outre, un récepteur TCP DEVRAIT (SHOULD) envoyer immédiatement un ACK lorsque le segment entrant comble tout ou partie d'un trou dans l'espace de séquence. Cela générera des informations plus opportunes pour un émetteur qui récupère d'une perte via un délai de retransmission, une retransmission rapide ou un algorithme avancé de récupération de perte, comme décrit à la section 4.3.

L'émetteur TCP DEVRAIT (SHOULD) utiliser l'algorithme de « retransmission rapide » pour détecter et réparer les pertes, sur la base des ACK duplicata entrants. L'algorithme de retransmission rapide utilise l'arrivée de 3 ACK duplicata (tels que définis à la section 2, sans aucun ACK intermédiaire déplaçant SND.UNA) comme indication qu'un segment a été perdu. Après avoir reçu 3 ACK duplicata, TCP effectue une retransmission de ce qui semble être le segment manquant, sans attendre l'expiration du délai de retransmission.

Après que l'algorithme de retransmission rapide a envoyé ce qui semble être le segment manquant, l'algorithme de « récupération rapide » régit la transmission de nouvelles données jusqu'à l'arrivée d'un ACK non duplicata. La raison pour laquelle le démarrage lent n'est pas effectué est que la réception des ACK duplicata indique non seulement qu'un segment a été perdu, mais aussi que des segments quittent très probablement le réseau (bien qu'une duplication massive de segments par le réseau puisse invalider cette conclusion). Autrement dit, comme le récepteur ne peut générer un ACK duplicata que lorsqu'un segment est arrivé, ce segment a quitté le réseau et se trouve dans la mémoire tampon du récepteur ; nous savons donc qu'il ne consomme plus de ressources réseau. De plus, comme l'« horloge » des ACK [Jac88] est préservée, l'émetteur TCP peut continuer à transmettre de nouveaux segments (bien que la transmission doive se poursuivre avec un cwnd réduit, la perte étant une indication de congestion).

Les algorithmes de retransmission rapide et de récupération rapide sont mis en œuvre ensemble comme suit.

  1. À la réception des premier et deuxième ACK duplicata par un émetteur, un TCP DEVRAIT (SHOULD) envoyer un segment de données jamais envoyées auparavant conformément à [RFC3042], à condition que la fenêtre annoncée par le récepteur le permette, que le FlightSize total reste inférieur ou égal à cwnd plus 2*SMSS, et que de nouvelles données soient disponibles pour la transmission. En outre, l'émetteur TCP NE DOIT PAS (MUST NOT) modifier cwnd pour refléter ces deux segments [RFC3042]. Notez qu'un émetteur utilisant SACK [RFC2018] NE DOIT PAS (MUST NOT) envoyer de nouvelles données à moins que l'accusé de réception duplicata entrant ne contienne de nouvelles informations SACK.

  2. Lorsque le troisième ACK duplicata est reçu, un TCP DOIT (MUST) fixer ssthresh à une valeur ne dépassant pas celle donnée par l'équation (4). Lorsque [RFC3042] est utilisé, les données supplémentaires envoyées en transmission limitée NE DOIVENT PAS (MUST NOT) être incluses dans ce calcul.

  3. Le segment perdu commençant à SND.UNA DOIT (MUST) être retransmis et cwnd fixé à ssthresh plus 3*SMSS. Cela « gonfle » artificiellement la fenêtre de congestion du nombre de segments (trois) qui ont quitté le réseau et que le récepteur a mis en mémoire tampon.

  4. Pour chaque ACK duplicata supplémentaire reçu (après le troisième), cwnd DOIT (MUST) être incrémenté de SMSS. Cela gonfle artificiellement la fenêtre de congestion afin de refléter le segment supplémentaire qui a quitté le réseau.

    Note : [SCWA99] traite d'une attaque côté récepteur dans laquelle de nombreux ACK duplicata frauduleux sont envoyés à l'émetteur de données afin de gonfler artificiellement cwnd et d'entraîner l'utilisation d'un débit d'émission plus élevé qu'approprié. Un TCP PEUT (MAY) donc limiter le nombre de fois où cwnd est artificiellement gonflé pendant la récupération de perte au nombre de segments en suspens (ou à une approximation de celui-ci).

    Note : lorsqu'un mécanisme avancé de récupération de perte (tel que celui décrit à la section 4.3) n'est pas utilisé, cette augmentation du FlightSize peut amener l'équation (4) à gonfler légèrement cwnd et ssthresh, certains segments entre SND.UNA et SND.NXT étant supposés avoir quitté le réseau tout en étant encore reflétés dans le FlightSize.

  5. Lorsque des données jamais envoyées auparavant sont disponibles et que la nouvelle valeur de cwnd et la fenêtre annoncée par le récepteur le permettent, un TCP DEVRAIT (SHOULD) envoyer 1*SMSS octets de données jamais envoyées auparavant.

  6. Lorsque l'ACK suivant arrive et acquitte des données auparavant non acquittées, un TCP DOIT (MUST) fixer cwnd à ssthresh (la valeur fixée à l'étape 2). C'est ce qu'on appelle le « dégonflage » de la fenêtre.

    Cet ACK devrait être l'accusé de réception suscité par la retransmission de l'étape 3, un RTT après la retransmission (bien qu'il puisse arriver plus tôt en présence d'une livraison significativement hors séquence des segments de données au récepteur). De plus, cet ACK devrait acquitter tous les segments intermédiaires envoyés entre le segment perdu et la réception du troisième ACK duplicata, si aucun d'entre eux n'a été perdu.

Note : cet algorithme est connu pour généralement ne pas récupérer efficacement de pertes multiples dans un même vol de paquets [FF96]. La section 4.3 ci-dessous traite de tels cas.