AVT T. VanCaenegem Internet-Draft Alcatel-Lucent Intended status: Standards Track March 07, 2011 Expires: September 8, 2011 RTCP FB NACK storm suppression and its impact on retransmission in RTP SSM sessions with unicast FB draft-vancaenegem-avtcore-fb-supp-and-retransm-00 Abstract This document discusses how RTCP Feedback storm suppression negatively affects retransmission efficacy for Source Specific Multicast sessions with unicast feedback architectures and proposes some recommendations by means of additional signaling (e.g. RSI message and new attribute parameters) and a small AVPF FB suppression rule modification resulting in a overall better system where the FB suppression can be maintained but with a optimised retransmission efficacy. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 8, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect VanCaenegem Expires September 8, 2011 [Page 1] Internet-Draft RTCP FB NACK storm suppression March 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Considered Architecture . . . . . . . . . . . . . . . . . . . 5 4. Feedback suppression in combination with retransmission for SSM with unicast feedback with single FT/RS . . . . . . . 7 4.1. Packet Loss Upstream of the Distribution Source . . . . . 7 4.2. Packet Loss Downstream of the Distribution Source . . . . 9 4.2.1. Simple feedback model . . . . . . . . . . . . . . . . 9 4.2.2. Feedback summary model . . . . . . . . . . . . . . . . 11 5. Feedback suppression and retransmission for SSM with unicast feedback with multiple and disjoint FTs . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7.1. Registration of SDP Attributes . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 VanCaenegem Expires September 8, 2011 [Page 2] Internet-Draft RTCP FB NACK storm suppression March 2011 1. Introduction RTCP Feedback (FB) storm suppression is efficiently realised by means of the AVPF algorithm implemented at RTP receivers participating to multi-party RTP sessions, defined in [RFC4585]. In RTP multi-party sessions, a single event may impact many or even all RTP receivers. RTP receivers that react on a packet loss event by sending RTCP FB NACK messages, must follow the [RFC4585] AVPF timing rules which include a suppression rule: a RTP receiver receiving the same FB message as the one it intends to send, must discard its own FB message. This results in FB storm suppression or mitigation. The AVPF FB storm suppression mechanism is introduced to protect the network, server(s) and indirectly all the receivers and works well in most RTP topologies, including SSM with unicast feedback. However, such RTCP feedback storm suppression does result in decreased visibility on the status of RTP receivers, and hence impacts monitoring service and also services triggered by the reception of such RTCP FB messages, such as the packet loss recovery service by means of RTP retransmission . RTP retransmissions are requested from RTP receivers by RTCP FB NACK messages, reporting RTP packet loss. The internet draft "draft-wu-avt-retransmission-supression-rtp" discusses FB storm suppression, and proposes a new RTCP message that is called "third party loss" message that can be taken advantage to counter FB storms for various considered architectures of various RTP multi-party sessions. However, the usability of such message in the context of the AVPF suppression algorithm is not clearly addressed and the possible interference with a packet loss recovery service by means of RTP retransmission is omitted in draft "draft-wu-avt-retransmission-supression-rtp". For instance, in the transport translator scenario that is addressed in the draft, all RTCP messages must normally be forwarded, and hence every RTCP NACK/ FIR FB message from one receiver will be sent to all other receivers, where the [RFC4585] FB suppression rule will kick-in. Hence the "third party loss" message does not bring substantial value. The present draft discusses also FB storm suppression, but focuses on RTCP SSM architectures with unicast feedback target(s). It describes how the goals of FB NACK storm suppression and the goal of retransmission in terms of service enhancement are often in conflict with each other. To that extent it discusses several packet loss event use cases for RTCP SSM with unicast FB -for both modes defined in [RFC5760] including the SSM architecture with multiple FTs and makes proposals to reconcile suppression and (retransmission) service fulfillment for SSM with unicast feedback, taking into account the minimisation of network bandwidth and server resources. In certain scenarios/architectures, the "third party loss" message from "draft-wu-avt-retransmission-supression-rtp" can be leveraged. VanCaenegem Expires September 8, 2011 [Page 3] Internet-Draft RTCP FB NACK storm suppression March 2011 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. VanCaenegem Expires September 8, 2011 [Page 4] Internet-Draft RTCP FB NACK storm suppression March 2011 3. Considered Architecture In this draft we consider the Source Specific Multicast (SSM) with unicast feedback architecture as defined in [RFC5760] defining one or several media senders, a Distribution Source (DS)-sourcing the SSM-, one or several Feedback Targets (FT) that may be co-joint with the DS and the SSM RTP receivers that provide unicast feedback to a FT. On top, similar as defined in [I-D.ietf-avt-rapid-acquisition-for-rtp] , also a Retransmission Source is considered that is co-joint with the Feedback Target, and together constitute the Retransmission Server (RS). It is assumed that the receivers support sending RTCP NACK FB messages . Two models for SSM with unicast FB have been defined in [RFC5760]: o In distribution source feedback summary model, the unicast RTCP Receiver Report messages from the SSM RTP receivers are default aggregated by the DS and their information is transmitted as Receiver Summary Information (RSI) messages in the SSM session. The RTCP FB packets are default terminated by the DS. However, the DS may also aggregate or forward RTCP FB packets and transmit them on the SSM, when this is explicitly signaled. Note that from the RTP perspective, the DS is an RTP receiver generating its own RTCP RR as well as other RTCP packets and sending them to the receiver group and media senders. o In simple feedback model the DS must reflect all RTCP messages (hence including RTCP FB) received in unicast via the FT from the SSM RTP receivers. In the remainder of this draft, both models will be considered. It must be noted that for large group of receivers in a SSM with unicast feedback session, the feedback summary model is the most useful one, as the simple feedback model would result in significant reflected RTCP messaging overhead in the network and for all the SSM receivers, from bandwidth resources and processing overhead point of view. We also make in this draft a distinction between two topologies for SSM with unicast feedback with retransmission server capability : o a topology where there is one DS and a single FT, and where the FT is combined with a Retransmission Source function. The FT/RS could be joint or disjoint from the DS, but this is not really relevant in the discussion. Because a retransmission packet is in general a response on a NACK directed to a FT, combining the FT and the RS in a single entity is a logical choice. In the remainder of this draft, the co-location of FT and RS is assumed, and they represent together the retransmission server, in agreement with [I-D.ietf-avt-rapid-acquisition-for-rtp]. VanCaenegem Expires September 8, 2011 [Page 5] Internet-Draft RTCP FB NACK storm suppression March 2011 o a topology where we have multiple FTs that are disjoint from the DS, and where each FT is combined with a Retransmission Source function. Also here is assumed that the FT is co-located with the Retransmission Source, being together the Retransmission Server. The interference of the [RFC4585] FB suppression mechanism with the client's ability for receiving retransmissions from the RS is discussed first for SSM with unicast feedback and single FT/RS, followed by a discussion for an SSM architecture with multiple FT/RS. VanCaenegem Expires September 8, 2011 [Page 6] Internet-Draft RTCP FB NACK storm suppression March 2011 4. Feedback suppression in combination with retransmission for SSM with unicast feedback with single FT/RS In the SSM architecture with single FT/RS that is either co-joint or separate from the DS, a FB storm can always be prevented or mitigated because SSM RTP receivers implementing AVPF, must adhere to the suppression rules defined in [RFC4585]. It is explored in this and the following sections how this impacts a RTP retransmission packet loss repair service for a given packet loss event at a SSM RTP receiver. 4.1. Packet Loss Upstream of the Distribution Source As an first example of a packet loss event triggering FB suppression, a packet drop event somewhere along the data path between a media sender and the DS is considered. All SSM RTP receivers will notice this packet loss, including the DS itself (in the RTP stream between the media sender and the DS). o In the simple feedback model, all RTCP messages are relayed back to all receivers and the media source(s). Hence, the first RTCP NACK(s) sent by a SSM RTP receiver or a subset of the SSM RTP receivers, will be relayed by the DS to all SSM receivers, which will make the other RTP SSM receivers refrain from sending a NACK, as determined by the RTP receiver's AVPF RTCP scheduling algorithm. This will limit the amount of RTCP FB traffic from the SSM receivers both to the DS and to the media source(s), and avoid a FB storm. o In the feedback summary model, the DS is an RTP receiver generating its own receiver reports and sending these to the receiver group and to the media senders. For the given use case example, the DS can generate its own RTCP FB message and send it to the SSM group. All SSM receivers supporting and implementing AVPF will adhere to the FB suppression rule defined in [RFC4585], and hence a FB storm is avoided. The DS can choose to send a FB NACK multiple times for redundancy reasons, as long as it complies to the AVPF RTCP scheduling algorithm. Consider now that the FT is also a retransmission server which can respond with retransmissions when receiving a RTCP FB NACK from a RTP receiver- provided this server has access to the original RTP packet. Note that for the considered packet loss use case, the retransmission server will also detect the packet loss. In both SSM models when considering large groups of receivers, at least one but not more than a few receivers will send a NACK FB. However still all receivers will be impacted by the packet loss and desire a retransmission. A fundamental aspect of combining retransmission service with FB VanCaenegem Expires September 8, 2011 [Page 7] Internet-Draft RTCP FB NACK storm suppression March 2011 suppression mechanism, is that retransmissions may be sent to receivers that are unsollicited. An unsollicited retransmission can be defined as a retransmission received by a receiver which was not requested by this same receiver via an RTCP FB NACK message or any other explicit signaling from that receiver. Sollicited retransmission is a retransmission provided to a receiver which was explicitly requested by that same receiver. For the given packet loss event, when the RS is capable of recovering the lost packet (the way this is achieved is not relevant nor discussed here), it can provide the retransmission to all RTP receivers. This retransmission can be performed either in a each separate unicast RTP retransmission sessions to each receiver or - in a single SSM RTP session that is session muxed with the original RTP SSM. Providing the retransmission over SSM has the advantage that o the retransmission packet must be transmitted by the DS/RS only once, saving both network and server resources o because the retransmission is not explicitly sollicited by means of a NACK, it may happen that the unsollicited retransmission packet when transmitted in unicast is blocked by any intermediate gateway on the path between the retransmission server and the RTP receiver. When a packet loss repair service is announced as a retransmission server-sourced SSM retransmission session, a RTP receiver that joins this RTP SSM retransmission session via IGMP/MLP, implicitly indicates it is willing to accept retransmissions over this SSM, that are unsollicited. When there is no SSM retransmission session in place and signaled to the receivers, a RS can of course still send unsollicited retransmissions in those unicast retransmission sessions that are established as per [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. It is implementation-specific whether RTP receivers choose to ignore received unsollicited retransmission packets (in the same way as RTP receivers may ignore retransmission packets for which the receiver did send a NACK FB message, i.e. sollicited retransmission) It should be noted that when an SSM RTP receiver is involved in both a unicast retransmission session and a SSM retransmission session sourced by the same retransmission server, a retransmission of a packet transmitted in the original SSM may be sent in the unicast retransmission session, in the multicast retransmission session or both. The retransmission server SHOULD send unsollicited retransmissions over the retransmission SSM session when such session is available. A retransmission server that receives a RTCP FB NACK and decides to provide a retransmission, should (also) send that retransmission in the unicast retransmission session to the receiver VanCaenegem Expires September 8, 2011 [Page 8] Internet-Draft RTCP FB NACK storm suppression March 2011 that sent the RTCP FB NACK (when such a unicast retransmission session is available and established as described in [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. In conclusion, note that in this packet loss event use case: o all SSM RTP receivers were impacted by the packet loss and detected this packet loss o all receivers behave compliant to [RFC4585] in terms of RTCP transmission scheduling and suppression rules o no RTCP FB storms occur o all SSM RTP receivers can receive the retransmission either in a dedicated retransmission SSM or in separate unicast retransmission sessions established by the RTP receivers. Whether the retransmission server does provide a retransmission and to which RTP receiver (when using unicast retransmission) is governed by the retransmission server policy. 4.2. Packet Loss Downstream of the Distribution Source As a second example packet loss event triggering feedback suppression, consider a packet drop event in the SSM tree downstream of the DS/FT, which may impact just one SSM RTP receiver but can possibly also impact a large set of SSM RTP receivers (all those that are downstream of the SSM tree branch where the packet loss event occured). The DS/RS in general does not know a particular RTP packet got lost untill it starts receiving RTCP FB NACK(s) from one or more SSM RTP receivers. Note that for the considered packet loss event use case, the RS will have in its cache the missing packet as the original packet got dropped downstream of the DS/RS. The feedback suppression will, depending on where the packet was lost, possibly interfere with the packet loss repair service based on RTP retransmission , as explained below for the two SSM feedback models. 4.2.1. Simple feedback model Consider the simple feedback model where a retransmission server is in place that is co-located with the DS. Assume that multiple RTP receivers observe the same packet loss in the RTP SSM, which is most likely caused by a single packet loss drop in a branch of the SSM tree connecting to the impacted receivers. Even though the retransmission server may be capable of providing a retransmission to all impacted SSM RTP receivers, even when each receiver individually transmits a RTCP FB NACK, some receivers may not have a chance to VanCaenegem Expires September 8, 2011 [Page 9] Internet-Draft RTCP FB NACK storm suppression March 2011 receive a retransmission. This is due to the fact that the DS is supposed to reflect all RTCP FB messages. Hence because of the RTCP FB transmission suppression algorithm, the RS will not know which (other) SSM receivers experienced the same packet loss. There are two ways to make sure that all impacted receivers do get a retransmission: o FB suppression is enabled by having the DS reflecting any RTCP FB message received, but the RS does send a unsollicited retransmission to all SSM receivers, each time a RTCP FB NACK is received. This solution is not desirable as it provides retransmissions to SSM receivers which are -in the large majority of possible cases- unneeded and results in a waste of network and also a waste of server resources when retransmissions are provided over unicast. o FB suppression is disabled because the DS does not forward/reflect RTCP FB packets down the SSM. All SSM RTP receivers impacted by the loss (ranging from one to all of the SSM RTP receivers) will send a RTCP FB NACK. Only when the storm of RTCP FB packets has no detrimental impact, the RS can respond to each NACK with a retransmission packet in each unicast retransmission session -or, alternatively, the retransmission is provided over a dedicated retransmission SSM. In summary: the DS/RS is capable of preventing a FB storm by reflecting the received RTCP FB messages down the SSM with the disadvantage of having no visibility on which receiver has detected which missing packets in the SSM. Alternatively, the DS takes the risk of being confronted with a FB storm by not forwarding the RTCP FB messages, where in general each SSM receiver that detected the packet loss event, can be paired with a unicast retransmission. The second option is in conflict with the forwarding requirement defined in [RFC5760]. It is also in disagreement with the first use case (packet loss upstream of the DS) where a simple reflection behaviour does result in efficient FB suppression, without withholding the impacted receivers from receiving a (unsollicited) retransmission. The general recommended solution addressing packet loss event use cases 1 and 2, is therefor to allow "selective" reflection (or "selective" termination) in the simple feedback model for RTCP FB messages. It allows feedback suppression but still giving visisbility to the DS on which are the impacted receivers, and providing reasonable guarantees on a efficient retransmission service to all receivers. With "selective" RTCP FB reflection, the DS will in general not VanCaenegem Expires September 8, 2011 [Page 10] Internet-Draft RTCP FB NACK storm suppression March 2011 reflect RTCP FB messages received from SSM receivers except in the following two cases: o the DS/RS itself is subject to packet loss and will reflect any RTCP FB NACK received from the downstream SSM RTP receivers reporting this same packet loss. o the DS (selectively) reflects received RTCP FB NACK, when the RS itself was not impacted directly by the packet loss but a certain threshold for incoming RTCP FB NACK packets has been reached, all pertaining to the same original packet in the SSM. This threshold is based on the total amount of receivers reporting to the FT/RS, and can be adjusted dynamically, but this is a metric internal to the FT/DS. Note that there is maximum efficiency in the retransmission operation that may occur after reflecting the RTCP FB NACK in these two exception cases, if the retransmission takes place over a (retransmission) SSM RTP session. The proposal is to define an additional parameter for the "rtcp- unicast" SDP attribute indicating SSM sessions with unicast feedback operated in simple feedback mode, named "selective reflection". Its meaning is that RTCP FB messages may not be reflected by the FT/DS, but instead terminated. All other RTCP reports are reflected, as imposed by [RFC5760]. 4.2.2. Feedback summary model For the considered use case of packet loss downstream of the DS/RS, similar as discussed for the simple feedback model discussion, feedback suppression is enabled by having the DS selectively forwarding the received RTCP FB messages: e.g. when the number of received RTCP FB NACKs pertaining to the same RTP packet loss crosses a certain threshold, the DS fowards such a RTCP FB NACK. "Selective Forwarding" is therefore proposed as a new parameter for the processing attribute in the rsi-rule in the SDP for the summary feedback model, that is allowed ONLY for RTCP FB packets: Alternatively the DS/RS always terminates RTCP FB messages, but prevents FB storms, in the following two ways: o for packet loss events taking place upstream of the DS, the DS simply sends itself a RTCP FB NACK o for packet loss events taking place downstream of the DS, the reception of RTCP FB NACKs may trigger the transmission of a new VanCaenegem Expires September 8, 2011 [Page 11] Internet-Draft RTCP FB NACK storm suppression March 2011 RTCP FB packet by the DS, named "3rd party NACK" which has the same semantics as a RTCP FB NACK, as defined in draft "draft-wu-avt-retransmission-supression-rtp" A SSM RTP receiver , receiving this message in the SSM, shall treat it the same way as a RTCP FB NACK received from another SSM RTP receiver and hence SHALL NOT send a RTCP FB message. The DS needs to carefully evaluate when to send or not send such a "3rd party NACK", as discussed previously in this section. VanCaenegem Expires September 8, 2011 [Page 12] Internet-Draft RTCP FB NACK storm suppression March 2011 5. Feedback suppression and retransmission for SSM with unicast feedback with multiple and disjoint FTs A specific case of SSM with unicast FB, is where there are multiple FTs disjoint from the DS. Similar as before, in the considered architectures, each FT is combined with a retransmission source, constituting a retransmission server [[I-D.ietf-avt-rapid-acquisition-for-rtp]]. Note that the RS (=FT+ BRSource) are generally not positioned in the direct SSM path between the DS and the SSM RTP receivers. This architecture provides a scalable solution for SSM with a large population of receivers, because it is able to distribute RTCP feedback processing loads across different entities in different parts of the network. It is an architecture that is well suited for IPTV networks of large service providers, where the DS is the head-end sourcing the SSM that carry broadcast streams over IP. [RFC5760] indicates that for the simple FB model where the FT(s) are disjoint from the DS, the FT must forward all RTCP packets to the DS. [RFC5760] indicates that for the summary FB model where the FT(s) are disjoint from the DS, the following: o The Feedback Target(s) MAY simply forward all RTCP packets incoming from the RTP receivers to the Distribution Source o The Feedback Target(s) MAY also perform aggregation of incoming RTCP packets and send only aggregated information to the Distribution Source. o If the Feedback Target performs summarization functions, it MUST also act as a receiver and choose a unique SSRC for its own reporting towards the Distribution Source. The discussion on how FB suppression and retransmissions can be efficiently combined for the SSM with single FT topology -as discussed above- remains applicable and valid for the SSM with multiple (disjoint) FTs topology, but there is an additional aspect that should be addressed, and a third example packet loss event use case visualises this. The considered topology is a DS with two disjoint FT/RS entities, FT/RS 1 and FT/RS 2 , where each FT receives RTCP messages from a separate group of SSM RTP receivers. The assumption is that a RTP packet (with Sequence Number N) in the original SSM got dropped in the network upstream of the FT 1 (and hence impacting FT 1, as well as all the SSM receivers that report to FT 1). Because FT 2 does not get the original SSM packets from the DS via the router where the VanCaenegem Expires September 8, 2011 [Page 13] Internet-Draft RTCP FB NACK storm suppression March 2011 packet loss took place, the FT 2 does receive the packet with SN N and so do the SSM receivers reporting to FT 2. The FT 1 and its reporting SSM receivers experience a situation that is discussed in the first use case for the SSM with single FT topology. Because the packet loss event impacts all SSM receivers reporting to FT 1, it is paramount that those receivers in general suppress sending a RTCP FB NACK. Hence having the FT 1 forwarding the first received RTCP FB NACK(s) from a SSM RTP receiver to the DS -which then reflects/forwards the FB NACK over the original SSM, is the correct thing to do from that point of view. However, the reflection /forwarding of the FB NACK by the DS means that also the SSM RTP receivers reporting to the FT 2 will suppress sending an RTCP FB NACK for packet N in the SSM, even if they detect the same packet loss - but which is not caused by the packet loss event impacting FT/RS 2 and all its reporting SSM RTP receivers. This means there is a discrepancy between the network reach of the suppression (covering all SSM receivers) and the actual network subdomain that was commonly impacted by the packet loss. The RS 2 will in general not know whether there are any SSM receivers -reporting to FT 2- that missed RTP packet with RTP SN N because of a different packet loss event . Note also that the unsollicited retransmission by RS 1 -following the packet loss with SN N detection -can remain confined to the subdomain impacted by the loss, when the FT is co-located with the RS (using either unicast retransmission sessions or a SSM retransmission session sourced by the RS). SSM with multiple disjoint unicast FTs hence may result in efficient feedback storm supression across all SSM RTP receivers, but this also prevents any SSM RTP receiver from sending a RTCP FB NACK for detected packet loss, even when no FB storm was imminent for the subdomain covered by a particular FT. A solution for maximising the retransmission service fulfillment may be for the DS to also act as RS and always send retransmissions requested by a particular FT, over a separate retransmission SSM to all SSM RTP receivers. However, this unnecessarily loads the network and requires all the SSM RTP receivers to receive both an original/primary SSM and a retransmission SSM. A more optimised solution is to keep both the FB suppression and retransmission within the same local "subdomain". This can be enabled by adding a rule to the AVPF FB suppression algorithm, that makes the suppression mechanism "selective" at the SSM RTP receivers side. The proposed overall solution to enable such selective receiver FB storm suppression algorithm, is accomplished in three steps: VanCaenegem Expires September 8, 2011 [Page 14] Internet-Draft RTCP FB NACK storm suppression March 2011 o The SSM RTP receivers first learn the SSRC identifier of the FT where the FT either acts as a translator in the original SSM session (simple feedback model) or acts as a SSM RTP receiver. There are several ways through which this can happen: * "in-band" : applies only for the feedback summary model, where by means of a new RSI message the DS provides a listing of all deployed FTs with the corresponding SSRC for each of these FTs. * "out-of-band" for either the feedback summary or simple feedback model of SSM operation, by advertising the FT's SSRC as a media attribute for the FT in the SSM RTP session description [RFC5576] . The "out-of-band" signaling mechanism requires the application signaling to know/learn the SSRCs deployed by the FTs prior to signaling this information to the SSM RTP receivers (those receivers that are not acting as FT). o In the feedback summary model, the FT does not forward RTCP FB NACK messages as received from the SSM RTP receivers to the DS. Instead the FT sends a RTCP FB NACK message using its own SSRC when the FT/RS itself directly detected the common packet loss event. Alternatively, the FT sends the RTCP message "3rd party NACK" ["draft-wu-avt-retransmission-supression-rtp"] using its own SSRC when it senses a local FB storm is imminent but when the RS itself was not subject to the packet loss. In the simple feedback model, the FT can act as translator in the SSM session and send the new RTCP FB message "3rd party NACK" using its own SSRC. Alternatively and similar as described for the feedback summary model, when the DS advertises itself as FT towards the RSs that host the FTs, the RS sends as SSM RTP receiver to the DS a RTCP FB NACK or RTCP FB "3rd party NACK", depending on whether it detected the reported packet loss itself or not. o The DS forwards the RTCP FB NACK messages or RTCP FB "3rd party loss" messages received from any of the FTs in the SSM session, down on the original SSM session. The feedback suppression can then remain localised, by having an SSM RTP receiver only activating feedback suppression when the "SSRC of packet sender" field value in the received RTCP FB message(s) matches with the SSRC that is used by the local FT to which it reports. Note that when the DS sends a third party loss report or NACK RTCP FB message using its own SSM SSRC, all the SSM RTP receivers (including the FTs) will abstain from sending a RTCP FB message, enabling a FB storm suppression across the whole SSM network domain. This occurs e.g. when a packet loss event took place between a media sender and VanCaenegem Expires September 8, 2011 [Page 15] Internet-Draft RTCP FB NACK storm suppression March 2011 the DS. VanCaenegem Expires September 8, 2011 [Page 16] Internet-Draft RTCP FB NACK storm suppression March 2011 6. Security Considerations No dedicated security measures must be considered other than the ones defined in [RFC4585] and [RFC5760]. VanCaenegem Expires September 8, 2011 [Page 17] Internet-Draft RTCP FB NACK storm suppression March 2011 7. IANA Considerations The following contact information shall be used for all registrations in this document: "tom.van_caenegem@alcatel-lucent.com" 7.1. Registration of SDP Attributes TBC. VanCaenegem Expires September 8, 2011 [Page 18] Internet-Draft RTCP FB NACK storm suppression March 2011 8. Acknowledgments VanCaenegem Expires September 8, 2011 [Page 19] Internet-Draft RTCP FB NACK storm suppression March 2011 9. References 9.1. Normative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010. 9.2. Informative References [I-D.ietf-avt-ports-for-ucast-mcast-rtp] Begen, A., Wing, D., and T. VanCaenegem, "Port Mapping Between Unicast and Multicast RTP Sessions", draft-ietf-avt-ports-for-ucast-mcast-rtp-11 (work in progress), January 2011. [I-D.ietf-avt-rapid-acquisition-for-rtp] Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- Based Rapid Acquisition of Multicast RTP Sessions", draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in progress), November 2010. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. VanCaenegem Expires September 8, 2011 [Page 20] Internet-Draft RTCP FB NACK storm suppression March 2011 Author's Address Tom VanCaenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen, 2018 Belgium Email: Tom.Van_Caenegem@alcatel-lucent.com VanCaenegem Expires September 8, 2011 [Page 21]