Passa al contenuto principale

6. Trasferimento dei dati utente (User Data Transfer)

Questo capitolo descrive il meccanismo di trasferimento dei dati utente tra gli endpoint SCTP.

6.1. Trasmissione dei chunk DATA (Transmission of DATA Chunks)​

Gli endpoint SCTP scambiano messaggi utente attraverso chunk DATA su un'associazione stabilita.

6.1.1. Dati di payload (Payload Data)​

Il mittente DOVREBBE utilizzare la "Path MTU Discovery" (come definito in [RFC4821]) per determinare la dimensione di frammentazione appropriata per la destinazione.

Il mittente PUÒ frammentare un messaggio utente in più chunk DATA, ognuno che trasporta una porzione del messaggio utente. Il destinatario utilizzerà il numero di sequenza del flusso (Stream Sequence Number) e i flag di frammentazione (bit B e bit E) per riassemblare il messaggio.

Quando un messaggio utente viene frammentato in più chunk DATA:

  • Il primo frammento DEVE impostare il bit B a 1 e il bit E a 0
  • I frammenti intermedi DEVONO impostare il bit B a 0 e il bit E a 0
  • L'ultimo frammento DEVE impostare il bit B a 0 e il bit E a 1
  • Un messaggio non frammentato DEVE impostare il bit B a 1 e il bit E a 1

Tutti i chunk DATA che trasportano frammenti dello stesso messaggio utente DEVONO avere lo stesso identificatore di flusso (Stream Identifier) e lo stesso numero di sequenza del flusso (Stream Sequence Number).

6.1.2. Numero di sequenza di trasmissione (Transmission Sequence Number, TSN)​

Ogni chunk DATA DEVE contenere un TSN valido. Il TSN è un numero di sequenza a 32 bit che inizia con il valore TSN iniziale scambiato durante l'inizializzazione dell'associazione e si incrementa di 1 per ogni chunk DATA inviato.

Lo spazio TSN è circolare, con confronti che utilizzano l'aritmetica dei numeri di serie (Serial Number Arithmetic) (come definito in [RFC1982]).

Il mittente NON DEVE utilizzare valori TSN riservati (cioè TSN al di fuori della finestra di ricezione annunciata dal suo peer) nei chunk DATA.

6.1.3. Controllo della congestione (Congestion Control)​

Gli endpoint SCTP DEVONO implementare il controllo della congestione per evitare la congestione della rete. SCTP utilizza meccanismi di controllo della congestione simili a TCP.

Ogni associazione SCTP mantiene i seguenti parametri di controllo della congestione:

  • cwnd (Finestra di congestione, Congestion Window): Il limite superiore dei dati che possono essere inviati senza riconoscimento
  • ssthresh (Soglia di avvio lento, Slow Start Threshold): La soglia che determina quando passare dall'avvio lento all'evitamento della congestione
  • rwnd (Finestra di ricezione, Receiver Window): Lo spazio buffer disponibile annunciato dal peer

La quantità di dati non riconosciuti che il mittente può trasmettere in qualsiasi momento NON DEVE superare min(cwnd, rwnd).

Avvio lento (Slow Start):

  • All'inizio di un'associazione o dopo un timeout, impostare cwnd a non più di 2*MTU
  • Ogni volta che viene ricevuto un SACK e tutti i dati riconosciuti sono stati inviati durante l'avvio lento, aumentare cwnd di non più del numero di byte riconosciuti, ma l'aumento NON DEVE superare MTU

Evitamento della congestione (Congestion Avoidance):

  • Quando cwnd > ssthresh, aumentare cwnd di al massimo 1*MTU per RTT
  • Le implementazioni DOVREBBERO utilizzare "Appropriate Byte Counting" (come definito in [RFC3465])

Ritrasmissione rapida e recupero rapido (Fast Retransmit and Fast Recovery):

  • Quando 4 SACK consecutivi riportano lo stesso TSN come mancante, il mittente DOVREBBE immediatamente ritrasmettere quel TSN senza attendere la scadenza del timer di ritrasmissione

6.1.4. Raggruppamento (Bundling)​

Gli endpoint SCTP POSSONO raggruppare più chunk DATA e chunk di controllo in un singolo pacchetto SCTP, purché la dimensione totale non superi l'MTU del percorso corrente.

I vantaggi del raggruppamento includono:

  • Riduzione dell'overhead dell'intestazione del pacchetto
  • Miglioramento dell'efficienza della rete
  • Riduzione del numero di chiamate di sistema

Il mittente DOVREBBE tentare di raggruppare quanti più dati possibile in un singolo pacchetto, ma NON DEVE ritardare la trasmissione dei chunk DATA solo per attendere più dati da raggruppare.

6.2. Riconoscimento alla ricezione di chunk DATA (Acknowledgement on Reception of DATA Chunks)​

Gli endpoint SCTP riceventi DEVONO utilizzare chunk SACK (Selective Acknowledgement) per riconoscere i chunk DATA ricevuti.

6.2.1. Regole di generazione SACK (SACK Generation Rules)​

Il destinatario DOVREBBE utilizzare le seguenti regole per generare SACK:

  1. Riconoscimento ritardato (Delayed Acknowledgement):

    • Il destinatario NON DOVREBBE inviare un SACK immediatamente per ogni pacchetto ricevuto
    • Il destinatario DOVREBBE ritardare l'invio di un SACK per un massimo di 200ms
    • Se viene ricevuto un secondo pacchetto, un SACK DEVE essere inviato immediatamente (nessun ulteriore ritardo)

  2. Situazioni di riconoscimento immediato:

    • Quando viene rilevato un gap (chunk DATA fuori sequenza ricevuto)
    • Quando un chunk DATA ricevuto riempie un gap precedente
    • Quando viene ricevuto un TSN duplicato

  3. Contenuto SACK:

    • Cumulative TSN Ack: Il TSN consecutivo più alto ricevuto
    • Gap Ack Blocks: Indicazione di intervalli di TSN consecutivi ricevuti dopo il punto cumulativo
    • Duplicate TSNs: Elenco di TSN ricevuti in duplicato

6.2.2. Elaborazione SACK (SACK Processing)​

Alla ricezione di un SACK, il mittente DEVE:

  1. Aggiornare il suo punto di riconoscimento cumulativo al Cumulative TSN Ack indicato nel SACK
  2. Contrassegnare i chunk DATA riconosciuti nei Gap Ack Blocks come riconosciuti
  3. Aggiornare la finestra di congestione e la soglia di avvio lento
  4. Pianificare le ritrasmissioni secondo necessità

6.2.3. Aggiornamento della finestra di ricezione (Receiver Window Update)​

Il chunk SACK include il credito della finestra di ricezione annunciato (advertised receiver window credit, a_rwnd), che indica lo spazio buffer disponibile del destinatario.

Il destinatario DOVREBBE riportare accuratamente il suo spazio buffer disponibile nel SACK. Il destinatario NON DEVE ridurre una dimensione della finestra già annunciata a meno che non abbia consumato lo spazio buffer corrispondente.

6.3. Gestione del timer di ritrasmissione (Management of Retransmission Timer)​

SCTP utilizza timer di ritrasmissione per garantire una trasmissione affidabile. Ogni indirizzo di trasporto di destinazione mantiene il proprio timer di ritrasmissione.

6.3.1. Calcolo RTO (RTO Calculation)​

Il timeout di ritrasmissione (Retransmission Timeout, RTO) viene calcolato utilizzando un algoritmo simile a TCP:

SRTT = Tempo di andata e ritorno levigato (Smoothed Round-Trip Time)
RTTVAR = Variazione del tempo di andata e ritorno (Round-Trip Time Variation)

Valori iniziali:
RTO.Initial = 3 secondi (valore raccomandato)
RTO.Min = 1 secondo
RTO.Max = 60 secondi

Prima misurazione RTT (R):
SRTT = R
RTTVAR = R/2
RTO = SRTT + 4 * RTTVAR

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

Dove: Alpha = 1/8, Beta = 1/4

Ad ogni ritrasmissione, il RTO DOVREBBE essere raddoppiato (backoff esponenziale) fino al raggiungimento di RTO.Max.

6.3.2. Regole del timer (Timer Rules)​

Timer T3-rtx (Timer di ritrasmissione):

  • Quando un chunk DATA viene inviato per la prima volta a una destinazione e il timer T3-rtx per quella destinazione non è in esecuzione, DEVE essere avviato
  • Quando tutti i chunk DATA non riconosciuti inviati a una destinazione sono riconosciuti, il timer T3-rtx per quella destinazione DEVE essere fermato
  • Quando il timer T3-rtx scade, il chunk DATA non riconosciuto più vecchio su quella destinazione DEVE essere ritrasmesso

Gestione del timeout T3-rtx:

  1. Contrassegnare la destinazione come inattiva (se applicabile)
  2. Impostare ssthresh a max(cwnd/2, 4*MTU)
  3. Impostare cwnd a 1*MTU
  4. Ritrasmettere il chunk DATA non riconosciuto più vecchio
  5. Raddoppiare il RTO

6.3.3. Meccanismo Heartbeat (Heartbeat Mechanism)​

Per monitorare la raggiungibilità della destinazione, gli endpoint SCTP DOVREBBERO inviare periodicamente chunk HEARTBEAT a ciascuna destinazione inattiva.

L'intervallo HEARTBEAT DOVREBBE essere configurabile, con un valore predefinito raccomandato di 30 secondi.

Quando viene inviato un HEARTBEAT:

  • Avviare il timer Heartbeat
  • Includere il timestamp di invio e le informazioni sull'indirizzo di destinazione nel HEARTBEAT

Quando viene ricevuto un HEARTBEAT ACK:

  • Calcolare il RTT
  • Aggiornare il RTO
  • Contrassegnare la destinazione come attiva

Se HEARTBEAT scade (nessun HEARTBEAT ACK ricevuto):

  • Incrementare il contatore degli errori della destinazione
  • Se il contatore degli errori supera la soglia, contrassegnare la destinazione come inattiva

6.4. Endpoint SCTP multi-homed (Multi-Homed SCTP Endpoints)​

SCTP supporta endpoint multi-homed, cioè endpoint con più indirizzi IP.

6.4.1. Percorso primario e percorsi alternativi (Primary and Alternate Paths)​

Ogni endpoint SCTP mantiene:

  • Percorso primario (Primary Path): Il percorso preferito per la trasmissione dati normale
  • Percorsi alternativi (Alternate Paths): Percorsi utilizzati quando il percorso primario fallisce

L'endpoint DOVREBBE preferenzialmente inviare dati attraverso il percorso primario, utilizzando percorsi alternativi solo quando il percorso primario non è disponibile.

6.4.2. Selezione del percorso (Path Selection)​

Il mittente DOVREBBE:

  • Utilizzare il percorso primario per inviare nuovi dati
  • Utilizzare percorsi alternativi per le ritrasmissioni (se il percorso primario è fallito)
  • Sondare periodicamente tutti i percorsi utilizzando HEARTBEAT

Quando il percorso primario viene determinato come inattivo, il mittente DOVREBBE selezionare un percorso alternativo attivo come nuovo percorso primario.

6.4.3. Rilevamento del guasto del percorso (Path Failure Detection)​

Un percorso è considerato fallito quando:

  • Si verificano più fallimenti di trasmissione consecutivi (raggiungendo Path.Max.Retrans)
  • Si verificano più timeout HEARTBEAT consecutivi

Quando tutti i percorsi falliscono, l'associazione DOVREBBE essere segnalata al livello superiore e può essere terminata.

6.5. Identificatore di flusso e numero di sequenza del flusso (Stream Identifier and Stream Sequence Number)​

SCTP supporta più flussi simultanei, ciascuno identificato univocamente da un identificatore di flusso (Stream Identifier, SI).

Identificatore di flusso (Stream Identifier, SI):

  • Valore a 16 bit, intervallo da 0 a 65535
  • Il numero di flussi viene negoziato durante l'inizializzazione dell'associazione
  • Ogni flusso consegna messaggi utente indipendentemente

Numero di sequenza del flusso (Stream Sequence Number, SSN):

  • Valore a 16 bit, mantenuto indipendentemente per flusso
  • Utilizzato per riordinare e riassemblare i messaggi al destinatario
  • Incrementato per flusso

I flussi forniscono una separazione logica dei messaggi, consentendo a più flussi di dati indipendenti di essere trasmessi simultaneamente sulla stessa associazione, evitando il blocco head-of-line (Head-of-Line Blocking).

6.6. Consegna ordinata e non ordinata (Ordered and Unordered Delivery)​

SCTP supporta due modalità di consegna dei messaggi:

6.6.1. Consegna ordinata (Ordered Delivery)​

Modalità predefinita. I messaggi vengono consegnati al livello superiore nell'ordine in cui sono stati inviati all'interno di ciascun flusso.

  • Il bit U del chunk DATA è impostato a 0
  • Il numero di sequenza del flusso garantisce l'ordine
  • I messaggi sullo stesso flusso vengono consegnati nell'ordine SSN

6.6.2. Consegna non ordinata (Unordered Delivery)​

I messaggi vengono consegnati al livello superiore immediatamente dopo la ricezione, indipendentemente dall'ordine.

  • Il bit U del chunk DATA è impostato a 1
  • Il numero di sequenza del flusso viene ignorato
  • Consegnato immediatamente dopo la ricezione, senza attendere i messaggi precedenti

La consegna non ordinata è adatta per dati in tempo reale che non richiedono garanzie di ordine (ad esempio, flussi video).

6.7. Segnalazione di gap nei TSN DATA ricevuti (Report Gaps in Received DATA TSNs)​

Quando il destinatario rileva gap nella sequenza ricevuta (cioè riceve dati fuori sequenza), DEVE segnalare questi gap nel SACK.

Formato Gap Ack Block:

Gap Ack Block Start: Offset relativo al Cumulative TSN Ack
Gap Ack Block End: Offset relativo al Cumulative TSN Ack

Ad esempio, se Cumulative TSN Ack = 100 e vengono ricevuti i TSN 102-105:

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

Il destinatario PUÒ segnalare più blocchi di gap in un singolo SACK.

6.8. Calcolo del checksum CRC32c (CRC32c Checksum Calculation)​

SCTP utilizza CRC32c (Castagnoli) come algoritmo di checksum, fornendo una capacità di rilevamento degli errori più forte rispetto ai checksum semplici.

6.8.1. Passaggi di calcolo del checksum (Checksum Calculation Steps)​

  1. Impostare il campo checksum del pacchetto SCTP a tutti zeri
  2. Calcolare CRC32c sull'intero pacchetto SCTP (inclusa l'intestazione comune SCTP e tutti i chunk)
  3. Posizionare il valore CRC32c calcolato nel campo checksum

Polinomio 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

Il destinatario DEVE verificare il checksum CRC32c di ogni pacchetto SCTP ricevuto. Se il checksum non corrisponde, il pacchetto DEVE essere scartato silenziosamente.

Questo capitolo copre in modo esaustivo i meccanismi fondamentali del trasferimento dei dati utente SCTP, inclusa la trasmissione affidabile, il controllo della congestione, il supporto multi-homing e il multiplexing dei flussi.

Ultimo aggiornamento il