4.1. Loss RLE Report Block (Paketverlust-RLE-Berichtsblock)
4.1. Loss RLE Report Block (Paketverlust-RLE-Berichtsblock)
Dieser Blocktyp ermöglicht detaillierte Berichte über einzelne Paketempfangs- und Verlustereignisse. Solche Berichte können beispielsweise für Multicast-Inferenz von Netzwerkmerkmalen (MINC) [11] verwendet werden. Mit MINC kann man die Topologie des Multicast-Baums entdecken, der zur Verteilung der RTP-Pakete einer Quelle verwendet wird, und die Verlustraten entlang der Verbindungen innerhalb dieses Baums, oder sie könnten verwendet werden, um Rohdaten für eine Netzwerkverwaltungsanwendung bereitzustellen.
Da eine boolesche Spur verlorener und empfangener RTP-Pakete potenziell lang ist, erlaubt dieser Blocktyp die Komprimierung der Spur durch Lauflängenkodierung. Um die Blockgröße weiter zu reduzieren, können Verlustereignisberichte systematisch aus der Spur in einem Mechanismus namens Ausdünnung (thinning) gelöscht werden, der unten beschrieben und in [13] untersucht wird.
Ein Teilnehmer, der einen Loss RLE Report Block generiert, sollte die Genauigkeit bei der Berichterstattung über beobachtete Ereignisse gegenüber der Interpretation dieser Ereignisse bevorzugen, wann immer dies möglich ist. Die Interpretation sollte denjenigen überlassen werden, die die Berichtsblöcke beobachten. Diesem Ansatz zu folgen bedeutet, dass die Buchführung für Loss RLE Report Blocks sich von der Buchführung für die Generierung der SR- und RR-Pakete, die in der RTP-Spezifikation [9] beschrieben ist, in den folgenden zwei Bereichen unterscheiden wird: Sender-basierte Buchführung und Paket-basierte Buchführung.
In seiner Sender-basierten Buchführung sollte ein RTP-Sitzungsteilnehmer den Empfang einer Mindestschwelle von RTP-Paketen nicht zur Bedingung für die Berichterstattung über den Sender dieser Pakete machen. Diese Buchführungstechnik unterscheidet sich von der in Abschnitt 6.2.1 und Anhang A.1 der RTP-Spezifikation beschriebenen Technik, die es einer Schwelle ermöglicht zu bestimmen, ob ein Sender als gültig angesehen wird.
In seiner Paket-basierten Buchführung sollte ein RTP-Sitzungsteilnehmer alle Sequenznummern als gültig behandeln. Diese Buchführungstechnik unterscheidet sich von der in Anhang A.1 der RTP-Spezifikation beschriebenen Technik, die vorschlägt, eine Sequenznummer auf der Grundlage ihrer Kontinuität mit den Sequenznummern zuvor empfangener Pakete als gültig oder ungültig zu beurteilen.
Sendergültigkeit und Sequenznummerngültigkeit sind Interpretationen der Rohdaten. Solche Interpretationen sind beispielsweise gerechtfertigt, um zu verhindern, dass das verirrte alte Paket aus einer nicht verwandten Sitzung einen Effekt auf die Berechnung des RTCP-Übertragungsintervalls hat. Das Vorhandensein verirrter Pakete könnte andererseits für eine Netzwerküberwachungsanwendung von Interesse sein.
Eine Buchführungsinterpretation, die noch notwendig ist, besteht darin, dass ein Teilnehmer entscheidet, ob die 16-Bit-Sequenznummer übergelaufen ist. Unter gewöhnlichen Umständen ist dies keine schwierige Aufgabe. Wenn beispielsweise Paketnummer 65,535 (die höchstmögliche Sequenznummer) kurz darauf von Paketnummer 0 gefolgt wird, ist es vernünftig anzunehmen, dass es einen Überlauf gegeben hat. Es ist jedoch möglich, dass das Paket ein früheres ist (von 65,535 Paketen früher). Es ist auch möglich, dass die Sequenznummern mehrfach übergelaufen sind, entweder vorwärts oder rückwärts. Die Interpretation wird schwieriger, wenn es große Lücken zwischen den Sequenznummern gibt, selbst unter Berücksichtigung des Überlaufs, und wenn es lange Intervalle zwischen empfangenen Paketen gibt.
Die hier vorgeschriebene Paket-basierte Buchführungstechnik besteht darin, dass ein Teilnehmer die Sequenznummer des zuletzt von einem Sender empfangenen Pakets verfolgt. Für das nächste Paket, das von diesem Sender eintrifft, muss die Sequenznummer so beurteilt werden, dass sie nicht mehr als 32,768 Pakete vor oder hinter der jüngsten liegt, je nachdem, welche Wahl sie näher platziert. Falls beide Wahlmöglichkeiten gleich weit entfernt sind (nur möglich, wenn die Entfernung 32,768 beträgt), muss die Wahl diejenige sein, die keinen Überlauf erfordert. Anhang A.1 präsentiert einen Algorithmus, der diese Technik implementiert.
Jeder Block berichtet über eine einzelne RTP-Datenpaketquelle, identifiziert durch ihre SSRC. Der Empfänger, der den Bericht liefert, wird im Header des RTCP-Pakets identifiziert.
Die Wahl der Anfangs- und End-RTP-Paket-Sequenznummern für die Spur wird der Anwendung überlassen. Diese Werte werden im Block berichtet. Die letzte Sequenznummer in der Spur kann sich von der Sequenznummer unterscheiden, über die in einem begleitenden SR- oder RR-Bericht berichtet wird.
Beachten Sie, dass aufgrund des Sequenznummern-Wraparounds die End-Sequenznummer kleiner als die Anfangs-Sequenznummer sein kann. Ein Loss RLE Report Block darf nicht verwendet werden, um über einen Bereich von 65,534 oder größer im Sequenznummernraum zu berichten, da es keine Möglichkeit gibt, mehrfache Wraparounds zu identifizieren.
Die von einem Loss RLE-Bericht beschriebene Spur besteht aus einer Sequenz von booleschen Werten, einen für jede Sequenznummer der Spur. Ein Wert von eins repräsentiert einen Paketempfang, was bedeutet, dass ein oder mehrere Pakete mit dieser Sequenznummer seit dem jüngsten Wraparound von Sequenznummern (oder seit dem Beginn der RTP-Sitzung, wenn kein Wraparound als aufgetreten beurteilt wurde) empfangen wurden. Ein Wert von null repräsentiert einen Paketverlust, was bedeutet, dass es zum Zeitpunkt des Berichts keinen Paketempfang für diese Sequenznummer gab. Wenn ein Paket mit einer gegebenen Sequenznummer nach einem Bericht über einen Verlust für diese Sequenznummer empfangen wird, kann ein späterer Loss RLE-Bericht einen Paketempfang für diese Sequenznummer berichten.
Die Kodierung selbst besteht aus einer Reihe von 16-Bit-Einheiten, die Chunks genannt werden und die Sequenzen von Paketempfängen oder -verlusten in der Spur beschreiben. Jeder Chunk gibt entweder eine Lauflänge oder einen Bitvektor an oder ist ein Null-Chunk. Eine Lauflänge beschreibt zwischen 1 und 16,383 Ereignissen, die alle gleich sind (alle empfangen oder alle verloren). Ein Bitvektor beschreibt 15 Ereignisse, die möglicherweise Empfänge und Verluste mischen. Ein Null-Chunk beschreibt keine Ereignisse und wird verwendet, um den Block auf eine 32-Bit-Wortgrenze aufzurunden.
Die Abbildung von einer Sequenz verlorener und empfangener Pakete zu einer Sequenz von Chunks ist nicht notwendigerweise eindeutig. Zum Beispiel deckt die folgende Spur 45 Pakete ab, von denen das 22. und 24. verloren gegangen sind und die anderen empfangen wurden:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
Eine Möglichkeit, dies zu kodieren, ist:
bit vector 1111 1111 1111 111
bit vector 1111 1101 0111 111
bit vector 1111 1111 1111 111
null chunk
Eine andere Möglichkeit, dies zu kodieren, ist:
run of 21 receipts
bit vector 0101 1111 1111 111
run of 9 receipts
null chunk
Die Wahl der Kodierung wird der Anwendung überlassen. Als Teil dieser Wahlfreiheit kann eine Anwendung eine Reihe von Lauflängen- und Bitvektor-Chunks mit einem Bitvektor-Block beenden, der über den vom Berichtsblock beschriebenen Sequenznummernraum hinausgeht. Wenn beispielsweise das 44. Paket in derselben Sequenz verloren gegangen wäre:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
Dies könnte wie folgt kodiert werden:
run of 21 receipts
bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000
null chunk
In diesem Beispiel beschreiben die letzten fünf Bits des zweiten Bitvektors einen Teil des Sequenznummernraums jenseits der letzten Sequenznummer in der Spur. Diese Bits wurden auf null gesetzt.
Alle Bits in einem Bitvektor-Block, die einen Teil des Sequenznummernraums jenseits der letzten Sequenznummer in der Spur beschreiben, müssen auf null gesetzt werden und müssen vom Empfänger ignoriert werden.
Wenn die Anzahl der Lauflängen- plus Bitvektor-Blöcke ungerade ist, muss ein Null-Paket am Ende des Loss RLE Report Blocks erscheinen. Ein Null-Block darf in keinem anderen Kontext erscheinen.
Loss RLE Report Blocks sollten mit Vorsicht gesendet werden, da sie selbst mit der durch Lauflängenkodierung bereitgestellten Kompression leicht eine unverhältnismäßige Bandbreite im Vergleich zu normalen RTCP-Paketen verbrauchen können. Der Blocktyp enthält einen Mechanismus namens Ausdünnung (thinning), der es einer Anwendung ermöglicht, die Berichtsgröße zu begrenzen.
Ein Ausdünnungswert T wählt eine Teilmenge von Paketen im Sequenznummernraum aus: Pakete, deren Sequenznummer ein Vielfaches von 2^T ist. Paketempfangs- und Verlustberichte gelten nur für diese Pakete. T kann zwischen 0 und 15 variieren. Wenn T null ist, wird jedes Paket im Sequenznummernraum berichtet. Wenn T 15 ist, wird jedes 32,768. Paket berichtet.
Angenommen, die gerade beschriebene Spur beginnt bei Sequenznummer 13,821. Die letzte Sequenznummer in der Spur ist 13,865. Wenn die Spur mit einem Ausdünnungswert T=2 ausgedünnt wird, werden die folgenden Sequenznummern berichtet: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. Die ausgedünnte Spur ist wie folgt:
1 1 1 1 1 0 1 1 1 1 0
Dies kann wie folgt kodiert werden:
bit vector 1111 1011 1100 000
null chunk
Die letzten vier Bits im Bitvektor, die die Sequenznummern 13,868, 13,872, 13,876 und 13,880 darstellen, liegen außerhalb des Spurbereichs und werden daher auf null gesetzt und vom Empfänger ignoriert. Durch die Ausdünnung wird der Verlust des 22. Pakets nicht berichtet, da seine Sequenznummer 13,842 kein Vielfaches von 4 ist. Paketempfänge für alle Sequenznummern, die keine Vielfachen von 4 sind, werden ebenfalls nicht berichtet. In diesem Beispiel ermöglicht die Ausdünnung jedoch, den Loss RLE Report Block um ein 32-Bit-Wort zu verkürzen.
Die Wahl des Ausdünnungswerts wird der Anwendung überlassen.
Der Loss RLE Report Block hat das folgende Format:
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
- Der Loss RLE Report Block wird durch die Konstante 1 identifiziert.
rsvd.: 4 Bits
- Dieses Feld ist für zukünftige Definitionen reserviert. In Abwesenheit einer solchen Definition müssen die Bits in diesem Feld auf null gesetzt werden und müssen vom Empfänger ignoriert werden.
thinning (T): 4 Bits
- Die Menge der Ausdünnung, die auf den Sequenznummernraum angewendet wird. Dieser Block berichtet nur über Pakete, deren Sequenznummer 0 mod 2^T ist. Der Wert 0 zeigt keine Ausdünnung an und alle Pakete werden berichtet. Die maximale Ausdünnung ist jedes 32,768. Paket (entsprechend zwei Paketen im 16-Bit-Sequenzraum).
block length: 16 Bits
- Definiert in Abschnitt 3.
SSRC of source: 32 Bits
- Die SSRC der RTP-Datenpaketquelle, über die dieser Berichtsblock berichtet.
begin_seq: 16 Bits
- Die erste Sequenznummer, über die dieser Block berichtet.
end_seq: 16 Bits
- Die letzte Sequenznummer, über die dieser Block berichtet, plus eins.
chunk i: 16 Bits
- Es gibt drei Chunk-Typen: Lauflänge, Bitvektor und abschließende Null, die in den folgenden Abschnitten definiert sind. Wenn ein Chunk komplett null ist, ist es ein abschließender Null-Block. Andernfalls bestimmt das linkeste Bit des Chunks seinen Typ: 0 für Lauflänge, 1 für Bitvektor.