6. Uso di SCTP per i data channel

6.1. Considerazioni sul protocollo SCTP

MUST essere usato l'incapsulamento DTLS dei pacchetti SCTP descritto in [RFC8261].

Questo stack SCTP e il suo livello superiore MUST supportare l'uso di piu stream SCTP. Un messaggio utente puo essere inviato in modo ordinato o non ordinato e con affidabilita parziale o completa.

Sono richieste le seguenti estensioni del protocollo SCTP:

• L'estensione di riconfigurazione degli stream definita in [RFC6525] MUST essere supportata. Viene usata per chiudere i canali.
• L'estensione di riconfigurazione dinamica degli indirizzi definita in [RFC5061] MUST essere usata per segnalare il supporto dell'estensione di reset degli stream definita in [RFC6525]. Le altre funzionalita di [RFC5061] sono OPTIONAL.
• L'estensione di affidabilita parziale definita in [RFC3758] MUST essere supportata. Oltre alla politica PR-SCTP di affidabilita temporizzata definita in [RFC3758], la politica di ritrasmissione limitata definita in [RFC7496] MUST essere supportata. Limitare a zero il numero di ritrasmissioni, insieme alla consegna non ordinata, fornisce un servizio simile a UDP in cui ogni messaggio utente e inviato esattamente una volta e consegnato nell'ordine di ricezione.

Il supporto per l'interleaving dei messaggi, come definito in [RFC8260], SHOULD essere usato.

6.2. Gestione dell'associazione SCTP

Nel contesto WebRTC, l'associazione SCTP verra stabilita quando i due endpoint della WebRTC PeerConnection concordano di aprirla, come negoziato dal JavaScript Session Establishment Protocol (JSEP), che e tipicamente uno scambio del Session Description Protocol (SDP) [RFC8829]. Essa usera la connessione DTLS selezionata tramite ICE e, tipicamente, questa sara condivisa tramite BUNDLE o equivalente con le connessioni DTLS usate per stabilire le chiavi degli stream media SRTP.

Il numero di stream negoziati durante la configurazione dell'associazione SCTP SHOULD essere 65535, che e il numero massimo di stream negoziabile durante la configurazione dell'associazione.

SCTP supporta due modi per terminare un'associazione SCTP. Il primo metodo e graceful, in cui si usa una procedura che assicura che nessun messaggio venga perso durante la chiusura dell'associazione. Il secondo metodo e non-graceful, in cui una parte puo semplicemente abortire l'associazione.

Ogni endpoint SCTP supervisiona continuamente la raggiungibilita del proprio peer monitorando il numero di ritrasmissioni dei messaggi utente e dei messaggi di test. In caso di ritrasmissioni eccessive, l'associazione viene terminata in modo non-graceful.

Se un'associazione SCTP viene chiusa in modo graceful, tutti i suoi data channel vengono chiusi. In caso di teardown non-graceful, anche tutti i data channel vengono chiusi, ma SHOULD essere fornita un'indicazione di errore se possibile.

6.3. Stream SCTP

SCTP definisce uno stream come un canale logico unidirezionale esistente all'interno di un'associazione SCTP verso un altro endpoint SCTP. Gli stream sono usati per fornire la nozione di consegna in sequenza e per il multiplexing. Ogni messaggio utente viene inviato su uno stream specifico, in modo ordinato o non ordinato. L'ordinamento e preservato solo per messaggi ordinati inviati sullo stesso stream.

6.4. Definizione di data channel

I data channel sono definiti in modo che la relativa API a livello applicativo possa rispecchiare da vicino l'API per WebSockets, il che implica stream bidirezionali di dati e un campo testuale chiamato 'label' usato per identificare il significato del data channel.

La realizzazione di un data channel e una coppia composta da uno stream in ingresso e uno stream SCTP in uscita con lo stesso identificatore di stream SCTP. Il modo in cui questi identificatori di stream SCTP vengono selezionati dipende dal protocollo e dall'implementazione. Questo consente una comunicazione bidirezionale.

Inoltre, ciascun data channel ha le seguenti proprieta in ciascuna direzione:

• trasmissione dei messaggi affidabile o inaffidabile: in caso di trasmissioni inaffidabili, viene usato lo stesso livello di inaffidabilita. Si noti che, in SCTP, questa e una proprieta di un messaggio utente SCTP e non di uno stream SCTP.
• consegna in ordine o fuori ordine per i messaggi inviati: si noti che, in SCTP, questa e una proprieta di un messaggio utente SCTP e non di uno stream SCTP.
• una priorita, che e un intero senza segno di 2 byte: queste priorita MUST essere interpretate come priorita di scheduling weighted-fair-queuing secondo la definizione del corrispondente scheduler di stream che supporta l'interleaving in [RFC8260]. Per l'uso in WebRTC, i valori usati SHOULD essere uno tra 128 ("below normal"), 256 ("normal"), 512 ("high") o 1024 ("extra high").
• una label opzionale.
• un protocollo opzionale.

Si noti che, per un data channel negoziato con il protocollo specificato in [RFC8832], tutte le proprieta sopra indicate sono uguali in entrambe le direzioni.

6.5. Apertura di un data channel

I data channel possono essere aperti usando la negoziazione all'interno dell'associazione SCTP (chiamata negoziazione in-band) oppure la negoziazione out-of-band. La negoziazione out-of-band e definita come qualsiasi metodo che porta a un accordo sui parametri di un canale e alla sua creazione. I dettagli non rientrano nell'ambito di questo documento. Le applicazioni che usano data channel devono usare i metodi di negoziazione in modo coerente su entrambi gli endpoint.

Un protocollo semplice per la negoziazione in-band e specificato in [RFC8832].

Quando una parte vuole aprire un canale usando la negoziazione out-of-band, sceglie uno stream. Salvo diversa definizione o negoziazione, gli stream sono scelti in base al ruolo DTLS (il client sceglie identificatori di stream pari e il server sceglie identificatori di stream dispari). Tuttavia, l'applicazione e responsabile di evitare collisioni con stream esistenti. Se tenta di riusare uno stream che fa parte di un data channel esistente, l'aggiunta MUST fallire. Oltre a scegliere uno stream, l'applicazione SHOULD anche determinare le opzioni da usare per l'invio dei messaggi. L'applicazione MUST garantire, in modo specifico dell'applicazione, che anche l'applicazione del peer conosca lo stream selezionato da usare, nonche le opzioni per inviare dati da quel lato.

6.6. Trasferimento di dati utente su un data channel

Tutti i dati inviati su un data channel in entrambe le direzioni MUST essere inviati sullo stream sottostante usando l'affidabilita definita quando il data channel e stato aperto, a meno che le opzioni vengano cambiate o opzioni per messaggio siano specificate da un livello superiore.

L'orientamento ai messaggi di SCTP viene usato per preservare i confini dei messaggi utente. Pertanto, i mittenti MUST NOT inserire piu di un messaggio applicativo in un messaggio utente SCTP. A meno che non venga usata la frammentazione e il riassemblaggio deprecati basati su PPID, il mittente MUST includere esattamente un messaggio applicativo in ciascun messaggio utente SCTP.

Gli SCTP Payload Protocol Identifiers (PPID) sono usati per segnalare l'interpretazione dei "payload data". I seguenti PPID MUST essere usati (vedere Sezione 8):

• WebRTC String: per identificare una stringa JavaScript non vuota codificata in UTF-8.
• WebRTC String Empty: per identificare una stringa JavaScript vuota codificata in UTF-8.
• WebRTC Binary: per identificare dati binari JavaScript non vuoti (ArrayBuffer, ArrayBufferView o Blob).
• WebRTC Binary Empty: per identificare dati binari JavaScript vuoti (ArrayBuffer, ArrayBufferView o Blob).

SCTP non supporta l'invio di messaggi utente vuoti. Pertanto, se deve essere inviato un messaggio vuoto, viene usato il PPID appropriato (WebRTC String Empty o WebRTC Binary Empty), e viene inviato un messaggio utente SCTP di un byte zero. Quando riceve un messaggio utente SCTP con uno di questi PPID, il ricevitore MUST ignorare il messaggio utente SCTP e trattarlo come un messaggio vuoto.

L'uso dei PPID "WebRTC String Partial" e "WebRTC Binary Partial" e deprecato. Erano usati per la frammentazione e il riassemblaggio basati su PPID di messaggi utente appartenenti a data channel affidabili e ordinati.

Se viene ricevuto un messaggio con un PPID non supportato o se il ricevitore rileva una condizione di errore relativa al messaggio ricevuto (per esempio, ordinamento illegale), il ricevitore SHOULD chiudere il data channel corrispondente. Questo implica in particolare che estensioni che usano PPID aggiuntivi non possono essere usate senza una negoziazione preventiva.

Il protocollo base SCTP specificato in [RFC4960] non supporta l'interleaving dei messaggi utente. Pertanto, l'invio di un messaggio utente di grandi dimensioni puo monopolizzare l'associazione SCTP. Per superare questa limitazione, [RFC8260] definisce un'estensione per supportare l'interleaving dei messaggi, che SHOULD essere usata. Finche l'interleaving dei messaggi non e supportato, il mittente SHOULD limitare la dimensione massima dei messaggi a 16 KB per evitare la monopolizzazione.

Si raccomanda di mantenere la dimensione dei messaggi entro determinati limiti, poiche le applicazioni non saranno in grado di supportare singoli messaggi arbitrariamente grandi. Questo limite deve essere negoziato, per esempio usando [RFC8841].

Il mittente SHOULD disabilitare l'algoritmo di Nagle (vedere [RFC1122]) per minimizzare la latenza.

6.7. Chiusura di un data channel

La chiusura di un data channel MUST essere segnalata reimpostando gli stream in uscita corrispondenti [RFC6525]. Questo significa che, se una parte decide di chiudere il data channel, reimposta lo stream in uscita corrispondente. Quando il peer vede che uno stream in ingresso e stato reimpostato, reimposta anche il proprio stream in uscita corrispondente. Una volta completata questa operazione, il data channel e chiuso. Reimpostare uno stream riporta a 'zero' gli Stream Sequence Numbers (SSN) dello stream, con una notifica corrispondente al livello applicativo che il reset e stato eseguito. Gli stream sono disponibili per il riuso dopo l'esecuzione del reset.

[RFC6525] garantisce inoltre che tutti i messaggi siano consegnati (o abbandonati) prima che lo stream venga reimpostato.