Annexe A. Comment contrôler le nombre de retransmissions par paquet
Déterminer le nombre de retransmissions (rtx) par paquet pour obtenir la meilleure transmission possible est une tâche difficile. Bien entendu, le minimum absolu devrait être un (1) ; sinon, n'utilisez pas ce format de charge utile. De plus, à la date de publication, les auteurs n'avaient connaissance d'aucune étude sur le nombre de retransmissions par paquet à utiliser pour de meilleures performances. Pour aider les implémenteurs et les chercheurs sur ce point, la présente section décrit une estimation du temps de mise en mémoire tampon nécessaire pour permettre un nombre donné de retransmissions. Une fois ce temps calculé, il peut être communiqué au client via le paramètre SDP « rtx-time », tel que défini dans le présent document.
A.1. Scénario et hypothèses
-
Scénario de streaming aux contraintes de délai assouplies. Le client et le serveur disposent d'un espace de mise en mémoire tampon comme indiqué par le paramètre « rtx-time » dans SDP.
-
Profil RTP AVPF utilisé avec le schéma de retransmission multiplexé par SSRC : 1 SSRC pour les paquets d'origine, 1 pour les paquets de retransmission.
-
Part de bande passante RTCP par défaut pour les SR et RR, c'est-à-dire SR+RR = 0,05. Nous avons des émetteurs (2) et des récepteurs (1). Les récepteurs et les émetteurs reçoivent chacun un tiers de la part de bande passante RTCP car la proportion d'émetteurs est supérieure au quart des membres de session.
-
avg-rtcp-size est approximé par 120 octets. Il s'agit d'une moyenne arrondie vers le haut de 2 SR, un pour chaque SSRC, contenant 40/8/28/32 octets pour IPv6/UDP/SR/SDES avec CNAME, soit 105 octets chacun ; et un RR avec 40/8/64/32 octets pour IPv6/UDP/2*RR/SDES, soit 157 octets. Comme les émetteurs et les récepteurs partagent la bande passante RTCP à parts égales, alors avg-rtcp-size = (157+105+105)/3 = 117,3 ≈ 120 octets. La caractéristique importante de cette valeur est qu'elle est légèrement supérieure à 100 octets, ce qui semble représentatif pour des configurations typiques.
-
Le profil utilisé est AVPF [1] et des NACK génériques sont utilisés pour demander les retransmissions. Cela ajoute 16 octets de surdébit pour 1 NACK et 4 octets de plus pour chaque champ d'information de contrôle de retour NACK (FCI) supplémentaire.
-
Nous supposons un scénario du pire cas dans lequel chaque paquet épuise son nombre correspondant de retransmissions disponibles, N, avant d'être reçu. Cela signifie que si un paquet est demandé en retransmission au plus 2 fois, le bloc de rapport NACK générique demandant ce paquet particulier est envoyé dans deux composés RTCP consécutifs ; de même, s'il est demandé 10 fois en retransmission, alors le NACK générique est envoyé 10 fois. Cette hypothèse rend la taille du paquet RTCP approximativement constante après N*intervalles RTCP (secondes), à savoir avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N). Dans notre cas, la part de bande passante RTCP du récepteur est 1/3 ; ainsi, avg-rtcp-size = 124 + 4*N/3.
-
Deux paramètres de délai sont difficiles à approximer et peuvent dépendre de l'implémentation. Nous les listons donc explicitement ici sans leur assigner de valeur particulière : l'un est le temps de détection de perte de paquet (T2), l'autre est le temps de traitement du retour et de mise en file d'attente pour les retransmissions (T5). Les implémentateurs doivent assigner des valeurs appropriées à ces deux paramètres.
Graphiquement, nous avons ce qui suit :
Sender
+-+---------------------------------^-----\-----------------
\ \ / \
\ \ | |
SN=0 \ \ SN=1 / \ RTX(SN=0)
\ \ / \
X \ / \
`. / \
\ / \
\ | |
\ / \ ......
\ / \
-------------V----D--------/-----------------------V--------
T1 T2 T3 T4 T5 T1 ........
Receiver
Légende :
- DL : liaison descendante (client→serveur)
- UL : liaison montante (serveur→client)
- L'unité de temps est la seconde, s.
- L'unité de débit est le bit par seconde, bps.
Temps de transmission DL : T1 = physical-delay-DL + tx-delay-DL (=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
Temps pour détecter une perte de paquet : T2 = pkt-loss-detect-time
Temps pour signaler une perte de paquet : T3 = time-to-next-rtcp-report
Temps de transmission UL : T4 = physical-delay-UL + transmission-delay-UL + interarrival-delay-jitter
Temps de traitement des retransmissions : T5 = feedback-processing-time + rtx-queuing-time
A.2. Objectif
Trouver une estimation du temps de mise en mémoire tampon, T(), qu'un serveur de streaming doit utiliser pour permettre un nombre donné de retransmissions pour chaque paquet, N. Ce temps est approximativement égal au serveur et au client, si l'on considère que le client commence à mettre en mémoire tampon T1 secondes plus tard.
A.3. Solution
D'abord, nous trouvons la valeur de l'estimation pour 1 retransmission, T(1)=T :
T = T1 + T2 + T3 + T4 + T5
Comme T1 + T4 ~= RTT,
T = RTT + T2 + T3 + T5
Le pire cas pour T3 serait de supposer que le signalement doit attendre tout un intervalle RTCP et que le facteur maximal de randomisation 1,5 est appliqué. Par conséquent, après application de la compensation subséquente pour éviter les rafales de trafic (voir l'annexe A.7 de RTP [3]), nous avons T3 = 1,5/1,21828*RTCP-Interval. Ainsi,
T = RTT + 1.2312*RTCP-Interval + T2 + T5
D'autre part, RTCP-Interval = avg-rtcp-size*8*(senders + receivers)/(RR+RS). Dans ce scénario : senders + receivers = 3 ; RR+RS est la part de bande passante rapport récepteur plus rapport émetteur, dans ce cas, égale par défaut à 5 % de la bande passante de session, bw. Nous supposons une taille moyenne de paquet RTCP, avg-rtcp-size = 120 octets. Ainsi :
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
pour 1 retransmission.
Pour permettre N retransmissions, le temps de mise en mémoire tampon disponible dans un serveur ou client de streaming est approximativement :
T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5)
où, comme ci-dessus,
avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N)
= 120 + (1/3)*(12 + 4*N)
= 124 + 4*N/3.
A.4. Chiffres
Si nous ignorons l'effet de T2 et de T5, c'est-à-dire si nous supposons que toutes les pertes sont détectées immédiatement et qu'il n'y a pas de délai supplémentaire dû au traitement du retour ou à la mise en file des retransmissions, nous avons les temps de mise en mémoire tampon suivants pour différentes valeurs de N :
RTCP avec plusieurs NACK génériques ; taille de paquet variable = 124 + 4*N/3 octets
|============|=====|======================================|
| 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
Pour quantifier l'erreur due au fait de ne pas prendre en compte les NACK génériques, nous pouvons refaire les mêmes chiffres, mais en ignorant la contribution des NACK génériques, avg-rtcp-size ≈ 120 octets. Comme on le voit ci-dessous, cela peut entraîner une erreur d'estimation de mémoire tampon de 1 à 1,5 secondes (5 à 10 %) pour les débits plus faibles et un nombre de retransmissions plus élevé. Cet effet est faible dans ce cas. Néanmoins, il doit être soigneusement évalué pour le scénario particulier ; c'est pourquoi la formule l'inclut.
RTCP sans NACK générique, taille de paquet fixe ≈ 120 octets
|============|=====|======================================|
| 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