Zum Hauptinhalt springen

Anhang A. Steuerung der Anzahl von Rtx pro Paket

Die Ermittlung der Anzahl von Retransmissionen (rtxs.) pro Paket für die bestmögliche Übertragung ist schwierig. Das absolute Minimum sollte eins (1) sein; andernfalls sollte dieses Nutzlastformat nicht verwendet werden. Zum Veröffentlichungszeitpunkt waren den Autoren zudem keine Studien zur optimalen Anzahl von Retransmissionen pro Paket bekannt. Um Implementierern und Forschern auf diesem Gebiet zu helfen, beschreibt dieser Abschnitt eine Schätzung der Pufferzeit, die für eine gegebene Anzahl von Retransmissionen nötig ist. Nach Berechnung dieser Zeit kann sie dem Client über den SDP-Parameter „rtx-time“ mitgeteilt werden, wie in diesem Dokument definiert.

A.1. Szenario und Annahmen​

  • Streaming-Szenario mit gelockerten Verzögerungsgrenzen. Client und Server verfügen über Pufferplatz gemäß dem Parameter „rtx-time“ in SDP.

  • RTP-AVPF-Profil mit Retransmissionsschema SSRC-Multiplexing: 1 SSRC für Originalpakete, 1 für Retransmission-Pakete.

  • Standard-RTCP-Bandbreitenanteil für SR und RR, d. h. SR+RR = 0,05. Es gibt Sender (2) und Empfänger (1). Empfänger und Sender erhalten je 1/3 des RTCP-Bandbreitenanteils, weil der Anteil der Sender größer als 1/4 der Session-Mitglieder ist.

  • avg-rtcp-size wird auf etwa 120 Byte geschätzt. Das ist ein aufgerundeter Mittelwert aus 2 SRs, je einem pro SSRC, mit 40/8/28/32 Byte für IPv6/UDP/SR/SDES mit CNAME, also je 105 Byte; und einem RR mit 40/8/64/32 Byte für IPv6/UDP/2*RR/SDES, also 157 Byte. Da Sender und Empfänger die RTCP-Bandbreite zu gleichen Teilen teilen, ist avg-rtcp-size = (157+105+105)/3 = 117,3 ≈ 120 Byte. Wichtig ist, dass der Wert etwas über 100 Byte liegt und damit typische Konfigurationen repräsentiert.

  • Das verwendete Profil ist AVPF [1], und Generic NACKs werden für Retransmissionsanforderungen genutzt. Das ergibt 16 Byte Overhead für 1 NACK und je 4 Byte mehr pro zusätzlichem NACK Feedback Control Information (FCI)-Feld.

  • Wir nehmen einen Worst-Case an, in dem jedes Paket seine verfügbare maximale Anzahl Retransmissionen N erschöpft, bevor es empfangen wird. Bedeutet: Wird ein Paket höchstens 2-mal angefordert, wird der zugehörige generische NACK-Berichtsblock für dieses Paket in zwei aufeinanderfolgenden RTCP-Compound-Paketen gesendet; analog 10-mal bei 10 Anforderungen. Diese Annahme hält die RTCP-Paketgröße nach N*RTCP-Intervallen (Sekunden) näherungsweise konstant bei avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N). Hier ist der Empfänger-RTCP-Bandbreitenanteil 1/3; also avg-rtcp-size = 124 + 4*N/3.

  • Zwei Verzögerungsparameter sind schwer zu schätzen und implementationsabhängig. Wir listen sie ohne festen Wert: Paketverlusterkennungszeit (T2) sowie Feedback-Verarbeitungs- und Warteschlangenzeit für Retransmissionen (T5). Implementierer sollen angemessene Werte zuweisen.

Grafisch ergibt sich Folgendes:

        Sender
      +-+---------------------------------^-----\-----------------
       \ \                               /       \
        \ \                             |         |
  SN=0   \ \ SN=1                       /         \  RTX(SN=0)
          \ \                          /           \
           X \                        /             \
              `.                     /               \
                \                   /                 \
                 \                 |                   |
                  \                /                   \    ......
                   \              /                     \
      -------------V----D--------/-----------------------V--------
             T1      T2    T3         T4    T5     T1   ........
       Receiver

Legende:

  • DL: Downlink (Client→Server)
  • UL: Uplink (Server→Client)
  • Zeiteinheit: Sekunden, s
  • Bitrateneinheit: Bit pro Sekunde, bps

DL-Übertragungszeit: T1 = physical-delay-DL + tx-delay-DL (=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter

Zeit bis zur Paketverlusterkennung: T2 = pkt-loss-detect-time

Zeit bis zur Meldung des Paketverlusts: T3 = time-to-next-rtcp-report

UL-Übertragungszeit: T4 = physical-delay-UL + transmission-delay-UL + interarrival-delay-jitter

Verarbeitungszeit für Retransmissionen: T5 = feedback-processing-time + rtx-queuing-time

A.2. Ziel​

Schätzung der Pufferzeit T(), die ein Streaming-Server nutzen soll, um eine gegebene Anzahl Retransmissionen N pro Paket zu ermöglichen. Diese Zeit ist am Server und Client näherungsweise gleich, wenn man annimmt, dass der Client T1 Sekunden später mit dem Puffern beginnt.

A.3. Lösung​

Zuerst die Schätzung für 1 Retransmission, T(1)=T:

T = T1 + T2 + T3 + T4 + T5

Da T1 + T4 ~= RTT,

T = RTT + T2 + T3 + T5

Der Worst-Case für T3: Es wird angenommen, dass auf einen ganzen RTCP-Intervall gewartet werden muss und der maximale Randomisierungsfaktor 1,5 gilt. Nach der anschließenden Kompensation zur Vermeidung von Verkehrsbursts (siehe Anhang A.7 von RTP [3]) gilt T3 = 1,5/1,21828*RTCP-Interval. Also:

T = RTT + 1.2312*RTCP-Interval + T2 + T5

Andererseits ist RTCP-Interval = avg-rtcp-size*8*(senders + receivers)/(RR+RS). In diesem Szenario: Sender + Empfänger = 3; RR+RS ist der Bandbreitenanteil für Empfänger- und Senderberichte, hier gleich dem Standard 5 % der Session-Bandbreite bw. Mit durchschnittlicher RTCP-Paketgröße avg-rtcp-size = 120 Byte:

T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5

für 1 Retransmission.

Für N Retransmissionen ist die verfügbare Pufferzeit auf einem Streaming-Server oder -Client näherungsweise:

T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5)

wobei wie oben:

avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N)
              = 120 + (1/3)*(12 + 4*N)
              = 124 + 4*N/3.

A.4. Zahlen​

Ignoriert man T2 und T5, d. h. alle Verluste werden sofort erkannt und es gibt keine zusätzliche Verzögerung durch Feedback-Verarbeitung oder Retransmission-Warteschlange, ergeben sich folgende Pufferzeiten für verschiedene N:

RTCP mit mehreren Generic NACKs; variable Paketgröße = 124 + 4*N/3 Byte

|============|=====|======================================|
|  RTP BW    | RTT |            N value                   |
|============|=====|   1      2       5       7       10  |
                     |======================================|

64000         0,05   1,21    2,44    6,28    8,97    13,18
128000        0,05   0,63    1,27    3,27    4,66    6,84
256000        0,05   0,34    0,68    1,76    2,50    3,67
512000        0,05   0,19    0,39    1,00    1,43    2,09
1024000       0,05   0,12    0,25    0,63    0,89    1,29
5000000       0,05   0,06    0,13    0,33    0,46    0,66
10000000      0,05   0,06    0,11    0,29    0,41    0,58

64000         0,2    1,36    2,74    7,03    10,02   14,68
128000        0,2    0,78    1,57    4,02    5,71    8,34
256000        0,2    0,49    0,98    2,51    3,55    5,17
512000        0,2    0,34    0,69    1,75    2,48    3,59
1024000       0,2    0,27    0,55    1,38    1,94    2,79
5000000       0,2    0,21    0,43    1,08    1,51    2,16
10000000      0,2    0,21    0,41    1,04    1,46    2,08

64000         1      2,16    4,34    11,03   15,62   22,68
128000        1      1,58    3,17    8,02    11,31   16,34
256000        1      1,29    2,58    6,51    9,15    13,17
512000        1      1,14    2,29    5,75    8,08    11,59
1024000       1      1,07    2,15    5,38    7,54    10,79
5000000       1      1,01    2,03    5,08    7,11    10,16
10000000      1      1,01    2,01    5,04    7,06    10,08

Um den Fehler zu quantifizieren, wenn Generic NACKs nicht berücksichtigt werden, dieselben Zahlen mit avg-rtcp-size ≈ 120 Byte ohne NACK-Beitrag. Wie unten zu sehen, kann die Pufferschätzung um 1–1,5 Sekunden (5–10 %) bei niedrigeren Bitraten und höherer Retransmissionsanzahl abweichen. In diesem Fall ist der Effekt gering. Dennoch sollte er für das jeweilige Szenario sorgfältig bewertet werden; daher ist der Beitrag in der Formel enthalten.

RTCP ohne Generic NACK, feste Paketgröße ≈ 120 Byte

|============|=====|======================================|
|  RTP BW    | RTT |            N value                   |
|============|=====|   1      2       5       7       10  |
                     |======================================|

64000         0,05   1,16    2,32    5,79    8,11    11,58
128000        0,05   0,60    1,21    3,02    4,23    6,04
256000        0,05   0,33    0,65    1,64    2,29    3,27
512000        0,05   0,19    0,38    0,94    1,32    1,89
1024000       0,05   0,12    0,24    0,60    0,83    1,19
5000000       0,05   0,06    0,13    0,32    0,45    0,64
10000000      0,05   0,06    0,11    0,29    0,40    0,57

64000         0,2    1,31    2,62    6,54    9,16    13,08
128000        0,2    0,75    1,51    3,77    5,28    7,54
256000        0,2    0,48    0,95    2,39    3,34    4,77
512000        0,2    0,34    0,68    1,69    2,37    3,39
1024000       0,2    0,27    0,54    1,35    1,88    2,69
5000000       0,2    0,21    0,43    1,07    1,50    2,14
10000000      0,2    0,21    0,41    1,04    1,45    2,07

64000         1      2,11    4,22    10,54   14,76   21,08
128000        1      1,55    3,11    7,77    10,88   15,54
256000        1      1,28    2,55    6,39    8,94    12,77
512000        1      1,14    2,28    5,69    7,97    11,39
1024000       1      1,07    2,14    5,35    7,48    10,69
5000000       1      1,01    2,03    5,07    7,10    10,14
10000000      1      1,01    2,01    5,04    7,05    10,07
Letztes Update am