AVTEXT A. Begen Internet-Draft Cisco Intended status: Standards Track T. VanCaenegem Expires: February 11, 2013 Alcatel-Lucent August 10, 2012 Retransmission for Source-Specific Multicast (SSM) Sessions draft-begen-avtext-retransmission-for-ssm-00 Abstract This document describes RTP retransmission for source-specific multicast (SSM) architectures with unicast feedback. RTP payload format for retransmissions has been defined in RFC 4588, whereas the RTP profile an RTP receiver could use to issue RTP Control Protocol (RTCP) feedback messages and the format of these feedback messages have been defined in RFC 4585. RFC 5760 defines the operation for SSM architectures with unicast feedback. First, we document potential issues that could arise when providing a retransmission service using RTP retransmission (RFC 4588 and RFC 4585) for RFC 5760 architectures based on rules described in the relevant RFCs. We then present solutions that allow to avoid unnecessary feedback suppression, provide enhanced retransmission services and address congestion control for retransmission in an SSM environment. These solutions specify certain rules that apply to the distribution source, feedback target(s), retransmission source(s) and RTP receivers. 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 February 11, 2013. Copyright Notice Begen & VanCaenegem Expires February 11, 2013 [Page 1] Internet-Draft Retransmission for SSM Sessions August 2012 Copyright (c) 2012 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Feedback Suppression and Retransmission for SSM: Applicable Specifications . . . . . . . . . . . . . . . . . . 6 4.1. RTCP Feedback Suppression in RFC 4585 . . . . . . . . . . 6 4.2. RTCP Feedback Message Distribution in RFC 5760 . . . . . . 7 4.3. RAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Pitfalls When Combining RTCP Feedback Handling and Retransmission Using RFC 5760 Rules . . . . . . . . . . . . . 10 5.1. Case of DS Forwarding/Reflecting All RTCP NACKs . . . . . 10 5.2. Case of DS Terminating All RTCP NACKs . . . . . . . . . . 10 5.3. Case of Multiple FTs . . . . . . . . . . . . . . . . . . . 11 5.4. Takeaways . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Rules for SSM with Retransmissions . . . . . . . . . . . . . . 13 6.1. Feedback Suppression Behavioral Requirements for DS, FT and RTP_Rx's . . . . . . . . . . . . . . . . . . . . . 13 6.2. Informing RTP_Rx's with the SSRC Value of FT/RS . . . . . 15 6.3. Unsolicited Retransmissions . . . . . . . . . . . . . . . 17 6.4. Congestion Control Considerations . . . . . . . . . . . . 18 6.4.1. Congestion Control in RFC 4585 and in RAMS . . . . . . 18 6.4.2. Congestion Handling for SSM with Retransmissions . . . 19 6.5. New RSI Message and RAMS-I TLV Extension . . . . . . . . . 21 6.5.1. RSI Message 'FT SSRC List' . . . . . . . . . . . . . . 21 6.5.2. RAMS-I TLV Extension 'FT SSRC' . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. RTP Retransmission Service in DVB IPTV . . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 Begen & VanCaenegem Expires February 11, 2013 [Page 2] Internet-Draft Retransmission for SSM Sessions August 2012 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Begen & VanCaenegem Expires February 11, 2013 [Page 3] Internet-Draft Retransmission for SSM Sessions August 2012 1. Introduction The RTP toolkit is used to deliver a variety services over IP multicast. [RFC5760] defines a source-specific multicast (SSM) architecture with one or several Media Senders, a Distribution Source (DS) (sourcing the SSM), one or several Feedback Targets (FT) that may or may not be co-joint with the DS and RTP receivers (RTP_Rx) that send unicast feedback to a FT. This document explores the complications one might face when adding one or more Retransmission Sources (RSo) in this architecture for reliable multicast distribution. In this specification, we assume that FT and RSo logical entities are combined in a single physical entity and they share state. In the remainder of the text, the term Retransmission Server (RS) is used whenever appropriate, to refer to this single physical entity. As in [RFC6285], the RS receives the RTP packets sent in an SSM session (as a normal RTP_Rx), and buffers these packets for a certain time for retransmission purposes. The term RAMS (Rapid Acquisition of Multicast Sessions) will be used to refer to the protocol and architecture defined in [RFC6285]. The RAMS specification presents a method in which an RTP_Rx can rapidly acquire reference information transported in an SSM session. This is enabled by having the RTP_Rx retrieve a unicast burst of data from an RS, formatted as RTP retransmission packets prior to joining the SSM session. While the present document will include some requirements and observations expressed in [RFC6285], it will particularly focus on the impact of packet loss events experienced in an SSM distribution, and how the elements in the SSM architecture interact best to ensure impacted RTP_Rx's are provided with appropriate RTP retransmissions. A packet loss event in an SSM session, will in general trigger one or multiple interactions between the RTP_Rx and the FT/RS/DS entities: o The RTP_Rx sending an RTCP NACK message to the FT ([RFC4585]) o The RTP_Rx receiving RTP retransmission(s) from the RS o The RTP_Rx receiving an RTCP feedback message from the DS This document describes the behavior for all entities defined in an SSM architecture with unicast feedback as described in [RFC5760] (DS, FT, RS and RTP_Rx) addressing feedback implosion (avoidance), retransmission efficacy and congestion concerns. One application that can benefit from this document is IPTV. In many Begen & VanCaenegem Expires February 11, 2013 [Page 4] Internet-Draft Retransmission for SSM Sessions August 2012 IPTV deployments, streams are transported over SSM. Transporting this data over SSM enables a packet loss recovery by means of RTP retransmissions and/or forward error correction (FEC) [I-D.ietf-fecframe-dvb-al-fec]. This document focuses on retransmission. Note that Digital Video Broadcasting (DVB) forum has specified an RTP retransmission solution for its managed Linear Media Broadcast (LMB) service, and which references most of the relevant RTP specifications. An overview of this solution is provided in Section 9. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definitions This document uses some acronyms and definitions which have been introduced [RFC6285] as the baseline. Some of these definitions have been slightly retailored to fit the restricted scope of this document. (Primary) SSM (or Multicast) Session: The multicast session to which RTP_Rx's can join at a random point in time. A primary SSM session can carry multiple RTP streams. Primary Multicast RTP Session: The multicast RTP session that is of interest to an RTP receiver. It comprises the primary multicast RTP stream(s) and an associated unicast RTCP feedback stream to a Feedback Target. Primary Multicast (RTP) Streams: The RTP stream(s) carried in the primary multicast RTP session. Source Filtering Group Management Protocol (SFGMP): Following the definition in [RFC4604], SFGMP refers to the Internet Group Management Protocol (IGMP) version 3 [RFC3376] and the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and IPv6 networks, respectively. In the remainder of this document, SFGMP will refer to any group management protocol that has Join and Leave functionalities. Feedback Target (FT): Unicast RTCP feedback target as defined in [RFC5760]. FT_Ap denotes a specific feedback target running on a Begen & VanCaenegem Expires February 11, 2013 [Page 5] Internet-Draft Retransmission for SSM Sessions August 2012 particular address and port. Retransmission Packet: An RTP packet that is formatted as defined in Section 4 of [RFC4588]. The payload of a retransmission packet comprises the retransmission payload header followed by the payload of the original RTP packet. (Unicast) Retransmission RTP Session: The unicast RTP session used to send one or more unicast retransmission RTP streams and their associated RTCP messages. This session is setup as described in [RFC6284]. Retransmission Server (RS): The RTP/RTCP endpoint that can generate the retransmission packets. New definitions introduced in this document are: Solicited Retransmission: Retransmission packet(s) that are received by an RTP_Rx which have been explicitly requested by this RTP_Rx by means of one or more RTCP NACKs. Unsolicited Retransmission: Retransmission packet(s) that are received by an RTP_Rx which have not been explicitly requested by this RTP_Rx by means of an RTCP NACK. Feedback Implosion/Storm: The situation where multiple RTP receivers start sending (quasi-) simultaneously (RTCP) feedback, often triggered by an upstream packet loss event in the SSM tree impacting a large set of RTP receivers. 4. Feedback Suppression and Retransmission for SSM: Applicable Specifications In this section we first look at the various specifications in place that describe the architecture for SSM with unicast feedback and determine how feedback suppression and retransmission are accomplished. 4.1. RTCP Feedback Suppression in RFC 4585 [RFC4585] defines an RTP profile for an RTP receiver that wishes to provide fast feedback by means of RTCP feedback messages, such as is applicable to an RTP retransmission scenario. [RFC4585] defines the timing rules by which such RTCP feedback messages can be transmitted both in unicast and multicast/multi-party sessions, and it also defines the general format of RTCP feedback messages, as well as some specific feedback messages. One of the transport-layer feedback Begen & VanCaenegem Expires February 11, 2013 [Page 6] Internet-Draft Retransmission for SSM Sessions August 2012 messages that is particularly relevant here is the RTCP NACK message through which an RTP receiver can report missing packets. The missing packets are identified by means of an SSRC identifier (associated with the primary multicast stream for which the DS uses this SSRC as media sender) and an RTP sequence number (SN). The RS receiving such an RTCP NACK message can respond by sending retransmission packets whose format has been described in [RFC4588]. An important aspect covered by [RFC4585] is feedback suppression for RTP receivers involved in a multi-party session in order to avoid feedback implosion. To that extent, the RTP receiver waits for a (short) random dithering interval to check whether it sees a feedback message from any other RTP receiver reporting the same event. If such a feedback message is received, the RTP receiver refrains from sending the feedback message and continues to follow the regular RTCP transmission schedule. Note that a feedback message from one RTP receiver is typically not visible to other RTP receivers, so the FT might need to provide information to the RTP receivers. We will investigate the implications of this feedback suppression rule for SSM architectures with unicast feedback as defined in [RFC5760], where one or multiple RS's are deployed. To that extent we first provide an overview of how RTCP feedback messages transmitted by the RTP receivers are handled in the SSM architecture as specified by [RFC5760]. 4.2. RTCP Feedback Message Distribution in RFC 5760 Two models in terms of DS behavior have been defined in [RFC5760]: o In Feedback Summary Model, the unicast RTCP receiver report messages from the RTP_Rx's are by default aggregated at the DS and their information is transmitted as Receiver Summary Information (RSI) messages in the SSM session. The RTCP feedback messages are by default terminated by the DS. However, the DS might also aggregate or forward RTCP feedback messages and transmit them in the SSM session, when this is explicitly signaled. Note that from the RTP perspective, the DS is an RTP_Rx generating its own RTCP receiver reports as well as other RTCP packets and sending them to the receiver group and media senders. o In Simple Feedback Model, the DS reflects all RTCP messages (including RTCP feedback) received in unicast via the FT from the RTP_Rx's. Note that many network topologies have a high degree of fanout, and also have a constrained link between the FT and the RTP_Rx's, so that reflecting all of the feedback messages is often not feasible. The communication between DS and disjoint FT(s) occurs as follows: Begen & VanCaenegem Expires February 11, 2013 [Page 7] Internet-Draft Retransmission for SSM Sessions August 2012 [RFC5760] indicates that for the Simple Feedback Model where the FT(s) are disjoint from the DS, the FT must forward all RTCP packets to the DS. [RFC5760] indicates the following for the Feedback Summary Model where the FT(s) are disjoint from the DS: o The FTs may simply forward all RTCP packets incoming from the RTP_Rx's to the DS. o The FTs may also perform aggregation of incoming RTCP packets and send only aggregated information to the DS. o If the FT performs summarization functions, it must also act as a receiver and choose a unique SSRC for its own reporting towards the DS. 4.3. RAMS Assume now that the FT is combined with an RSo, constituting together the RS, which provides retransmissions in response to unicast RTCP NACK messages received from RTP_Rx's. Such architecture is described in [RFC6285] where the FT is co-joint with a Burst/Retransmission Source (BRS). Figure 1 shows the main entities involved in SSM with retransmission enabled. They are o Distribution Source o Feedback Target (FT) o Retransmission Source (RSo) o RTP Receiver (RTP_Rx) The figure also shows the various RTP/RTCP flows and associated sessions. The difference with RAMS is that the Burst/Retransmission Source (BRS) is replaced with a Retrasmission Source (RSo). Another difference - not shown in the figure - is that next to the primary multicast session, there might also be a (source-specific) multicast retransmission session that can be sourced by the same DS entity (acting as an RS itself) or by the same RS that provides the unicast retransmissions. This is discussed in more detail in Section 6.3. The unicast retransmission session must be established as per [RFC6284]. Note that when RAMS and retransmissions are provided for the same SSM session, a single unicast retransmission session is established. The RAMS specification puts a constraint on the RS/FT, Begen & VanCaenegem Expires February 11, 2013 [Page 8] Internet-Draft Retransmission for SSM Sessions August 2012 stating that an FT (identified by means of IP address and port, and referred to as FT_Ap) must be associated with only a single RTP session. This constraint was put in place, because an RTP_Rx using the RAMS service may not necessarily know the media sender SSRC a priori. However, an RTP_Rx using the retransmission service can of course learn the SSRC by inspecting the SSRC identifier field in the RTP packets, and furthermore the SSRC field needs to be correctly filled out in the RTCP NACK message. Thus, while we do not have this constraint on FTs when only the retransmission service is enabled, the contraint still applies when both RAMS and retransmission services are enabled. ----------- -------------- | |------------------------------------>| | | |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| | | | | | | Distrib. | ---------------- | | | Source | | Retransmission | | | | |-------->| Server (RS) | | | | |.-.-.-.->| | | | | | | ------------ | | | ----------- | | Feedback | |<.=.=.=.=.| | | | Target (FT)| |<~~~~~~~~~| RTP Receiver | PRIMARY SSM | ------------ | | (RTP_Rx) | RTP SESSION with | | | | UNICAST FEEDBACK | | | | | | | | - - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- - | | | | UNICAST | ------------ | | | RETRANSMISSION | | | |<~~~~~~~~>| | RTP SESSION | | Retrans. | |.........>| | | |Source (RSo)| |<.=.=.=.=>| | | ------------ | | | | | | | ---------------- -------------- -------> Multicast RTP Flow .-.-.-.> Multicast RTCP Flow .=.=.=.> Unicast RTCP Reports ~~~~~~~> Unicast RTCP Feedback Messages .......> Unicast RTP Flow Figure 1: Flow diagram for SSM with retransmission Begen & VanCaenegem Expires February 11, 2013 [Page 9] Internet-Draft Retransmission for SSM Sessions August 2012 5. Pitfalls When Combining RTCP Feedback Handling and Retransmission Using RFC 5760 Rules In this section, we investigate a number of scenarios in terms of SSM topology and behavior of the DS with respect to the forwarding/ termination of RTCP feedback messages received from RTP_Rx's. In the first two scenarios, we assume there is only one FT. Note that the DS could be joint with the FT or disjoint from the FT. 5.1. Case of DS Forwarding/Reflecting All RTCP NACKs The forwarding of RTCP feedback messages is one option allowed for by the Feedback Summary Model of [RFC5760], where reflection is what the DS must do based on the Simple Feedback Model of RFC 5760. In this case, RTP_Rx's applying the [RFC4585]suppression rule will result in the following: when an RTP_Rx X reports a packet loss to the FT by sending an RTCP NACK, this message is distributed, via the FT and, by the DS via the SSM to all other RTP_Rx's. If an RTP_Rx Y, different from RTP_Rx X, detected the same packet loss, but prior to sending out a NACK, this receiver Y gets the NACK message originally sent by X, it will refrain from sending a NACK, following [RFC4585]. The forwarding/reflection of RTCP NACK messages effectively results in feedback suppression, but obviously this is at the expense of limited visibility to the RS on which RTP_Rx suffered packet loss. In general this will result in a decreased quality at the service layer for any RTP_Rx X, because the SSM receiver does not even get an opportunity to report its packet loss by means of an RTCP NACK. Note that for packet losses upstream of the DS and which subsequently impact all RTP_Rx's, the DS does not need to be informed by each individual RTP_Rx about this packet loss. When the DS is capable of recovering the lost packet in due time, it may send an unsolicited retransmission to all RTP_Rx's. The reduced visibility to the RS of packet losses taking place downstream of the DS, could be compensated for by having the RS sending an unsolicited retransmission, whenever an RTCP NACK is received. This will increase the chance on network congestion and will also consume RS processing resources when retransmissions are provided over unicast. The conclusion is that reflection/forwarding of RTCP NACK messages by the DS is not (always) the "right" thing to do. 5.2. Case of DS Terminating All RTCP NACKs Not forwarding and hence terminating RTCP feedback messages is the alternative option for a DS behaving in [RFC5760] Feedback Summary Model. In this case every RTP_Rx that detects a packet loss event, will also transmit an RTCP NACK (assuming no congestion is sensed by the receiver, see Section 6.4.2 ). We look at two example scenarios resulting in different consequences: As a first example: two or Begen & VanCaenegem Expires February 11, 2013 [Page 10] Internet-Draft Retransmission for SSM Sessions August 2012 multiple RTP_Rx's detect the same packet loss, which was caused by two or multiple un-related packet loss events taking place (quasi-) simultaneously. This could be caused by link transmission errors, such as on xDSL links or in cable networks. In this case, the RS will receive the NACKs from all impacted receivers, and can act accordingly by sending a unicast (solicited) retransmission to the impacted receivers. As a second example, take the case considered previously where a packet loss event took place on the link between a media sender and the DS. Because, even though the transmissions could be dispersed in a time frame Delta T, when a very large number of SSM receivers are impacted by the single packet loss event, a feedback implosion might occur. This may load the network link(s) downstream of the RS and the RS itself, beyond its processing capabilities. Clearly, this is a case where the feedback suppression rule of [RFC4585] would be useful. The conclusion is that termination of RTCP NACK messages by the DS is not (always) the "right" thing to do. 5.3. Case of Multiple FTs A specific case of SSM with unicast feedback, 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. Note that the RS are generally not positioned in the direct SSM path between the DS and the RTP_Rx's, i.e., an RS is typically a leaf of the SSM tree. 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, where the DS is the head-end sourcing the SSM that carries video broadcast streams over IP. Note that we again assume that the RTP_Rx's behave compliant to [RFC4585], inclusive conformance to the feedback suppression rule. The previous discussions on feedback suppression (or absence of feedback suppression) and its consequences on retransmissions for the SSM with single FT topology remains applicable and valid for the SSM with multiple (disjoint) FTs topology. A distributed FT architecture brings in an additional aspect that should be addressed, and a dedicated example packet loss event use case visualizes 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 RTP_Rx's. The assumption is that o An RTP packet (with RTP sequence number N) in the primary SSM got dropped in the network upstream of the FT 1 and upstream of the SSM receivers that report to FT 1. Begen & VanCaenegem Expires February 11, 2013 [Page 11] Internet-Draft Retransmission for SSM Sessions August 2012 o The FT 2 and the SSM receivers reporting to FT 2 are not impacted by the packet loss event impacting FT 1. This is because the FT 2 and its reporting SSM receivers do not get the original SSM packets from the DS via the router where the packet loss impacting FT 1 took place. The FT 1 and its reporting SSM receivers experience a situation that is discussed in a previous section. Because the packet loss event impacts all SSM receivers reporting to FT 1, it is important that those receivers in general suppress sending an RTCP NACK. Hence having the FT 1 forwarding the first received RTCP NACK(s) from an RTP_Rx to the DS which then reflects/forwards the NACK over the original SSM, is the correct thing to do from that point of view. However, the reflection /forwarding of the NACK by the DS means that also the RTP_Rx's reporting to the FT 2 will suppress sending an RTCP NACK for packet N in the SSM. As a consequence, a packet loss event involving an RTP packet with SN N impacting a single RTP_Rx reporting to FT 2 / RS 2 -e.g. due to a link transmission error- will not be reported by this RTP_Rx to RS 2. This means there is a discrepancy between the network reach of the suppression (covering all SSM receivers) and the actual network domain 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. Note also that an unsolicited retransmission by RS 1 optionally following the loss detection for packet with SN N -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 multicast retransmission session sourced by the RS). SSM with multiple disjoint unicast FTs hence may result in efficient feedback storm suppression across all RTP_Rx's, but this also prevents any RTP_Rx from sending an RTCP NACK for detected packet loss, even when no feedback storm was imminent for the subdomain covered by a particular FT. A solution for maximizing 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 RTP_Rx's. However, this unnecessarily loads the network and requires all the SSM RTP receivers to join both a primary SSM and the multicast retransmission session. 5.4. Takeaways The general conclusion from these three scenarios is that feedback suppression enabled by having the DS forwarding/reflecting RTCP Messages received from the RTP_Rx's or (disjoint) FTs is sometimes Begen & VanCaenegem Expires February 11, 2013 [Page 12] Internet-Draft Retransmission for SSM Sessions August 2012 the right thing to do, but sometimes feedback suppression is not appropriate and interferes in a negative way with the packet loss reporting and retransmission service. 6. Rules for SSM with Retransmissions 6.1. Feedback Suppression Behavioral Requirements for DS, FT and RTP_Rx's The combination of the [RFC4585] suppression rule imposed on RTP_Rx's and the behavior of the DS and the FT(s) -when disjoint from the DS- as specified in [RFC5760], does result in non-ideal situations when deploying an SSM RTP session with Retransmission Server(s), especially for a large group of receivers. In this section we provide some rules for DS and FT on the one hand and RTP_Rx's on the other hand, which impose a deviation respectively from rules defined in [RFC5760] and [RFC4585] , and which results in: o All RTP_Rx's offering the opportunity to report detected packet loss by means of RTCP NACK when there is no risk on feedback implosion o RTCP NACK suppression (only) when RTCP NACK implosion is imminent o A better retransmission efficacy The rules apply to the transmission and handling of RTCP NACK messages by RTP_Rx's and FT, but similar rules may be applicable for other RTCP feedback messages that may or may not trigger dedicated service actions. Note that in the context of this document, the FT is part of a Retransmission Server, which is an RTP_Rx on its own. In the remainder of this text, the term 'RTP_Rx' always refers to any RTP receiver reporting to a FT/RS and which does not host a FT/RS functionality, unless mentioned otherwise. The rules are: 1. A FT/RS that is disjoint from the DS MUST NOT forward nor reflect RTCP NACK messages received from the RTP_Rx's, to the DS. This behavior for a FT operating in an SSM enabled with retransmission is different from the behavior prescribed by [RFC5760] for a FT with a primary SSM operating in Simple Feedback mode.This rule will prevent feedback suppression at the RTP_Rx's directly triggered by RTCP feedback messages sent by Begen & VanCaenegem Expires February 11, 2013 [Page 13] Internet-Draft Retransmission for SSM Sessions August 2012 other RTP_Rx's. 2. A disjoint FT MAY send either an RTCP NACK or a 3rd party loss RTCP feedback message, each time using its own SSRC, to the DS. Note : The third party loss message format is defined in [RFC6642]. This behavior for a FT operating in an SSM enabled with retransmission is different from the behavior prescribed by [RFC5760] for a FT with a primary SSM operating in Simple Feedback mode. This rule will enable feedback suppression in the group of RTP_Rx's reporting to this FT (see recommendation 5). The FT/RS will send an RTCP NACK or 3rd party loss message depending on the location of the packet loss event: * The FT/RS SHOULD send an RTCP NACK to the DS -using its own SSRC- when it detected packet loss itself (with the FT/RS acting as an RTP_Rx). * The FT/RS SHOULD send an RTCP NACK or a third party loss message to the DS -using its own SSRC- when it did not detect packet loss itself, but there is a risk on feedback implosion. Feedback implosion risk detection by the FT without detecting directly packet loss, can be based on monitoring the amount of arriving RTCP NACKs from RTP_Rx's reporting the same packet loss, and setting a threshold as function of the known amount of RTP SSM receivers reporting to this FT/RS. 3. A DS MUST forward/reflect any RTCP NACK or RTCP third party loss feedback message received from FT entities on the primary SSM RTP session 4. When capable of detecting packet loss in the RTP streams received from the media senders, the DS MUST send an RTCP NACK using its own SSRC on the primary SSM RTP session and to the media senders 5. An RTP_Rx receiving a third party loss message or RTCP NACK in the primary SSM RTP session MUST conform to the following behavior: If the SSRC identifier in the 'packet sender SSRC' field in the received RTCP feedback message matches either Begen & VanCaenegem Expires February 11, 2013 [Page 14] Internet-Draft Retransmission for SSM Sessions August 2012 * the SSRC of the (primary SSM) DS (this is the 'media sender SSRC') * or the SSRC that is used by the FT/RS entity to which the RTP_Rx reports (see next section) the RTP_Rx MUST follow the feedback suppression rule defined in [RFC4585], i.e. it abstains from sending an RTCP NACK for the same SN. If there is no match with these SSRC values, the RTP_Rx SHOULD NOT apply the [RFC4585] feedback suppression rule This behavior is different from [RFC4585], and prevents feedback suppression when there is no risk on feedback implosion. If the RTP_Rx does not know the value of the SSRC that is used by the FT/RS entity -in its role towards the DS- to which the receiver reports, it MAY still send its own RTCP feedback message, when having detected the same packet loss, but respecting the [RFC4585]timing rules. RTP_Rx's that do not know the value of the SSRC that is used by its FT/RS entity in its primary SSM role and abstain from sending an RTCP NACK message when receiving such a message, implement feedback suppression and behave as defined in [RFC4585]. The next section describes how an RTP_Rx knows the value of the SSRC that is used by the FT/RS entity to which the receiver reports 6.2. Informing RTP_Rx's with the SSRC Value of FT/RS There are different SSRC values that can be associated to the FT/RS: o As described in [RFC5760], in summary feedback model, the FT must act as a receiver and choose a unique SSRC for its own reporting towards the Distribution Source. If a FT acts strictly according to the Simple Feedback Model of [RFC5760], it does not need a unique SSRC. However, with the recommendation '2' of the previous section, the FT acts rather as translator when sending its own RTCP NACK or Third Party Loss message to the DS. The FT selects a SSRC value in its role as translator between the RTP_Rx's and the DS. o The FT is part of the RS and the RS will typically also act as RTP_Rx, being the most efficient way for obtaining and caching copies of RTP packets that are transmitted down the primary SSM Begen & VanCaenegem Expires February 11, 2013 [Page 15] Internet-Draft Retransmission for SSM Sessions August 2012 and providing retransmission from that RS. The RS selects a SSRC value in its role as RTP_Rx as well, when reporting to the DS. Nothing prevents this SSRC value to be the same as the SSRC value used by the FT entity. o An RS also takes a role as RTP sender towards each of the RTP_Rx's that established a unicast retransmission session. In this unicast retransmission session, the SSRC used by the RS is the same as the SSRC value used by the DS in the primary SSM RTP session, as per [RFC4588]. Note that the CNAME of the FT/RS associated with all these SSRC identifier values is one and the same. It is the SSRC value used by the FT acting as receiver/translator in the SSM with unicast feedback topology, that will be present in the 'Packet Sender SSRC' field of the RTCP NACK or Third Party Loss message forwarded by the DS to the RTP_Rx's. There can be several ways by which an RTP_Rx learns this SSRC value: 1. In-band : applies only for the Feedback Summary Model, where by means of a new RSI "FT SSRC list" message, the DS provides a listing of all deployed FT_Ap's with the corresponding SSRC for each of these FTs/RSs. FTs/RSs are identified by means of their IPv4/IPv6 address, optional port, and optional CNAME. The DS can learn the SSRC value chosen by a FT/RS by inspecting RTCP messages received from the FT. The DS sends regularly the RSI "FT SSRC list" message down the primary SSM, to give every RTP_Rx joining the SSM at a random time a chance to learn this SSRC value. 2. Application-specific : a specific extension can be defined for the RAMS-I message that signals the SSRC value associated with the FT in its role as reporter to the DS. This RAMS-I message is transferred in the Burst/Retransmission Session. 3. 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 RTP_Rx's. Begen & VanCaenegem Expires February 11, 2013 [Page 16] Internet-Draft Retransmission for SSM Sessions August 2012 6.3. Unsolicited Retransmissions The method of providing an (unsolicited) RTP retransmission packet to a set of RTP_Rx's enables loss recovery for packet loss events impacting a large set of receivers without risk for feedback implosion. Unsolicited retransmissions can be provided over each of the established unicast retransmission sessions or only once in a single multicast retransmission session, sourced either by the DS or by the RS. Providing (unsolicited) retransmissions over a separate multicast retransmission RTP session has the following advantages: o The retransmission packet is transmitted by the DS/RS only once, saving both network and server resources. o The multicast retransmission packet is less likely to be blocked by any intermediate gateway or a middlebox on the path between the DS/RS and RTP_Rx. o An RTP_Rx that joins the multicast retransmission RTP session via SFGMP, implicitly indicates it is willing to accept unsolicited retransmissions. The rules related to the feedback suppression in Section 6.1 do not impose an RS/DS implementation to provide (support for) unsolicited retransmissions. In this document, we assume that whenever the FT/ RS/DS supports solicited retransmission and it actively suppresses feedback by sending a RTCP NACK or 3rd party loss message, it might try to provide one or more subsequent unsolicited retransmissions. However, as it is the case with any RTP retransmission, such unsolicited retransmissions may or may not arrive at their destinations. The requirements for unsolicited retransmissions are: 1. Unsolicited retransmissions MAY be provided over a separate multicast retransmission that is sourced by the RS that also acts as retransmission server for the unicast retransmission sessions or by the DS that also sources the primary SSM session. 2. An RS SHOULD only send unsolicited retransmissions when it knows with a minimum certainty that the receiver has implemented feedback suppression for this specific packet (unicast retransmission) or a majority of the receivers have implemented feedback suppression (multicast retransmission). The same retransmission of a packet originally transmitted in the primary SSM can be sent in both a unicast retransmission session and multicast retransmission session. The RTP_Rx will handle these two Begen & VanCaenegem Expires February 11, 2013 [Page 17] Internet-Draft Retransmission for SSM Sessions August 2012 (solicited or unsolicited) packets as duplicate packets. Editor's note: Should we define a means by which an RTP_Rx can indicate it does not want to receive unsolicited retransmissions in the unicast retransmission session? 6.4. Congestion Control Considerations 6.4.1. Congestion Control in RFC 4585 and in RAMS The RAMS document indicates that an RTP SSM distribution equipped with a retransmission/burst server can work reliably in both engineered and best-effort networks. However, there is a difference in the core operation of RAMS and the core operation of a Retransmission-enabled SSM in terms of congestion risk and avoidance: 1. In RAMS, retransmission packets, constituting a burst from the RAMS server, are requested by an RTP_Rx prior to the moment the receiver joins the SSM session. The Retransmission server bursts the retransmission packets to the receiver and instructs the receiver when to join the SSM, which will take place near the end of this burst. The congestion control for the bursting process can hence be decoupled from the SSM distribution (and any congestion control taking place on the SSM). RAMS discusses in more detail how to limit the risk on congestion for the RAMS bursts, especially in a best effort environment. 2. When using retransmission service for an SSM, retransmission packets are transmitted to and received by an RTP_Rx, while the RTP_Rx also receives simultaneously the SSM RTP session. When used in best effort networks, packet losses can be caused by congestion or (access) transmission link errors. If packets in the SSM are dropped because of congestion, there is a good chance that a subsequent retransmission will actually exaggerate the congestion situation (this will depend on the relative positioning of the congestion, the RS and the RTP_Rx in the considered SSM topology). [RFC4588] section 7 states: 'In a best-effort environment, the sender SHOULD NOT send retransmission packets without reducing the packet rate and bitrate of the original stream (for example, by encoding the data at a lower rate).' In the context of SSM, some RTP_Rx's may observe packet loss (caused by congestion), other receivers receiving the same SSM may not. As the DS transmits a single original stream to all SSM receivers, the recommendation from [RFC4588] for the DS to adapt its packet rate whenever an RTP_Rx is reporting packet loss, will impact all SSM receivers. This would make SSM with retransmission service practically infeasible in best Begen & VanCaenegem Expires February 11, 2013 [Page 18] Internet-Draft Retransmission for SSM Sessions August 2012 effort networks. It is also important to note that the retransmission server/sender may be different from the DS sending the original stream, especially in large-scale SSM applications. Hence, to a large extent the SSM path from DS to an SSM receiver may be decoupled from the network path between RS and SSM receiver. I.e. it is quite possible that the congestion on the SSM does not impact the network path taken by the retransmission packet(s). For these reasons, a different recommendation is in place in terms of congestion handling when retransmission is applied in SSM with unicast feedback. 6.4.2. Congestion Handling for SSM with Retransmissions In this section we formulate a set of rules for the RS in order to be cautious that retransmissions will not contribute to enhanced congestion situations on the SSM path between DS and RTP_Rx, but without imposing an explicit role to the RS to assist in (helping to) relieve any (potential) congestion between DS and RTP_Rx. This results in a congestion control mechanism for an RS operating in an SSM deployment that is decoupled from the behavior of the DS which may use its own congestion control. Note: in this section only congestion on the path from the RS towards the RTP_Rx is considered. Congestion on the upstream path towards the FT/RS has been discussed in the context of feedback implosion risk and avoidance in the previous sections. Case: Unmanaged Networks The general requirement is that for unmanaged networks, an RTP retransmission server for an SSM RTP session SHOULD keep track, on a per RTP_Rx basis, of the recent retransmission request pattern for that RTP_Rx. The RS then behaves as follows: o Initially and when an RTP_Rx sends a retransmission request for the first time to the FT/RS, the RS SHOULD assume there is no congestion between the DS and the RTP_Rx, unless the RS has information deduced or received not by way of RTCP NACKs through which it can assume the SSM path is likely congested. Such non-RTCP feedback information can be information coming from RTCP RR, other RTCP messages or any out-of-band signaling from the receiver or other network elements. o An RS MAY respond to a retransmission request with one or more retransmission packets when the path from the DS to the RTP_Rx originating the request is assumed to be congestion free. Begen & VanCaenegem Expires February 11, 2013 [Page 19] Internet-Draft Retransmission for SSM Sessions August 2012 o When an RS observes an increasing amount of retransmission requests from a single receiver, while having serviced all or most retransmission requests from that receiver, or the server receives information in a way different from RTCP NACKs which predicts or indicates that congestion may likely occur, it SHOULD stop responding to retransmission requests from that receiver. Equally, the RS SHOULD NOT send unicast unsolicited retransmissions to such receiver. o When no other information is available, an RS MAY assume absence of congestion for an RTP_Rx when it has not received retransmission requests for a minimum duration of time. o An RS sending unsolicited retransmissions over a dedicated retransmission multicast SHOULD only do so when it knows this will not cause or contribute to congestion on the primary SSM path for the large majority of primary SSM receivers. Detailed algorithms by which a RS can declare an RTP_Rx in a congestion state, or free from congestion, are not elaborated further upon in this document. Note 1: an RS may correlate information it has on RTP_Rx's to make a judgement on congestion or congestion-free state of the SSM paths to other RTP_Rx's using the same RS. Note 2: any congestion handling policy is orthogonal to any other policy maintained at the RS having to do with retransmission service access control e.g. using access control lists, IP anti-spoofing measures, authentication, etc. Note 3: an algorithm similar to the one described above for congestion handling, but to handle a denial of service attack MAY be considered for the RS implementation, next to the other security considerations related to retransmission as discussed in section 12 in [RFC4588]. Equivalent requirements are formulated for an RTP_Rx in an unmanaged network, where retransmission is enabled: o An RTP_Rx which senses that the net throughput of the combination of original RTP packets and retransmission packets decreases over time with increasing amount of retransmission requests and subsequent retransmissions, SHOULD cease making retransmission requests. o An RTP_Rx may re-start sending out retransmission requests once the original SSM session is received with close-to-zero packet Begen & VanCaenegem Expires February 11, 2013 [Page 20] Internet-Draft Retransmission for SSM Sessions August 2012 loss, and where any optional sporadic packet loss can be assumed to be attributed to link transmission errors. Case: Managed Networks For managed networks congestion should not happen on the SSM path or otherwise be a rare event. [RFC4588] states : 'If enhanced service is used, it should be made sure that the total bitrate and packet rate do not exceed that of the requested service. It should be further monitored that the requested services are actually delivered.' Note: The total bitrate and packet rate is the original data (or primary data) and retransmission data. This means that the network is engineered to make sure that the combined SSM packets and retransmission packets on the network paths to any RTP_Rx will not be impacted by congestion. An alternative approach is to engineer the network for the congestion-free transmission of the primary SSM data, where-as retransmissions are delivered without dedicated bandwidth engineering provisions or otherwise with limited engineering provisions, in a sense that up to a certain maximum rate and up to certain maximum burst size, the retransmission traffic can be delivered on a congestion-free path. In the engineered case for SSM where retransmissions are not taken into account for the bandwidth provisioning, the chance on having congestion in the retransmission session for SSM enabled with retransmission-only service is expected to be smaller compared to an SSM enabled with RAMS service. This is because a single RAMS-R request results in a burst of packets in the retransmission session whereas retransmissions requests typically results in the transmission of only one or several retransmission packets, with retransmission requests being sporadic. 6.5. New RSI Message and RAMS-I TLV Extension 6.5.1. RSI Message 'FT SSRC List' TBD. 6.5.2. RAMS-I TLV Extension 'FT SSRC' TBD. Begen & VanCaenegem Expires February 11, 2013 [Page 21] Internet-Draft Retransmission for SSM Sessions August 2012 7. Security Considerations Editor's note: A subset of the security aspects discussed in the RAMS specification also applies to this document. TBC. 8. IANA Considerations TBC. 9. RTP Retransmission Service in DVB IPTV RTP retransmission for linear IPTV streams has been specified in Annex D of [DVB-IPTV]. This ETSI document, produced by the DVB Technical Module on IP-Infrastructure (TM-IPI) specifies the interface of a managed IPTV service client, commonly called the Home Network End Device or HNED in DVB IPTV terms. The DVB IPTV RTP retransmission solution in Annex D references [RFC3550], [RFC4585], [RFC4588] and the [RFC5760]. Its solution is hence very well aligned with the IETF RTP specifications and addresses feedback implosion and feedback suppression in a similar way as described in this document: o The DVB Linear Media Broadcast (LMB) services are delivered over an RTP SSM that operates according to the summary feedback model defined in [RFC5760] o RTCP NACK messages transmitted by HNEDs towards the FT('s) are not forwarded over the primary RTP SSM. o An HNED enables feedback suppression when receiving an RTCP Feedforward message from the network. This RTCP Feedforward (FF) message has the same format as an RTCP NACK message. o The RTCP FF message stems from a 'so-called' upstream reporter (having its own SSRC identifier, signaled to the HNEDs in a DVB IPTV specific way) , which represents the Retransmission Server in its role as primary RTP_Rx. Alternatively the RTCP FF message is transmitted by the RS acting as RTP translator when the RS assumes a packet loss event took place that is impacting many HNEDs, but not the RS (as RTP_Rx) itself. o This RTCP FF message may be sent in the primary RTP SSM but may also be sent in a dedicated RTP SSM sourced by the Retransmission Server. o In order to better control and allow the Retransmission Server to better recognize potential feedback implosion situations, an Begen & VanCaenegem Expires February 11, 2013 [Page 22] Internet-Draft Retransmission for SSM Sessions August 2012 optional feature has been defined. A subset of RTP_Rx can act as immediate reporters (which do not follow the dithering transmission timing rules from [RFC4585]), and will send an RTCP NACK message immediately upon packet loss detection. Whether an HNED acts as immediate reporter or not is determined by whether its randomly chosen SSRC identifier value maps to a pre-defined SSRC mask/pattern that is signaled to all HNEDs. 10. Contributors TBC. 11. References 11.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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [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. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [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. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Begen & VanCaenegem Expires February 11, 2013 [Page 23] Internet-Draft Retransmission for SSM Sessions August 2012 Specific Multicast", RFC 4604, August 2006. [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping between Unicast and Multicast RTP Sessions", RFC 6284, June 2011. [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 2011. [RFC6642] Wu, Q., Xia, F., and R. Even, "RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report", RFC 6642, June 2012. 11.2. Informative References [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. [I-D.ietf-fecframe-dvb-al-fec] Begen, A. and T. Stockhammer, "Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection", draft-ietf-fecframe-dvb-al-fec-04 (work in progress), December 2009. [DVB-IPTV] "ETSI TS 102034 Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks", August 2009. Authors' Addresses Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada Email: abegen@cisco.com Begen & VanCaenegem Expires February 11, 2013 [Page 24] Internet-Draft Retransmission for SSM Sessions August 2012 Tom VanCaenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen, 2018 Belgium Email: Tom.Van_Caenegem@alcatel-lucent.com Begen & VanCaenegem Expires February 11, 2013 [Page 25]