3.4. Definitionen und Algorithmusüberblick (Definitions and Algorithm Overview)

Die folgenden Zustandsinformationen müssen pro Empfänger geführt werden (größtenteils aus [1] übernommen). Beachten Sie, dass alle Variablen (außer in Punkt h) unten) unabhängig an jedem Empfänger berechnet werden. Daher können ihre lokalen Werte zu einem beliebigen Zeitpunkt voneinander abweichen.

a) Sei senders die Anzahl aktiver Sender in der RTP-Sitzung.

b) Sei members die aktuelle Schätzung der Anzahl der Empfänger in der RTP-Sitzung.

c) Seien tn und tp die Zeitpunkte für die nächste (bzw. letzte) geplante RTCP-RR-Übertragung, berechnet vor der Timer-Reconsideration.

d) Sei Tmin das minimale Intervall zwischen RTCP-Paketen gemäß [1]. Anders als in [1] wird der anfängliche Tmin auf 1 Sekunde gesetzt, um vor dem ersten RTCP-Paket eine gewisse Stichprobenerhebung der Gruppengröße zu ermöglichen. Nach dem Senden des ersten RTCP-Pakets wird Tmin auf 0 gesetzt.

e) Sei T_rr das Intervall, nach dem ein Empfänger, der gerade ein regulär geplantes RTCP-Paket gesendet hat, die Übertragung seines nächsten regulären RTCP-Pakets planen würde. Dieser Wert wird nach den Regeln von [1] ermittelt, jedoch mit Tmin wie in diesem Dokument definiert: T_rr = T (das in [1] definierte „berechnete Intervall“) mit tn = tp + T. T_rr bezieht sich stets auf den letzten berechneten Wert von T (aufgrund von Reconsideration oder zur Bestimmung von tn). T_rr wird in diesem Dokument auch als Regular-RTCP-Intervall (Regular RTCP interval) bezeichnet.

f) Sei t0 der Zeitpunkt, zu dem ein zu meldendes Ereignis von einem Empfänger erkannt wird.

g) Sei T_dither_max das maximale Intervall, um das ein RTCP-Feedback-Paket MAY zusätzlich verzögert wird, um Implosionen in Mehrteilnehmer-Sitzungen zu verhindern; der Wert für T_dither_max wird dynamisch aus T_rr berechnet (oder MAY in Zukunft durch ein allen RTP-Empfängern gemeinsames anderes Verfahren abgeleitet werden). Für Punkt-zu-Punkt-Sitzungen (d. h. Sitzungen mit genau zwei Mitgliedern ohne erwartete Änderung der Gruppengröße, z. B. Unicast-Streaming) wird T_dither_max auf 0 gesetzt.

h) Sei T_max_fb_delay die Obergrenze, innerhalb derer Feedback zu einem Ereignis zum Sender zurückgemeldet werden muss, um überhaupt noch nützlich zu sein. Dieser Wert ist anwendungsspezifisch; in diesem Dokument werden keine Werte definiert.

i) Sei te der Zeitpunkt, für den ein Feedback-Paket geplant ist.

j) Sei T_fd die tatsächliche (randomisierte) Verzögerung für die Übertragung einer FB-Nachricht als Reaktion auf ein Ereignis zum Zeitpunkt t0.

k) Sei allow_early eine boolesche Variable, die angibt, ob der Empfänger FB-Nachrichten vor seinem nächsten regulär geplanten RTCP-Intervall tn senden darf. Diese Variable dient der Drosselung des Feedbacks eines einzelnen Empfängers. allow_early wird nach Early-Feedback-Übertragung auf FALSE gesetzt und sobald die nächste reguläre RTCP-Übertragung stattfindet wieder auf TRUE.

l) Sei avg_rtcp_size der gleitende Mittelwert der RTCP-Paketgröße wie in [1] definiert.

m) Sei T_rr_interval ein OPTIONALES Mindestintervall zwischen regulären RTCP-Paketen. Wenn T_rr_interval == 0, hat diese Variable keine Auswirkung auf den Gesamtablauf des RTCP-Feedback-Algorithmus. Wenn T_rr_interval != 0, wird das nächste reguläre RTCP-Paket nicht T_rr nach der letzten regulären RTCP-Übertragung (d. h. bei tp+T_rr) geplant. Stattdessen wird das nächste reguläre RTCP-Paket frühestens T_rr_interval nach der letzten regulären RTCP-Übertragung geplant, d. h. zu oder später als tp+T_rr_interval. Beachten Sie, dass T_rr_interval die Berechnung von T_rr und tp nicht beeinflusst; vielmehr werden reguläre RTCP-Pakete, die vor tp+T_rr_interval zur Übertragung geplant sind, unterdrückt, wenn sie z. B. keine FB-Nachrichten enthalten. T_rr_interval beeinflusst die Übertragungsplanung von Early-RTCP-Paketen nicht.

Hinweis: T_rr_interval als unabhängige Variable bereitzustellen, soll reguläres RTCP-Feedback (und damit Bandbreitenverbrauch) nach Bedarf der Anwendung minimieren und gleichzeitig häufigere Early-RTCP-Pakete für zeitnahes Feedback ermöglichen. Dieses Ziel ließe sich nicht durch Reduktion der gesamten RTCP-Bandbreite erreichen, da eine solche Reduktion auch die Häufigkeit von Early-Feedback beeinträchtigen würde.

n) Sei t_rr_last der Zeitpunkt, zu dem das letzte reguläre RTCP-Paket geplant und gesendet wurde, d. h. nicht aufgrund von T_rr_interval unterdrückt wurde.

o) Sei T_retention das Zeitfenster, in dem vergangene FB-Nachrichten von einer AVPF-Entität gespeichert werden. Damit soll sichergestellt werden, dass Feedback-Unterdrückung auch für Entitäten funktioniert, die FB-Nachrichten von anderen Entitäten erhalten haben, bevor sie selbst das Feedback-Ereignis bemerken. T_retention MUST mindestens 2 Sekunden betragen.

p) Sei M*Td der Timeout-Wert, ab dem ein Empfänger als inaktiv gilt (wie in [1] definiert).

Die Feedback-Situation für ein zu meldendes Ereignis an einem Empfänger ist in Abbildung 2 dargestellt. Zum Zeitpunkt t0 wird ein solches Ereignis (z. B. ein Paketverlust) am Empfänger erkannt. Der Empfänger entscheidet – basierend auf aktueller Bandbreite, Gruppengröße und anderen anwendungsspezifischen Parametern –, dass eine FB-Nachricht an den Sender zurückgesendet werden muss.

Um eine Implosion von Feedback-Paketen in Mehrteilnehmer-Sitzungen zu vermeiden, MUST der Empfänger die Übertragung des RTCP-Feedback-Pakets um einen zufälligen Betrag T_fd verzögern (mit gleichverteilter Zufallszahl im Intervall [0, T_dither_max]). Die Übertragung des zusammengesetzten RTCP-Pakets MUST dann für te = t0 + T_fd geplant werden.

Der Parameter T_dither_max leitet sich aus dem Regular-RTCP-Intervall T_rr ab, das wiederum von der Gruppengröße abhängt. Ein zukünftiges Dokument MAY auch andere Berechnungen für T_dither_max spezifizieren (z. B. basierend auf RTT), wenn sichergestellt werden kann, dass alle RTP-Empfänger dasselbe Verfahren zur Berechnung von T_dither_max verwenden.

Für ein bestimmtes Anwendungsszenario MAY ein Empfänger eine Obergrenze für die akzeptable lokale Verzögerung von FB-Nachrichten bestimmen: T_max_fb_delay. Wenn eine a-priori-Schätzung oder die tatsächliche Berechnung von T_dither_max darauf hindeutet, dass diese Obergrenze verletzt werden könnte (z. B. weil T_dither_max > T_max_fb_delay), MAY der Empfänger entscheiden, gar kein Feedback zu senden, weil der erzielbare Nutzen als unzureichend erachtet wird.

Wenn ein Early-RTCP-Paket geplant ist, MUST der Zeitpunkt für das nächste reguläre RTCP-Paket entsprechend angepasst werden, sodass ein neues tn (tn=tp+2*T_rr) und anschließend ein neues tp (tp=tp+T_rr) gilt. Damit wird sichergestellt, dass die kurzfristig gemittelte RTCP-Bandbreite bei Early-Feedback die Bandbreite ohne Early-Feedback nicht übersteigt.

            event to
            report
            detected
               |
               |  RTCP feedback range
               |   (T_max_fb_delay)
               vXXXXXXXXXXXXXXXXXXXXXXXXXXX     ) )
|---+--------+-------------+-----+------------| |--------+--->
    |        |             |     |            ( (        |
    |       t0            te                             |
    tp                                                   tn
              \_______  ________/
                      \/
                T_dither_max

     Figure 2: Event report and parameters for Early RTCP scheduling