7. Considerazioni su RTCP per flussi con velocità disparate

Una sessione RTP ha un unico insieme di parametri che configurano la larghezza di banda della sessione. Questi sono le frazioni RTCP di mittente e ricevitore (ad es., le righe SDP "b=RR:" e "b=RS:" [RFC3556]) e i parametri del profilo RTP/AVPF [RFC4585] (ad es., trr-int) se quel profilo (o la sua estensione sicura, RTP/SAVPF [RFC5124]) viene utilizzato. Di conseguenza, l'intervallo di reportistica RTCP di base, prima della randomizzazione, sarà lo stesso per ogni SSRC mittente in una sessione RTP. Analogamente, ogni SSRC ricevente in una sessione RTP avrà lo stesso intervallo di reportistica di base, sebbene questo possa differire dall'intervallo di reportistica scelto dagli SSRC mittenti. Questo intervallo di reportistica RTCP uniforme per tutti gli SSRC può comportare l'invio di report RTCP più spesso, o troppo di rado, di quanto sia considerato auspicabile per un flusso RTP.

Per esempio, si consideri uno scenario in cui un flusso audio che invia a decine di kilobit al secondo è multiplato in una sessione RTP con un flusso video multi-megabit ad alta qualità. Se la larghezza di banda della sessione è configurata in base alla velocità di invio del video, e viene usata la frazione di larghezza di banda RTCP predefinita del 5% della larghezza di banda della sessione, è probabile che la larghezza di banda RTCP superi la velocità di invio dell'audio. Se nella sessione viene poi usato l'intervallo RTCP minimo ridotto descritto nella Sezione 6.2 di [RFC3550], come appropriato per il video dove si desidera un feedback rapido sui frame I danneggiati, l'intervallo di reportistica uniforme per tutti i mittenti potrebbe significare che ci si aspetta che le sorgenti audio inviino pacchetti RTCP più spesso di quanto inviino pacchetti di dati audio. Questo disallineamento di larghezza di banda può essere ridotto mediante una taratura accurata dei parametri RTCP, specialmente trr_int quando si usa il profilo RTP/AVPF, ma non può essere evitato del tutto poiché è inerente al progetto delle regole di temporizzazione RTCP, e riguarda tutte le sessioni RTP che contengono flussi con larghezza di banda molto disallineata.

Velocità di media diverse o comportamenti RTCP desiderati diversi possono verificarsi anche con SSRC che trasportano lo stesso tipo di media. Un caso comune nella conferenza multipartecipante è quando un piccolo numero di flussi video è mostrato in alta risoluzione, mentre gli altri sono mostrati come miniature a bassa risoluzione, con la scelta di quale mostrare in alta risoluzione controllata dall'attività vocale. Qui le differenze riguardano sia la velocità effettiva dei media sia le scelte su quali messaggi di feedback possano essere necessari. Altri esempi di differenze che possono esistere sono dovuti all'uso previsto di una sorgente di media. Una sorgente di media che trasporta il video dell'oratore in una conferenza è diversa da una telecamera per documenti. I parametri di base che possono differire in questo caso sono la frequenza dei fotogrammi, il ritardo end-to-end accettabile e la fedeltà del rapporto segnale-rumore (SNR) dell'immagine. Queste differenze influenzano non solo le velocità di bit necessarie, ma anche i possibili comportamenti di trasmissione, i meccanismi di riparazione utilizzabili, quali messaggi di feedback richiedono il controllo e la riparazione, i requisiti di trasmissione su quei messaggi di feedback e il monitoraggio della consegna del flusso RTP. Possono esistere anche altri scenari simili.

L'invio di più tipi di media in una singola sessione RTP fa sì che quella sessione contenga più SSRC di quanti ne avrebbe se ciascun tipo di media fosse inviato in una sessione RTP separata. Per esempio, se due partecipanti inviano ciascuno un flusso RTP audio e uno video in una singola sessione RTP, quella sessione comprenderà quattro SSRC; ma se fossero state usate sessioni RTP separate per audio e video, ciascuna di quelle due sessioni RTP comprenderebbe solo due SSRC. Quindi, inviare più flussi RTP in una sessione RTP aumenta la quantità di reportistica incrociata tra gli SSRC, poiché ciascun SSRC invia report su tutti gli altri SSRC nella sessione. Ciò aumenta la dimensione dei report RTCP, facendoli inviare meno spesso di quanto accadrebbe se fossero usate sessioni RTP separate per una data larghezza di banda RTCP.

Infine, quando una sessione RTP contiene più tipi di media, è importante notare che i report di qualità di ricezione RTCP, i messaggi di feedback e i blocchi di report estesi utilizzati potrebbero non essere applicabili a tutti i tipi di media. Gli endpoint dovranno considerare il tipo di media di ciascun SSRC, e inviare o elaborare solo report e feedback che si applicano a quel particolare SSRC e al suo tipo di media. Le soluzioni di segnalazione potrebbero avere carenze quando si tratta di indicare che un particolare insieme di report RTCP o messaggi di feedback si applica solo a un particolare tipo di media all'interno di una sessione RTP.

Dal punto di vista di RTCP, quindi, si può vedere che ci sono vantaggi nell'usare sessioni RTP separate per ciascuna sorgente di media, piuttosto che inviare più sorgenti di media in una singola sessione RTP. Tuttavia, questi sono spesso compensati dalla necessità di ridurre l'uso delle porte e di facilitare la traversata di NAT/firewall, ottenuta combinando le sorgenti di media in un'unica sessione RTP. Le sezioni seguenti considerano più in dettaglio alcune delle problematiche relative all'uso di RTCP in sessioni con più sorgenti di media.

7.1. Timeout degli SSRC

Sono state identificate varie problematiche con il timeout dei valori SSRC quando si inviano più flussi RTP in una sessione RTP.

7.1.1. Problemi con il parametro T_rr_interval di RTP/AVPF

Il profilo RTP/AVPF include un metodo per evitare che i report RTCP regolari vengano inviati troppo spesso. Questo meccanismo è descritto nella Sezione 3.5.3 di [RFC4585]; è controllato dal parametro T_rr_interval. Funziona come segue. Quando viene inviato un report RTCP regolare, viene generato un nuovo valore casuale, T_rr_current_interval, estratto uniformemente nell'intervallo da 0.5 a 1.5 volte T_rr_interval. Se un pacchetto RTCP regolare deve essere inviato prima di T_rr_current_interval secondi dopo il pacchetto RTCP regolare precedente, e non ci sono messaggi di feedback da inviare, allora quel pacchetto RTCP regolare viene soppresso e viene pianificato il successivo pacchetto RTCP regolare. Il T_rr_current_interval viene ricalcolato ogni volta che viene inviato un pacchetto RTCP regolare. Il beneficio della soppressione è che evita di sprecare larghezza di banda quando non c'è nulla che richieda trasmissioni RTCP frequenti, ma consente comunque di utilizzare la larghezza di banda configurata quando il feedback è necessario.

Sfortunatamente, questo meccanismo di soppressione distorce la distribuzione degli intervalli di invio RTCP rispetto agli intervalli di reportistica RTCP regolari. Le regole standard di temporizzazione RTCP, inclusi la riconsiderazione e il fattore di compensazione, fanno sì che gli intervalli tra l'invio di pacchetti RTCP abbiano una distribuzione sbilanciata verso l'estremo superiore dell'intervallo [0.5/1.21828, 1.5/1.21828]*Td, dove Td è l'intervallo di reportistica RTCP deterministico calcolato. Con Td = 5 s, questa distribuzione copre l'intervallo [2.052 s, 6.156 s]. In confronto, le regole di soppressione RTP/AVPF agiscono in un intervallo che è da 0.5 a 1.5 volte T_rr_interval; per T_rr_interval = 5s, questo è [2.5 s, 7.5 s].

L'effetto di ciò è che il tempo tra pacchetti RTCP consecutivi quando si usa la soppressione di T_rr_interval può diventare grande. L'intervallo di tempo massimo tra l'invio di un pacchetto RTCP regolare e il successivo, quando si usa T_rr_interval, si verifica quando T_rr_current_interval assume il suo valore massimo e un pacchetto RTCP regolare viene soppresso alla fine del periodo di soppressione, poi il successivo pacchetto RTCP regolare viene pianificato dopo il suo più grande intervallo di reportistica possibile. Prendendo il caso peggiore dei due intervalli si ottiene un tempo massimo tra due report RTCP di 1.5T_rr_interval + 1.5/1.21828Td.

Questo comportamento può essere sorprendente quando Td e T_rr_interval hanno lo stesso valore. Ossia, quando T_rr_interval è configurato per corrispondere all'intervallo di reportistica RTCP regolare. In questo caso, ci si potrebbe aspettare che i pacchetti RTCP regolari siano inviati secondo la loro pianificazione abituale, ma che i pacchetti di feedback possano essere inviati in anticipo. Tuttavia, il problema sopra menzionato fa sì che i pacchetti RTCP siano effettivamente inviati nell'intervallo [0.5Td, 2.731Td] con una distribuzione altamente non uniforme, invece che nell'intervallo [0.41Td, 1.23Td]. Questo è forse inatteso, ma non è un problema di per sé. Tuttavia, quando si combina con la perdita di pacchetti, solleva il problema del timeout prematuro.

7.1.2. Evitare timeout prematuri

In RTP/AVP [RFC3550] il comportamento di timeout è semplice; è 5 volte Td, dove Td è calcolato con un valore Tmin di 5 secondi. In altre parole, se la larghezza di banda RTCP configurata consente un intervallo di reportistica RTCP medio inferiore a 5 secondi, il timeout è di 25 secondi senza attività dall'SSRC (RTP o RTCP); altrimenti, il timeout è di 5 intervalli di reportistica medi.

RTP/AVPF [RFC4585] introduce comportamenti di timeout diversi a seconda del valore di T_rr_interval. Quando T_rr_interval è 0, usa lo stesso calcolo del timeout di RTP/AVP. Tuttavia, quando T_rr_interval è diverso da zero, sostituisce Tmin nel calcolo del timeout, molto probabilmente per accelerare il rilevamento degli SSRC scaduti. Tuttavia, l'uso di un T_rr_interval diverso da zero ha due conseguenze per il comportamento di RTP.

In primo luogo, a causa della soppressione, il numero di pacchetti RTP e RTCP inviati da un SSRC che non è un mittente RTP attivo può diventare molto basso, a causa del problema discusso nella Sezione 7.1.1. Poiché l'intervallo dei pacchetti RTCP può essere lungo fino a 2.73Td, durante un periodo di tempo di 5Td un endpoint potrebbe in effetti trasmettere un solo pacchetto RTCP. Gli intervalli lunghi comportano meno pacchetti RTCP, al punto che la perdita di un singolo pacchetto RTCP può talvolta comportare il timeout di un SSRC.

In secondo luogo, le modifiche di RTP/AVPF alle regole di timeout riducono la robustezza agli errori di configurazione. È comune usare RTP/AVPF configurato in modo che i pacchetti RTCP possano essere inviati frequentemente per consentire un feedback rapido; tuttavia, ciò rende i timeout molto sensibili a T_rr_interval. Per esempio, se due SSRC sono configurati, uno con T_rr_interval = 0.1 s e l'altro con T_rr_interval = 0.6 s, allora questa piccola differenza farà sì che l'SSRC con il T_rr_interval più breve mandi in timeout l'altro se questo smette di inviare pacchetti RTP, poiché l'altro intervallo di reportistica RTCP è più di cinque volte il proprio. Quando si usa RTP/AVP, o RTP/AVPF con T_rr_interval = 0, questo non è un problema, poiché il periodo di timeout sarà di 25 s, e le differenze tra la larghezza di banda RTCP configurata possono causare timeout prematuri solo quando gli intervalli di reportistica sono maggiori di 5 s e differiscono di un fattore cinque. Per limitare la possibilità di tale configurazione errata problematica, definiamo un aggiornamento delle regole di timeout di RTP/AVPF nella Sezione 7.1.4.

7.1.3. Interoperabilità tra RTP/AVP e RTP/AVPF

Se endpoint che implementano i profili RTP/AVP e RTP/AVPF (o le loro varianti sicure) sono combinati all'interno di una singola sessione RTP, e gli endpoint RTP/AVPF usano un T_rr_interval diverso da zero che è significativamente inferiore a 5 secondi, esiste il rischio che gli endpoint RTP/AVPF mandino prematuramente in timeout gli SSRC degli endpoint RTP/AVP, a causa delle loro diverse regole di timeout RTCP. Viceversa, se gli endpoint RTP/AVPF usano un T_rr_interval significativamente maggiore di 5 secondi, esiste il rischio che gli endpoint RTP/AVP mandino in timeout gli SSRC degli endpoint RTP/AVPF.

Miscelare endpoint che usano due profili RTP diversi all'interno di una singola sessione RTP NON è RACCOMANDATO (NOT RECOMMENDED). Tuttavia, se si usano profili RTP misti, e gli endpoint RTP/AVPF non sono aggiornati per seguire la Sezione 7.1.4 di questo memo, allora la sessione RTP/AVPF DOVREBBE (SHOULD) essere configurata per usare T_rr_interval = 4 secondi per evitare timeout prematuri.

La scelta di T_rr_interval = 4 secondi per l'interoperabilità può sembrare strana. Intuitivamente, questo valore dovrebbe essere 5 secondi, per far usare sia a RTP/AVP sia a RTP/AVPF lo stesso periodo di timeout. Tuttavia, il comportamento delineato nella Sezione 7.1.1 mostra che gli intervalli di reportistica RTP/AVPF effettivi possono essere più lunghi del previsto. Impostare T_rr_interval = 4 secondi fornisce intervalli RTCP effettivi vicini a quelli attesi da RTP/AVP, garantendo l'interoperabilità.

7.1.4. Regole aggiornate per il timeout degli SSRC

Per garantire l'interoperabilità ed evitare timeout prematuri, tutti gli SSRC in una sessione RTP DEVONO (MUST) usare lo stesso comportamento di timeout. Tuttavia, le specifiche precedenti sono incoerenti al riguardo. Per evitare problemi di interoperabilità, questo memo aggiorna le regole di timeout come segue:

• Per i profili RTP/AVP, RTP/SAVP, RTP/AVPF e RTP/SAVPF, l'intervallo di timeout DEVE (SHALL) essere calcolato usando un moltiplicatore di cinque volte l'intervallo di reportistica RTCP deterministico. Ossia, l'intervallo di timeout DEVE (SHALL) essere 5*Td.
• Per i profili RTP/AVP, RTP/SAVP, RTP/AVPF e RTP/SAVPF, il calcolo di Td, al solo scopo di calcolare il timeout del partecipante, DEVE (SHALL) essere effettuato usando un valore Tmin di 5 secondi e non l'intervallo minimo ridotto, anche se l'intervallo minimo ridotto è usato per calcolare gli intervalli di trasmissione dei pacchetti RTCP.

Ciò modifica il comportamento per i profili RTP/AVPF o RTP/SAVPF quando T_rr_interval != 0. In particolare, il primo paragrafo della Sezione 3.5.4 di [RFC4585] è aggiornato per usare Tmin invece di T_rr_interval nel calcolo del timeout per le entità RTP/AVPF.

7.2. Ottimizzazione delle trasmissioni RTCP

Questa sottosezione discute quali ottimizzazioni possono essere fatte per ridurre gli svantaggi degli intervalli condivisi dei pacchetti RTCP. Prima vengono elencate le possibilità esistenti per il profilo RTP/AVP [RFC3551], seguite dagli strumenti aggiuntivi forniti da RTP/AVPF [RFC4585].

7.2.1. RTP/AVP e RTP/SAVP

Quando si usano i profili RTP/AVP o RTP/SAVP, le opzioni per ottimizzare gli intervalli di reportistica RTCP sono limitate alla larghezza di banda RTCP di mittente e ricevitore, e al fatto che l'intervallo RTCP minimo sia scalato in base alla larghezza di banda. Poiché l'algoritmo di pianificazione include sia la randomizzazione sia la riconsiderazione, non si può semplicemente calcolare l'intervallo di trasmissione medio atteso usando la formula per Td data nella Sezione 6.3.1 di [RFC3550]. Tuttavia, considerando gli input di quell'espressione, e le regole di randomizzazione e riconsiderazione, possiamo iniziare a comprendere il comportamento dell'intervallo di trasmissione RTCP.

Iniziamo con alcune osservazioni di base:

1. A meno che non venga usato l'intervallo RTCP minimo scalato, Td prima della randomizzazione e della riconsiderazione non può mai essere inferiore a Tmin. Il valore predefinito di Tmin è 5 secondi.
2. Se viene usato l'intervallo RTCP minimo scalato, Td può diventare basso fino a 360 diviso per la larghezza di banda della sessione RTP in kilobit al secondo. In SDP, la larghezza di banda della sessione RTP è segnalata usando una riga "b=AS". Una larghezza di banda della sessione RTP di 72 kbps comporta che Tmin sia di 5 secondi. Una larghezza di banda della sessione RTP di 360 kbps dà ovviamente un Tmin di 1 secondo, e per ottenere un Tmin pari a una volta per fotogramma per un flusso video a 25 fotogrammi al secondo è necessaria una larghezza di banda della sessione RTP di 9 Mbps. L'uso del profilo RTP/AVPF o RTP/SAVPF consente report RTCP più frequenti per la stessa larghezza di banda, come discusso di seguito.
3. Il valore di Td scala con il numero di SSRC e con la dimensione media dei report RTCP per mantenere costante la larghezza di banda RTCP complessiva.
4. L'intervallo di trasmissione effettivo per un valore Td è nell'intervallo [0.5Td/1.21828, 1.5Td/1.21828], e la distribuzione è sbilanciata, a causa della riconsiderazione, con la maggior parte della massa di probabilità al di sopra di Td. Ciò significa, per esempio, che per Td = 5 s, l'intervallo di trasmissione effettivo sarà distribuito nell'intervallo [2.052 s, 6.156 s], e tenderà verso la metà superiore dell'intervallo. Si noti che il parametro Tmin limita il valore di Td prima che vengano applicate randomizzazione e riconsiderazione, quindi l'intervallo di trasmissione effettivo coprirà un range che si estende al di sotto di Tmin.

Dato quanto sopra, possiamo calcolare il numero di SSRC, n, che una sessione RTP con il 5% della larghezza di banda della sessione assegnato a RTCP può supportare mantenendo Td uguale a Tmin. Questo ci dirà su quanti flussi RTP possiamo inviare report, mantenendo l'overhead RTCP entro limiti accettabili. Facciamo due assunzioni che semplificano il calcolo: che tutti gli SSRC siano mittenti, e che tutti inviino pacchetti RTCP composti comprendenti un pacchetto SR con n-1 blocchi di report, seguiti da un pacchetto SDES contenente un valore CNAME di 16 ottetti [RFC7022] (tali pacchetti RTCP varieranno in dimensione tra 54 e 798 ottetti a seconda di n, fino al massimo di 31 blocchi di report che possono essere inclusi in un pacchetto SR). Se inseriamo questa dimensione di pacchetto, e una frazione di larghezza di banda RTCP del 5%, nel calcolo dell'intervallo RTCP della Sezione 6.3.1 di [RFC3550], e calcoliamo il valore di n necessario per dare Td = Tmin per l'intervallo minimo scalato, troviamo che possono essere supportati n=9 SSRC (indipendentemente dall'intervallo, per come l'intervallo di reportistica scala con la larghezza di banda della sessione). Vediamo che per supportare più SSRC senza cambiare l'intervallo minimo scalato, dobbiamo aumentare la frazione di larghezza di banda RTCP dal 5%; cambiare la larghezza di banda della sessione a un valore più alto ridurrebbe il Tmin. Tuttavia, se si usa l'allocazione predefinita del 5% della larghezza di banda RTCP, un aumento comporterà il supporto di più SSRC dato un obiettivo Td fisso.

In base a quanto sopra, quando si usa il profilo RTP/AVP o il profilo RTP/SAVP, la limitazione chiave per una reportistica RTCP rapida in piccole sessioni unicast sarà il valore Tmin. La larghezza di banda della sessione RTP configurata in RTCP deve essere sufficientemente elevata per raggiungere gli obiettivi di reportistica che l'applicazione ha seguendo le regole per l'intervallo RTCP minimo scalato.

7.2.2. RTP/AVPF e RTP/SAVPF

Quando si usa RTP/AVPF o RTP/SAVPF, abbiamo un potente strumento aggiuntivo per ottimizzare le trasmissioni RTCP: il parametro T_rr_interval. L'uso di questo parametro consente brevi intervalli di reportistica RTCP; in alternativa offre la capacità di inviare feedback RTCP frequenti senza inviare frequenti report RTCP regolari.

L'uso del profilo RTP/AVPF o RTP/SAVPF con T_rr_interval impostato a un valore maggiore di zero ma minore di Tmin consente un feedback RTCP più frequente rispetto ai profili RTP/AVP o RTP/SAVP, per una data larghezza di banda RTCP. Ciò accade perché Tmin viene impostato a zero dopo la trasmissione del report RTCP iniziale, facendo sì che l'intervallo di reportistica per i pacchetti successivi sia determinato dall'usuale calcolo basato sulla larghezza di banda RTCP, con Tmin=0, e dal T_rr_interval. Ciò ha l'effetto che non siamo più limitati dall'intervallo minimo (che sia il minimo predefinito di 5 secondi o l'intervallo minimo ridotto). Piuttosto, la larghezza di banda RTCP e il T_rr_interval sono i fattori determinanti, consentendo un feedback più rapido. Le applicazioni che tengono a un feedback RTCP regolare rapido dovrebbero considerare di usare il profilo RTP/AVPF o RTP/SAVPF, anche se non usano le funzionalità di feedback di quel profilo.

L'uso del profilo RTP/AVPF o RTP/SAVPF consente di inviare frequentemente pacchetti di feedback RTCP, senza richiedere anche l'invio frequente di report RTCP regolari, poiché T_rr_interval limita la velocità con cui i pacchetti RTCP regolari possono essere inviati, pur consentendo l'invio dei pacchetti di feedback RTCP. Le applicazioni che possono usare pacchetti di feedback per alcuni flussi RTP, ad es., flussi video, ma non vogliono una reportistica regolare frequente per altri flussi RTP, possono configurare il T_rr_interval a un valore tale che la reportistica regolare sia per audio sia per video sia a un livello considerato accettabile per l'audio. Potrebbero poi usare pacchetti di feedback, che includeranno pacchetti RTCP SR/RR a meno che non si usino pacchetti di feedback RTCP a dimensione ridotta [RFC5506], per la reportistica video. Ciò consente di dedicare la larghezza di banda RTCP disponibile al feedback che fornisce la massima utilità per l'applicazione.

Usare T_rr_interval richiede comunque di determinare valori adeguati per il valore della larghezza di banda RTCP. Anzi, potrebbe rendere questa scelta ancora più importante, poiché è più probabile che influenzi il comportamento e le prestazioni di RTCP rispetto a quando si usa il profilo RTP/AVP o RTP/SAVP, dato che ci sono meno limitazioni che influenzano la trasmissione RTCP.

Quando T_rr_interval è diverso da zero, ci sono configurazioni che devono essere evitate. Se la larghezza di banda RTCP scelta è tale che il valore Td è minore, ma vicino, a T_rr_interval, allora l'intervallo effettivo di trasmissione dei pacchetti RTCP regolari può diventare molto grande, come discusso nella Sezione 7.1.1. Pertanto, per una configurazione in cui si intende avere Td minore di T_rr_interval, si RACCOMANDA (RECOMMENDED) che Td sia puntato a valori inferiori a 1/4 di T_rr_interval, il che porta l'intervallo a diventare [0.5T_rr_interval, 1.81T_rr_interval].

Con i profili RTP/AVPF o RTP/SAVPF, usare T_rr_interval = 0 ha utilità e comporta un comportamento in cui la trasmissione RTCP è limitata solo dalla larghezza di banda, ossia nessuna limitazione di Tmin. Ciò consente una reportistica RTCP regolare più frequente di quella ottenibile usando il profilo RTP/AVP. Molte configurazioni di RTCP non consumeranno tutta la larghezza di banda che è stata loro configurata, ma questa configurazione consumerà ciò che le è stato dato. Si noti che si otterrà lo stesso comportamento fintanto che T_rr_interval è minore di 1/3 di Td, poiché ciò impedisce a T_rr_interval di influenzare la trasmissione.

Non esiste alcun metodo per usare intervalli di reportistica RTCP regolari diversi a seconda del tipo di media o del singolo flusso RTP, se non usando una sessione RTP separata per ciascun tipo o flusso.