Network Working Group Q. Wu Internet-Draft F. Xia Intended status: Standards Track R. Even Expires: August 26, 2010 Huawei February 22, 2010 Proposal for an extension to RTCP for Retransmission Storm Suppression of RTP Stream draft-wu-avt-retransmission-supression-rtp-00 Abstract This document extends Receiver Summary Information (RSI) report block to define a new sub-report block for retransmission suppression within the framework of RTP retransmission. One of initial retransmission requests for the missing packets is RTCP NACK. This feedback message conveys packet loss events. Unlike NACK, this new sub-report block, which is referred to as the Retransmission Storm Suppression Report, also carries the information regarding retransmission suppression early indication events to the receiver before the receiver detects an original packet loss and all the packet loss repair methods are applied. By using Retransmission Suppression together with NACK, the delay for the receiver to recover from the packet loss can be reduced and the risk of increasing network congestion can be mitigated or avoided. This document also registers a new sub-report block type for Retransmission Storm Suppression within RTP retransmission framework. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 Wu, et al. Expires August 26, 2010 [Page 1] Internet-Draft Retransmission Suppression February 2010 http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 26, 2010. Copyright Notice Copyright (c) 2010 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 BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Wu, et al. Expires August 26, 2010 [Page 2] Internet-Draft Retransmission Suppression February 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Basic Operation . . . . . . . . . . . . . . . . . . . . . . . 5 4. Sub-Report Block for Retransmission Suppression Early Indication . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Example scenarios for Retransmission Storm Suppression . . . . . . . . . . . . . . . . . . . . . 8 A.1. Scenario 1: One media Sender, one Distribution Source . . 8 A.2. Scenario 2: One Media Sender, more distribution sources . 8 Appendix B. Applicability of Retransmission Suppression Early Indication . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Wu, et al. Expires August 26, 2010 [Page 3] Internet-Draft Retransmission Suppression February 2010 1. Introduction RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds [RFC4588],e.g., streaming media. The conventional RTCP feedback (NACK) message that indicates the sequence number of the lost RTP packets can be used to request the retransmission of the missing packets [RFC4585]. This RTCP NACK message conveys the RTP sequence number of the lost packets and request the sender to compensate the missing RTP packets based on the RTP sequence number of these packets. However, in lots of multicast environments, packet loss occurs between the media sender and the intermediate network element (e.g., Distribution Source) due to oversaturated network link, faulty networking hardware or corrupted packets rejected in-transit. It may result in retransmission storm targeting at the same sender, i.e., massive retransmission request for the same RTP packets through RTCP NACK to the same multicast sender. To increase the robustness to the loss of a NACK or of a retransmission packet, a receiver may also send multiple NACKs for the same packet. As the retransmission storm progresses, the network is overwhelmed with constant retransmission traffic, in the worsening case, RTP retransmission poses a risk of increasing network congestion, with excessive traffic and degrading network performance, this can eventually lead to a complete loss of network connectivity as the retransmission packets proliferate, the network may become unusable. In order to solve this, the current text in RTCP-SSM allows the distribution source to filter out the NACK messages while this document propose an option to let the receivers know that NACK is not needed in the specified cases. i.e., generating a new RSI sub-report block, which reflects the packet receipt/loss events before the receiver detects an original packet loss and retransmission suppression early indication events before all the packet loss repair methods are applied. This new RSI sub-report block, which we refer to as Retransmission Suppression Early Indication, indicates suppressing requests for transmission of lost packets before the receiver sends a NACK for those packets. In order to detect the original packet loss in the upstream direction before the receiver perceives it, the distribution source located between the sender and receiver may reserve space to replicate one copy of multicast data and check the sequence number consistency of the original multicast packets. Also the distribution source should take into account such factors as the tolerable application delay, the network environment, and the media type. When the packet loss is detected immediately and initial latency is tolerable, in the upstream direction towards the sender, the Wu, et al. Expires August 26, 2010 [Page 4] Internet-Draft Retransmission Suppression February 2010 distribution source may ask for retransmission of the lost packet from the sender using RTCP NACK, in the meanwhile, in the downstream direction from the sender, the distribution source may convey Retransmission Suppression Indication to all the receivers concerned to indicate the receiver not to request packet retransmission. When the sender receives the packet retransmission request from the distribution source, the sender resends the missing packet to the receiver via RTP using retransmission payload format [RFC4588]. Similar to RTCP NACK, the Retransmission Suppression Early Indication also conveys the packet receipt/loss events at the packet level and considers missing packets as unrepaired. But different from RTCP NACK, the retransmission Suppression Early Indication is used by the intermediate network element to suppress retransmission from the receiver and can not be taken as feedback-based error repair mechanism but network based packet loss repair method. Note that the retransmission suppression Early Indication should collectively work together with RTCP NACK to repair the lost source packets. Thus, the delay for the receiver to recover from the packet loss can be reduced and the risk of increasing network congestion can be mitigated or avoided. The receive may send a NACK message before receiving the indication but will not need to resend the NACK message after receiving the indication. Also the idea of retransmission Suppression Early Indication can be further extended when the distributed content distribution network are considered. That is to say several distribution sources and media senders may constitute one hierarchical model. In this distributed hierarchical content distribution environment, the Retransmission Suppression Early Indication not only can be used to suppress all the receivers behind itself not to send NACK but also suppress the neighboring nodes not to send NACK for the missing packets via unicast. How the neighboring node is discovered is beyond scope of this document. This document registers a new sub-report block type for Retransmission Storm Suppression within RTP retransmission framework. Applications that are employing one or more loss-repair methods MAY use retransmission Suppression Early Indication approach together with these loss-repair methods for every packet they receive or for a set of specific packets they have received. 2. Terminology The keywords "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]. Wu, et al. Expires August 26, 2010 [Page 5] Internet-Draft Retransmission Suppression February 2010 3. Basic Operation The new sub-report block of the retransmission suppression Early Indication (RSEI) will work in Simple Feedback and in Distribution Source Feedback Summary Models defined in [I-D.ietf-avt-rtcpssm]. The distribution source will include the support for retransmission as part of the offered SDP and will expect such support from the Media Sender. The distribution source may send this new sub-report block RSEI to the receivers when detecting a loss on its incoming link while send a NACK to the media sender. The distribution source may receive NACK messages from the receivers and may filter them out if it already sent a NACK for the requested packet to the media source. If the receiver understands this message it will not send NACKs for the missing packets reported in the message and will accept a retransmission stream. The receiver may send NACK messages if it did not understand this new message. 4. Sub-Report Block for Retransmission Suppression Early Indication The Retransmission suppression Early Indication (RSEI) sub-report block uses the similar format of sub-report block specific to the RSI packet defined in the section 7.1.2 of [I-D.ietf-avt-rtcpssm]. The report format is shown in Figure 1. Using this RSEI sub-report block with RTCP NACK can efficiently prevent Retransmission Storm to happen. The format of this sub-report block is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRBT(RSEI) | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLSN | LLSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format for the RSEI sub-report block SRBT:8bits Report block type for retransmission Suppression Early Indication. Wu, et al. Expires August 26, 2010 [Page 6] Internet-Draft Retransmission Suppression February 2010 Length:8bits The length of the sub-report in 32-bit words. Reserved:16bits Starting Loss Sequence Number (SLSN):16bits The SSN field is used to specify the contiguous packet lost. The SSN field refers to the RTP sequence number of the first lost packet. Last Loss Sequence Number (LLSN): 16 bits The LSN field is used to specify the contiguous packet loss. The LSN refers to the RTP sequence number of the last lost packet. 5. SDP Signaling No new parameter needs to be defined for the Retransmission Storm Suppression Indication message to be used with Session Description Protocol (SDP) [RFC4566]using the Augmented Backus-Naur Form (ABNF) [RFC5234]. It uses the same syntax within the "rtcp-unicast" attribute [I-D.ietf-avt-rtcpssm]. Refer to Section 10.1 of [I-D.ietf-avt-rtcpssm] for a detailed description and the full syntax of the "rtcp-unicast" attribute. 6. IANA Consideration New sub-report block types for RTCP RSI block are subject to IANA registration. For general guidelines on IANA considerations for RTCP RSI, refer to [I-D.ietf-avt-rtcpssm]. This document assigns the sub-report block type (SRBT) value x in the RTCP RSI sub-report Block Type Registry to "Retransmission Storm Suppression Indication Report Block", with the following registrations format: Name: RSEI Long name: Retransmission Suppression Early Indication Value: TBD Reference: This Document. The contact information for the registrations is: Wu, et al. Expires August 26, 2010 [Page 7] Internet-Draft Retransmission Suppression February 2010 Qin Wu sunseawq@huawei.com Site B, Floor 12F,Huihong Mansion, No.91,Baixia Rd. Nanjing, JiangSu 210001 China 7. References 7.1. Normative References [I-D.ietf-avt-rtcpssm] Ott, J., Chesterfield , J., and E. Schooler, "RTCP Extensions for Single- Source Multicast Sessions with Unicast Feedback", September 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 7.2. Informative References [I-D.hunt-avt-monarch-01] Hunt, G. and P. Arden, "Monitoring Architectures for RTP", August 2008. [I-D.ietf-pmol-metrics-framework-02] Clark, A., "Framework for Performance Metric Development". Wu, et al. Expires August 26, 2010 [Page 8] Internet-Draft Retransmission Suppression February 2010 Appendix A. Example scenarios for Retransmission Storm Suppression A.1. Scenario 1: One media Sender, one Distribution Source The general architecture is displayed below in Figure 2. In this figure, one or more Media Senders send RTP packets to the Distribution Source. The Distribution Source relays the RTP packets to the receivers using a source-specific multicast channel. In the reverse direction, the receivers transmit RTCP packets via unicast to the distribution source. The Distribution Source in turn relays RTCP packets to the media sender and then transmits the RTCP packets back to the receivers, using source-specific multicast. When packet loss happens between Media sender and distribution source, it may result in massive retransmission request for the same RTP packets from all the receivers using RTCP NACK to the same multicast sender. We refer to it as Retransmission Storm. +-------+ |---->|RTP_Rx1| +--------+ | +-------+ | | +--------------+ | | | | | | +-------+ | Media |-------| Distribution |-------|---->|RTP_Rx2| | | | Source | | +-------+ | Sender | | | | . | | +--------------+ | . | | | . +--------+ | +-------+ |---->|RTP_Rxn| +-------+ Figure 2: One media Sender, one Distribution Source A.2. Scenario 2: One Media Sender, more distribution sources The hierarchical model is displayed below in Figure 3. In this figure, one media sender and two Distribution source constitute one hierarchical model. In this model, one Media Senders send RTP packets to two Distribution Sources respectively. These Distribution Sources relay the RTP packets respectively to the receivers behind itself using a source-specific multicast channel. In the reverse direction, the receivers transmit RTCP packets via unicast to the distribution source. The Distribution Source in turn relays RTCP packets to the media sender and then transmits the RTCP packets back to the receivers, using source-specific multicast. When packet loss happens between Media sender and distribution source, it may result in massive retransmission request for the same RTP packets from all the receivers using RTCP NACK to the same multicast sender. We refer Wu, et al. Expires August 26, 2010 [Page 9] Internet-Draft Retransmission Suppression February 2010 to it as Retransmission Storm. +--------+ |---->|RTP_Rx11| | +--------+ +--------------+ | | | | +--------+ |--->| Distribution |----|---->|RTP_Rx12| | | Source1 | | +--------+ | | | | . +--------+ | +--------------+ | . | | | | . | | | | +--------+ | Media | | |---->|RTP_Rx1k| | |---| +--------+ | Sender | | +--------+ | | | |---->|RTP_Rx21| | | | | +--------+ +--------+ | +--------------+ | | | | | +--------+ | | Distribution |----|---->|RTP_Rx22| |--->| Source2 | | +--------+ | | | . +--------------+ | . | . | +--------+ |---->|RTP_Rx2j| +--------+ Figure 3: One Media Sender, more distribution sources Appendix B. Applicability of Retransmission Suppression Early Indication This document defines new RTCP RSI sub-report block, which we refer to as Retransmission Suppression Early Indication to deal with Retransmission Storm mentioned above. Here we give two examples to show how this new RTCP sub-report block is applied into two scenarios described in section A.1 for Retransmission Storm Suppression. Applicability of Retransmission Storm Suppression in Scenario 1 described in Figure 2 is shown in the Figure 4. In this figure, the distribution source detect the packet loss before the receiver perceive it and ask for retransmission of the missing packets from the media sender, in the meanwhile, the distribution source transmits the RTCP Retransmission Storm Suppression Indication back to the receivers using source-specific multicast channel. In this way, the Wu, et al. Expires August 26, 2010 [Page 10] Internet-Draft Retransmission Suppression February 2010 delay for the receiver to recover from the packet loss can be reduced and the risk of increasing network congestion can be mitigated. +------+ +--------------+ +--------+ |Media | | Distribution | | | |Sender| | Source | | RTP_Rx | +--+---+ +------+-------+ +---+----+ | | | | | | |------------------->|------RTP Multicast---->| | | | | | | | +--------+----------+ | | |Detect Packet Loss | | | |and Identify the SN| | | |of missing Packets | | | +--------+----------+ | |<-----RTCP NACK-----| | | | | | +--Multicast RTCP RSSI-->| | RTP Retransmission | | |------------------->| | | |------RTP Multicast---->| | | Retransmission | | | | | | | | | | Figure 4: Applicability of Retransmission Suppression Early Indication Applicability of Retransmission Storm Suppression in Scenario 2 described in Figure 3 is shown in the figure A.2.2. The procedure in the figure A.2.2 is similar to the one in the figure Figure 5. The only difference is distribution source should not only notify all the receiver behind itself not to send NACK but also propagate the retransmission suppression indication to the neighboring distribution sources. In this way, all the receivers behind all the neighboring distribution source can avoid sending massive retransmission request to the media sender. Wu, et al. Expires August 26, 2010 [Page 11] Internet-Draft Retransmission Suppression February 2010 +------+ +-------+ +--------+ +-------+ +--------+ |Media | | | | RTP_Rx | | | | RTP_Rx | |Sender| | DS1 | | (DS1) | | DS2 | | (DS2) | +--+---+ +---+---+ +---+----+ +---+---+ +---+----+ | | | | | | |RTP Multicast | | | |----------->|------------->| | | | | | | | | | | |RTP Multicast| |------------------------------------------->|------------>| | | | | | | +--------+------------+ | | | | |Detect Packet Loss | | | | | |and Identify the SN | | | | | |of the missing Packets | | | | +--------+------------+ | | | | | | | | |<-RTCP NACK-| Multicast RTCP RSSI | | | |------------->| | | | | | | | | |-----Unicast RTCP RSSI-------->|Multicast RTCP RSSI | | | |------------>| |RTP Retransmission | | | |----------->| | | | | | | | | | | RTP Retransmission | | |------------+--------------+--------------->| | | | | | | | | RTP Multicast| | RTP Multicast | |Retransmission| |Retransmission | |------------->| |------------>| | | | | | DS1: Distribution Source 1 DS2: Distribution Source 2 Figure 5: Applicability of Retransmission Suppression Early Indication Wu, et al. Expires August 26, 2010 [Page 12] Internet-Draft Retransmission Suppression February 2010 Authors' Addresses Qin Wu Huawei Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd. Nanjing, Jiangsu 21001 China Phone: +86-25-84565892 Email: sunseawq@huawei.com Frank Xia Huawei 1700 Alma Dr. Suite 500 Plano, TX 75075 USA Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel Email: even.roni@huawei.com Wu, et al. Expires August 26, 2010 [Page 13]