Résumé
- RFC 3758 rend l’abandon d’un message dépendant d’une politique de service, tandis que FORWARD TSN fournit un mécanisme générique de progression.
- Le service de fiabilité temporisée n’exige pas que la pile SCTP contrôle chaque message exactement à l’instant où sa durée de vie expire.
Un délai peut arriver à son terme sans que la pile s’arrête aussitôt pour le constater. RFC 3758 autorise cette distinction ; il ne transforme pas l’expiration en interruption matérielle.
La fiabilité partielle n’est pas une garantie vague de livraison. L’extension de 2004 permet à l’application de régler, message par message, la persistance des retransmissions. Si les deux extrémités annoncent la prise en charge de FORWARD TSN pendant l’établissement de l’association, l’émetteur peut cesser de poursuivre certaines données et indiquer au récepteur comment avancer son point cumulatif de numéros de séquence de transmission, ou TSN. Pour les messages ordonnés, les numéros de flux inclus aident aussi à libérer des données retenues derrière le trou.
La politique d’abandon et son effet sur le fil ne sont pas le même objet. Le récepteur n’a pas besoin de connaître la raison : limite de temps, plafond de retransmissions ou autre service. Il doit interpréter le TSN avancé et ne plus signaler les numéros antérieurs comme manquants. Le signal ne contient donc pas le récit de la décision applicative ; il expose uniquement la conséquence nécessaire à la progression du transport.
Cette architecture rend la règle d’expiration moins absolue qu’un chronomètre de laboratoire. Dans le protocole SCTP de base, le paramètre de durée de vie sert à éviter l’envoi d’une donnée devenue périmée avant sa première transmission. Une fois la première transmission effectuée avant l’échéance, le message reste fiable et ses retransmissions continuent. RFC 3758 lève cette restriction pour le service de fiabilité temporisée : l’émetteur peut abandonner une donnée dont le TSN est déjà attribué. Mais il doit évaluer sa durée de vie avant l’attribution du TSN, puis avant une transmission ou une retransmission lorsque le TSN existe.
Le texte précise aussi qu’il n’est pas nécessaire de créer un minuteur distinct pour chaque message. La pile peut vérifier la durée de vie à des moments déjà utiles — attribution du TSN, envoi, expiration d’un temporisateur de retransmission ou autre occasion pratique. Elle n’a pas à effectuer cette vérification précisément au moment où la durée de vie expire. Une API qui accepte une valeur de durée de vie n’est donc pas, à elle seule, une promesse de délai strict ; l’évaluation peut intervenir plus tard, lorsqu’un autre événement sollicite la pile.
La phase du message change également le coût de l’abandon. Avant l’attribution d’un TSN, une donnée périmée peut être retirée sans créer de trou dans l’espace de séquence. Après l’attribution, l’émetteur doit marquer les données abandonnées et, si un message fragmenté est concerné, abandonner ses autres fragments en même temps. Le point cumulatif est commun à l’association, mais les numéros de séquence ordonnés appartiennent aux flux. FORWARD TSN réunit ces deux niveaux de progression sans faire semblant que le contenu manquant a été reçu.
Un FORWARD TSN n’est donc ni un reçu de livraison ni la preuve que l’application destinataire a accepté le message suivant. Il signifie que l’émetteur ne poursuivra plus certains TSN et demande au pair de les franchir. La congestion reste prise en compte : les données abandonnées ne donnent pas de crédit à la fenêtre de congestion, et un événement de retransmission conserve ses conséquences de contrôle. Une politique de fraîcheur peut cesser de gaspiller des ressources sur une donnée périmée ; elle ne convertit pas la progression de séquence en réussite applicative.
La négociation constitue une autre frontière. Si le pair n’annonce pas la prise en charge, l’association ne peut pas utiliser FORWARD TSN. Une application qui dépend de l’abandon partiel doit recevoir cette information et choisir comment continuer. La capacité locale de la pile ne suffit pas : il faut distinguer le soutien de l’association, la politique par message et le résultat obtenu par le récepteur.
RFC 7496 a ensuite ajouté des politiques de limite de retransmissions et de priorité en réutilisant l’idée générale d’abandon. L’évolution confirme le partage des rôles : la règle déterminant quand renoncer peut changer sans inventer un signal de séquence différent à chaque fois. Le transport définit comment sortir proprement du trou ; le service définit quand ce trou devient acceptable.
Sources
- RFC 3758 — Extension de fiabilité partielle de SCTP
- RFC 2960 — Stream Control Transmission Protocol
- RFC 4960 — Stream Control Transmission Protocol
- RFC 9260 — Stream Control Transmission Protocol
- RFC 7496 — Politiques PR-SCTP supplémentaires
- RFC 6458 — API sockets SCTP
- RFC 8260 — Ordonnanceurs de flux et entrelacement des messages SCTP
- RFC 8095 — Services des protocoles de transport de l’IETF
- RFC 6083 — DTLS pour SCTP
- RFC 3436 — TLS au-dessus de SCTP
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
