Passa al contenuto principale

RFC 8838 - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol

  • Stato: Proposed Standard
  • Pubblicato: January 2021
  • Stream: IETF
  • Errata: Nessun errata

Abstract (Sommario)​

Questo documento descrive "Trickle ICE", un'estensione del protocollo ICE (Interactive Connectivity Establishment) che consente agli agenti ICE di iniziare i controlli di connettività mentre stanno ancora raccogliendo candidati, scambiando i candidati in modo incrementale nel tempo invece che tutti in una volta. Questo metodo può accelerare notevolmente il processo di stabilire una sessione di comunicazione.

Table of Contents (Indice)​

Appendices (Appendici)​

1. Introduction (Introduzione)​

L'Interactive Connectivity Establishment (ICE) [RFC8445] definisce un meccanismo che consente ai protocolli multimediali come il Real-time Transport Protocol (RTP) [RFC3550] di stabilire e mantenere sessioni IP tra peer in presenza di Network Address Translators (NAT) e altri elementi di rete intermedi. In ICE, i candidati (indirizzi di trasporto potenzialmente utilizzabili per la comunicazione) sono raccolti dagli agenti ICE e poi scambiati in modo completo prima che qualsiasi tentativo di stabilire una sessione di comunicazione possa avvenire effettivamente.

Quando è richiesta una rete IPv6, la latenza complessiva di questa procedura può essere significativa. È anche comune che uno o entrambi gli agenti dispongano di diverse interfacce di rete (ad esempio, wireless e cablate), più di un indirizzo su una singola interfaccia (ad esempio, IPv4 e IPv6), e siano configurati per utilizzare l'attraversamento STUN (Session Traversal Utilities for NAT) [RFC5389] o TURN (Traversal Using Relays around NAT) [RFC5766]. In simili scenari, la raccolta può richiedere un tempo sostanziale, rendendo l'intera chiamata lunga da stabilire dal punto di vista dell'utente e dall'applicazione.

Il protocollo "Trickle ICE", definito in questo documento, riduce la latenza di stabilimento delle sessioni estendendo ICE. Consente agli agenti ICE di trasmettere informazioni sui candidati quando divengono disponibili (quindi il termine "trickle", che significa "gocciolare" o "fluire gradualmente"). In questo modo, un agente ICE può iniziare immediatamente i controlli di connettività con i candidati ricevuti da un peer senza dover attendere che il peer raccolga tutti i candidati.

Trickle ICE specifica anche alcune modalità e le regole che governano il loro utilizzo. "Full Trickle" (Trickle completo) è il modello di funzionamento più comune, in cui gli agenti ICE possono scegliere di scambiare candidati incrementalmente o tutto in una volta. "Half Trickle" (Mezzo trickle) è una modalità in cui uno degli agenti scambia candidati in modo completo, mentre l'altro agente si impegna nello scambio incrementale dei candidati; questo modo è particolarmente utile in scenari dove non è chiaro se entrambe le parti supportano questo protocollo.

Questa specifica definisce solo il comportamento degli agenti ICE e lascia intatti i meccanismi di raccolta dei candidati, nonché i dettagli di come i candidati vengono trasmessi tra gli agenti ICE. Come per ICE in generale, questa specifica si concentra sul formato e la sémantique, non sui metodi di trasporto; tale uso specifico è definito separatamente (ad esempio, [RFC8840] definisce l'uso con SIP [RFC3261] e [XEP-0176] definisce l'uso con XMPP [RFC6120]).

2. Terminology (Terminologia)​

Le parole chiave "deve (MUST)", "non deve (MUST NOT)", "richiesto (REQUIRED)", "deve (SHALL)", "non deve (SHALL NOT)", "dovrebbe (SHOULD)", "non dovrebbe (SHOULD NOT)", "raccomandato (RECOMMENDED)", "non raccomandato (NOT RECOMMENDED)", "può (MAY)" e "opzionale (OPTIONAL)" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, compaiono in maiuscolo, come mostrato qui.

Questa specifica utilizza tutta la terminologia definita per l'Interactive Connectivity Establishment in [RFC8445]. Inoltre, definisce i seguenti termini:

Checklist vuota (Empty Checklist): Una checklist che inizialmente non contiene coppie di candidati perché verranno aggiunte incrementalmente man mano che vengono trickle. (Questo scenario non si verifica con un agente ICE regolare, poiché tutte le coppie di candidati sono conosciute quando l'agente crea l'insieme di checklist.)

Full Trickle (Trickle completo): La modalità di funzionamento tipica per gli agenti Trickle ICE, in cui la descrizione ICE iniziale può includere qualsiasi numero di candidati (anche zero candidati) e non ha bisogno di includere una generazione completa di candidati come nel half trickle.

Generation (Generazione): Tutti i candidati trasmessi all'interno di una sessione ICE (correlati con una particolare combinazione di Username Fragment e Password).

Half Trickle (Mezzo trickle): Una modalità di funzionamento di Trickle ICE in cui l'initiator raccoglie una generazione completa di candidati strettamente prima di creare e trasmettere la descrizione ICE iniziale. Una volta trasmesse, queste informazioni sui candidati possono essere elaborate da agenti ICE regolari, che non richiedono il supporto per Trickle ICE. Questo consente anche ai risponditori compatibili con Trickle ICE di raccogliere sempre candidati ed eseguire controlli di connettività in modo non bloccante, fornendo così circa "la metà" dei benefici di Trickle ICE. Il meccanismo half-trickle è principalmente inteso per l'uso quando il supporto Trickle ICE del risponditore non può essere confermato prima di trasmettere la descrizione ICE iniziale.

ICE Description (Descrizione ICE): Tutti gli attributi relativi alla sessione ICE (diversi dai candidati) richiesti per configurare un agente ICE. Questi includono, ma non sono limitati a, Username Fragment, Password e altri attributi.

Trickled Candidates (Candidati trickled): Candidati che un agente Trickle ICE trasmette dopo aver trasmesso o risposto alla descrizione ICE iniziale, ma all'interno della stessa sessione ICE. I candidati trickled possono essere trasmessi in parallelo con la raccolta dei candidati e i controlli di connettività.

Trickling: L'atto di trasmettere incrementalmente i candidati trickled.

3. Determining Support for Trickle ICE (Determinazione del supporto per Trickle ICE)​

Per supportare completamente Trickle ICE, i protocolli di utilizzo dovrebbero (SHOULD) incorporare uno dei seguenti meccanismi in modo che le implementazioni possano determinare se Trickle ICE è supportato:

  1. Fornire un metodo di scoperta delle capacità in modo che gli agenti possano verificare il supporto di Trickle ICE prima di avviare una sessione (la Service Discovery di XMPP [XEP-0030] è uno di questi meccanismi).

  2. Rendere obbligatorio il supporto di Trickle ICE in modo che gli agenti utente possano presumere il supporto.

Se un protocollo di utilizzo non fornisce un metodo per determinare in anticipo se Trickle ICE è supportato, gli agenti possono utilizzare la procedura half-trickle descritta nella Sezione 16.

Prima di trasmettere la descrizione ICE iniziale, gli agenti che implementano protocolli di utilizzo che supportano la scoperta delle capacità possono tentare di verificare se la parte remota supporta Trickle ICE o meno. Se un agente determina che la parte remota non supporta Trickle ICE, deve (MUST) tornare all'utilizzo di ICE regolare o abbandonare l'intera sessione.

Anche se un protocollo di utilizzo non include un metodo di scoperta delle capacità, un agente utente può fornire un'indicazione nella descrizione ICE che supporta Trickle ICE comunicando un'opzione ICE di 'trickle'. Questo token deve (MUST) essere fornito sia a livello di sessione, sia, se a livello di flusso di dati, per ogni flusso di dati (un agente non deve (MUST NOT) specificare il supporto di Trickle ICE per alcuni flussi di dati ma non per altri). Nota: La codifica dell'opzione ICE 'trickle' e il/i messaggio/i utilizzato/i per trasmetterla al peer sono specifici del protocollo; ad esempio, la codifica per SDP [RFC4566] è definita in [RFC8840].

La semantica di scoperta dedicata e il half trickle sono necessari solo prima dell'avvio di una sessione ICE. Dopo che una sessione ICE è stabilita e il supporto di Trickle ICE è confermato per entrambe le parti, entrambi gli agenti possono utilizzare il full trickle per gli scambi successivi (vedere anche la Sezione 15).

4. Generating the Initial ICE Description (Generazione della descrizione ICE iniziale)​

Un agente ICE può iniziare a raccogliere candidati non appena ha un'indicazione che la comunicazione è imminente (ad esempio, un segnale dell'interfaccia utente o una richiesta esplicita di avviare una sessione di comunicazione). A differenza di ICE regolare, nelle implementazioni Trickle ICE non è necessario raccogliere candidati in modo bloccante. Pertanto, a meno che non venga utilizzato l'half trickle, l'esperienza utente è migliorata se l'agente initiator genera e trasmette la sua descrizione ICE iniziale il prima possibile (consentendo così alla parte remota di iniziare a raccogliere e trickle i candidati).

Un initiator può (MAY) includere qualsiasi combinazione di candidati quando trasmette la descrizione ICE iniziale. Ciò include la possibilità di trasmettere tutti i candidati che l'initiator prevede di utilizzare (come nell'half trickle), di trasmettere solo un indirizzo IP pubblicamente accessibile (ad esempio, un candidato su un relay di dati che è noto per non essere dietro un firewall), o di non trasmettere alcun candidato (nel qual caso l'initiator può ottenere l'elenco iniziale dei candidati dal risponditore più presto, e il risponditore può iniziare la raccolta dei candidati più rapidamente).

Per i candidati inclusi nella descrizione ICE iniziale, i metodi di calcolo delle priorità e delle fondazioni (Foundations), di determinazione della ridondanza dei candidati e simili funzionano esattamente come in ICE regolare [RFC8445].

5. Handling the Initial ICE Description and Generating the Initial ICE Response (Gestione della descrizione ICE iniziale e generazione della risposta ICE iniziale)​

Quando un risponditore riceve la descrizione ICE iniziale, controlla prima se la descrizione ICE o l'initiator indica il supporto di Trickle ICE come spiegato nella Sezione 3. Se non lo fa, il risponditore deve (MUST) elaborare la descrizione ICE iniziale secondo le procedure ICE regolari [RFC8445] (o, se non viene rilevato alcun supporto ICE, secondo le regole di elaborazione pertinenti per il protocollo di utilizzo, come le regole di elaborazione Offerta/Risposta [RFC3264]). Tuttavia, se il supporto di Trickle ICE è confermato, un risponditore assumerà automaticamente anche il supporto di ICE regolare.

Se la descrizione ICE iniziale indica il supporto di Trickle ICE, il risponditore determinerà il suo ruolo e inizierà a raccogliere e dare priorità ai candidati; in tal modo, risponderà anche trasmettendo una risposta ICE iniziale, in modo che l'initiator e il risponditore possano formare checklist e iniziare i controlli di connettività.

Un risponditore può rispondere alla descrizione ICE iniziale in qualsiasi momento durante la raccolta dei candidati. La risposta ICE iniziale può (MAY) contenere qualsiasi insieme di candidati, inclusi tutti i candidati o nessun candidato. (Il vantaggio di non includere candidati è trasmettere la risposta ICE iniziale il più rapidamente possibile, in modo che entrambe le parti possano considerare la sessione ICE come in negoziazione attiva il prima possibile.)

Come notato nella Sezione 3, nei protocolli di utilizzo che utilizzano SDP, la risposta ICE iniziale può indicare il supporto di Trickle ICE includendo un token 'trickle' nell'attributo ice-options.

8. Performing Connectivity Checks (Esecuzione dei controlli di connettività)​

Come specificato in [RFC8445], ogni volta che il timer Ta si attiva, solo le checklist nello stato In esecuzione (Running) verranno selezionate durante la pianificazione dei controlli di connettività per le coppie di candidati. Pertanto, un agente Trickle ICE deve (MUST) mantenere ogni checklist nello stato In esecuzione finché prevede che le coppie di candidati vengano aggiunte incrementalmente alla lista. Dopo di ciò, lo stato della checklist viene impostato secondo le procedure in [RFC8445].

Ogni volta che il timer Ta si attiva e viene selezionata una checklist vuota, non viene eseguita alcuna azione per la lista. Senza attendere che il timer Ta scada di nuovo, l'agente seleziona la checklist successiva nello stato In esecuzione, conformemente alla Sezione 6.1.4.2 di [RFC8445].

La Sezione 7.2.5.4 di [RFC8445] richiede che gli agenti aggiornino le checklist e gli stati dei timer al completamento di una transazione di controllo di connettività. Durante tale aggiornamento, gli agenti ICE regolari imposterebbero lo stato di una checklist su Fallito (Failed) se entrambe le seguenti condizioni sono soddisfatte:

  • tutte le coppie nella checklist sono nello stato Fallito (Failed) o nello stato Riuscito (Succeeded); e

  • non c'è una coppia nella lista valida per ogni componente del flusso di dati.

Con Trickle ICE, la situazione sopra si verificherebbe spesso quando la raccolta dei candidati e il trickling sono ancora in corso, anche se è del tutto possibile che le future verifiche abbiano successo. Per questo motivo, gli agenti Trickle ICE aggiungono le seguenti condizioni all'elenco sopra:

  • tutta la raccolta dei candidati è completata, e l'agente non prevede di scoprire nuovi candidati locali; e

  • l'agente remoto ha trasmesso un'indicazione di fine dei candidati per questa checklist come descritto nella Sezione 13.

9. Gathering and Conveying Newly Gathered Local Candidates (Raccolta e trasmissione dei candidati locali appena raccolti)​

Dopo che gli agenti Trickle ICE hanno trasmesso le descrizioni ICE iniziali e le risposte ICE iniziali, molto probabilmente continueranno a raccogliere nuovi candidati locali man mano che i meccanismi di raccolta dei candidati STUN, TURN e altri candidati non-host iniziano a produrre risultati. Ogni volta che un agente scopre un tale nuovo candidato, calcolerà la sua priorità, tipo, fondazione (Foundation) e ID di componente secondo le procedure ICE regolari.

Il nuovo candidato viene quindi verificato per la ridondanza rispetto all'elenco esistente di candidati locali. Se il suo indirizzo di trasporto e la sua base corrispondono a quelli di un candidato esistente, sarà considerato ridondante e sarà ignorato. Questo accadrebbe spesso per i candidati riflessivi del server che corrispondono agli indirizzi host da cui sono stati ottenuti (ad esempio, quando questi ultimi sono indirizzi IPv4 pubblici). A differenza di ICE regolare, gli agenti Trickle ICE considereranno il nuovo candidato come ridondante indipendentemente dalla sua priorità.

Successivamente, l'agente "trickle" il/i candidato/i appena scoperto/i verso l'agente remoto. La consegna effettiva dei nuovi candidati è gestita da un protocollo di utilizzo come SIP o XMPP. Trickle ICE non impone alcuna restrizione su come questo viene fatto (ad esempio, alcuni protocolli di utilizzo possono scegliere di non trickle gli aggiornamenti per i candidati riflessivi del server e affidarsi invece alla scoperta di candidati riflessivi del peer).

Quando i candidati vengono trickled, il protocollo di utilizzo deve (MUST) consegnare ogni candidato (e qualsiasi indicazione di fine dei candidati come descritto nella Sezione 13) all'implementazione Trickle ICE ricevente esattamente una volta e nello stesso ordine in cui è stato trasmesso. Se il protocollo di utilizzo fornisce ritrasmissioni di candidati, devono essere nascoste dall'implementazione ICE.

Inoltre, il trickling dei candidati deve essere correlato a una sessione ICE specifica, in modo che se c'è un riavvio ICE, tutti gli aggiornamenti ritardati per una sessione precedente possano essere riconosciuti come tali e ignorati dalla parte ricevente. Ad esempio, i protocolli di utilizzo che segnalano i candidati tramite SDP possono includere un valore di Username Fragment nella corrispondente riga a=candidate, come:

a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY

Oppure, come altro esempio, le implementazioni WebRTC possono includere un Username Fragment negli oggetti JavaScript che rappresentano i candidati.

Nota: Il protocollo di utilizzo deve fornire un meccanismo per entrambe le parti per indicare e concordare sulla sessione ICE in vigore (identificata dalla combinazione Username Fragment e Password), in modo che abbiano una vista coerente dei candidati da accoppiare. Questo è particolarmente importante nel caso di riavvii ICE (vedere Sezione 15).

Nota: Un protocollo di utilizzo potrebbe preferire di non trickle i candidati riflessivi del server verso entità che sono note per essere pubblicamente accessibili e dove l'invio di una richiesta di binding STUN diretto è probabile che raggiunga la destinazione più velocemente dell'aggiornamento trickle che viaggia attraverso il percorso di segnalazione.

10. Pairing Newly Gathered Local Candidates (Accoppiamento dei candidati locali appena raccolti)​

Quando un agente Trickle ICE raccoglie candidati locali, deve formare coppie di candidati; questo funziona come descritto nella specifica ICE [RFC8445], con le seguenti condizioni:

  1. Un agente Trickle ICE non deve (MUST NOT) accoppiare un candidato locale finché non è stato trickled verso la parte remota.

  2. Una volta che l'agente ha trasmesso il candidato locale alla parte remota, l'agente controlla se eventuali candidati remoti sono attualmente noti per lo stesso flusso e componente. Se non lo sono, l'agente aggiunge semplicemente il nuovo candidato all'elenco dei candidati locali (senza accoppiarlo).

  3. Altrimenti, se l'agente ha già appreso uno o più candidati remoti per questo flusso e componente, tenta di accoppiare il nuovo candidato locale come descritto nella specifica ICE [RFC8445].

  4. Se una coppia appena formata ha un candidato locale il cui tipo è riflessivo del server (server-reflexive), l'agente deve (MUST) sostituire il candidato locale con la sua base prima di completare i test di ridondanza pertinenti.

  5. L'agente pota le coppie ridondanti seguendo le regole della Sezione 6.1.2.4 di [RFC8445] ma controlla le coppie esistenti solo se hanno uno stato In attesa (Waiting) o Congelato (Frozen); questo evita la rimozione di coppie per le quali i controlli di connettività sono in corso (uno stato In corso (In-Progress)) o per le quali i controlli di connettività hanno già dato un risultato definitivo (uno stato Riuscito (Succeeded) o Fallito (Failed)).

  6. Se, dopo aver completato i test di ridondanza pertinenti, la checklist in cui la coppia deve essere aggiunta contiene già il numero massimo di coppie di candidati (100 per impostazione predefinita secondo [RFC8445]), l'agente dovrebbe (SHOULD) rifiutare tutte le coppie nello stato Fallito per fare spazio alla nuova coppia. Se non ci sono tali coppie, l'agente dovrebbe (SHOULD) rifiutare una coppia con una priorità inferiore alla nuova coppia per fare spazio alla nuova coppia, fino a quando il numero di coppie è uguale al numero massimo di coppie. Questo trattamento è coerente con la Sezione 6.1.2.5 di [RFC8445].

11. Receiving Trickled Candidates (Ricezione dei candidati trickled)​

In qualsiasi momento durante una sessione ICE, un agente Trickle ICE può ricevere nuovi candidati dall'agente remoto, da cui tenterà di formare una coppia di candidati; questo funziona come descritto nella specifica ICE [RFC8445], con le seguenti condizioni:

  1. L'agente controlla se eventuali candidati locali sono attualmente noti per lo stesso flusso e componente. Se non lo sono, l'agente aggiunge semplicemente il nuovo candidato all'elenco dei candidati remoti (senza accoppiarlo).

  2. Altrimenti, se l'agente ha già raccolto uno o più candidati locali per questo flusso e componente, tenta di accoppiare il nuovo candidato remoto come descritto nella specifica ICE [RFC8445].

  3. Se una coppia appena formata ha un candidato locale il cui tipo è riflessivo del server (server-reflexive), l'agente deve (MUST) sostituire il candidato locale con la sua base prima di completare il controllo di ridondanza al passo successivo.

  4. L'agente pota le coppie ridondanti come descritto di seguito ma controlla le coppie esistenti solo se hanno uno stato In attesa (Waiting) o Congelato (Frozen); questo evita la rimozione di coppie per le quali i controlli di connettività sono in corso (uno stato In corso (In-Progress)) o per le quali i controlli di connettività hanno già dato un risultato definitivo (uno stato Riuscito (Succeeded) o Fallito (Failed)).

    A. Se l'agente trova una ridondanza tra due coppie e una di queste coppie contiene un candidato remoto appena ricevuto il cui tipo è riflessivo del peer (peer-reflexive), l'agente dovrebbe (SHOULD) rifiutare la coppia contenente tale candidato, impostare la priorità della coppia esistente alla priorità della coppia rifiutata e riordinare la checklist. (Questa politica aiuta a eliminare i problemi con i candidati riflessivi del peer remoti per i quali una richiesta di binding STUN viene ricevuta prima che la segnalazione del candidato venga trickled all'agente ricevente, come una vista diversa delle priorità di coppia tra l'agente locale e l'agente remoto, perché lo stesso candidato potrebbe essere percepito come riflessivo del peer da un agente e come riflessivo del server dall'altro agente.)

    B. L'agente applica quindi le regole definite nella Sezione 6.1.2.4 di [RFC8445].

  5. Se, dopo aver completato i test di ridondanza pertinenti, la checklist in cui la coppia deve essere aggiunta contiene già il numero massimo di coppie di candidati (100 per impostazione predefinita secondo [RFC8445]), l'agente dovrebbe (SHOULD) rifiutare tutte le coppie nello stato Fallito per fare spazio alla nuova coppia. Se non ci sono tali coppie, l'agente dovrebbe (SHOULD) rifiutare una coppia con una priorità inferiore alla nuova coppia per fare spazio alla nuova coppia, fino a quando il numero di coppie è uguale al numero massimo di coppie. Questo trattamento è coerente con la Sezione 6.1.2.5 di [RFC8445].

12. Inserting Trickled Candidate Pairs into a Checklist (Inserimento di coppie di candidati trickled in una checklist)​

Dopo che l'agente locale ha trickled un candidato e formato una coppia di candidati da tale candidato locale (Sezione 9), o dopo che l'agente remoto ha ricevuto un candidato trickled e formato una coppia di candidati da tale candidato remoto (Sezione 11), l'agente Trickle ICE aggiunge la nuova coppia di candidati alla checklist come definito in questa sezione.

Per facilitare la comprensione delle procedure definite in questa sezione, considerare la seguente rappresentazione tabulare di tutte le checklist in un agente (notare che inizialmente per una delle fondazioni, cioè f5, non ci sono coppie di candidati):

+=================+====+====+====+====+====+
|                 | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
|| s1 (Audio.RTP)  | F  | F  | F  |    |    |
+-----------------+----+----+----+----+----+
|| s2 (Audio.RTCP) | F  | F  | F  | F  |    |
+-----------------+----+----+----+----+----+
|| s3 (Video.RTP)  | F  |    |    |    |    |
+-----------------+----+----+----+----+----+
|| s4 (Video.RTCP) | F  |    |    |    |    |
+-----------------+----+----+----+----+----+

Tabella 1: Esempio di stato checklist

Trickle ICE conserva tutte queste regole come si applicano all'insieme di checklist "statico". Ciò significa che se un agente Trickle ICE inizia i controlli di connettività mentre tutte le coppie di candidati sono già presenti, il modo in cui gli stati delle coppie di candidati cambiano è indistinguibile da un agente ICE regolare.

Naturalmente, la principale differenza con Trickle ICE è che l'insieme di checklist può essere aggiornato dinamicamente, poiché i candidati possono arrivare dopo l'inizio dei controlli di connettività. Quando questo accade, l'agente imposta lo stato della coppia di candidati appena formata come descritto di seguito.

Regola 1: Impostare lo stato su In attesa (Waiting) se la coppia di candidati appena formata ha l'ID di componente più basso di tutte le coppie di candidati per quella fondazione, o se gli ID di componente sono uguali, la priorità più alta (cioè se è la coppia di candidati più alta nella colonna).

Regola 2: Impostare lo stato su In attesa (Waiting) se c'è almeno una coppia di candidati nello stato Riuscito per quella fondazione.

Regola 3: Impostare lo stato su Congelato (Frozen) se nessuna delle regole precedenti si applica.

Notare che anche se una coppia di candidati è posta nello stato In attesa, le regole di [RFC8445] si applicano ancora, in modo che i controlli di connettività vengano eseguiti solo da checklist nello stato In esecuzione (Running). Pertanto, è possibile che una coppia di candidati cambi stato più volte tra In attesa e Congelato fino a quando un controllo di connettività non viene effettivamente eseguito per quella coppia.

13. Generating an End-of-Candidates Indication (Generazione di un'indicazione di fine candidati)​

Una volta che tutta la raccolta dei candidati è completata o scade per una sessione ICE associata a un flusso di dati specifico, l'agente genererà un'indicazione "fine dei candidati" (end-of-candidates) per quella sessione e la trasmetterà all'agente remoto tramite il canale di segnalazione. Sebbene la forma esatta dell'indicazione dipenda dal protocollo di utilizzo, l'indicazione deve (MUST) specificare la generazione (combinazione di Username Fragment e Password), in modo che un agente possa correlare l'indicazione di fine dei candidati con una sessione ICE particolare. L'indicazione può essere trasmessa nei seguenti modi:

  • Come parte di una richiesta di avvio (che sarebbe tipicamente il caso con la descrizione ICE iniziale per half trickle)
  • Con l'ultimo candidato che un agente può inviare per un flusso
  • Come una notifica autonoma (ad esempio, dopo la scadenza delle richieste di binding STUN o delle richieste di allocazione TURN a un server e l'agente non sta più raccogliendo attivamente candidati)

La trasmissione di un'indicazione di fine dei candidati in modo tempestivo è importante per evitare ambiguità e accelerare la conclusione del trattamento ICE. In particolare:

  • Un agente Trickle ICE controllato dovrebbe (SHOULD) trasmettere un'indicazione di fine dei candidati dopo aver completato la raccolta per un flusso di dati, a meno che il trattamento ICE non si concluda prima che l'agente abbia avuto la possibilità di completare la raccolta.
  • Un agente controllante può (MAY) concludere il trattamento ICE prima di trasmettere indicazioni di fine dei candidati per tutti i flussi. Tuttavia, è raccomandato (RECOMMENDED) che un agente controllante trasmetta indicazioni di fine dei candidati nella misura possibile per coerenza e per tenere informati i middlebox e gli agenti controllati sullo stato del trattamento ICE.

Durante la trasmissione di un'indicazione di fine dei candidati durante il trickling (piuttosto che come parte della descrizione ICE iniziale o di una risposta ad essa), spetta al protocollo di utilizzo definire metodi per associare l'indicazione a uno o più flussi di dati specifici.

Un agente può (MAY) anche scegliere di generare un'indicazione di fine dei candidati prima che la raccolta dei candidati sia effettivamente completata, se l'agente determina che la raccolta si è protratta per più di un periodo di tempo accettabile. Tuttavia, un agente non deve (MUST NOT) trasmettere altri candidati dopo aver trasmesso un'indicazione di fine dei candidati.

Durante l'esecuzione di half trickle, un agente dovrebbe (SHOULD) trasmettere un'indicazione di fine dei candidati con la sua descrizione ICE iniziale, a meno che non preveda potenzialmente di trickle candidati aggiuntivi (ad esempio, nel caso in cui la parte remota si riveli supportare Trickle ICE).

Dopo che un agente ha trasmesso l'indicazione di fine dei candidati, aggiornerà lo stato della checklist corrispondente come spiegato nella Sezione 8. Oltre questo punto, un agente non deve (MUST NOT) trickle nuovi candidati all'interno di quella sessione ICE. Pertanto, l'aggiunta di nuovi candidati alla negoziazione è possibile solo tramite un riavvio ICE (vedere Sezione 15).

Questa specifica non sostituisce la semantica ICE regolare per concludere il trattamento ICE. Pertanto, anche se le indicazioni di fine dei candidati sono trasmesse, un agente dovrà comunque procedere con la nomina di coppie. Inoltre, se le coppie sono state nominate per componenti e flussi di dati, il trattamento ICE può (MAY) ancora concludere anche se le indicazioni di fine dei candidati non sono state ricevute per tutti i flussi. In tutti i casi, un agente non deve (MUST NOT) trickle nuovi candidati all'interno di una sessione ICE dopo la nomina di una coppia di candidati come descritto nella Sezione 8.1.1 di [RFC8445].

14. Receiving an End-of-Candidates Indication (Ricezione di un'indicazione di fine candidati)​

La ricezione di un'indicazione di fine dei candidati consente a un agente di aggiornare gli stati delle checklist e, nel caso in cui le coppie valide non esistano per ogni componente in ogni flusso di dati, di determinare che il trattamento ICE è fallito. Consente anche a un agente di accelerare la conclusione del trattamento ICE quando una coppia di candidati è stata validata ma utilizza un trasporto di preferenza inferiore come TURN. In tali situazioni, un'implementazione può (MAY) scegliere di attendere e vedere se vengono ricevuti candidati di priorità più alta; in questo caso, l'indicazione di fine dei candidati fornisce una notifica che tali candidati non stanno arrivando.

Quando un agente riceve un'indicazione di fine dei candidati per un flusso di dati specifico, aggiornerà lo stato della checklist pertinente secondo la Sezione 8 (il che potrebbe portare ad alcune checklist contrassegnate come Fallite). Se la checklist è ancora nello stato In esecuzione (Running) dopo l'aggiornamento, l'agente noterà che un'indicazione di fine dei candidati è stata ricevuta e ne terrà conto nei futuri aggiornamenti della checklist.

Dopo che un agente ha ricevuto un'indicazione di fine dei candidati, deve (MUST) ignorare tutti i candidati appena ricevuti per quel flusso di dati o sessione di dati.

15. Subsequent Exchanges and ICE Restarts (Scambi successivi e riavvii ICE)​

Prima di trasmettere un'indicazione di fine dei candidati, entrambi gli agenti possono (MAY) trasmettere informazioni sui candidati successive in qualsiasi momento consentito dal protocollo utilizzatore. Quando questo accade, gli agenti utilizzeranno la semantica di [RFC8445] (ad esempio, il controllo della combinazione di Username Fragment e Password) per determinare se le nuove informazioni sui candidati richiedono o meno un riavvio ICE.

Se si verifica un riavvio ICE, gli agenti possono presumere che Trickle ICE sia ancora supportato se il supporto è stato determinato in precedenza; pertanto, possono impegnarsi in un comportamento Trickle ICE come farebbero in uno scambio iniziale di descrizioni ICE dove il supporto è stato determinato da un metodo di scoperta delle capacità.

16. Half Trickle (Half Trickle)​

Nel half trickle, l'initiator trasmette la descrizione ICE iniziale con una generazione di candidati utilizzabile ma non necessariamente completa. Questo garantisce che la descrizione ICE possa essere elaborata da un risponditore ICE regolare ed è principalmente destinato all'uso nei casi in cui il supporto di Trickle ICE non può essere confermato prima di trasmettere la descrizione ICE iniziale. La descrizione ICE iniziale indica il supporto di Trickle ICE, in modo che il risponditore possa rispondere con qualcosa di meno di una generazione completa di candidati, quindi trickle il resto. La descrizione ICE iniziale per half trickle può contenere un'indicazione di fine dei candidati, sebbene questo non sia obbligatorio perché se il supporto di trickle è confermato, l'initiator può scegliere di trickle candidati aggiuntivi prima di trasmettere un'indicazione di fine dei candidati.

Il meccanismo di half trickle può essere utilizzato nei casi in cui non c'è modo per un agente di verificare in anticipo se una parte remota supporta Trickle ICE. Poiché la descrizione ICE iniziale contiene una generazione completa di candidati, può quindi essere gestita da un agente ICE regolare, consentendo comunque a un agente Trickle ICE di utilizzare l'ottimizzazione definita in questa specifica. Questo evita il fallimento della negoziazione nel primo caso mentre fornisce circa la metà dei benefici di Trickle ICE nel secondo.

L'uso di half trickle è necessario solo durante uno scambio iniziale di descrizioni ICE. Dopo che entrambe le parti hanno ricevuto una descrizione ICE dal loro peer, ciascuno può determinare in modo affidabile il supporto di Trickle ICE e utilizzarlo per tutti gli scambi successivi (vedere Sezione 15).

In alcuni casi, l'uso di half trickle potrebbe portare più della metà del miglioramento in termini di esperienza utente. Questo può accadere quando un agente inizia a raccogliere candidati su indizi dell'interfaccia utente che indicano che l'utente sta per avviare un'interazione, come attività su una tastiera o il telefono che viene sollevato. Questo significherebbe che parte o tutta la raccolta dei candidati potrebbe essere completata prima che l'agente debba effettivamente trasmettere le informazioni sui candidati. Poiché il risponditore potrà trickle candidati, entrambi gli agenti potranno iniziare i controlli di connettività e terminare il trattamento ICE prima rispetto a ICE regolare e potenzialmente anche presto come con il trickle completo.

Tuttavia, tale anticipazione non è sempre possibile. Ad esempio, un agente utente multifunzione o una pagina web WebRTC dove la comunicazione è una funzionalità non centrale (ad esempio, chiamare una linea di supporto in caso di problema con le funzionalità principali) non avrebbe necessariamente un modo per distinguere tra le intenzioni di chiamata e altre attività utente. In tali casi, l'uso del trickle completo è il più probabile a dare un'esperienza utente ideale. Anche così, l'uso di half trickle sarebbe un miglioramento rispetto a ICE regolare perché darebbe un'esperienza migliore per i risponditori.

18. Requirements for Using Protocols (Requisiti per i protocolli utilizzatori)​

Al fine di consentire pienamente l'uso di Trickle ICE, questa specifica definisce i seguenti requisiti per i protocolli di utilizzo.

  • Un protocollo di utilizzo dovrebbe (SHOULD) fornire un mezzo per le parti di pubblicizzare e scoprire il supporto di Trickle ICE prima che una sessione ICE inizi (vedere Sezione 3).

  • Un protocollo di utilizzo deve (MUST) fornire metodi per trasmettere in modo incrementale (cioè, "trickle") candidati aggiuntivi dopo aver trasmesso la descrizione ICE iniziale (vedere Sezione 9).

  • Un protocollo di utilizzo deve (MUST) consegnare ogni candidato trickled o indicazione di fine dei candidati esattamente una volta e nello stesso ordine in cui è stato trasmesso (vedere Sezione 9).

  • Un protocollo di utilizzo deve (MUST) fornire un meccanismo per entrambe le parti per indicare e concordare sulla sessione ICE in vigore (vedere Sezione 9).

  • Un protocollo di utilizzo deve (MUST) fornire un modo per le parti di comunicare l'indicazione di fine dei candidati, che deve (MUST) specificare la sessione ICE particolare a cui l'indicazione si applica (vedere Sezione 13).

19. IANA Considerations (Considerazioni IANA)​

IANA ha registrato la seguente opzione ICE nel sottoregistro "ICE Options" del "registro Interactive Connectivity Establishment (ICE)", conformemente alle procedure definite in [RFC6336].

Opzione ICE: trickle

Contatto: IESG <[email protected]>

Controllore delle modifiche: IESG

Descrizione: Un'opzione ICE di 'trickle' indica il supporto per la comunicazione incrementale dei candidati ICE.

Riferimento: RFC 8838

20. Security Considerations (Considerazioni sulla sicurezza)​

Questa specifica eredita la maggior parte della sua semantica da [RFC8445], e di conseguenza, tutte le considerazioni sulla sicurezza descritte lì si applicano a Trickle ICE.

Se le implicazioni sulla privacy legate alla rivelazione di indirizzi host su un dispositivo terminale sono una preoccupazione (vedere, ad esempio, la discussione in [RFC8828] e nella Sezione 19 di [RFC8445]), gli agenti possono generare descrizioni ICE che non contengono candidati, quindi trickle solo candidati che non rivelano indirizzi host (ad esempio, candidati relay).

Appendix A. Interaction with Regular ICE (Interazione con ICE regolare)​

Il protocollo ICE è stato progettato per essere sufficientemente flessibile da funzionare e adattarsi a quanti più ambienti di rete possibile. Nonostante questa flessibilità, ICE come specificato in [RFC8445] non supporta Trickle ICE da solo. Questa sezione descrive come il trickling dei candidati interagisce con ICE.

[RFC8445] descrive le condizioni richieste per aggiornare le checklist e gli stati dei timer mentre un agente ICE è nello stato In esecuzione (Running). Queste condizioni vengono verificate al completamento della transazione, e una di esse stabilisce che:

se non c'è una coppia valida nella lista valida per ogni componente del flusso di dati associato alla checklist, lo stato della checklist viene impostato su Fallito (Failed).

Questo potrebbe essere un problema e causare il fallimento prematuro del trattamento ICE in un certo numero di scenari. Considerare il seguente caso:

Scenario 1: Collisione di blocchi di indirizzi privati​

  1. Alice e Bob sono entrambi situati in reti diverse con Network Address Translation (NAT). Alice e Bob stessi hanno indirizzi diversi, ma entrambe le reti utilizzano lo stesso blocco internet privato (ad esempio, il "blocco da 20 bit" 172.16/12 specificato in [RFC1918]).
  2. Alice trasmette a Bob il candidato 172.16.0.1, che corrisponde anche a un host esistente sulla rete di Bob.
  3. Bob crea una coppia di candidati dal suo candidato host e 172.16.0.1, posiziona questa coppia in una checklist e avvia i controlli.
  4. Questi controlli raggiungono l'host a 172.16.0.1 sulla rete di Bob, che risponde con un errore ICMP "porta irraggiungibile"; secondo [RFC8445], Bob segna la transazione come Fallita.

A questo punto, la checklist contiene solo una coppia Fallita, e la lista valida è vuota. Questo porta al fallimento del flusso di dati e potenzialmente all'intero trattamento ICE, anche se gli agenti Trickle ICE possono successivamente trasmettere candidati che potrebbero avere successo.

Scenario 2: Non corrispondenza della famiglia di indirizzi​

Una condizione di gara simile si verificherebbe se la descrizione ICE iniziale di Alice contiene solo candidati che possono essere determinati come irraggiungibili da qualsiasi candidato che Bob ha raccolto (ad esempio, questo sarebbe il caso se i candidati di Bob contenessero solo indirizzi IPv4 e il primo candidato che riceve da Alice è un indirizzo IPv6).

Scenario 3: Interazione Non-Trickle ICE​

Un altro potenziale problema potrebbe sorgere quando un'implementazione Non-Trickle ICE avvia un'interazione con un'implementazione Trickle ICE. Considerare il seguente caso:

  1. Il client di Alice ha un'implementazione Non-Trickle ICE.
  2. Il client di Bob supporta Trickle ICE.
  3. Alice e Bob sono dietro NAT con filtraggio dipendente dall'indirizzo [RFC4787].
  4. Bob ha due server STUN, ma uno di essi è attualmente irraggiungibile.

Dopo che l'agente di Bob ha ricevuto la descrizione ICE iniziale di Alice, inizierebbe immediatamente i controlli di connettività. Inizierebbe anche a raccogliere candidati, il che richiederebbe molto tempo a causa del server STUN irraggiungibile. Nel momento in cui la risposta di Bob è pronta e trasmessa ad Alice, i controlli di connettività di Bob potrebbero essere falliti: fino a quando Alice non ottiene la risposta di Bob, non potrà iniziare i controlli di connettività e forare buchi nel suo NAT. Il NAT filtrerebbe quindi i controlli di Bob come provenienti da un endpoint sconosciuto.