Network Working Group H. Chao, Ed. Internet-Draft Alcatel-Lucent Shanghai Bell Intended status: Standards Track Co., Ltd. Expires: May 9, 2013 November 5, 2012 Extension of RTP for SVC and MVC with usage of ECN draft-hua-avt-rtp-svcmvc-00 Abstract This memo specifies how to support RTP packet stream thinning (or rate adaptation) and Explicit Congestion Notification (ECN) with the Real-time Transport Protocol (RTP) running over UDP to make effect in parallel with reliable RTCP report to the RTP sender. It introduces "dummy RTP packets" into the single-session transmission (SST) mode for Scalable Video Coding (SVC) and Multiview Video Coding (MVC). The reactions of RTP receivers upon receiving the "dummy RTP packets" are defined. The document also recommend to extend the ECN functionalities based on the scalability feature of SVC and MVC. 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 May 9, 2013. Copyright Notice 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 Chao Expires May 9, 2013 [Page 1] Internet-Draft Extension of RTP for SVC/MVC November 2012 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 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . . 4 1.2.1. Definitions Specific to This Memo . . . . . . . . . . . 4 2. Discussion and Design Rationale . . . . . . . . . . . . . . . . 4 2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Interoperability . . . . . . . . . . . . . . . . . . . . . 5 3. RTP extension for ECN . . . . . . . . . . . . . . . . . . . . . 5 4. Use of ECN with RTP/UDP/IP for SVC and MVC . . . . . . . . . . 5 4.1. Setting ECN-CE within an RTP Session . . . . . . . . . . . 6 4.2. Reporting ECN Feedback via RTCP . . . . . . . . . . . . . . 6 4.3. Response to Congestion Notifications . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Chao Expires May 9, 2013 [Page 2] Internet-Draft Extension of RTP for SVC/MVC November 2012 1. Introduction The SVC and MVC bring new challenges for the ECN design. Based on congestion control principle, media-aware network elements (MANEs) may perform media-aware stream thinning i.e. selective removing incoming RTP packets or portions thereof. It implies that MANEs may need to rewrite the RTP header as defined in RFC 6190 [RFC6190]. During the period of stream thinning making effect, routers in the video transmission path may apply ECN due to their impending congestion and indicate to the RTP sender. In this situation, as the RTP receiver does not aware the removing of RTP packets the MANEs have done, it will not counter the dropped RTP packets by the MANEs when calculating parameters of the RTCP signaling (specified as ECN feedback report and ECN summary report, see [RFC6679] for details) e.g. "ECT(0) Counter", "ECT(1) Counter", "Lost Packets Counter". As a result, the RTCP reports from the RTP receiver to the RTP sender are not accurate and reliable for SVC and MVC streams. Based on above considerations, mechanisms defined in this document aim to improve the accuracy of RTCP reports for SVC and MVC streams over UDP and in return help the RTP sender to achieve a better rate adaptation or congestion control effect. The document recommends to improve current stream thinning or rate adaptation schemes in MANEs for SVC or MVC bitstreams. It introduces "dummy RTP packets" into the single-session transmission mode. The reactions of RTP receivers upon receiving the "dummy RTP packets" are also defined. The document recommends to extend the ECN functionalities based on the scalability feature of SVC and MVC. Corresponding behaviours of routers or other network element with ECN capability are defined. The behaviours of receivers upon receiving ECN-CE marked packet are also specified. 1.1. Background The mechanisms defined for ECN provide in-band ways to indicate congestion before packet loss occuring. Two bit ECN field was defined for IP packets to indicate ECN-capable packets as well as ECN-CE marked packets. In addition to the functionality given by the ECN field in the IP packet header, ECN requires support from the transport protocol to inform the sender that ECN-CE marked packets are being received. As regards to TCP, RFC 3168 [RFC3168] specifies the incorporation of ECN to TCP and IP. It leaves issues of ECN in other transport protocols to further research. UDP-based transports, such as RTP [RFC3550], faces challenges to use Chao Expires May 9, 2013 [Page 3] Internet-Draft Extension of RTP for SVC/MVC November 2012 ECN due to lack of feedback mechanisms directly in UDP. Later on, [RFC6679] defines how ECN can be used with RTP over UDP. By using RTCP as a feedback mechanism, both periodic ECN feedback and timely report of congestion events are supported. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback and a new RTCP transport feedback message for timely reporting of congestion events. As defined in RFC 6190 [RFC6190] and [I-D.ietf-payload-rtp-mvc] both single session transmission (SST) and multi-session transmission (MST) are defined for SVC and MVC. In the case of SST all SVC or MVC data are carried in a single RTP session. In the case of MST two or more RTP sessions are used to carry the SVC or MVC data. 1.2. Terminology and Abbreviations 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]. The abbreviations and definitions "Sender", "Receiver", "ECN Capable Packets", "ECN-CE" and "not-ECT Packets" in this document are to be interpreted as described in [RFC6679]. The abbreviations and definitions "Enhancement layer", "Empty NAL unit", "MANE", "Multi-session transmission", "RTP packet stream" and "single-session transmission" are to be interpreted as described in [RFC6190]. The abbreviations and definitions "Base view", "non-base view", are to be interpreted as described in [I-D.ietf-payload-rtp-mvc]. 1.2.1. Definitions Specific to This Memo Dummy RTP packet: For a given RTP packet, a dummy RTP packet replaces the payload of one or more NAL units with an empty NAL unit. 2. Discussion and Design Rationale 2.1. Assumptions Before the descriptions of the solutions defined in this document, work assumptions of this document are listed as bellow. o Assumption1: One SVC or MVC bitstream could consist of one or more RTP sub- streams, i.e. single-session transmission (SST) mode or multiple-session transmission (MST) mode in other words. In this document we only consider the SST transmission mode. Chao Expires May 9, 2013 [Page 4] Internet-Draft Extension of RTP for SVC/MVC November 2012 o Assumption2: The solutions defined in this document are complied with the four different pieces (as specified by Section 4 in [RFC6679]) that together make the solution for using ECN with RTP over UDP/IP work. o Assumption3: This document assumes that initiation of ECN usage in one or more RTP Sessions is finished. Receivers tell the sender that their paths support ECN. And the RTP sender makes the decision to use ECN (otherwise the problems proposed to solve in this document do not exist) by setting ECT(0) or ECT(1) codepoint in the corresponding IP packet flow. 2.2. Interoperability For interoperability we mandate both the implementation of RTCP XR extension for periodic ECN feedback purpose and the ECN feedback format, which require the RTP/AVPF profile to ensure timely feedback. 3. RTP extension for ECN The scalability features of SVC and MVC enable the adapation functionality to be performed at the RTP sender, the RTP receiver or in MANEs. The MANEs can find that the RTP sender uses ECN when receiving IP packets marked as ECT(0) and ECT(1). For these IP packets, when MANEs perform the stream thinning, the basic operation of adaptation (or stream thinning) is improved to avoid full RTP packet removing. When an MANE finds a full RTP packet needs to be removed, it replaces the RTP packet with a dummy RTP packet instead of removing it at all. It means that the dummy RTP packet contains the same RTP header as the original RTP packet and includes a single empty NAL unit. When MANEs find that part of a RTP packet (i.e. one or more NAL units) needs to be removed the operation of stream thinning remain the same as today. As empty NAL unit is only defined for MST mode today [RFC6190], this document extends the usage of empty NAL units to SST mode. 4. Use of ECN with RTP/UDP/IP for SVC and MVC In this section, the solutions of this document are described in details. Below, behaviour of different network elements are described in separate subsections. Chao Expires May 9, 2013 [Page 5] Internet-Draft Extension of RTP for SVC/MVC November 2012 4.1. Setting ECN-CE within an RTP Session In this subsection, the behaviour of the routers or other network elements with ECN functionality in the video stream transmission path are defined. A router could decide to select more than one enhancement layers or non-base views to set the CE codepoint. This method can trigger multiple different congestion events. For each selected layer or non-base view, one router could set the CE codepoint for more than one IP packet. Especially for routers or network elements within radio network, we recommend setting two or three packets in the time order for each selected layer or non-base view to avoid packet loss due to the time-varying of wireless channel. 4.2. Reporting ECN Feedback via RTCP In this subsection, the behaviour of the receivers are defined. When receiving the dummy RTP packets, the receiver records the IP and RTP header for future ECN usage and does not use them for video decoding. The receiver should counter the dummy RTP packets when calculates the parameters of the ECN reports. Especially, the dummy RTP packets should be countered into the parameter of "ECT(0) Counter", "ECT(1) Counter", "ECN-CE Counter" and "Lost Packets Counter". An immediate or early (depending on the RTP/AVPF mode defined in [RFC4585]) ECN feedback report should be generated on receipt of the first ECN-CE marked packet. The early ECN feedback report metioned in this document complies with the available IETF mechanism. For each new received ECN-CE marked packet, the receiver shall determine whether the new arriving packet belongs to an existing congestion event or is a new congestion event. The receiver only needs to generate ECN feedback reports for new congestion events to avoid unnecessary ECN feedback reports. The principles are: a. The receivers always treat different ECN-CE marked packet of different layers or non-base view as different congestion events. b. For the ECN-CE marked packets of the same layer or the same non- base view, the receiver calculates the reception time of the new arriving ECN- CE marked packet, i.e. T_new. It compares the T_new with the reception time of the previous arrived ECN-CE marked packet i.e. T_old. If the T_new < T_old + RTT, then the Chao Expires May 9, 2013 [Page 6] Internet-Draft Extension of RTP for SVC/MVC November 2012 new arriving ECN-CE marked packet is considered to belong to the same congestion event. Otherwise, it is considered as a new congestion event. T_odd is the reception time of a previous ECN-CE marked packet of the same layer or non-base view. RTT is the Round Trip Time between the RTP sender and the RTP receiver. 4.3. Response to Congestion Notifications In this subsection, the behaviour of the sender is defined. Upon receiving ECN feedback reports from the UE, the RTP sender inputs the ECN feedback reports into its congestion control or rate adaptation algorithms and acts as if packet loss is detected. With multiple ECN feedback reports for the same RTP packet stream, we believe that the RTP sender will get a reference to perform proper congestion control or rate adaptation. More amount of ECN feedback reports will contribute to quicker congestion control or rate adaptation effect but will bring more quality loss. The trade-off details are algorithm-dependent and are not included in this document. 5. Acknowledgements TBD. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations The security considerations of the RTP Payload Format for SVC Video specification [RFC6190] apply. The security considerations of the ECN for RTP over UDP draft [RFC6679] apply. 8. References 8.1. Normative References [I-D.ietf-payload-rtp-mvc] Wang, Y., Schierl, T., Skupin, R., and P. Yue, "RTP Payload Format for MVC Video", draft-ietf-payload-rtp-mvc-02 (work in progress), Chao Expires May 9, 2013 [Page 7] Internet-Draft Extension of RTP for SVC/MVC November 2012 June 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 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. [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, May 2011. [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, August 2012. 8.2. Informative References [I-D.carlberg-tsvwg-ecn-reactions] Carlberg, K. and P. O'Hanlon, "Reactions to Signaling from ECN Support for RTP/RTCP", draft-carlberg-tsvwg-ecn-reactions-03 (work in progress), October 2012. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. Chao Expires May 9, 2013 [Page 8] Internet-Draft Extension of RTP for SVC/MVC November 2012 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006. Author's Address Hua Chao (editor) Alcatel-Lucent Shanghai Bell Co., Ltd. Shanghai, China Phone: +86 21 38436338 Email: hua.chao@alcatel-sbell.com.cn Chao Expires May 9, 2013 [Page 9]