3.6. Considerazioni sulla dimensione del gruppo (Considerations on the Group Size)
Questa sezione fornisce linee guida sulle dimensioni di gruppo in cui i vari modi di feedback possono essere usati.
3.6.1. Modalità ACK
La sessione RTP MUST avere esattamente due membri e la dimensione del gruppo MUST NOT crescere: MUST essere comunicazione punto-punto. Negli indirizzi di sessione SHOULD usare indirizzi unicast.
Per comunicazione unidirezionale o bidirezionale tra due parti, il 2,5% della banda della sessione RTP è disponibile per il traffico RTCP dai ricevitori incluso il feedback. A 64 kbit/s si ottengono 1.600 bit/s per RTCP. Con una media di 96 byte (=768 bit) per pacchetto RTCP, un ricevitore può segnalare 2 eventi al secondo. Se dieci ACK sono raggruppati per messaggio FB, 20 eventi al secondo possono essere confermati. A 256 kbit/s si possono segnalare 8 eventi/s; gli ACK possono essere più fini (es. tre ACK per FB).
Le strategie ACK MUST essere definite per rispettare questi limiti di banda. Un'indicazione se gli ACK sono ammessi e quale strategia usare MAY essere veicolata fuori banda (es. attributi SDP specifici del media).
3.6.2. Modalità NACK
Gli acknowledgments negativi (e altri feedback con caratteristiche simili) MUST essere usati per tutte le sessioni la cui dimensione può superare due. I NACK MAY essere usati anche punto-punto.
L'uso di RTCP anticipati dipende da banda, codec, tipo di feedback, numero di mittenti e ricevitori.
Parametri chiave: intervallo minimo tra due RTCP composti (T_rr) e numero medio di eventi da segnalare per intervallo (e distribuzione nel tempo). L'intervallo minimo deriva dalla banda RTCP e dalla dimensione media attesa del pacchetto RTCP. Il numero di eventi (es. al secondo) da perdita e tasso di invio. Da questi due valori si ricava la dimensione di gruppo ammissibile per Immediate Feedback.
Come nella sezione 3.3:
Sia N la media di eventi da segnalare per intervallo T da un ricevitore, B la frazione di banda RTCP per quel ricevitore, R la dimensione media del pacchetto RTCP; il ricevitore opera in Immediate Feedback finché N<=B*T/R.
Il limite superiore per Early RTCP dipende solo dalla degradazione di qualità accettabile (quanti eventi possono restare non segnalati).
Come nella sezione 3.3:
Con le stesse notazioni, Early RTCP si caratterizza grossolanamente con N > B*T/R come «limite inferiore». Una stima del limite superiore è più difficile. Con N=1, per R e B dati, T = R/B è l'intervallo medio tra eventi da segnalare, utile come indicazione sull'utilità della trasmissione anticipata.
Esempio: video 256 kbit/s a 30 fps, MTU ~1500 byte, spesso un frame per pacchetto → 30 pacchetti/s. Con 5% di perdita uniforme e ricevitori indipendenti, ogni ricevitore segnala in media 3 pacchetti persi ogni due secondi. Un solo mittente e più di tre ricevitori → 3,75% di banda RTCP ai ricevitori, 9,6 kbit/s. Con 120 byte medi per RTCP composto → 10 pacchetti/s o 20 in due secondi. Se ogni ricevitore deve segnalare tre perdite ogni due secondi, dimensione massima di gruppo 6–7 se tutte le perdite sono segnalate. Le regole per RTCP anticipato dovrebbero consentire segnalazioni tempestive.
Estendendo l'esempio al limite superiore Early RTCP: se schema di codifica e utenti tollerano circa una perdita senza riparazione ogni due secondi, le segnalazioni scendono a due ogni due secondi e il gruppo sale a 10. Con perdite correlate, il traffico di feedback si riduce ulteriormente; gruppi di circa 12–16 (forse 20) possono essere supportati in Early RTCP. Tutte queste considerazioni sono statistiche e possono fallire in alcuni casi.