Aller au contenu principal

7. Contrôle de congestion (Congestion Control)

SCTP utilise des mécanismes de contrôle de congestion similaires à TCP pour éviter la congestion du réseau et assurer un partage équitable des ressources réseau.

7.1. Différences entre SCTP et le contrôle de congestion TCP (SCTP Differences from TCP Congestion Control)​

Bien que le contrôle de congestion de SCTP soit basé sur les mécanismes TCP, il existe les différences clés suivantes :

7.1.1. Multi-domiciliation et multi-chemins​

SCTP prend en charge les points de terminaison multi-domiciliés, chaque adresse de transport de destination maintenant des paramètres de contrôle de congestion indépendants :

  • cwnd par destination : Chaque chemin a sa propre fenêtre de congestion
  • ssthresh par destination : Chaque chemin a son propre seuil de démarrage lent
  • RTO par destination : Chaque chemin a son propre délai d'expiration de retransmission

Cela permet à SCTP d'effectuer un contrôle de congestion indépendamment sur différents chemins.

7.1.2. Accusé de réception basé sur TSN​

SCTP utilise des TSN plutôt que des numéros de séquence d'octets pour l'accusé de réception. Cela signifie :

  • La fenêtre de congestion est maintenue en octets
  • SACK accuse réception des plages de TSN
  • Les mises à jour de cwnd sont basées sur les octets acquittés, pas sur le nombre de TSN

7.1.3. Transmission multi-flux​

Les multiples flux de SCTP partagent les paramètres de contrôle de congestion de la même association. Il n'y a pas de contrôle de congestion séparé entre les flux, ce qui garantit :

  • Tous les flux partagent équitablement la bande passante
  • Empêche un seul flux de monopoliser les ressources

7.2. Démarrage lent et évitement de congestion SCTP (SCTP Slow-Start and Congestion Avoidance)​

L'algorithme de contrôle de congestion de SCTP suit les principes de démarrage lent et d'évitement de congestion de TCP.

7.2.1. Initialisation et redémarrage​

Lorsqu'une association est établie pour la première fois ou qu'un chemin redémarre après avoir été inactif :

cwnd = min(4*MTU, max(2*MTU, 4380 octets))
ssthresh = a_rwnd du pair

Note : Le calcul du cwnd initial garantit qu'au moins 2 paquets complets peuvent être envoyés, mais pas plus de 4 paquets de taille MTU.

7.2.2. Phase de démarrage lent​

Pendant le démarrage lent (cwnd <= ssthresh) :

Lorsqu'un SACK pour de nouvelles données est reçu :

cwnd = cwnd + min(octets acquittés, MTU)

Règles :

  • cwnd augmente d'au plus un MTU à la fois
  • N'augmenter que lorsque toutes les données acquittées ont été envoyées sous le cwnd actuel
  • Lorsque cwnd atteint ou dépasse ssthresh, entrer en phase d'évitement de congestion

7.2.3. Phase d'évitement de congestion​

Lorsque cwnd > ssthresh :

Utilisation du comptage d'octets approprié (Appropriate Byte Counting, ABC) :

Par RTT :
partial_bytes_acked = partial_bytes_acked + octets acquittés

Lorsque partial_bytes_acked >= cwnd :
    cwnd = cwnd + MTU
    partial_bytes_acked = partial_bytes_acked - cwnd

Objectif : Augmenter cwnd d'environ 1 MTU par RTT.

7.2.4. Détection et réponse à la congestion​

Signaux de congestion :

  1. Expiration du délai de retransmission (expiration RTO)
  2. Retransmission rapide (4 SACK en double reçus)

Réponse à l'expiration RTO :

ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0

Réponse à la retransmission rapide :

ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
partial_bytes_acked = 0

7.2.5. Gestion après période d'inactivité​

Si une destination n'a pas de transmission de données pendant une période RTO (inactive) :

Option 1 (Recommandée) :

cwnd = max(cwnd/2, 4*MTU)

Option 2 (Conservative) :

cwnd = min(4*MTU, max(2*MTU, 4380 octets))

Cela empêche d'envoyer soudainement de grandes quantités de données après une longue période d'inactivité.

7.3. Découverte du MTU de chemin (Path MTU Discovery)​

Les points de terminaison SCTP DEVRAIENT utiliser la découverte du MTU de chemin (Packetization Layer PMTUD tel que défini dans [RFC4821]) pour :

  • Déterminer le MTU maximum disponible vers la destination
  • Éviter la fragmentation IP
  • Optimiser l'efficacité de la transmission de données

7.3.1. Processus de découverte PMTU​

  1. MTU initial : Utiliser une valeur initiale conservative (généralement 576 octets pour IPv4, 1280 octets pour IPv6)

  2. Sonder un MTU plus grand :

    • Envoyer des paquets avec le drapeau "Don't Fragment" activé
    • Si réussi, essayer un MTU plus grand
    • Si échoué (recevoir ICMP "Packet Too Big"), utiliser un MTU plus petit

  3. Re-sondage périodique : Essayer périodiquement un MTU plus grand pour s'adapter aux changements de chemin

7.3.2. Impact des mises à jour MTU sur le contrôle de congestion​

Lorsque PMTU augmente :

cwnd = (cwnd / ancien_MTU) * nouveau_MTU
ssthresh = (ssthresh / ancien_MTU) * nouveau_MTU

Lorsque PMTU diminue :

cwnd = (cwnd / ancien_MTU) * nouveau_MTU
ssthresh = (ssthresh / ancien_MTU) * nouveau_MTU
partial_bytes_acked = min(partial_bytes_acked, cwnd)

Cela garantit que les paramètres de contrôle de congestion maintiennent une relation cohérente avec la taille du MTU.

7.3.3. Gestion des échecs​

Si la découverte PMTU échoue ou n'est pas disponible :

  • Utiliser une valeur MTU conservative
  • Ne pas utiliser le drapeau "Don't Fragment"
  • Permettre à la couche IP d'effectuer la fragmentation

Résumé​

La conception du contrôle de congestion de SCTP considère les facteurs clés suivants :

  1. Support multi-chemins : Contrôle de congestion indépendant par chemin
  2. Convivialité TCP : Partage équitable de la bande passante réseau avec TCP
  3. Efficacité multi-flux : Éviter le blocage en tête de ligne tout en maintenant le contrôle de congestion
  4. Adaptation de chemin : Optimiser la transmission via la découverte PMTU

Ces mécanismes garantissent que SCTP peut utiliser efficacement les ressources réseau tout en coexistant équitablement avec d'autres trafics.

Dernière mise à jour le