Passa al contenuto principale

Appendice A. Come controllare il numero di rtx per pacchetto

Determinare il numero di ritrasmissioni (rtx) per pacchetto per ottenere la migliore trasmissione possibile è un compito difficile. Naturalmente, il minimo assoluto dovrebbe essere uno (1); altrimenti, non usare questo formato di payload. Inoltre, alla data di pubblicazione, gli autori non erano a conoscenza di studi sul numero di ritrasmissioni per pacchetto da usare per le migliori prestazioni. Per aiutare implementatori e ricercatori su questo punto, questa sezione descrive una stima del tempo di buffering necessario per ottenere un dato numero di ritrasmissioni. Una volta calcolato questo tempo, può essere comunicato al client tramite il parametro SDP "rtx-time", come definito in questo documento.

A.1. Scenario e assunzioni​

  • Scenario di streaming con vincoli di ritardo rilassati. Client e server dispongono di spazio di buffering come indicato dal parametro "rtx-time" in SDP.

  • Profilo RTP AVPF usato con schema di ritrasmissione SSRC-multiplexing: 1 SSRC per i pacchetti originali, 1 per i pacchetti di ritrasmissione.

  • Quota di banda RTCP predefinita per SR e RR, cioè SR+RR = 0,05. Si hanno mittenti (2) e riceventi (1). Riceventi e mittenti ottengono in modo uguale 1/3 della quota di banda RTCP perché la proporzione di mittenti è maggiore di 1/4 dei membri della sessione.

  • avg-rtcp-size è approssimato con 120 byte. È una media arrotondata per eccesso di 2 SR, uno per ciascun SSRC, con 40/8/28/32 byte per IPv6/UDP/SR/SDES con CNAME, quindi 105 byte ciascuno; e un RR con 40/8/64/32 byte per IPv6/UDP/2*RR/SDES, cioè 157 byte. Poiché mittenti e riceventi condividono la banda RTCP in modo uguale, allora avg-rtcp-size = (157+105+105)/3 = 117,3 ≈ 120 byte. La caratteristica importante di questo valore è che è qualcosa sopra i 100 byte, che sembra una cifra rappresentativa per configurazioni tipiche.

  • Il profilo usato è AVPF [1] e si usano Generic NACK per richiedere le ritrasmissioni. Ciò aggiunge 16 byte di overhead per 1 NACK e 4 byte in più per ogni ulteriore campo NACK Feedback Control Information (FCI).

  • Si assume uno scenario peggiore in cui ogni pacchetto esaurisce il corrispondente numero disponibile di ritrasmissioni, N, prima di essere ricevuto. Ciò significa che se un pacchetto è richiesto per la ritrasmissione al massimo 2 volte, il corrispondente blocco di report generic NACK che richiede quel particolare pacchetto è inviato in due composti RTCP consecutivi; analogamente, se è richiesto per la ritrasmissione 10 volte, il generic NACK è inviato 10 volte. Questa assunzione rende la dimensione del pacchetto RTCP approssimativamente costante dopo N*intervalli RTCP (secondi), cioè avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N). Nel nostro caso, la quota di banda RTCP del ricevente è 1/3; quindi avg-rtcp-size = 124 + 4*N/3.

  • Due parametri di ritardo sono difficili da approssimare e possono dipendere dall'implementazione. Pertanto li elenchiamo qui esplicitamente senza assegnare un valore particolare: uno è il tempo di rilevamento della perdita di pacchetti (T2), l'altro è il tempo di elaborazione del feedback e di accodamento per le ritrasmissioni (T5). Gli implementatori devono assegnare valori appropriati a questi due parametri.

Graficamente, si ha quanto segue:

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

Legenda:

  • DL: downlink (client → server)
  • UL: uplink (server → client)
  • L'unità di tempo è il secondo, s.
  • L'unità di bitrate è il bit al secondo, bps.

Tempo di trasmissione DL: T1 = physical-delay-DL + tx-delay-DL (=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter

Tempo per rilevare la perdita di pacchetto: T2 = pkt-loss-detect-time

Tempo per segnalare la perdita di pacchetto: T3 = time-to-next-rtcp-report

Tempo di trasmissione UL: T4 = physical-delay-UL + transmission-delay-UL + interarrival-delay-jitter

Tempo di elaborazione delle ritrasmissioni: T5 = feedback-processing-time + rtx-queuing-time

A.2. Obiettivo​

Trovare una stima del tempo di buffering, T(), che un server di streaming deve usare per abilitare un dato numero di ritrasmissioni per ogni pacchetto, N. Questo tempo è approssimativamente uguale sul server e sul client, se si considera che il client inizia a mettere in buffer T1 secondi dopo.

A.3. Soluzione​

Per prima cosa, si trova il valore della stima per 1 ritrasmissione, T(1)=T:

T = T1 + T2 + T3 + T4 + T5

Poiché T1 + T4 ~= RTT,

T = RTT + T2 + T3 + T5

Il caso peggiore per T3 sarebbe assumere che la segnalazione debba attendere un intero intervallo RTCP e che sia applicato il fattore massimo di randomizzazione 1,5. Pertanto, dopo la successiva compensazione per evitare raffiche di traffico (si veda appendice A.7 di RTP [3]), si ha T3 = 1,5/1,21828*RTCP-Interval. Quindi,

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

D'altra parte, RTCP-Interval = avg-rtcp-size*8*(senders + receivers)/(RR+RS). In questo scenario: sender + receivers = 3; RR+RS è la quota di banda receiver report più sender report, in questo caso uguale al default 5% della banda di sessione, bw. Si assume una dimensione media dei pacchetti RTCP, avg-rtcp-size = 120 byte. Quindi:

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

per 1 ritrasmissione.

Per abilitare N ritrasmissioni, il tempo di buffering disponibile in un server o client di streaming è approssimativamente:

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

dove, come sopra,

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

A.4. Numeri​

Se si ignora l'effetto di T2 e T5, cioè si assume che tutte le perdite siano rilevate immediatamente e che non vi sia ritardo aggiuntivo dovuto all'elaborazione del feedback o all'accodamento delle ritrasmissioni, si hanno i seguenti tempi di buffering per diversi valori di N:

RTCP con diversi Generic NACK; dimensione variabile del pacchetto = 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

Per quantificare l'errore di non tenere conto dei Generic NACK, si possono rifare gli stessi numeri, ma ignorando il contributo Generic NACK, avg-rtcp-size ≈ 120 byte. Come si vede sotto, ciò può comportare un errore di stima del buffer di 1–1,5 secondi (5–10%) per valori di banda inferiori e numero maggiore di ritrasmissioni. In questo caso l'effetto è basso. Tuttavia, va valutato con attenzione per lo scenario particolare; per questo la formula lo include.

RTCP senza Generic NACK, dimensione fissa del pacchetto ≈ 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
Ultimo aggiornamento il