Passa al contenuto principale

7. Controllo della congestione (Congestion Control)

SCTP utilizza meccanismi di controllo della congestione simili a TCP per evitare la congestione della rete e garantire una condivisione equa delle risorse di rete.

7.1. Differenze tra SCTP e il controllo della congestione TCP (SCTP Differences from TCP Congestion Control)​

Sebbene il controllo della congestione di SCTP sia basato sui meccanismi TCP, esistono le seguenti differenze chiave:

7.1.1. Multi-homing e multi-percorso​

SCTP supporta endpoint multi-homed, con ciascun indirizzo di trasporto di destinazione che mantiene parametri di controllo della congestione indipendenti:

  • cwnd per destinazione: Ogni percorso ha la propria finestra di congestione
  • ssthresh per destinazione: Ogni percorso ha la propria soglia di avvio lento
  • RTO per destinazione: Ogni percorso ha il proprio timeout di ritrasmissione

Ciò consente a SCTP di eseguire il controllo della congestione indipendentemente su percorsi diversi.

7.1.2. Riconoscimento basato su TSN​

SCTP utilizza TSN anziché numeri di sequenza di byte per il riconoscimento. Ciò significa:

  • La finestra di congestione viene mantenuta in byte
  • SACK riconosce intervalli di TSN
  • Gli aggiornamenti di cwnd si basano sui byte riconosciuti, non sul conteggio dei TSN

7.1.3. Trasmissione multi-flusso​

I multipli flussi di SCTP condividono i parametri di controllo della congestione della stessa associazione. Non esiste un controllo della congestione separato tra i flussi, il che garantisce:

  • Tutti i flussi condividono equamente la larghezza di banda
  • Impedisce a un singolo flusso di monopolizzare le risorse

7.2. Avvio lento e evitamento della congestione SCTP (SCTP Slow-Start and Congestion Avoidance)​

L'algoritmo di controllo della congestione di SCTP segue i principi di avvio lento ed evitamento della congestione di TCP.

7.2.1. Inizializzazione e riavvio​

Quando un'associazione viene stabilita per la prima volta o un percorso si riavvia dopo essere stato inattivo:

cwnd = min(4*MTU, max(2*MTU, 4380 byte))
ssthresh = a_rwnd del peer

Nota: Il calcolo del cwnd iniziale garantisce che almeno 2 pacchetti completi possano essere inviati, ma non più di 4 pacchetti di dimensione MTU.

7.2.2. Fase di avvio lento​

Durante l'avvio lento (cwnd <= ssthresh):

Quando viene ricevuto un SACK per nuovi dati:

cwnd = cwnd + min(byte riconosciuti, MTU)

Regole:

  • cwnd aumenta di al massimo un MTU alla volta
  • Aumentare solo quando tutti i dati riconosciuti sono stati inviati sotto il cwnd corrente
  • Quando cwnd raggiunge o supera ssthresh, entrare nella fase di evitamento della congestione

7.2.3. Fase di evitamento della congestione​

Quando cwnd > ssthresh:

Utilizzando il conteggio appropriato dei byte (Appropriate Byte Counting, ABC):

Per RTT:
partial_bytes_acked = partial_bytes_acked + byte riconosciuti

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

Obiettivo: Aumentare cwnd di circa 1 MTU per RTT.

7.2.4. Rilevamento e risposta alla congestione​

Segnali di congestione:

  1. Timeout di ritrasmissione (scadenza RTO)
  2. Ritrasmissione rapida (4 SACK duplicati ricevuti)

Risposta al timeout RTO:

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

Risposta alla ritrasmissione rapida:

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

7.2.5. Gestione dopo periodo di inattività​

Se una destinazione non ha trasmissione di dati per un periodo RTO (inattiva):

Opzione 1 (Consigliata):

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

Opzione 2 (Conservativa):

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

Ciò impedisce di inviare improvvisamente grandi quantità di dati dopo un lungo periodo di inattività.

7.3. Scoperta dell'MTU del percorso (Path MTU Discovery)​

Gli endpoint SCTP DOVREBBERO utilizzare la scoperta dell'MTU del percorso (Packetization Layer PMTUD come definito in [RFC4821]) per:

  • Determinare l'MTU massimo disponibile verso la destinazione
  • Evitare la frammentazione IP
  • Ottimizzare l'efficienza della trasmissione dei dati

7.3.1. Processo di scoperta PMTU​

  1. MTU iniziale: Utilizzare un valore iniziale conservativo (tipicamente 576 byte per IPv4, 1280 byte per IPv6)

  2. Sondare MTU più grande:

    • Inviare pacchetti con il flag "Don't Fragment" impostato
    • Se ha successo, provare MTU più grande
    • Se fallisce (ricevere ICMP "Packet Too Big"), utilizzare MTU più piccolo

  3. Ri-sondaggio periodico: Provare periodicamente MTU più grande per adattarsi ai cambiamenti del percorso

7.3.2. Impatto degli aggiornamenti MTU sul controllo della congestione​

Quando PMTU aumenta:

cwnd = (cwnd / vecchio_MTU) * nuovo_MTU
ssthresh = (ssthresh / vecchio_MTU) * nuovo_MTU

Quando PMTU diminuisce:

cwnd = (cwnd / vecchio_MTU) * nuovo_MTU
ssthresh = (ssthresh / vecchio_MTU) * nuovo_MTU
partial_bytes_acked = min(partial_bytes_acked, cwnd)

Ciò garantisce che i parametri di controllo della congestione mantengano una relazione coerente con la dimensione dell'MTU.

7.3.3. Gestione dei fallimenti​

Se la scoperta PMTU fallisce o non è disponibile:

  • Utilizzare un valore MTU conservativo
  • Non utilizzare il flag "Don't Fragment"
  • Consentire al livello IP di eseguire la frammentazione

Il design del controllo della congestione di SCTP considera i seguenti fattori chiave:

  1. Supporto multi-percorso: Controllo della congestione indipendente per percorso
  2. Compatibilità TCP: Condivisione equa della larghezza di banda di rete con TCP
  3. Efficienza multi-flusso: Evitare il blocco head-of-line mantenendo il controllo della congestione
  4. Adattamento del percorso: Ottimizzare la trasmissione tramite la scoperta PMTU

Questi meccanismi garantiscono che SCTP possa utilizzare efficacemente le risorse di rete coesistendo equamente con altro traffico.

Ultimo aggiornamento il