Hi,
I have two questions/comments mostly regarding the RTCP-SSM draft (http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18). The background of my questions is the use case of "broadcast channels" in an IPTV context, where the channels are distributed over IP multicast (SSM). In this context, the concept of feedback target(s) is obviously very useful, and actually necessary given today's restrictions with multicast in upstream in the "WAN".
For the IPTV use case, it also makes sense to have multiple feedback targets, each responsible for a subset of RTP receivers, because of the large number of RTP receivers involved (100.000s is possible). The way to signal this by means of SDP is that each local subset of RTP receivers sees a different IP address in the "a=rtcp: "portnumber" IN IP4 "IP address" line. So, multiple "localised" FT is covered by the draft IMO.
However, in that case, the maximum bandwidth that can be used for RTCP reporting by RTP receivers only needs to be determined by the size of the local group of RTP receivers (sending RTCP to the same localised Feedback Target), especially in the summary FB model. But in my interpretation of the architecture, the actual RTCP bandwith limit information can only be retrieved by the RTP receivers from the information sent by the distribution source in the ssm session. Either by refected RTCP reports from RTP receivers (not a feasible solution for the given use case) or from a RSI message -in the summary FB model- indicating the session size or explicitly the RTCP reporting bandwidth limit. The fact is that this information is sent to ALL RTP receivers, which may be reporting to different Feedback targets where each Feedback target is collecting RTCP messages from a different number of RTP receivers, and hence may have different "requirements" for total RTCP reporting bandwidth limit. My question is whether local Feedback targets have been considered with respect to this issue?
My second question again has to do with multiple feedback targets for the same use case.
In the IPTV use case for rtcpssm, Feedback Targets can also be used as retransmission sources (RFC 4588) and in http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03, the feedback target architecture is used to allow fast acquisition of SSM RTP sessions. The draft proposes that a "burst source" is co-located with the FT which transmits unicast data (starting with a random access point of the video channel) from a cache that holds the most recent data distributed over the RTP SSM. It does transmit the RTP packets at an accelerated speed, allowing the RTP receiver to join the SSM after some time.
The idea I would like to bring forward is to allow separate Feedback Targets for the same RTP receiver (population): one Feedback target acts as RTP retransmission server (see http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03) and collects RTCP FB messages, while the other Feedback Target is solely "responsible" for the non RTCP-FB messages, such as RTCP XR messages. I realise this idea is not necessarily linked with the rtcp-ssm draft, but IMO only for a massive scale application that makes use of RTP and leverages rtcp ssm such a separation is justified. The possibility for separation of the monitoring service –associated with a server function basically responsible for collecting RTCP receiver reports for the purpose of monitoring- and the retransmission service requiring a server function that is responsible for processing and responding to RTCP FB messages, is driven from the point of view of server function optimisation (different requirements on the server platform).
In terms of signaling two Feedback Targets, we could make use of the following lines:
a=rtcp:40001 IN IP4 192.0.2.1 (This is for retransmission)
a=rtcp-fb:96 nack
a=rtcp:40001 IN IP4 192.0.2.2 (This is for XR collection)
However, that is probably quite ambiguous..?
Furthermore I also realise such a solution introduces other questions than just signaling syntax including the fact that we may need guiding rules on how RTCP reports are issued by the RTP receiver with two RTCP targets in place, as in the example above. The new RFC 5506 is certainly helpful here, but this is probably not sufficient.
Comments appreciated on this idea.
Kind regards,
Tom Van Caenegem