3.6. Considérations sur la taille du groupe (Considerations on the Group Size)
Cette section donne des indications sur les tailles de groupe auxquelles les différents modes de feedback peuvent être utilisés.
3.6.1. Mode ACK
La session RTP MUST compter exactement deux membres et cette taille MUST NOT croître : communications point à point. Les adresses unicast SHOULD être utilisées dans la description de session.
Pour une communication unidirectionnelle ou bidirectionnelle entre deux parties, 2,5 % de la bande passante de la session RTP sont disponibles pour le trafic RTCP des récepteurs, feedback inclus. Pour un flux à 64 kbit/s, cela donne 1 600 bit/s pour le RTCP. Avec une moyenne de 96 octets (=768 bits) par paquet RTCP, un récepteur peut signaler 2 événements par seconde à l'émetteur. Si dix acquittements sont regroupés par message FB, 20 événements par seconde peuvent être acquittés. À 256 kbit/s, 8 événements par seconde pourraient être signalés ; les ACK peuvent donc être plus fins (par ex. trois ACK par message FB).
Les stratégies ACK MUST être définies pour fonctionner correctement avec ces limites de bande passante. Une indication sur l'autorisation des ACK et, le cas échéant, la stratégie à utiliser, MAY être fournie hors bande, par ex. via des attributs spécifiques au média dans une description SDP.
3.6.2. Mode NACK
Les acquittements négatifs (et autres feedbacks à caractéristiques similaires) MUST être utilisés pour toute session dont la taille de groupe peut dépasser deux. Les NACK MAY aussi être utilisés en point à point.
L'usage de paquets RTCP anticipés dépend de nombreux paramètres : bande passante, codec, type de feedback, nombre d'émetteurs et de récepteurs.
Les paramètres clés pour le mode de fonctionnement sont l'intervalle minimal autorisé entre deux paquets RTCP composés (T_rr) et le nombre moyen d'événements à signaler par intervalle de temps (plus leur distribution). L'intervalle minimal se déduit de la bande passante RTCP disponible et de la taille moyenne attendue d'un paquet RTCP. Le nombre d'événements (par ex. par seconde) peut se déduire du taux de perte et du débit d'émission. À partir de ces deux valeurs, on calcule la taille de groupe admissible pour le mode Immediate Feedback.
Comme indiqué en section 3.3 :
Soit N le nombre moyen d'événements à signaler par intervalle T par un récepteur, B la fraction de bande passante RTCP pour ce récepteur et R la taille moyenne d'un paquet RTCP ; le récepteur est en mode Immediate Feedback tant que N<=B*T/R.
La borne supérieure pour le mode Early RTCP dépend alors uniquement de la dégradation de qualité acceptable, c'est-à-dire du nombre d'événements non signalés par intervalle.
Comme indiqué en section 3.3 :
Avec les notations ci-dessus, le mode Early RTCP se caractérise grossièrement par N > B*T/R comme « borne inférieure ». Une estimation de borne supérieure est plus difficile. Avec N=1, on obtient pour R et B donnés T = R/B comme intervalle moyen entre événements à signaler, ce qui sert d'indication sur l'utilité d'une transmission anticipée.
Exemple : une vidéo 256 kbit/s à 30 ips sur un réseau avec MTU d'environ 1 500 octets : souvent une image par paquet, soit 30 paquets/s. Avec 5 % de perte (uniforme, indépendance entre récepteurs), chaque récepteur signale en moyenne 3 paquets perdus toutes les deux secondes. Un seul émetteur et plus de trois récepteurs donnent 3,75 % de bande passante RTCP aux récepteurs, soit 9,6 kbit/s. Avec 120 octets en moyenne par paquet RTCP composé, 10 paquets/s ou 20 sur deux secondes. Si chaque récepteur doit signaler trois pertes sur deux secondes, la taille maximale du groupe est de 6 à 7 récepteurs si toutes les pertes sont signalées. Les règles d'envoi des paquets RTCP anticipés doivent offrir assez de flexibilité pour un signalement opportun.
Pour estimer la borne supérieure du mode Early RTCP : supposons schéma de codage et application (et utilisateurs tolérants) acceptant environ une perte sans réparation sur deux secondes. Le nombre de paquets à signaler par récepteur passe à deux sur deux secondes et la taille du groupe à 10. Des pertes corrélées réduisent encore le trafic de feedback ; des tailles d'environ 12 à 16 (voire 20) peuvent être raisonnablement supportées en mode Early RTCP. Ces raisonnements sont statistiques et peuvent échouer dans certains cas.