4.1. Loss RLE Report Block (Bloc de rapport RLE de perte)
4.1. Loss RLE Report Block (Bloc de rapport RLE de perte)
Ce type de bloc permet de rapporter en détail les événements de réception et de perte de paquets individuels. De tels rapports peuvent être utilisés, par exemple, pour l'inférence multicast des caractéristiques du réseau (MINC) [11]. Avec MINC, on peut découvrir la topologie de l'arbre multicast utilisé pour distribuer les paquets RTP d'une source, ainsi que les taux de perte le long des liens dans cet arbre, ou ils pourraient être utilisés pour fournir des données brutes à une application de gestion de réseau.
Étant donné qu'une trace booléenne des paquets RTP perdus et reçus est potentiellement longue, ce type de bloc permet de compresser la trace par codage par plages. Pour réduire davantage la taille du bloc, les rapports d'événements de perte peuvent être systématiquement supprimés de la trace dans un mécanisme appelé amincissement (thinning) qui est décrit ci-dessous et qui est étudié dans [13].
Un participant qui génère un bloc de rapport RLE de perte devrait favoriser la précision dans le rapport des événements observés plutôt que l'interprétation de ces événements dans la mesure du possible. L'interprétation devrait être laissée à ceux qui observent les blocs de rapport. Suivre cette approche implique que la comptabilité pour les blocs de rapport RLE de perte différera de la comptabilité pour la génération des paquets SR et RR décrite dans la spécification RTP [9] dans les deux domaines suivants: comptabilité par expéditeur et comptabilité par paquet.
Dans sa comptabilité par expéditeur, un participant de session RTP ne devrait pas faire de la réception d'un nombre minimum seuil de paquets RTP une condition pour rapporter l'expéditeur de ces paquets. Cette technique de comptabilité diffère de la technique décrite dans la section 6.2.1 et l'annexe A.1 de la spécification RTP qui permet à un seuil de déterminer si un expéditeur est considéré comme valide.
Dans sa comptabilité par paquet, un participant de session RTP devrait traiter tous les numéros de séquence comme valides. Cette technique de comptabilité diffère de la technique décrite dans l'annexe A.1 de la spécification RTP qui suggère de juger un numéro de séquence valide ou invalide sur la base de sa contiguïté avec les numéros de séquence des paquets précédemment reçus.
La validité de l'expéditeur et la validité du numéro de séquence sont des interprétations des données brutes. De telles interprétations sont justifiées dans l'intérêt, par exemple, d'exclure le paquet ancien errant d'une session non liée d'avoir un effet sur le calcul de l'intervalle de transmission RTCP. La présence de paquets errants pourrait, d'autre part, intéresser une application de surveillance de réseau.
Une interprétation comptable qui est encore nécessaire est qu'un participant décide si le numéro de séquence de 16 bits a basculé. Dans des circonstances ordinaires, ce n'est pas une tâche difficile. Par exemple, si le paquet numéro 65,535 (le numéro de séquence le plus élevé possible) est suivi peu après par le paquet numéro 0, il est raisonnable de supposer qu'il y a eu un basculement. Cependant, il est possible que le paquet soit un paquet antérieur (de 65,535 paquets plus tôt). Il est également possible que les numéros de séquence aient basculé plusieurs fois, soit en avant soit en arrière. L'interprétation devient plus difficile lorsqu'il y a de grands écarts entre les numéros de séquence, même en tenant compte du basculement, et lorsqu'il y a de longs intervalles entre les paquets reçus.
La technique de comptabilité par paquet mandatée ici est qu'un participant garde une trace du numéro de séquence du paquet le plus récemment reçu d'un expéditeur. Pour le prochain paquet qui arrive de cet expéditeur, le numéro de séquence doit être jugé ne pas tomber à plus de 32,768 paquets en avant ou en arrière du plus récent, selon le choix qui le place le plus près. Dans le cas où les deux choix sont également distants (seulement possible lorsque la distance est de 32,768), le choix doit être celui qui ne nécessite pas de basculement. L'annexe A.1 présente un algorithme qui implémente cette technique.
Chaque bloc rapporte une seule source de paquets de données RTP, identifiée par son SSRC. Le récepteur qui fournit le rapport est identifié dans l'en-tête du paquet RTCP.
Le choix des numéros de séquence de paquets RTP de début et de fin pour la trace est laissé à l'application. Ces valeurs sont rapportées dans le bloc. Le dernier numéro de séquence dans la trace peut différer du numéro de séquence rapporté dans tout rapport SR ou RR accompagnant.
Notez qu'en raison du bouclage du numéro de séquence, le numéro de séquence de fin peut être inférieur au numéro de séquence de début. Un bloc de rapport RLE de perte ne doit pas être utilisé pour rapporter une plage de 65,534 ou plus dans l'espace de numéros de séquence, car il n'y a aucun moyen d'identifier plusieurs bouclages.
La trace décrite par un rapport RLE de perte consiste en une séquence de valeurs booléennes, une pour chaque numéro de séquence de la trace. Une valeur de un représente une réception de paquet, ce qui signifie qu'un ou plusieurs paquets ayant ce numéro de séquence ont été reçus depuis le bouclage le plus récent des numéros de séquence (ou depuis le début de la session RTP si aucun bouclage n'a été jugé s'être produit). Une valeur de zéro représente une perte de paquet, ce qui signifie qu'il n'y a eu aucune réception de paquet pour ce numéro de séquence au moment du rapport. Si un paquet avec un numéro de séquence donné est reçu après un rapport de perte pour ce numéro de séquence, un rapport RLE de perte ultérieur peut rapporter une réception de paquet pour ce numéro de séquence.
Le codage lui-même consiste en une série d'unités de 16 bits appelées chunks qui décrivent des séquences de réceptions ou de pertes de paquets dans la trace. Chaque chunk spécifie soit une longueur de plage, soit un vecteur de bits, soit est un chunk nul. Une longueur de plage décrit entre 1 et 16,383 événements tous identiques (tous reçus ou tous perdus). Un vecteur de bits décrit 15 événements pouvant mélanger des réceptions et des pertes. Un chunk nul ne décrit aucun événement et est utilisé pour arrondir le bloc à une limite de mot de 32 bits.
Le mappage d'une séquence de paquets perdus et reçus à une séquence de chunks n'est pas nécessairement unique. Par exemple, la trace suivante couvre 45 paquets, dont les 22ème et 24ème ont été perdus et les autres reçus:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
Une façon de coder cela est:
bit vector 1111 1111 1111 111
bit vector 1111 1101 0111 111
bit vector 1111 1111 1111 111
null chunk
Une autre façon de coder cela est:
run of 21 receipts
bit vector 0101 1111 1111 111
run of 9 receipts
null chunk
Le choix du codage est laissé à l'application. Dans le cadre de cette liberté de choix, une application peut terminer une série de chunks de longueur de plage et de vecteur de bits avec un bloc de vecteur de bits qui s'étend au-delà de l'espace de numéros de séquence décrit par le bloc de rapport. Par exemple, si le 44ème paquet de la même séquence était perdu:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
Cela pourrait être codé comme:
run of 21 receipts
bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000
null chunk
Dans cet exemple, les cinq derniers bits du second vecteur de bits décrivent une partie de l'espace de numéros de séquence au-delà du dernier numéro de séquence dans la trace. Ces bits ont été mis à zéro.
Tous les bits dans un bloc de vecteur de bits décrivant une partie de l'espace de numéros de séquence au-delà du dernier numéro de séquence dans la trace doivent être mis à zéro et doivent être ignorés par le récepteur.
Si le nombre de blocs de longueur de plage plus vecteur de bits est impair, un paquet nul doit apparaître à la fin du bloc de rapport RLE de perte. Un bloc nul ne doit apparaître dans aucun autre contexte.
Les blocs de rapport RLE de perte doivent être envoyés avec prudence, car même avec la compression fournie par le codage par plages, ils peuvent facilement consommer une bande passante disproportionnée par rapport aux paquets RTCP normaux. Le type de bloc comprend un mécanisme appelé amincissement (thinning) qui permet à une application de limiter la taille du rapport.
Une valeur d'amincissement T sélectionne un sous-ensemble de paquets dans l'espace de numéros de séquence: les paquets dont le numéro de séquence est un multiple de 2^T. Les rapports de réception et de perte de paquets ne s'appliquent qu'à ces paquets. T peut varier de 0 à 15. Si T est zéro, chaque paquet dans l'espace de numéros de séquence est rapporté. Si T est 15, un paquet sur 32,768 est rapporté.
Supposons que la trace qui vient d'être décrite commence au numéro de séquence 13,821. Le dernier numéro de séquence dans la trace est 13,865. Si la trace est amincie avec une valeur d'amincissement T=2, les numéros de séquence suivants seront rapportés: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. La trace amincie est la suivante:
1 1 1 1 1 0 1 1 1 1 0
Cela peut être codé comme suit:
bit vector 1111 1011 1100 000
null chunk
Les quatre derniers bits du vecteur de bits, représentant les numéros de séquence 13,868, 13,872, 13,876 et 13,880, sont au-delà de la portée de la trace et sont donc mis à zéro et ignorés par le récepteur. Grâce à l'amincissement, la perte du 22ème paquet n'est pas rapportée, car son numéro de séquence 13,842 n'est pas un multiple de 4. Les réceptions de paquets pour tous les numéros de séquence qui ne sont pas des multiples de 4 ne sont pas non plus rapportées. Cependant, dans cet exemple, l'amincissement permet de raccourcir le bloc de rapport RLE de perte d'un mot de 32 bits.
Le choix de la valeur d'amincissement est laissé à l'application.
Le bloc de rapport RLE de perte a le format suivant:
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 bits
- Le bloc de rapport RLE de perte est identifié par la constante 1.
rsvd.: 4 bits
- Ce champ est réservé pour une définition future. En l'absence d'une telle définition, les bits de ce champ doivent être mis à zéro et doivent être ignorés par le récepteur.
thinning (T): 4 bits
- La quantité d'amincissement effectuée sur l'espace de numéros de séquence. Ce bloc ne rapporte que les paquets dont le numéro de séquence est 0 mod 2^T. La valeur 0 indique aucun amincissement et tous les paquets sont rapportés. L'amincissement maximal est un paquet sur 32,768 (équivalent à deux paquets dans l'espace de séquence de 16 bits).
block length: 16 bits
- Défini dans la section 3.
SSRC of source: 32 bits
- Le SSRC de la source de paquets de données RTP sur laquelle ce bloc de rapport rapporte.
begin_seq: 16 bits
- Le premier numéro de séquence sur lequel ce bloc rapporte.
end_seq: 16 bits
- Le dernier numéro de séquence sur lequel ce bloc rapporte plus un.
chunk i: 16 bits
- Il existe trois types de chunks: longueur de plage, vecteur de bits et nul de terminaison, définis dans les sections suivantes. Si un chunk est tout zéro, c'est un bloc nul de terminaison. Sinon, le bit le plus à gauche du chunk détermine son type: 0 pour longueur de plage, 1 pour vecteur de bits.