I have some questions about the RTCP feedback mechanism used in IPTV.
What do I already know?
1. I know that the RTCP mechanism is used within IPTV to generate sender report (SR) and receiver report (RR) packets with respect to IPTV performance.
2. I know that IPTV StreamWatch uses these SR and RR reports to generate its output. StreamWatch
documentation also claims to be able to keep track of up to 10,000 viewers.
3. I know that each IPTV viewer watches these SR/RR packets in order to change the color of the
performance icon on the lower right hand corner of the program window.
4. I know that within IPTV Content Manager, you can specify whether or not to allow these RTCP RR's to be generated by the IPTV Viewers.
5. I know that beginning in IPTV version 3.4 the IPTV Viewers unicast (vs. multicast) their RR's to the IPTV Server to reduce the amount of router multicast state management. The IPTV server then echos these RR's as multicast packets.
6. I know that a certain percentage of the bandwidth allocated to an IPTV program is reserved for the RTCP traffic. As an example, if you allocate 512Kbs to an MPEG1 program, 470Kbs is used by the audio/video and theoretically the other 42Kbs is available for RTCP. However, I have seen RTCP rates reported in StreamWatch as high 200,000 bps.
>>><<<<
What do I suspect?
Now, Here is what I *suspect* happens as the total number of viewers increases. These suspicions based on observations of real IPTV events where the number of viewers ranges between 1,500 and 2,500 users and RTCP feedback is enabled because the program sponsors want demographic information from SreamWatch.
7. As the total number of viewers increases, the total number of RR's/second increases linearly. So if 10 viewers generate 5 RR's/sec, 100 viewers generate 50 RR's/sec, and so forth. I have observed the RTCP bandwidth usage reported by StreamWatch to be as high 200,000 bps.
8. At some point as the audience increases, we begin to have what the Cisco docs refer to as 'response overload'. The viewers are bombarded with multicast SR/RR packets and they in turn can not keep up with processing of the more important multicast Audio and Video packets...The end result is dropouts -- first in the video stream and then in the audio stream.
9. At some point the many of the individual viewers apparently decide that they are experiencing response overload and they stop sending RR's completely in attempt to recover the audio & video (each viewer apparently assumes that all other viewers do this too...)
10. At some point the BW used by SR/RR greatly exceeds the BW reserved for RTCP and possibly even exceeds the BW used by the Audio and Video.
>>><<<
So, here then are my questions.
1. Which suspicions are correct? If a suspicion is not correct, can you tell me what really happens?
2. Is there any algorithmic behavior in the IPTV product that can be enabled that would result with the response load staying within its reserved BW? For example, the viewers change their RR sending rate up and down (double it, cut it in half, ect...) based on the number of RR's they see... Think about how TCP adjusts its flow rate and you will understand what I mean...
3. Is there anything configurable in IPTV that I am not aware of, that will allow me to use RTCP &
StreamWatch successfully with these larger audiences?
