Aller au contenu principal

6. Transfert de données utilisateur (User Data Transfer)

Ce chapitre décrit le mécanisme de transfert de données utilisateur entre les points de terminaison SCTP.

6.1. Transmission des chunks DATA (Transmission of DATA Chunks)​

Les points de terminaison SCTP échangent des messages utilisateur via des chunks DATA sur une association établie.

6.1.1. Données de charge utile (Payload Data)​

L'expéditeur DEVRAIT utiliser la "Découverte du MTU de chemin (Path MTU Discovery)" (comme défini dans [RFC4821]) pour déterminer la taille de fragmentation appropriée pour la destination.

L'expéditeur PEUT fragmenter un message utilisateur en plusieurs chunks DATA, chacun transportant une portion du message utilisateur. Le destinataire utilisera le numéro de séquence de flux (Stream Sequence Number) et les drapeaux de fragmentation (bit B et bit E) pour réassembler le message.

Lorsqu'un message utilisateur est fragmenté en plusieurs chunks DATA :

  • Le premier fragment DOIT définir le bit B à 1 et le bit E à 0
  • Les fragments intermédiaires DOIVENT définir le bit B à 0 et le bit E à 0
  • Le dernier fragment DOIT définir le bit B à 0 et le bit E à 1
  • Un message non fragmenté DOIT définir le bit B à 1 et le bit E à 1

Tous les chunks DATA transportant des fragments du même message utilisateur DOIVENT avoir le même identifiant de flux (Stream Identifier) et le même numéro de séquence de flux (Stream Sequence Number).

6.1.2. Numéro de séquence de transmission (Transmission Sequence Number, TSN)​

Chaque chunk DATA DOIT contenir un TSN valide. Le TSN est un numéro de séquence de 32 bits qui commence avec la valeur TSN initiale échangée lors de l'initialisation de l'association et s'incrémente de 1 pour chaque chunk DATA envoyé.

L'espace TSN est circulaire, avec des comparaisons utilisant l'arithmétique des numéros de série (Serial Number Arithmetic) (comme défini dans [RFC1982]).

L'expéditeur NE DOIT PAS utiliser des valeurs TSN réservées (c'est-à-dire des TSN en dehors de la fenêtre de réception annoncée par son pair) dans les chunks DATA.

6.1.3. Contrôle de congestion (Congestion Control)​

Les points de terminaison SCTP DOIVENT implémenter le contrôle de congestion pour éviter la congestion du réseau. SCTP utilise des mécanismes de contrôle de congestion similaires à TCP.

Chaque association SCTP maintient les paramètres de contrôle de congestion suivants :

  • cwnd (Fenêtre de congestion, Congestion Window) : La limite supérieure des données pouvant être envoyées sans accusé de réception
  • ssthresh (Seuil de démarrage lent, Slow Start Threshold) : Le seuil qui détermine quand passer du démarrage lent à l'évitement de congestion
  • rwnd (Fenêtre de réception, Receiver Window) : L'espace tampon disponible annoncé par le pair

La quantité de données non acquittées que l'expéditeur peut transmettre à tout moment NE DOIT PAS dépasser min(cwnd, rwnd).

Démarrage lent (Slow Start) :

  • Au début d'une association ou après un délai d'attente, définir cwnd à au plus 2*MTU
  • Chaque fois qu'un SACK est reçu et que toutes les données acquittées ont été envoyées pendant le démarrage lent, augmenter cwnd d'au plus le nombre d'octets acquittés, mais l'augmentation NE DOIT PAS dépasser MTU

Évitement de congestion (Congestion Avoidance) :

  • Lorsque cwnd > ssthresh, augmenter cwnd d'au plus 1*MTU par RTT
  • Les implémentations DEVRAIENT utiliser le "Comptage d'octets approprié (Appropriate Byte Counting)" (comme défini dans [RFC3465])

Retransmission rapide et récupération rapide (Fast Retransmit and Fast Recovery) :

  • Lorsque 4 SACK consécutifs signalent le même TSN comme manquant, l'expéditeur DEVRAIT immédiatement retransmettre ce TSN sans attendre l'expiration du temporisateur de retransmission

6.1.4. Regroupement (Bundling)​

Les points de terminaison SCTP PEUVENT regrouper plusieurs chunks DATA et chunks de contrôle dans un seul paquet SCTP, tant que la taille totale ne dépasse pas le MTU de chemin actuel.

Les avantages du regroupement incluent :

  • Réduction de la surcharge d'en-tête de paquet
  • Amélioration de l'efficacité du réseau
  • Réduction du nombre d'appels système

L'expéditeur DEVRAIT tenter de regrouper autant de données que possible dans un seul paquet, mais NE DOIT PAS retarder la transmission de chunks DATA uniquement pour attendre plus de données à regrouper.

6.2. Accusé de réception lors de la réception de chunks DATA (Acknowledgement on Reception of DATA Chunks)​

Les points de terminaison SCTP receveurs DOIVENT utiliser des chunks SACK (Selective Acknowledgement) pour accuser réception des chunks DATA reçus.

6.2.1. Règles de génération SACK (SACK Generation Rules)​

Le destinataire DEVRAIT utiliser les règles suivantes pour générer des SACK :

  1. Accusé de réception différé (Delayed Acknowledgement) :

    • Le destinataire NE DEVRAIT PAS envoyer un SACK immédiatement pour chaque paquet reçu
    • Le destinataire DEVRAIT retarder l'envoi d'un SACK pendant au maximum 200ms
    • Si un deuxième paquet est reçu, un SACK DOIT être envoyé immédiatement (sans plus de délai)

  2. Situations d'accusé de réception immédiat :

    • Lorsqu'un écart est détecté (chunk DATA hors séquence reçu)
    • Lorsqu'un chunk DATA reçu comble un écart précédent
    • Lorsqu'un TSN en double est reçu

  3. Contenu SACK :

    • Cumulative TSN Ack : Le TSN consécutif le plus élevé reçu
    • Gap Ack Blocks : Indiquant les plages de TSN consécutifs reçus après le point cumulatif
    • Duplicate TSNs : Listant les TSN reçus en double

6.2.2. Traitement SACK (SACK Processing)​

Lors de la réception d'un SACK, l'expéditeur DOIT :

  1. Mettre à jour son point d'accusé de réception cumulatif au Cumulative TSN Ack indiqué dans le SACK
  2. Marquer les chunks DATA acquittés dans les Gap Ack Blocks comme acquittés
  3. Mettre à jour la fenêtre de congestion et le seuil de démarrage lent
  4. Planifier les retransmissions si nécessaire

6.2.3. Mise à jour de la fenêtre de réception (Receiver Window Update)​

Le chunk SACK inclut le crédit de fenêtre de réception annoncé (advertised receiver window credit, a_rwnd), indiquant l'espace tampon disponible du destinataire.

Le destinataire DEVRAIT signaler avec précision son espace tampon disponible dans le SACK. Le destinataire NE DOIT PAS réduire une taille de fenêtre déjà annoncée à moins d'avoir consommé l'espace tampon correspondant.

6.3. Gestion du temporisateur de retransmission (Management of Retransmission Timer)​

SCTP utilise des temporisateurs de retransmission pour assurer une transmission fiable. Chaque adresse de transport de destination maintient son propre temporisateur de retransmission.

6.3.1. Calcul du RTO (RTO Calculation)​

Le délai d'expiration de retransmission (Retransmission Timeout, RTO) est calculé à l'aide d'un algorithme similaire à TCP :

SRTT = Temps d'aller-retour lissé (Smoothed Round-Trip Time)
RTTVAR = Variation du temps d'aller-retour (Round-Trip Time Variation)

Valeurs initiales :
RTO.Initial = 3 secondes (valeur recommandée)
RTO.Min = 1 seconde
RTO.Max = 60 secondes

Première mesure RTT (R) :
SRTT = R
RTTVAR = R/2
RTO = SRTT + 4 * RTTVAR

Mesures RTT suivantes (R') :
RTTVAR = (1 - Beta) * RTTVAR + Beta * |SRTT - R'|
SRTT = (1 - Alpha) * SRTT + Alpha * R'
RTO = SRTT + 4 * RTTVAR

Où : Alpha = 1/8, Beta = 1/4

À chaque retransmission, le RTO DEVRAIT être doublé (retrait exponentiel) jusqu'à ce que RTO.Max soit atteint.

6.3.2. Règles du temporisateur (Timer Rules)​

Temporisateur T3-rtx (Temporisateur de retransmission) :

  • Lorsqu'un chunk DATA est envoyé pour la première fois à une destination et que le temporisateur T3-rtx pour cette destination n'est pas en cours d'exécution, il DOIT être démarré
  • Lorsque tous les chunks DATA non acquittés envoyés à une destination sont acquittés, le temporisateur T3-rtx pour cette destination DOIT être arrêté
  • Lorsque le temporisateur T3-rtx expire, le chunk DATA non acquitté le plus ancien sur cette destination DOIT être retransmis

Gestion de l'expiration T3-rtx :

  1. Marquer la destination comme inactive (si applicable)
  2. Définir ssthresh à max(cwnd/2, 4*MTU)
  3. Définir cwnd à 1*MTU
  4. Retransmettre le chunk DATA non acquitté le plus ancien
  5. Doubler le RTO

6.3.3. Mécanisme de pulsation (Heartbeat Mechanism)​

Pour surveiller l'accessibilité de la destination, les points de terminaison SCTP DEVRAIENT périodiquement envoyer des chunks HEARTBEAT à chaque destination inactive.

L'intervalle HEARTBEAT DEVRAIT être configurable, avec une valeur par défaut recommandée de 30 secondes.

Lorsqu'un HEARTBEAT est envoyé :

  • Démarrer le temporisateur Heartbeat
  • Inclure l'horodatage d'envoi et les informations d'adresse de destination dans le HEARTBEAT

Lorsqu'un HEARTBEAT ACK est reçu :

  • Calculer le RTT
  • Mettre à jour le RTO
  • Marquer la destination comme active

Si le HEARTBEAT expire (aucun HEARTBEAT ACK reçu) :

  • Incrémenter le compteur d'erreurs de la destination
  • Si le compteur d'erreurs dépasse le seuil, marquer la destination comme inactive

6.4. Points de terminaison SCTP multi-domiciliés (Multi-Homed SCTP Endpoints)​

SCTP prend en charge les points de terminaison multi-domiciliés, c'est-à-dire des points de terminaison avec plusieurs adresses IP.

6.4.1. Chemin principal et chemins alternatifs (Primary and Alternate Paths)​

Chaque point de terminaison SCTP maintient :

  • Chemin principal (Primary Path) : Le chemin préféré pour la transmission de données normale
  • Chemins alternatifs (Alternate Paths) : Chemins utilisés lorsque le chemin principal échoue

Le point de terminaison DEVRAIT préférentiellement envoyer des données via le chemin principal, en utilisant des chemins alternatifs uniquement lorsque le chemin principal est indisponible.

6.4.2. Sélection de chemin (Path Selection)​

L'expéditeur DEVRAIT :

  • Utiliser le chemin principal pour envoyer de nouvelles données
  • Utiliser des chemins alternatifs pour les retransmissions (si le chemin principal a échoué)
  • Sonder périodiquement tous les chemins en utilisant HEARTBEAT

Lorsque le chemin principal est déterminé comme inactif, l'expéditeur DEVRAIT sélectionner un chemin alternatif actif comme nouveau chemin principal.

6.4.3. Détection de défaillance de chemin (Path Failure Detection)​

Un chemin est considéré comme défaillant lorsque :

  • Plusieurs échecs de transmission consécutifs se produisent (atteignant Path.Max.Retrans)
  • Plusieurs expirations HEARTBEAT consécutives se produisent

Lorsque tous les chemins échouent, l'association DEVRAIT être signalée à la couche supérieure et peut être terminée.

6.5. Identifiant de flux et numéro de séquence de flux (Stream Identifier and Stream Sequence Number)​

SCTP prend en charge plusieurs flux simultanés, chacun identifié de manière unique par un identifiant de flux (Stream Identifier, SI).

Identifiant de flux (Stream Identifier, SI) :

  • Valeur de 16 bits, plage de 0 à 65535
  • Le nombre de flux est négocié lors de l'initialisation de l'association
  • Chaque flux livre indépendamment des messages utilisateur

Numéro de séquence de flux (Stream Sequence Number, SSN) :

  • Valeur de 16 bits, maintenue indépendamment par flux
  • Utilisé pour réordonner et réassembler les messages au niveau du destinataire
  • Incrémenté par flux

Les flux fournissent une séparation logique des messages, permettant à plusieurs flux de données indépendants d'être transmis simultanément sur la même association, évitant le blocage en tête de ligne (Head-of-Line Blocking).

6.6. Livraison ordonnée et non ordonnée (Ordered and Unordered Delivery)​

SCTP prend en charge deux modes de livraison de messages :

6.6.1. Livraison ordonnée (Ordered Delivery)​

Mode par défaut. Les messages sont livrés à la couche supérieure dans l'ordre dans lequel ils ont été envoyés au sein de chaque flux.

  • Le bit U du chunk DATA est défini à 0
  • Le numéro de séquence de flux assure l'ordre
  • Les messages sur le même flux sont livrés dans l'ordre SSN

6.6.2. Livraison non ordonnée (Unordered Delivery)​

Les messages sont livrés à la couche supérieure immédiatement après réception, quel que soit l'ordre.

  • Le bit U du chunk DATA est défini à 1
  • Le numéro de séquence de flux est ignoré
  • Livré immédiatement après réception, sans attendre les messages précédents

La livraison non ordonnée convient aux données en temps réel qui ne nécessitent pas de garanties d'ordre (par exemple, flux vidéo).

6.7. Signalement des écarts dans les TSN DATA reçus (Report Gaps in Received DATA TSNs)​

Lorsque le destinataire détecte des écarts dans la séquence reçue (c'est-à-dire reçoit des données hors séquence), il DOIT signaler ces écarts dans le SACK.

Format Gap Ack Block :

Gap Ack Block Start : Décalage relatif au Cumulative TSN Ack
Gap Ack Block End : Décalage relatif au Cumulative TSN Ack

Par exemple, si Cumulative TSN Ack = 100, et que les TSN 102-105 sont reçus :

Gap Ack Block Start = 2  (102 - 100)
Gap Ack Block End = 5    (105 - 100)

Le destinataire PEUT signaler plusieurs blocs d'écart dans un seul SACK.

6.8. Calcul de la somme de contrôle CRC32c (CRC32c Checksum Calculation)​

SCTP utilise CRC32c (Castagnoli) comme algorithme de somme de contrôle, offrant une capacité de détection d'erreur plus forte que les sommes de contrôle simples.

6.8.1. Étapes de calcul de la somme de contrôle (Checksum Calculation Steps)​

  1. Définir le champ de somme de contrôle du paquet SCTP à tous zéros
  2. Calculer CRC32c sur l'ensemble du paquet SCTP (y compris l'en-tête commun SCTP et tous les chunks)
  3. Placer la valeur CRC32c calculée dans le champ de somme de contrôle

Polynôme CRC32c :

x^32 + x^28 + x^27 + x^26 + x^25 + x^23 + x^22 + x^20 + x^19 + 
x^18 + x^14 + x^13 + x^11 + x^10 + x^9 + x^8 + x^6 + x^0

Le destinataire DOIT vérifier la somme de contrôle CRC32c de chaque paquet SCTP reçu. Si la somme de contrôle ne correspond pas, le paquet DOIT être silencieusement rejeté.

Ce chapitre couvre de manière exhaustive les mécanismes de base du transfert de données utilisateur SCTP, notamment la transmission fiable, le contrôle de congestion, la prise en charge multi-domiciliation et le multiplexage de flux.

Dernière mise à jour le