Passa al contenuto principale

5. Considerazioni su SCTP sopra DTLS sopra UDP

Le caratteristiche importanti di SCTP nel contesto WebRTC sono le seguenti:

  • Uso di un controllo di congestione TCP-friendly.
  • Controllo di congestione modificabile per l'integrazione con il controllo di congestione degli stream media SRTP.
  • Supporto di piu stream unidirezionali, ciascuno dei quali fornisce una propria nozione di consegna ordinata dei messaggi.
  • Supporto della consegna dei messaggi ordinata e fuori ordine.
  • Supporto di messaggi utente di dimensione arbitrariamente grande tramite frammentazione e riassemblaggio.
  • Supporto della scoperta PMTU.
  • Supporto del trasporto di messaggi affidabile o parzialmente affidabile.

Il meccanismo dei data channel WebRTC non supporta il multihoming SCTP. Il livello SCTP si comportera semplicemente come se fosse in esecuzione su un host single-homed, poiche questa e l'astrazione esposta dal livello DTLS (un servizio datagrammi inaffidabile orientato alla connessione).

L'incapsulamento di SCTP sopra DTLS definito in [RFC8261] fornisce riservatezza, autenticazione della sorgente e trasferimenti protetti nell'integrita. L'uso di DTLS sopra UDP in combinazione con Interactive Connectivity Establishment (ICE) [RFC8445] abilita l'attraversamento dei middlebox in reti basate su IPv4 e IPv6. SCTP come specificato in [RFC4960] MUST essere usato in combinazione con l'estensione definita in [RFC3758] e fornisce le seguenti caratteristiche per il trasporto di dati non multimediali tra browser:

  • Supporto di piu stream unidirezionali.
  • Consegna ordinata e non ordinata dei messaggi utente.
  • Trasporto affidabile e parzialmente affidabile dei messaggi utente.

Ogni messaggio utente SCTP contiene un Payload Protocol Identifier (PPID) che viene passato a SCTP dal suo livello superiore sul lato di invio e fornito al suo livello superiore sul lato di ricezione. Il PPID puo essere usato per multiplexare/demultiplexare piu livelli superiori su una singola associazione SCTP. Nel contesto WebRTC, il PPID viene usato per distinguere tra dati utente codificati in UTF-8, dati utente codificati in binario e il Data Channel Establishment Protocol (DCEP) definito in [RFC8832]. Si noti che il PPID non e accessibile tramite l'API JavaScript.

L'incapsulamento di SCTP sopra DTLS, insieme alle caratteristiche SCTP elencate sopra, soddisfa tutti i requisiti indicati nella Sezione 4.

La stratificazione dei protocolli per WebRTC e mostrata nella Figura 2.

              +------+------+------+
              | DCEP | UTF-8|Binary|
              |      | Data | Data |
              +------+------+------+
              |        SCTP        |
+----------------------------------+
| STUN | SRTP |        DTLS        |
+----------------------------------+
|                ICE               |
+----------------------------------+
| UDP1 | UDP2 | UDP3 | ...         |
+----------------------------------+

Figura 2: livelli di protocollo WebRTC

Questo stack (in particolare rispetto a DTLS sopra SCTP [RFC6083] e in combinazione con SCTP sopra UDP [RFC6951]) e stato scelto per le seguenti ragioni:

  • supporta la trasmissione di messaggi utente di dimensione arbitrariamente grande;
  • condivide la connessione DTLS con i canali media SRTP della PeerConnection; e
  • fornisce privacy per le informazioni di controllo SCTP.

Con riferimento allo stack di protocollo mostrato nella Figura 2:

  • l'uso di DTLS 1.0 sopra UDP e specificato in [RFC4347];
  • l'uso di DTLS 1.2 sopra UDP e specificato in [RFC6347];
  • l'uso di DTLS 1.3 sopra UDP e specificato in un documento futuro [TLS-DTLS13]; e
  • l'uso di SCTP sopra DTLS e specificato in [RFC8261].

Si noti che la demultiplexazione Session Traversal Utilities for NAT (STUN) [RFC5389] vs. SRTP vs. DTLS viene eseguita come descritto nella Sezione 5.1.2 di [RFC5764], e SCTP e l'unico payload di DTLS.

Poiche DTLS e tipicamente implementato nello spazio dell'applicazione utente, anche lo stack SCTP deve essere uno stack nello spazio dell'applicazione utente.

Il livello ICE/UDP puo gestire cambiamenti di indirizzo IP durante una sessione senza richiedere interazione con i livelli DTLS e SCTP. Tuttavia, SCTP SHOULD essere notificato quando si e verificato un cambiamento di indirizzo. In questo caso, SCTP SHOULD rieseguire il test della Path MTU e reimpostare lo stato di congestione allo stato iniziale. Nel caso di controllo di congestione basato su finestra come quello specificato in [RFC4960], cio significa impostare la congestion window e la soglia di slow-start ai valori iniziali.

I messaggi ICMP o ICMPv6 in ingresso non possono essere elaborati dal livello SCTP, poiche non c'e modo di identificare l'associazione corrispondente. Pertanto, SCTP MUST supportare l'esecuzione della scoperta della Path MTU senza fare affidamento su ICMP o ICMPv6, come specificato in [RFC4821], usando i messaggi di probing specificati in [RFC4820]. La Path MTU iniziale al livello IP SHOULD NOT superare 1200 byte per IPv4 e 1280 byte per IPv6.

In generale, l'interfaccia di livello inferiore di un'implementazione SCTP dovrebbe essere adattata per gestire le differenze tra IPv4 e IPv6 (senza connessione) o DTLS (orientato alla connessione).

Quando si usa lo stack di protocollo mostrato nella Figura 2, DTLS protegge l'intero pacchetto SCTP, quindi fornisce riservatezza, integrita e autenticazione della sorgente dell'intero pacchetto SCTP.

SCTP fornisce controllo di congestione su base per associazione. Questo significa che tutti gli stream SCTP all'interno di una singola associazione SCTP condividono la stessa congestion window. Il traffico non inviato sopra SCTP non e coperto dal controllo di congestione SCTP. Usare un controllo di congestione diverso da quello standard potrebbe migliorare l'impatto sugli stream media SRTP paralleli.

SCTP usa lo stesso concetto di numeri di porta di TCP e UDP. Pertanto, un'associazione SCTP usa due numeri di porta, uno per ciascun endpoint SCTP.

Ultimo aggiornamento il