1.1. Applicability (Applicabilità)
1.1. Applicability (Applicabilità)
I pacchetti XR sono utili in più applicazioni e, per questo motivo, non sono definiti come estensioni specifiche del profilo per i rapporti mittente o ricevitore RTCP [9, Sezione 6.4.3]. Tuttavia, non sono utili in tutti i contesti. In particolare, il blocco rapporto metriche VoIP (Sezione 4.7) è specifico per applicazioni vocali, sebbene possa essere impiegato in un'ampia varietà di tali applicazioni.
Il blocco rapporto metriche VoIP può essere applicato a qualsiasi applicazione vocale uno-a-uno o uno-a-molti per la quale è specificato l'uso di RTP e RTCP. L'uso di metriche conversazionali (Sezione 4.7.5), incluso il fattore R (come descritto dal modello E definito in [3]) e il punteggio medio di opinione per la qualità conversazionale (MOS-CQ), in applicazioni diverse dalle semplici chiamate tra due parti non è definito; pertanto, queste metriche dovrebbero essere identificate come non disponibili nelle applicazioni di conferenza multicast.
I tipi di blocchi di rapporto pacchetto per pacchetto, RLE perdita (Sezione 4.1), RLE duplicato (Sezione 4.2) e tempi ricezione pacchetti (Sezione 4.3), sono stati definiti tenendo presente applicazioni di tomografia di rete, come l'inferenza multicast delle caratteristiche di rete (MINC) [11]. MINC richiede tracce dettagliate di ricezione pacchetti dai ricevitori di sessione multicast al fine di dedurre la struttura grossolana dell'albero di distribuzione multicast e i parametri, come i tassi di perdita e i ritardi, che si applicano ai percorsi tra i punti di ramificazione di quell'albero.
Qualsiasi applicazione multimediale multicast in tempo reale può utilizzare i tipi di blocchi di rapporto pacchetto per pacchetto. Tale applicazione potrebbe impiegare un sottosistema di inferenza MINC che le fornirebbe informazioni sulla topologia dell'albero multicast. Un potenziale uso di tale sottosistema sarebbe l'identificazione di regioni ad alta perdita nell'albero multicast e l'identificazione di partecipanti alla sessione multicast ben posizionati per fornire ritrasmissioni di pacchetti persi.
I rapporti dettagliati pacchetto per pacchetto non devono necessariamente consumare banda proporzionalmente eccessiva rispetto ad altri pacchetti RTCP. Un'applicazione può limitare la dimensione di questi blocchi. Per questi blocchi di rapporto è fornito un meccanismo chiamato "diradamento" che può essere utilizzato per garantire che aderiscano a un limite di dimensione limitando il numero di pacchetti riportati all'interno di qualsiasi intervallo di numeri di sequenza. La logica e l'uso di questo meccanismo sono descritti in [13]. Inoltre, le applicazioni potrebbero non richiedere blocchi di rapporto da tutti i ricevitori per rispondere a domande importanti come dove nell'albero multicast ci sono percorsi che superano una soglia di tasso di perdita definita. Decisioni intelligenti riguardo a quali ricevitori inviano questi blocchi di rapporto possono ulteriormente limitare la porzione di banda RTCP che consumano.
I blocchi di rapporto pacchetto per pacchetto possono anche essere utilizzati da applicazioni dedicate di monitoraggio di rete. Per tale applicazione, potrebbe essere appropriato consentire che più del 5% della banda dati RTP sia utilizzata per pacchetti RTCP, consentendo così blocchi di rapporto proporzionalmente più grandi e dettagliati.
Nulla nei tipi di blocchi pacchetto per pacchetto limita il loro uso alle applicazioni multicast. In particolare, potrebbero essere utilizzati per tomografia di rete simile a MINC, ma utilizzando pacchetti unicast striati invece. Inoltre, se risultasse utile, potrebbero essere utilizzati per applicazioni limitate a due partecipanti.
Un uso per cui i rapporti pacchetto per pacchetto non sono immediatamente adatti è per gli acknowledgment di pacchetti dati come parte di un meccanismo di ritrasmissione pacchetti. Il motivo è che la tecnica di contabilizzazione pacchetti suggerita per questi blocchi differisce dalla contabilizzazione pacchetti normalmente impiegata da RTP. Per favorire le applicazioni di misurazione, si fa uno sforzo per interpretare il meno possibile al ricevitore dati e lasciare l'interpretazione il più possibile ai partecipanti che ricevono i blocchi di rapporto. Quindi, ad esempio, un pacchetto con un ID SSRC anomalo o un numero di sequenza anomalo potrebbe essere escluso dalla contabilizzazione RTP normale, ma verrebbe riportato per scopi di monitoraggio di rete.
Il blocco rapporto riepilogo statistiche (Sezione 4.6) è stato anche definito pensando al monitoraggio di rete. Questo tipo di blocco può essere utilizzato ugualmente bene per riportare la ricezione di pacchetti unicast e multicast.
I tipi di blocchi relativi al tempo di riferimento sono stati concepiti per il controllo della congestione multicast TCP-friendly basato sul ricevitore [18]. Permettendo ai ricevitori dati di calcolare i loro tempi di andata e ritorno ai mittenti, aiutano i ricevitori a stimare la banda downstream che dovrebbero richiedere. Si noti che se ogni ricevitore deve inviare blocchi rapporto tempo riferimento ricevitore (Sezione 4.4), un mittente potrebbe potenzialmente inviare un numero di blocchi rapporto DLRR (Sezione 4.5) uguale al numero di ricevitori i cui pacchetti RTCP sono arrivati al mittente entro il suo intervallo di rapporto. Man mano che il numero di partecipanti in una sessione multicast aumenta, un'applicazione dovrebbe usare discrezione riguardo a quali partecipanti inviano questi blocchi e con quale frequenza.
I pacchetti XR integrano i pacchetti RTCP esistenti e possono essere impilati con altri pacchetti RTCP per formare pacchetti RTCP composti [9, Sezione 6]. L'introduzione di pacchetti XR in una sessione non modifica in alcun modo le regole che governano il calcolo dell'intervallo di rapporto RTCP [9, Sezione 6.2]. Poiché i pacchetti XR sono pacchetti RTCP, contano come tali per i calcoli di banda. Di conseguenza, l'aggiunta di informazioni di rapporto estese può tendere ad aumentare la dimensione media dei pacchetti RTCP e quindi l'intervallo di rapporto medio. Questo aumento può essere limitato limitando la dimensione dei pacchetti XR.
La segnalazione SDP definita per i pacchetti XR in questo documento (Sezione 5) è stata realizzata tenendo presente tre scenari d'uso: un'applicazione di streaming controllata dal protocollo di streaming in tempo reale (RTSP), un'applicazione multimediale multicast uno-a-molti come una lezione di corso con feedback migliorato e una sessione conversazionale controllata dal Session Initiation Protocol (SIP) che coinvolge due parti. Le applicazioni che impiegano SDP sono libere di utilizzare segnalazione SDP aggiuntiva per casi non coperti qui. Inoltre, le applicazioni sono libere di utilizzare meccanismi di segnalazione diversi da SDP.