Internet Engineering Task Force AVT WG Internet Draft Julian Chesterfield draft-chesterfield-avt-rtcpssm-01.txt AT&T Internet Research Joerg Ott Tellique Kommunikationstechnik GmbH July 19, 2001 Expires: January, 2002 RTCP Extension for Single Source Multicast Sessions with Unicast RTCP feedback Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a modification to the Real-time Transport Control Protocol to enable the operation of RTP/RTCP with unicast RTCP feedback in Single Source multicast sessions such as Source Specific Multicast (SSM) Communication where the traditional model of Any Source Multicast (ASM) group communication of many to many is not possible and for any group communication which might benefit from a sender controlled summarised reporting mechanism. This specification extends [1], section 6 which defines the RTP session group control channel. 1. Conventions and Acronyms The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119. Chesterfield, Ott [Page 1] Internet Draft RTCP with Unicast Feedback July, 2001 2. Introduction RTP [1] provides a real-time transport mechanism suitable for unicast or Internet Standard Multicast communication between multimedia applications. Typical uses are for real-time or near real-time group communication via audio and video data streams. An important component of the RTP protocol is the communication channel, defined as the Real-Time Control Protocol (RTCP). RTCP involves the periodic transmission of control packets between group members in a session, enabling the distribution or calculation of session specific information such as packet loss, and round trip time calculation to other hosts. An additional advantage of providing a control channel for a session is that a third-party session monitor can listen to the traffic and establish network conditions and diagnose faults based on receiver locations. RTP was designed to operate in a unicast mode or in the traditional mode of Any Source Multicast (ASM) Group communication which encompasses a network which supports both one to many and many to many communication via a common group address in the range 224.0.0.0 through 239.255.255.255. Typical routing protocols that enable such communication are Distance Vector Multicast Routing Protocol (DVMRP) [2] or Protocol Independent Multicast (PIM) [3][4] Sparse/Dense Mode in combination with an Inter-domain routing protocol such as Multicast Border Gateway Protocol (MBGP) [5] with Multicast Source Discovery (MSDP) [6]. Such routing protocols enable a host to join a single Multicast group address and send to or receive traffic from all members in the group with no prior knowledge of membership. In order to enable such a service in the network, however there is a great deal of complexity involved at the routing level. The Source Specific Multicast (SSM) [7] Model has the advantage of removing a great deal of the routing complexity involved in multicast group creation and source information distribution. The disadvantage of SSM with respect to Real-time traffic using RTP is that the simplification to the routing protocols removes the ability for any member of the group to communicate with any other member of the group without an explicit SSM (Source, Group) or unicast join to that host. The solution proposed in this draft defines a new method for distributing control information amongst all members in a multicast session and is designed to operate under any multicast group communication scenario. It is, however, of particular benefit to SSM sessions in the absence of receivers being able to communicate with each other. The RTP data stream protocol itself is unaffected. Chesterfield, Ott [Page 2] Internet Draft RTCP with Unicast Feedback July, 2001 The basic architectural models to which this feedback method could apply are: a) SSM groups with a single sender. This is the main motivation behind the unicast RTCP feedback mechanism and allows SSM groups which do not have many to many communication capability, traditionally available in ASM multicast groups to still receive RTP data streams and operate on them in the usual manner. SSM adopts the notion of a sender data channel which provides a one to many communication facility from the source to all the receivers in the group. The feedback is unicast to the source on the standard RTCP port. b) One to many broadcast networks such as satellite communication typically using a terrestrial link low bandwidth return channel or a broadband cable link. This architecture differs very little from the SSM channel concept, but most likely will require a translator of some kind to render the RTP data stream onto the satellite or cable distribution channel. c) ASM with a single sender. An SDP session announcement type identifies a session as having a single sender receiving unicast RTCP feedback. Receivers join the multicast group address and receive RTP and RTCP data on the specified address/port combinations. The RTCP feedback is directed to the source on the RTCP port. This model is not considered to be more efficient than a standard multicast group RTP communication scenario, and is therefore not recommended to replace the traditional mechanism. It may, however be useful for certain applications which have different feedback requirements. SSM sessions are typically assigned a value in the group address range 232.0.0.0 through 232.255.255.255, although this is not a requirement. A session may be assigned any valid multicast address, as long as the local network is configured to allow source specific joins outside the suggested SSM range. In order for a host to receive traffic from an SSM capable source, it must support the IGMPv3 multicast group membership reporting protocol which enables the host to explicitly request traffic from a source,group pair. In this case, the host is aware of the significance of the address range and is therefore capable of identifying the unicast RTCP feedback session requirements based on this knowledge. For sessions which take advantage of the unicast feedback model but do not inherently need to use it, it is anticipated that an SDP syntax will be defined. The modifications proposed in this document are intended to provide an optional replacement to the method of RTCP operation for sessions which either require or may benefit from a new reporting structure. For certain distribution networks, such as SSM networks, this may be a requirement, however in other cases this is an optional feature which may be used. 3. Basic Operation This draft proposes two methods for enabling receiver feedback to all members in a session. Each involves the unicasting of RTCP packets to a source, whose job it is to distribute the information to the members of the group. The source must always be able to communicate with all the other members. The responsibility for maintaining the operation of RTCP to the receivers is on the source. Chesterfield, Ott [Page 3] Internet Draft RTCP with Unicast Feedback July, 2001 The first method is a basic mechanism whereby all receiver reports are unicast to the source and subsequently forwarded to all members. The advantage of this method is that apart from modifying the destination address for feedback reports, a receiver implementation remains unchanged from the original RTP specification in order for the protocol to operate. This method has the advantage of being backwards compatible with RTP/RTCP implementations which do not support unicast feedback to the source and operate using the standard multicast group communication model. For a session that is using ASM, the Receiver Reports will be multicast on the multicast group/port+1 which should still be received by all the receivers since they are listening for any traffic on that port. For sessions that are using an SSM channel, the network should prevent any data being distributed to the whole group, assuming the receiver is able to receive the SSM data stream anyway. This should not harm any existing implementations, but will prevent the source from receiving an accurate picture of the receiver group. SSM provides the greatest benefit to large group sessions with only one sender, such as internet radio stations or traditional broadcast television style applications, since the network complexity is greatly simplified and larger numbers of receivers do not add any substantial state to the network in order to maintain connectivity. As the size of the group increases, however receivers gain less benefit from receiving all the reports from all the members in a session detailing the quality of service and timing information which is directed to the source. A second method, therefore is defined in section 7 which provides a facility for the source to summarize multiple receiver reports and distributes the information as average values in a Receiver Summary Information (RSI) packet. This helps to conserve network bandwidth by reducing the amount of data distributed to all the receivers. 4. Definitions Distribution Source: In order for unicast feedback to work, there can only be one session distribution source for any subset of receivers to which RTCP feedback is directed. Heterogeneous networks such as ASM multiple sender groups, unicast only clients and SSM single sender/receiver groups can be connected via translators or mixers (see section 9 for details on this), but for unicast feedback to occur within single source groups there can only be one distribution source. Unicast RTCP Feedback: For a session defined as having a distribution source A, on ports n and n+1, the unicast feedback identifier is the IP address of Source A on port n+1. Chesterfield, Ott [Page 4] Internet Draft RTCP with Unicast Feedback July, 2001 5. Packet types and host feedback mechanism As in the original specification, the main rtp data stream is carried on an even port number. For unicast RTCP feedback, the RTCP control channel used by the source is also carried on the same address but on the next higher (odd) port number. The RTCP packet types defined in [1] are: abbrev. name value SR sender report 200 RR receiver report 201 SDES source description 202 BYE goodbye 203 APP application-defined 204 The modifications to these are described in the following sections. 6. Simple feedback model 6.1 Distribution Source behaviour This is a simple packet reflection mechanism. It is the default behaviour for any distribution source and is the minimum requirement for acting as a source to a group of receivers using unicast RTCP feedback. For any operations that involve more complexity such as translator/mixer functionality, the ability to understand the RSI packet format is required. This model remains mostly similar to the original specification. The differences for each packet type are discussed below: SR: Sender report, for transmission and reception statistics from the source. The core functionality remains unchanged, and even though there is likely to only be one source in the session, the sender may only stack additional RTCP blocks that correspond to it's own SSRC. Chesterfield, Ott [Page 5] Internet Draft RTCP with Unicast Feedback July, 2001 RR: Receiver reports are for reception statistics from participants that are not active senders, these packets are generated by any members of a session. For an SSM session, RRs will typically be sent only for one sender, however with the addition of network gateways such as mixers and translators, receivers must be prepared to respond to unlimited numbers of sources. Under these circumstances, the responding mechanism remains the same, all reports are unicast to the distribution source. SDES: Source description packet. This packet type is issued by sources in a session, typically both by receivers and senders. The standard rules for chaining SDES information with SR or RR packets still applies. BYE: Indicates end of participation in the session by an SSRC. The usual behaviour applies. APP: Application specific functions, this packet type remains unchanged and should be specified on an individual application basis. The default operation of the distribution source is to forward any APP packets in their original format. 7. Sender feedback summary model Since there is typically expected to be fewer sources in a unicast feedback style session, the simple feedback model, while maintaining the correct operation of RTCP, results in a substantial amount of redundancy of data and unnecessary group information in cases where the ratio of senders to receivers becomes very large. For this purpose, a Sender Feedback summary model is proposed. A new packet type called a Receiver Summary Information packet (RSI) which provides aggregated information on Receiver Reports is introduced. The format is discussed in the following section. The RSI packet is assigned the Payload value 205. 7.1 RSI Packet Format Chesterfield, Ott [Page 6] Internet Draft RTCP with Unicast Feedback July, 2001 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| SC | PT=RI=TBA | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | group size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reporting group size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |GSD| DP| distrib1 | DP| distrib2 | Receiver RTCP Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | collision SSRC #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | The RSI packet consists of one report block modeled along the same lines as a receiver report. The first 4 bytes of header extension follow the standard RTP header outline. This ensures backwards compatibility with older versions which may not understand the RSI packet format but can read the length field indicating the end of the report block. The following fields are included: The fields "V", "P", and "length" have the same meaning as per [1]. sc: 5 bits The number of collision SSRC entries towards the end of the report block. SSRC: 32 bits The synchronisation source identifier for the originator of the summary report packet. group size: 32 bits This field provides the sender's view of the number of receivers in a session. This should include the sender itself and any other senders potentially connected to the session e.g. via a mixer/translator gateway. The group size is calculated according to the rules outlined in [1]. reporting group size: 32 bits a field to indicate the number of group members to which this report corresponds. fraction lost: 8 bits The average fraction lost indicated by receiver reports forwarded to this source, expressed as a fixed point number with the binary point at the left edge of the field. cumulative number of packets lost: 24 bits Highest cumulative number of packets lost since the last RSI as reported in an RTCP RR by any of the receivers. Chesterfield, Ott [Page 7] Internet Draft RTCP with Unicast Feedback July, 2001 interarrival jitter: 32 bits Highest interarrival jitter since the last RSI as reported in an RTCP RR by any of the receivers. group size dynamics: 2 bits This field is used to indicate the current trend in the group size over the last 1/4 of time since the last RTCP RSI. The following values are defined for the GSD field: GSD | Meaning -----+---------------------------------------------- 00 | No (significant) change in the group size 01 | Group size increases 10 | Group size decreases 11 | reserved dp: 2 bits This field indicates the relevance of the corresponding distribution value. DP | Meaning of Corresponding distribution bits 5-0 -----+---------------------------------------------- 00 | indicates precise value; yields 0-63 01 | indicates (value+1) * 16; yields 16-1024 10 | indicates (value+1) * 256; yields 256-16K 11 | indicates percentage distribution1: 6 bits This field indicates the number or fraction of receivers that are in a 10% percentile of the worst relative packet loss value reported. The relevance of the value is indicated by the preceding dp field [see table above]. distribution2: 6 bits This field indicates the number or fraction of receivers that are in a 10% percentile of the worst relative packet jitter value reported. The relevance of the value is indicated by the preceding dp field [see table above]. receiver bandwidth: 14 bits indicates the maximum bandwidth allocated to any single receiver for sending RTCP data relating to the session. This is a fraction value indicating a percentage of the session bandwidth, expressed as a fixed point number with the binary point at the left edge of the field. collision SSRC: n x 32 bits the final fields in the packet are used to identify any SSRCs which are duplicated within the group. Usually this is handled by the hosts upon detection of the same SSRC, however since receivers no longer have a global view of the session, the collision algorithm is handled by the source. SSRCs which collide are listed in the packet and it is the responsibility of the receiver to detect the collision and select another ID. Chesterfield, Ott [Page 8] Internet Draft RTCP with Unicast Feedback July, 2001 8. Session Client Behaviour 8.1 Senders The simple feedback model requires the sender to forward Receiver Reports that are unicast by the receivers individually as they arrive. The sender may not chain report blocks from different receivers into the same packet, but should forward the packets in their entirety, including the SDES information and any additional report blocks. The summary mode requires the sender to calculate summary values over the internal tables. The sender must ensure that eventually every summary report covers values from all known receivers, even in the event that the stored values are old, in order to avoid oscillations. If using the summary mode, it is important to ensure that all members in a session understand the summarised packet format. In an SSM session, if a receiver is unable to unicast feedback to the source, and instead attempts to multicast data on the address/port combination, the network should prevent the data from ever reaching any other members of the group. If the sender detects a member of the group that is sending at a higher rate than indicated by the summary packet information, suggesting that a client does not understand the RSI payload type, the response of the sender SHOULD be to revert to simple RTCP packet feedback. It is unlikely that a situation where a sender in an SSM session which is not acting as a gateway detects another sender within the SSM distribution network. In the event that it occurs, the sender should be ignored, since it is unknown how many receivers in the session will also receive the traffic from this other source. It is quite feasible for additional senders to join an ASM session with unicast feedback. Under these circumstances, a sender should respond as usual by providing receiver feedback to the new source on the standard RTCP channel. The new source should receive the RTCP feedback channel data as usual, so will also have knowledge of the group size and can calculate the RTCP scaling properties accordingly. In order to switch between simple packet forwarding and summary reporting via RSI packets, the sender has the option of gradually introducing the summary reporting by selecting subsets of the receiver report group or by switching directly to the summary scheme at some convenient point in the session and reporting on all the receivers. Note: The first method could be achieved by dividing the address space/SSRC distribution or more heuristically such as via grouping report packets into average ranges of values. Another option might be to group reports via receiver addresses, if the source had some knowledge of network configuration or address allocation. It should be noted that the grouping method for generating the average values can adversely affect the results provided for average receiver loss and jitter. It is therefore recommended that as the number of members in a group increases to substantial levels, the sender should begin to generate moving averages of the receiver quality reports. This applies also to the generation of distribution indicators. Chesterfield, Ott [Page 9] Internet Draft RTCP with Unicast Feedback July, 2001 8.2 Receivers Receivers should always be aware that in any distribution network scenario, there is the potential for a source to be a gateway, bridging the network to a multiple sender/receiver group communication architecture. Receivers should respond in the usual manner to the detection of sources in the group but should always maintain the unicast feedback of RTCP mode to the distribution source identified at the start of the session. The calculation of the transmission interval for RTCP data is based upon the standard algorithm. The value for the group size is derived from the RSI packet, or from the individual calculation of the group size, whichever value is larger, based upon the receipt of receivers reports. The receivers SHOULD concatenate RRs for different senders in the usual manner since this provides some savings in header overhead. If a sender begins to gradually introduce RSI packets, the receiver should assume that the group size value calculated by the source is likely to be the most accurate estimation based on the sender's global view of the session. The receiver should calculate it's bandwidth allowance using the standard algorithm specified in the RTP specification, and based upon it's perception of the number of receivers and senders in the session. Between the RSI receiver bandwidth value and the receiver calculated value, the receiver should choose the lowest value and apply that as the maximum bandwidth value. This provides the sender with some level of control over how much receiver report traffic it can handle. It is essential that a receiver does not generate any RTCP feedback until it has received at least one control packet from the distribution source using the address identified in either the SSM sender,group mapping or the SDP session announcement. This helps to combat the potential threat of packet bombing to an unsuspecting source via a fake session announcement. This does not totally eliminate the threat, and it is recommended that a sender should at least echo the first receiver report generated by each receiver using the simple feedback mechanism to provide some stronger assurance to the receiver that the host identified in the session announcement is the distribution source of the session. In a similar way, the issue of avoiding receiver startup implosion needs to be deployed as outlined in the RTP specification. This should allow the receivers time to discover the group size gradually in the event that a large number of clients join a session at the same time. The source also has some control over how this is managed via the receiver bandwidth field in the RSI packet, although it is not a requirement that RSI packets are distributed at the beginning of a session. Chesterfield, Ott [Page 10] Internet Draft RTCP with Unicast Feedback July, 2001 9. Mixer/Translator issues The original RTP specification allows for the use of mixers and translators in an RTP session which help to connect heterogeneous networks into one session. There are a number of issues, however which are raised by the unicast feedback model proposed in this document. The functionality of an RTP translator and a mixer is not always distinct and sometimes features of both may be introduced in one application, however the issues outlined here apply to either. For this reason they are referred to here generically as a gateway. A gateway between distribution networks in a session must ensure that all members in the session receive all the relevant traffic to enable the usual operation by the clients. A typical use may be to connect an older implementation of an RTP client with an SSM distribution network, where the client is not capable of unicasting feedback to the source. In this instance the gateway must join the session on behalf of the client and send and receive traffic from the session to the client. Certain hybrid scenarios may have different requirements. The following sections attempt to address some of the issues which may arise: 9.1 Example Uses of a gateway a) A translator acts as a gateway between an ASM multicast group and an SSM receiver only group. Under this scenario, it is quite feasible that there may be multiple senders in the ASM group, although it is assumed that the receivers in the SSM group are unable to send RTP data traffic. It is the responsibility of the gateway to ensure that all members of the ASM group receive all the feedback from the SSM receivers, and that the RTP and RTCP data from the ASM senders is forwarded to the SSM channel. In order to do this, in it's simplest form, the translator can forward all traffic on the opposite interface to which it was received, in this case the unicast receiver reports are multicast to the ASM group on the standard address/port pair. b) A translator acts as a gateway between a multiple unicast to SSM receiver only group. The unicast connected hosts may be either just receivers or senders and receivers in the session. Under these circumstances, the gateway has some options. It can either replicate data in it's simplest form, as it receives unicast RTCP feedback from the SSM group, it forwards it on all unicast interfaces. If the senders in the session are capable of handling unicast feedback and sending out summarised receiver feedback information, the gateway can take advantage of this capability and forward the summarised packet information to the SSM group. If this capability is not available, it is the responsibility of the gateway to reflect the Receiver Chesterfield, Ott [Page 11] Internet Draft RTCP with Unicast Feedback July, 2001 report information back to the SSM RTCP channel. The gateway also has the option of reading the RTP level information, and storing an SSRC to IP address mapping in order to do transport level demultiplexing. However, since receivers are permitted to chain reports for different senders into one packet, the translator MUST either take the relevant report blocks for each sender (e.g. SDES + RR) and forward them in a packet destined for that source, or forward the same packet to all the relevant sources. The gateway MUST NOT chain report blocks from different receivers into the same packet. This method provides some saving on replicating all data in it's basic form to all the other interfaces, however it is still the responsibility of the gateway to ensure that the RTCP information is forwarded in some form to all the clients. If the gateway has a 'receiver only' client joined via a unicast connection to the session, it has no accurate way of distinguishing the capability of that client, and cannot therefore ascertain whether the client understands the summarised packet format. The behaviour of the gateway must therefore be to forward all RTCP data in it's original format even if there is summarised information available. c) A translator acts as a receiver in an SSM session and connects either an ASM group, another SSM group of receivers or 'unicast only' clients. This situation poses a more complex scenario for the gateway. It is feasible that the gateway is translating data to a group of receivers that do not understand the new packet format. The danger is that the packet frequency will not reflect the actual size of the group. It is the responsibility of the gateway in this situation to make a decision as to whether to forward the data to the distribution source or to suppress the feedback. The worst case scenario is that the source will receive N*0.0375 of the session bandwidth, where N indicates the number of independent distribution trees. Typically, there will only be two trees (one ASM and one SSM). Under certain circumstances such as a mixer transcoding the data stream to a lower rate in order to conserve resources for low bandwidth links, it may be desirable for the gateway to do the packet summarisation in order to ensure the minimal information is distributed to the receivers. 9.2 Encryption issues The issue of how a gateway should handle encrypted data controls some of the options available to a gateway in handling data streams. If the gateway does not have knowledge of the keys necessary to encrypt or decrypt the data, the operations which can be conducted on the data stream are limited. The gateway should still be able to identify which sources are senders and which are receivers in a session. This enables it to make decisions about how to handle control channel data. It most likely does not provide the flexibility for the gateway to conduct it's own packet summarisation algorithms. Under these circumstances, it is recommended that the gateway should simply forward packets based on identifying senders and receivers via IP address/port pairs. It should then adopt a simple forwarding algorithm such as that identified in section 9.1.a. Chesterfield, Ott [Page 12] Internet Draft RTCP with Unicast Feedback July, 2001 10. Transmission interval calculation The RTCP transmission Interval calculation remains the same as in the original RTP specification. In the original specification, the senders are allocated 1/4 of the control traffic bandwidth if they number 25% or less than the group size. Otherwise the allocation for senders is the percentage of senders to group size. The remaining bandwidth is allocated to the receivers to be divided evenly amongst the group. The Control Traffic Bandwidth is an arbitrary amount which is intended to be supplied by a session management application or decided based upon the bandwidth of a single sender in a session. A receiver calculates the number of other members in a session based upon either it's own SSRC count determined by the forwarded Receiver Reports, or from the RSI report from a sender. 11. Security Considerations Packet bombing of unsuspecting victims via a fake SDP or SSM address is a real concern for this communication architecture. Receivers are required to suppress control traffic until at least one control data packet has been received from the source address identified in the session startup information. As an additional measure, it is recommended that the source should reflect at least the first receiver report from every client back to the control channel using the simple feedback mechanism. This provides the source with some assurance that the session announcement was authentic. None of these methods can protect a source entirely from being compromised and this remains an area of risk. The issue of source feedback implosion should not occur in the event that receivers practice the standard RTP/RTCP guidelines for starting sessions and for implementing scaling algorithms based on the number of hosts. An additional issue which should be addressed beyond the scope of this document is the potential for host anonymity which is facilitated by Source Specific Multicast and adds additional security measures into group communication. By explicitly controlling receiver feedback, a source could solicit feedback from the receivers in a scalable way without the need to inform all members in a session of the group membership. 12. Open Issues 1. If there are multiple sources without a translator, how should a receiver handle RTCP feedback? Should feedback be sent individually to the new sources? What if they don't support packet reflection? 2. It is assumed that translators are not considered members of a session and hence affect group size calculation. 3. What is the correct method for handling migration from simple feedback to packet summarisation? What is the significance Chesterfield, Ott [Page 13] Internet Draft RTCP with Unicast Feedback July, 2001 of a partial RSI report? How can a receiver understand the relevance of the values relative to other Receiver Reports that it may still be receiving. 4. The issue of NATs and Firewalls poses a problem for RTCP feedback and security checks such as verifying the address of the Source packets matches the RTCP feedback address in the SDP information. How should this be handled? 5. Consideration is being given as to whether or not an extension to SDP is required. 6. Is the payload value 205 free for use in this context? 13. References [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP - A Transport Protocol for Real-time Applications," Internet Draft, draft-ietf-avt-rtp-new-09.txt, Work in Progress, March 2001. [2] Pusateri, T, "Distance Vector Multicast Routing Protocol", draft-ietf-idmr-dvmrp-v3-10, August 2000 [3] Fenner, B, Handley, M, Holbrook, H, Kouvelas, I, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-02.txt, March 2001 [4] Farinacci, D, Kouvelas, I, Windisch, K, "State Refresh in PIM-DM" draft-ietf-pim-refresh-02.txt, November, 2000 [5] Thaler, D, Cain, B, "BGP Attributes for Multicast Tree Construction", draft-ietf-idmr-bgp-mcast-attr-00.txt, February 1999 [6] Farinacci, D, Rekhter, Y, Meyer, D, Lothberg, P, Kilmer, H, Hall, J, "Multicast Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-06.txt, July 2000 [7] Shepherd, G, Luczycki, E, Rockell, R, "Source-Specific Protocol Independent Multicast in 232/8", draft-shepherd-ssm232-00.txt, March 2000. [8] Holbrook, H, Cain, B, "Using IGMPv3 For Source-Specific Multicast", draft-holbrook-idmr-igmpv3-ssm-00.txt, July 2000. Chesterfield, Ott [Page 14] Internet Draft RTCP with Unicast Feedback July, 2001 AUTHORS ADDRESSES Julian Chesterfield AT&T Labs - Research 75 Willow Road Menlo Park, CA 94025 julian@research.att.com Joerg Ott Tellique Kommunikationstechnik GmbH Berliner Str. 26 D-13507 Berlin GERMANY Phone: +49.30.43095-560 (sip:jo@tzi.org) Fax: +49.30.43095-579 Email: jo@tellique.com