4.1. Loss RLE Report Block (Blocco di Report RLE per Perdite)

4.1. Loss RLE Report Block (Blocco di Report RLE per Perdite)

Questo tipo di blocco consente la segnalazione dettagliata di singoli eventi di ricezione e perdita di pacchetti. Tali report possono essere utilizzati, ad esempio, per l'inferenza multicast delle caratteristiche di rete (MINC) [11]. Con MINC, è possibile scoprire la topologia dell'albero multicast utilizzato per distribuire i pacchetti RTP di una sorgente e i tassi di perdita lungo i collegamenti all'interno di tale albero, oppure potrebbero essere utilizzati per fornire dati grezzi a un'applicazione di gestione di rete.

Poiché una traccia booleana di pacchetti RTP persi e ricevuti è potenzialmente lunga, questo tipo di blocco consente di comprimere la traccia attraverso la codifica a lunghezza di corsa (run length encoding). Per ridurre ulteriormente le dimensioni del blocco, i report di eventi di perdita possono essere sistematicamente eliminati dalla traccia in un meccanismo chiamato diradamento (thinning) che è descritto di seguito e che è studiato in [13].

Un partecipante che genera un Loss RLE Report Block dovrebbe favorire l'accuratezza nel riportare gli eventi osservati rispetto all'interpretazione di tali eventi quando possibile. L'interpretazione dovrebbe essere lasciata a coloro che osservano i blocchi di report. Seguire questo approccio implica che la contabilità per i Loss RLE Report Block differirà dalla contabilità per la generazione dei pacchetti SR e RR descritta nella specifica RTP [9] nelle seguenti due aree: contabilità per mittente e contabilità per pacchetto.

Nella sua contabilità per mittente, un partecipante alla sessione RTP non dovrebbe rendere la ricezione di un numero minimo soglia di pacchetti RTP una condizione per riportare il mittente di tali pacchetti. Questa tecnica di contabilità differisce dalla tecnica descritta nella sezione 6.2.1 e nell'appendice A.1 della specifica RTP che consente a una soglia di determinare se un mittente è considerato valido.

Nella sua contabilità per pacchetto, un partecipante alla sessione RTP dovrebbe trattare tutti i numeri di sequenza come validi. Questa tecnica di contabilità differisce dalla tecnica descritta nell'appendice A.1 della specifica RTP che suggerisce di giudicare un numero di sequenza valido o non valido in base alla sua contiguità con i numeri di sequenza dei pacchetti precedentemente ricevuti.

La validità del mittente e la validità del numero di sequenza sono interpretazioni dei dati grezzi. Tali interpretazioni sono giustificate nell'interesse, ad esempio, di escludere il vecchio pacchetto vagante da una sessione non correlata dall'avere un effetto sul calcolo dell'intervallo di trasmissione RTCP. La presenza di pacchetti vaganti potrebbe, d'altra parte, essere di interesse per un'applicazione di monitoraggio di rete.

Un'interpretazione contabile che è ancora necessaria è che un partecipante decida se il numero di sequenza a 16 bit è stato sottoposto a rollover. In circostanze ordinarie questo non è un compito difficile. Ad esempio, se il pacchetto numero 65,535 (il numero di sequenza più alto possibile) è seguito poco dopo dal pacchetto numero 0, è ragionevole presumere che ci sia stato un rollover. Tuttavia, è possibile che il pacchetto sia uno precedente (da 65,535 pacchetti prima). È anche possibile che i numeri di sequenza siano stati sottoposti a rollover più volte, sia in avanti che all'indietro. L'interpretazione diventa più difficile quando ci sono grandi lacune tra i numeri di sequenza, anche tenendo conto del rollover, e quando ci sono lunghi intervalli tra i pacchetti ricevuti.

La tecnica di contabilità per pacchetto qui richiesta è che un partecipante tenga traccia del numero di sequenza del pacchetto ricevuto più recentemente da un mittente. Per il prossimo pacchetto che arriva da quel mittente, il numero di sequenza deve essere giudicato non cadere a più di 32,768 pacchetti avanti o indietro rispetto al più recente, a seconda della scelta che lo posiziona più vicino. Nel caso in cui entrambe le scelte siano ugualmente distanti (possibile solo quando la distanza è 32,768), la scelta deve essere quella che non richiede un rollover. L'appendice A.1 presenta un algoritmo che implementa questa tecnica.

Ogni blocco riporta su una singola sorgente di pacchetti dati RTP, identificata dal suo SSRC. Il ricevitore che fornisce il report è identificato nell'intestazione del pacchetto RTCP.

La scelta dei numeri di sequenza di pacchetti RTP di inizio e fine per la traccia è lasciata all'applicazione. Questi valori sono riportati nel blocco. L'ultimo numero di sequenza nella traccia può differire dal numero di sequenza riportato in qualsiasi report SR o RR di accompagnamento.

Si noti che a causa del wraparound del numero di sequenza, il numero di sequenza finale può essere inferiore al numero di sequenza iniziale. Un Loss RLE Report Block non deve essere utilizzato per riportare su un intervallo di 65,534 o maggiore nello spazio dei numeri di sequenza, poiché non c'è modo di identificare più wraparound.

La traccia descritta da un report RLE di perdita consiste in una sequenza di valori booleani, uno per ogni numero di sequenza della traccia. Un valore di uno rappresenta una ricezione di pacchetto, il che significa che uno o più pacchetti con quel numero di sequenza sono stati ricevuti dall'ultimo wraparound dei numeri di sequenza (o dall'inizio della sessione RTP se non è stato giudicato essersi verificato alcun wraparound). Un valore di zero rappresenta una perdita di pacchetto, il che significa che non c'è stata alcuna ricezione di pacchetto per quel numero di sequenza al momento del report. Se un pacchetto con un dato numero di sequenza viene ricevuto dopo un report di perdita per quel numero di sequenza, un successivo report RLE di perdita può riportare una ricezione di pacchetto per quel numero di sequenza.

La codifica stessa consiste in una serie di unità a 16 bit chiamate chunk che descrivono sequenze di ricezioni o perdite di pacchetti nella traccia. Ogni chunk specifica una lunghezza di corsa o un vettore di bit, oppure è un chunk nullo. Una lunghezza di corsa descrive da 1 a 16,383 eventi tutti uguali (tutti ricevuti o tutti persi). Un vettore di bit descrive 15 eventi che possono mescolare ricezioni e perdite. Un chunk nullo non descrive alcun evento ed è utilizzato per arrotondare il blocco a un limite di parola a 32 bit.

La mappatura da una sequenza di pacchetti persi e ricevuti a una sequenza di chunk non è necessariamente unica. Ad esempio, la seguente traccia copre 45 pacchetti, di cui il 22° e il 24° sono stati persi e gli altri ricevuti:

1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1

Un modo per codificare questo è:

bit vector 1111 1111 1111 111
bit vector 1111 1101 0111 111
bit vector 1111 1111 1111 111
null chunk

Un altro modo per codificare questo è:

run of 21 receipts
bit vector 0101 1111 1111 111
run of 9 receipts
null chunk

La scelta della codifica è lasciata all'applicazione. Come parte di questa libertà di scelta, un'applicazione può terminare una serie di chunk di lunghezza di corsa e vettore di bit con un blocco di vettore di bit che si estende oltre lo spazio dei numeri di sequenza descritto dal blocco di report. Ad esempio, se il 44° pacchetto nella stessa sequenza fosse perso:

1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1

Questo potrebbe essere codificato come:

run of 21 receipts
bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000
null chunk

In questo esempio, gli ultimi cinque bit del secondo vettore di bit descrivono una parte dello spazio dei numeri di sequenza oltre l'ultimo numero di sequenza nella traccia. Questi bit sono stati impostati a zero.

Tutti i bit in un blocco di vettore di bit che descrivono una parte dello spazio dei numeri di sequenza oltre l'ultimo numero di sequenza nella traccia devono essere impostati a zero e devono essere ignorati dal ricevitore.

Se il numero di blocchi di lunghezza di corsa più vettore di bit è dispari, un pacchetto nullo deve apparire alla fine del Loss RLE Report Block. Un blocco nullo non deve apparire in nessun altro contesto.

I Loss RLE Report Block dovrebbero essere inviati con cautela, perché anche con la compressione fornita dalla codifica a lunghezza di corsa, possono facilmente consumare una larghezza di banda sproporzionata rispetto ai normali pacchetti RTCP. Il tipo di blocco include un meccanismo chiamato diradamento (thinning) che consente a un'applicazione di limitare le dimensioni del report.

Un valore di diradamento T seleziona un sottoinsieme di pacchetti nello spazio dei numeri di sequenza: pacchetti il cui numero di sequenza è un multiplo di 2^T. I report di ricezione e perdita di pacchetti si applicano solo a questi pacchetti. T può variare da 0 a 15. Se T è zero, ogni pacchetto nello spazio dei numeri di sequenza viene riportato. Se T è 15, viene riportato un pacchetto ogni 32,768.

Supponiamo che la traccia appena descritta inizi al numero di sequenza 13,821. L'ultimo numero di sequenza nella traccia è 13,865. Se la traccia viene diradata con un valore di diradamento T=2, verranno riportati i seguenti numeri di sequenza: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. La traccia diradata è la seguente:

1    1    1    1    1    0    1    1    1    1    0

Questo può essere codificato come segue:

bit vector 1111 1011 1100 000
null chunk

Gli ultimi quattro bit nel vettore di bit, che rappresentano i numeri di sequenza 13,868, 13,872, 13,876 e 13,880, sono oltre l'intervallo della traccia e sono quindi impostati a zero e ignorati dal ricevitore. Grazie al diradamento, la perdita del 22° pacchetto non viene riportata, perché il suo numero di sequenza 13,842 non è un multiplo di 4. Anche le ricezioni di pacchetti per tutti i numeri di sequenza che non sono multipli di 4 non vengono riportate. Tuttavia, in questo esempio, il diradamento consente di accorciare il Loss RLE Report Block di una parola a 32 bit.

La scelta del valore di diradamento è lasciata all'applicazione.

Il Loss RLE Report Block ha il seguente formato:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     BT=1      | rsvd. |   T   |         block length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        SSRC of source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          begin_seq            |             end_seq           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          chunk 1              |             chunk 2           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                              ...                              :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          chunk n-1            |             chunk n           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

block type (BT): 8 bit

• Il Loss RLE Report Block è identificato dalla costante 1.

rsvd.: 4 bit

• Questo campo è riservato per definizioni future. In assenza di tale definizione, i bit in questo campo devono essere impostati a zero e devono essere ignorati dal ricevitore.

thinning (T): 4 bit

• La quantità di diradamento eseguita sullo spazio dei numeri di sequenza. Questo blocco riporta solo i pacchetti il cui numero di sequenza è 0 mod 2^T. Il valore 0 indica nessun diradamento e tutti i pacchetti vengono riportati. Il diradamento massimo è un pacchetto ogni 32,768 (equivalente a due pacchetti nello spazio di sequenza a 16 bit).

block length: 16 bit

• Definito nella sezione 3.

SSRC of source: 32 bit

• L'SSRC della sorgente di pacchetti dati RTP su cui questo blocco di report riporta.

begin_seq: 16 bit

• Il primo numero di sequenza su cui questo blocco riporta.

end_seq: 16 bit

• L'ultimo numero di sequenza su cui questo blocco riporta più uno.

chunk i: 16 bit

• Ci sono tre tipi di chunk: lunghezza di corsa, vettore di bit e nullo di terminazione, definiti nelle sezioni seguenti. Se un chunk è tutto zero, è un blocco nullo di terminazione. Altrimenti, il bit più a sinistra del chunk determina il suo tipo: 0 per lunghezza di corsa, 1 per vettore di bit.