3.6. Überlegungen zur Gruppengröße (Considerations on the Group Size)
Dieser Abschnitt liefert einige Richtlinien zu Gruppengrößen, bei denen die verschiedenen Feedback-Modi verwendet werden können.
3.6.1. ACK-Modus
Die RTP-Sitzung MUST genau zwei Mitglieder haben, und diese Gruppengröße MUST NOT wachsen, d. h. es MUST Punkt-zu-Punkt-Kommunikation sein. In der Sitzungsbeschreibung SHOULD Unicast-Adressen verwendet werden.
Für unidirektionale sowie bidirektionale Kommunikation zwischen zwei Parteien stehen 2,5 % der RTP-Sitzungsbandbreite für RTCP-Verkehr von den Empfängern einschließlich Feedback zur Verfügung. Bei einem 64-kbit/s-Strom ergeben sich 1.600 bit/s für RTCP. Geht man von durchschnittlich 96 Byte (=768 Bit) pro RTCP-Paket aus, kann ein Empfänger 2 Ereignisse pro Sekunde an den Sender melden. Werden Bestätigungen für 10 Ereignisse in jeder FB-Nachricht gesammelt, können 20 Ereignisse pro Sekunde bestätigt werden. Bei 256 kbit/s könnten 8 Ereignisse pro Sekunde gemeldet werden; die ACKs können also in feinerer Granularität gesendet werden (z. B. nur drei ACKs pro FB-Nachricht).
ACK-Strategien MUST so definiert sein, dass sie mit diesen Bandbreitenbegrenzungen ordnungsgemäß funktionieren. Eine Angabe, ob ACKs für eine Sitzung erlaubt sind und, falls ja, welche ACK-Strategie verwendet werden soll, MAY durch außerbandige Mechanismen vermittelt werden, z. B. medienspezifische Attribute in einer Sitzungsbeschreibung mit SDP.
3.6.2. NACK-Modus
Negative Bestätigungen (und andere Feedback-Arten mit ähnlichen Meldecharakteristika) MUST für alle Sitzungen mit einer Gruppengröße verwendet werden, die größer als zwei werden kann. Natürlich MAY NACKs auch für Punkt-zu-Punkt-Kommunikation verwendet werden.
Ob der Einsatz von Early-RTCP-Paketen in Betracht gezogen werden soll, hängt von einer Reihe von Parametern ab, darunter Sitzungsbandbreite, Codec, besondere Feedback-Art sowie Anzahl der Sender und Empfänger.
Die wichtigsten Parameter bei der Bestimmung des Betriebsmodus sind das erlaubte Mindestintervall zwischen zwei zusammengesetzten RTCP-Paketen (T_rr) und die durchschnittliche Anzahl von Ereignissen, die vermutlich pro Zeitintervall gemeldet werden müssen (plus deren zeitliche Verteilung). Das Mindestintervall kann aus der verfügbaren RTCP-Bandbreite und der erwarteten durchschnittlichen Größe eines RTCP-Pakets abgeleitet werden. Die Anzahl zu meldender Ereignisse (z. B. pro Sekunde) kann aus der Paketverlustrate und der Senderate abgeleitet werden. Aus diesen beiden Werten lässt sich die zulässige Gruppengröße für den Immediate-Feedback-Modus berechnen.
Wie in Abschnitt 3.3 ausgeführt:
Sei N die durchschnittliche Anzahl von Ereignissen, die ein Empfänger pro Intervall T melden soll, B der RTCP-Bandbreitenanteil für diesen Empfänger und R die durchschnittliche RTCP-Paketgröße, dann arbeitet der Empfänger im Immediate-Feedback-Modus, solange N<=B*T/R.
Die Obergrenze für den Early-RTCP-Modus hängt dann allein von der akzeptablen Qualitätsverschlechterung ab, d. h. wie viele Ereignisse pro Zeitintervall ungemeldet bleiben dürfen.
Wie in Abschnitt 3.3 ausgeführt:
Mit obiger Notation lässt sich der Early-RTCP-Modus grob durch N > B*T/R als „untere Grenze“ charakterisieren. Eine Schätzung für eine obere Grenze ist schwieriger. Setzt man N=1, erhält man für gegebenes R und B das Intervall T = R/B als durchschnittliches Intervall zwischen zu meldenden Ereignissen. Diese Information kann als Hinweis dienen, ob eine frühe Übertragung von RTCP-Paketen nützlich ist.
Beispiel: Wird ein 256-kbit/s-Video mit 30 fps über ein Netz mit einer MTU von etwa 1.500 Byte übertragen, passt in den meisten Fällen jedes Bild in ein Paket, was zu einer Paketrate von 30 Paketen pro Sekunde führt. Tritt im Netz 5 % Paketverlust auf (gleichverteilt, keine Abhängigkeit zwischen Empfängern), muss jeder Empfänger im Durchschnitt 3 verlorene Pakete je zwei Sekunden melden. Bei einem einzelnen Sender und mehr als drei Empfängern entfallen 3,75 % der RTCP-Bandbreite auf die Empfänger, also 9,6 kbit/s. Geht man weiter von 120 Byte für das durchschnittliche zusammengesetzte RTCP-Paket aus, erlaubt dies 10 RTCP-Pakete pro Sekunde oder 20 in zwei Sekunden. Muss jeder Empfänger drei verlorene Pakete je zwei Sekunden melden, ergibt sich eine maximale Gruppengröße von 6–7 Empfängern, wenn alle Verlustereignisse gemeldet werden. Die Regeln für die Übertragung von Early-RTCP-Paketen sollten genügend Flexibilität bieten, damit der Großteil dieser Meldungen zeitnah erfolgen kann.
Eine Erweiterung dieses Beispiels zur Bestimmung der oberen Grenze für den Early-RTCP-Modus könnte zu folgenden Überlegungen führen: Es werde angenommen, dass das zugrunde liegende Codierverfahren und die Anwendung (sowie tolerante Nutzer) etwa einen Verlust ohne Reparatur je zwei Sekunden zulassen. Damit sinkt die Anzahl zu meldender Pakete pro Empfänger auf zwei je zwei Sekunden, und die Gruppengröße steigt auf 10. Geht man ferner davon aus, dass ein Teil der Paketverluste korreliert ist, sinkt der Feedback-Verkehr weiter, und Gruppengrößen von etwa 12 bis 16 (möglicherweise sogar 20) lassen sich mit dem Early-RTCP-Modus noch vernünftig unterstützen. Beachten Sie, dass all diese Überlegungen auf Statistik beruhen und in manchen Fällen nicht zutreffen werden.