Acquittements sélectifs (SACK)

Contexte

Dans la présentation du protocole TCP, nous avons vu que les acquittements sont cumulatifs.
Par conséquent, la pile TCP ne peut acquitter qu'une suite continue d'octets. Le problème se pose si un segment est perdu et que les suivants arrivent à destination.

De plus, la pile TCP ne peut pas transmettre à l'application les données reçues avec des « trous », de par le modèle de flux d'octet.

Que faire des segments 20 à 23 pour le récepteur ? De même, quelle stratégie de retransmission à appliquer pour l'émetteur des données ?
Car d'après la RFC 793, aucun des segments n'aura été reçu du point de vue de l'émetteur. En effet, le récepteur des données devra acquitter en premier le segment 19 (ci­-dessus) qui a été perdu.
Le risque est que l'émetteur retransmette les segments 19 à 23.

Le mécanisme d'acquittement sélectif (« Selective Acknowledgement » ou SACK) permet de répondre à cette problématique.
Le destinataire des données peut indiquer à l'émetteur quels sont les segments reçus, et ainsi permettre à ce dernier de ne retransmettre que les segments manquants.

Fonctionnement

La RFC 2018 définit 2 options.

La première permet d'indiquer au destinataire que l'émetteur implémente cette fonctionnalité. Le type est 0x04 et de longueur 2 (octets).

Elle ne peut être envoyée que lors de l'établissement de la connexion (Lorsque le drapeau SYN est activé).

La deuxième option informe l'émetteur de l'existence de blocs de données non contigus dans les segments reçus.

L'option liste tous les blocs reçus valides (contenus dans la fenêtre de réception) et isolés dans le flux d'octets. Pour N éléments dans la liste, la longueur de cette option est N*8+2.

Chaque bloc est constitué de 2 entiers non signés de 32 bits :

• celui de gauche indique le premier numéro de séquence de ce bloc.

• celui de droite indique le prochain numéro de séquence après ce bloc.

Chaque bloc constitue un ensemble d'octets reçus, contigus et isolés dans la fenêtre de réception. Les octets juste autour de ce bloc n'ont pas été reçus.

Dans la mesure où l'en­-tête TCP ne peut pas avoir une longueur supérieure à 60 octets, il ne peut y avoir que 4 éléments dans la liste, au maximum. Dans la pratique, avec l'utilisation des timestamps, ce nombre est plutôt de 3 au maximum.

Il est à noter que le champ d'acquittement dans l'en­tête ne change pas de signification, il pointe toujours vers le premier octet attendu dans la fenêtre de réception. Dans l'exemple ci-­dessus, le champ ACK pointe toujours vers le segment 19.

N.B. : cette option est uniquement informative, elle n'engage pas le récepteur à garder ces blocs de données.
Ce dernier peut notifier l'émetteur au moyen de l'option SACK et quand même supprimer ces blocs de ses files d'attente (par manque de mémoire), même si cela n'est pas recommandé.
Toutefois, à part le dernier segment reçu isolé, le récepteur des données ne doit pas signaler de blocs de données supprimés.

Règles d'envoi de l'option SACK

• Le destinataire de cette option doit avoir indiqué son acceptation lors de l'établissement de la connexion.

• Chaque segment d'acquittement (avec le drapeau ACK activé) peut contenir l'option SACK. Par contre, le premier bloc de la liste doit contenir les numéros de séquence du dernier segment reçu.

• Le destinataire des données devrait lister autant de blocs de données qu'il est nécessaire. Néanmoins, cette liste peut être tronquée par les limites de la taille maximale de l'en­tête.

• La liste des blocs devrait être remplie dans l'ordre inverse d'ancienneté (le plus récent d'abord). Ce qui assure à chaque bloc d'être transmis au moins 3 fois (4 sans timestamps) si nécessaire.


L'idée principale est d'indiquer à l'émetteur des données l'état le plus récent de la fenêtre de réception du destinataire.
De plus, ces segments d'acquittement SACK peuvent être perdus eux aussi. Le fait de transmettre chaque bloc au moins 3 fois diminue le risque qu'un bloc ne soit pas signalé à l'émetteur des données.

Exemple d'envoi de plusieurs blocs SACK

Dans l'exemple ci-dessus, le récepteur des données (10.8.0.22) indique à l'émetteur qu'il se retrouve avec un bloc isolé de données (paquet n° 131) puis avec un deuxième (paquet n° 132).
A noter que le premier bloc (n° 132) fait référence au dernier segment reçu (paquet n° 130).

Stratégie de retransmission

L'émetteur des données est supposé tenir à jour une liste des segments à retransmettre (les segments qui n'ont toujours pas été acquittés).

En cas de réception de l'option SACK, les segments concernés sont mis à part. Par exemple, avec l'utilisation d'un drapeau SACK qui indique la bonne réception par le destinataire.

Ce mécanisme permet de déterminer les segments à retransmettre, sans attendre l'expiration du temps d'attente (« retransmit timeout »).

Toutefois, en cas d'expiration de ce temps d'attente, tous les segments de cette liste, marqués ou non, sont considérés comme perdus et doivent être retransmis.

N'oublions pas que cette option SACK est informative. Le récepteur des données peut, pour des raisons diverses, ne pas avoir gardé en mémoire les segments déclarés dans l'option SACK.

Avec ou sans cette fonctionnalité SACK, LA seule façon d'enlever un segment de cette liste de retransmission, est que le récepteur des données ait acquitté ce segment grâce au champ d'acquittement dans l'en­tête TCP.


Toutes les copies écrans sont issues du logiciel d'analyse réseau de Comoe Networks.