Résumé

  • La fiabilité partielle de SCTP permet d’abandonner un message sans fermer l’association ni renoncer à la livraison fiable de tous les autres.
  • FORWARD TSN indique jusqu’où le récepteur peut cesser d’attendre. Ce déplacement peut intégrer des données abandonnées, et pas seulement des données effectivement reçues.
  • Le choix de l’expéditeur reste local : durée de vie, nombre de retransmissions ou arbitrage de mémoire. Il ne constitue ni une date de péremption imposée au destinataire, ni un rappel des données déjà consommées.

Le trou reste vide, pourtant le curseur avance

Le récepteur a 104 et 105 en mémoire, mais pas 103. Puis son point cumulatif passe de 102 à 103, avant d’atteindre 105. Si l’on ne conserve que la valeur finale, le résultat ressemble à une suite entièrement reçue. Or le contenu de 103 n’est jamais apparu : le RFC 3758 autorise précisément le récepteur à poursuivre tout en gardant cette absence comme fait.

Cette scène de spécification pose un problème de conservation de la preuve. Trois lieux observent trois réalités différentes. Le tampon de réception sait quels blocs sont physiquement présents. L’état SCTP sait qu’une frontière peut avancer par combinaison d’un saut autorisé et de données déjà reçues. La couche applicative, enfin, sait ce qu’elle a effectivement obtenu, voire commencé à consommer. Aucun de ces observatoires ne peut être remplacé par les deux autres.

Dans l’exemple du récepteur, FORWARD TSN permet d’abord de franchir le 103 manquant. Les 104 et 105, déjà détenus, prolongent ensuite le cumul jusqu’à 105. Le 106 manque encore et bloque la progression, même si 107 est arrivé. Le curseur n’est donc ni un inventaire des contenus ni une attestation de remise : il résume ce que le transport n’attend plus à cette frontière.

Cette distinction devient matérielle lorsqu’un message est en cours de réassemblage. Si une pièce toujours absente porte un TSN désormais situé sous la nouvelle frontière, le réassemblage incomplet doit être supprimé. Si une livraison partielle avait commencé, la couche supérieure devrait être avertie que le message ne sera pas terminé. Faire le ménage dans l’état de transport ne réécrit pas pour autant ce que l’application a déjà vu.

Un bloc sauté qui arrive après l’avancement est traité comme un doublon et écarté selon la procédure. Cela règle une arrivée tardive ; ce n’est ni un rappel d’une copie déjà remise, ni la preuve qu’aucune copie n’est passée auparavant. La durée de vie choisie à l’émission ne devient pas une échéance de validité chez le destinataire.

L’autorité de FORWARD TSN est étroite

FORWARD TSN ne certifie pas que le trou a été rempli. Il apporte l’autorité commune nécessaire pour que le récepteur cesse de l’attendre. Pour les messages ordonnés, il ajoute les références de flux et de séquence qui permettent de libérer des données retenues derrière le message abandonné ; les données non ordonnées ne doivent pas être inscrites dans ces entrées d’ordre.

Cette autorité a une borne. Dans l’exemple de l’expéditeur du RFC 3758, l’acquittement cumulatif réel est 102. Les TSN 103 et 104 ont été abandonnés ; 105 n’est ni acquitté ni abandonné ; 106 est acquitté. Le point avancé peut atteindre 104, mais il ne peut pas traverser le 105 fiable encore en suspens pour rejoindre 106. Le mécanisme saute des obligations explicitement abandonnées, pas toute lacune qui gêne la suite.

L’instruction n’est elle-même qu’un paquet susceptible de se perdre. L’expéditeur doit veiller à ce qu’un temporisateur T3-rtx soit actif et réexaminer l’avancement lors de son expiration. Un FORWARD TSN ancien ou égal à la position courante ne ramène pas le récepteur en arrière ; il peut déclencher un SACK, notamment si le précédent acquittement s’est perdu. Une commande émise et un état effectivement partagé restent deux observations séparées.

Deux acquittements, deux significations

Du côté de l’expéditeur, un bloc abandonné cesse d’être « outstanding » et est traité comme « finally acknowledged » pour solder la comptabilité d’envoi. Cette expression ne décrit pas une réception. Le RFC interdit d’ailleurs de créditer les octets abandonnés à partial_bytes_acked ou de les utiliser pour accroître la fenêtre de congestion. Jeter une obligation ne peut pas fabriquer la preuve ni le crédit d’un transport réussi.

L’autre acquittement est le cumulatif réellement annoncé par le pair dans ses SACK. SCTP maintient séparément l’Advanced.Peer.Ack.Point, frontière locale qui incorpore les abandons. Une divergence entre ces deux valeurs est justement la condition qui appelle FORWARD TSN ; elle ne transforme pas le point avancé en observation distante.

L’abandon porte sur le message utilisateur. Si un fragment est abandonné, tous les TSN du même message fragmenté le sont ensemble. La décision ne peut donc pas préserver fictivement un message complet après en avoir retiré une pièce. Les ajustements de congestion et de temporisation qui seraient requis restent dus ; la fiabilité partielle n’est pas un moyen de contourner le contrôle de congestion.

Le service temporel applique cette logique à deux moments différents. Avant l’attribution d’un TSN, un message expiré peut être abandonné sans exposer de position commune et sans FORWARD TSN. Une fois numéroté, son expiration avant transmission ou retransmission ouvre au contraire la procédure d’abandon. Il n’est pas nécessaire de réveiller un temporisateur propre à chaque message à l’instant exact de l’échéance, et l’application ne peut plus modifier la durée après la remise à SCTP.

Il s’ensuit, par analyse du mécanisme, qu’une copie déjà en vol peut encore parvenir au récepteur avant le saut. Cette hypothèse n’est pas le récit d’un incident. Elle montre seulement pourquoi le temps de persistance de l’expéditeur n’est ni l’horloge du récepteur ni un dispositif de rappel. Une règle applicative de fraîcheur exige sa propre version, sa propre heure d’acceptation ou une autre preuve au point de décision.

Le droit de sauter se négocie, le motif reste local

L’autorité commune n’existe que si l’extension a été négociée lors de l’établissement de l’association. Une implémentation capable de la prendre en charge mais qui ne l’annonce pas doit se comporter sans elle pour cette association. Si le pair ne la prend pas en charge, la couche supérieure peut interrompre l’établissement ou continuer sans fiabilité partielle ; cette seconde voie constitue un autre service, pas une activation implicite.

L’histoire éclaire pourquoi cette frontière a été ajoutée. Le SCTP d’octobre 2000, dans le RFC 2960, possédait déjà une durée de vie : si la première transmission ne commençait pas à temps, le travail pouvait être annulé. Après une première tentative, il demeurait fiable. Les RFC 4960 et RFC 9260 conservent cette distinction de l’interface de base. L’extension ne rend donc pas toute donnée SCTP partiellement fiable par défaut.

Le document informatif RFC 6458 expose ensuite un sélecteur de politique, en distinguant le service fiable du service temporel. Il ne garantit ni constantes numériques ni réglages initiaux universels. Le RFC 7496 ajoute une limite de retransmissions et une politique de priorité sous pression du tampon d’envoi. Une limite nulle autorise l’envoi initial puis abandonne lorsqu’une première retransmission serait nécessaire ; la priorité arbitre la mémoire locale, non la route ni l’exécution distante. Dans les deux cas, la raison locale change sans élargir l’autorité de FORWARD TSN.

Le RFC 8831 exige les politiques temporelle et à retransmissions limitées dans le contrat des canaux de données WebRTC. L’ordre et la fiabilité y restent des choix distincts, et la pile place SCTP sur DTLS sur ICE/UDP. C’est une exigence de cette architecture, pas un recensement des navigateurs actuels ni une propriété automatique de toute association SCTP.

La trajectoire historique va donc du récepteur vers l’expéditeur autant que l’inverse. La politique décide localement de la persistance ; la séquence commune rend cette décision supportable par le pair ; les preuves de réception et de remise restent ailleurs. Avancer malgré une absence est une capacité contrôlée, pas une manière de rebaptiser l’absence en succès.

Documents de référence

  • RFC 2960 : interface initiale et durée de vie.
  • RFC 3758 : négociation, abandon, FORWARD TSN et service temporel.
  • RFC 4960 : maintien de la distinction dans la spécification de base.
  • RFC 6458 : interface informative de sélection des politiques.
  • RFC 7496 : retransmissions limitées, priorités locales et statistiques.
  • RFC 8831 : contrat des canaux de données WebRTC.
  • RFC 9260 : interface SCTP de base en 2022.