Audio/Video Transport P. Yang Internet-Draft Y. Hu Intended status: Standards Track Huawei Technologies Co., Ltd. Expires: January 10, 2011 July 9, 2010 RTP Extension Header for Selective Transmission draft-yang-avt-selective-transmission-01.txt Abstract When network congestion occurs or dynamic transient burst stream transfers on a bandwidth constrained network, it is easy to cause bursts of consecutive packet loss. Video streams are very vulnerable to packet loss because of motion compensation predictive coding at the decoder. In this document, we describe a method of using selective transmission to decrease the effect of random drop to video stream when necessary. At the same time, this document describes a method to avoid retransmission request due to selective transmission. 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 January 10, 2011. 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 Yang & Hu Expires January 10, 2011 [Page 1] Internet-Draft Selective transmission July 2010 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Selective transmission Mechanism Description . . . . . . . . . 4 5. The use case of network congestion . . . . . . . . . . . . . . 5 6. RTP Packet Format . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Selective Transmission Notification Indication . . . . . . 6 7. Signaling Information . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Yang & Hu Expires January 10, 2011 [Page 2] Internet-Draft Selective transmission July 2010 1. Introduction When a congestion event in the network occurs, it tends to result in a burst of successive packet loss. Real-time video services is very vulnerable to packet loss of reference frame even if a single packet loss of reference frame occurs, because video compression coding makes use of Motion-Compensated Predictive Coding at the decoder. A burst of consecutive packet loss is more likely to cause the loss of reference frame which makes it difficult for the decoder to construct a picture. Though RTP retransmission [RFC4588] can partly solve this issue, the retransmission may cause more serious congestion if network congestion still exists. Therefore, it is necessary to utilize a new method to avoid the loss of the reference frame packets when a congestion event occurs. Packets of reference frame are normally important because they are used as a reference for predicting other pictures, while packets of predictive non-reference frame or reference frame which is used as references for only one or a few frames are less decoding-sensitive. For reference frame, intra frame is the best decoding-sensitive, predictive frames in turn reduce their sensitivity from the beginning to the end of GOP. Take an example, packets of I-frame is the best significant and decoding- sensitive; packets of P-frames in one GOP are also decoding- sensitive, decoding-sensitivity of P-frames in turn decrease from the beginning to the end of GOP; packets of non-reference B-frame are least decoding-sensitive; packets of reference B-frame is more decoding-sensitive than non-reference B-frame; We use these inherent characteristic of video codec to selectively transmit video packets when a network congestion occurs. Based on the difference of network congestion levels, intermediary network element drops video packets according to the order from less decoding-sensitive packets to significant and decoding-sensitive packets during selective transmission. If an intermediary network element selectively transmits significant, decoding-sensitive packets and drops less decoding-sensitive packets of video stream, it will result in non-consecutive RTP sequence number of media stream packets. When RTP receivers have received these non-consecutive RTP packets, they may request the retransmission of these RTP packets which have been dropped by intermediary network element. However, those RTP packets have been dropped selectively by the intermediary network element due to network congestion, and the intermediary network element do would like the RTP receivers not to request retransmission for them. Therefore, in order to suppress these retransmission requests, it is necessary to notify RTP receivers not to request retransmission for those RTP packets which have been dropped by the intermediary network element. Yang & Hu Expires January 10, 2011 [Page 3] Internet-Draft Selective transmission July 2010 2. Conventions 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]. 3. Definitions This document uses the following acronyms and definitions frequently: Decoding-sensitivity: The degree of influence of a video packet to decode. The more a video packet which has been directly or indirectly used as a reference to predict other pictures is, the more decoding-sensitive it is, otherwise, the less decoding-sensitive it is. Selective transmission: An intermediary network element transmits the remainder of the packets after dropping video packets according to the order from less sensitive packets to sensitive and significant packets during selective transmission. 4. Selective transmission Mechanism Description A General Mechanism for RTP Header Extensions [RFC 5285] provides a general mechanism to use the header extension feature of RTP Protocol. It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. This document uses the header extension mechanism to build a new RTP extension header to avoid retransmission request from RTP receivers. When selective transmission is required (e.g. network congestion occurs), the intermediary network element drops video packets based on the order from less decoding-sensitive to decoding-sensitive and significant according to present network situation, and sends RTP receivers a notification indication to indicate some dropped video packets that have been taken the initiative to discard. This document defines the expected behaviors of the intermediary network element when selective transmission happens. It is instructive to have independently operating implementations on the intermediary network element that inspect decoding-sensitivity of video packets, discard less decoding-sensitivity of video packets, and send notification indication. The following steps describe selective transmission in detail: Yang & Hu Expires January 10, 2011 [Page 4] Internet-Draft Selective transmission July 2010 1. When selective transmission is required, the intermediary network element has acquired the decoding-sensitivity of video packets in the active queue. 2. The intermediary network drops some less decoding-sensitive video packets according to the level of network condition. The worse network condition is, the more video packets according to the order from less decoding-sensitive to decoding-sensitive and significant are dropped, the less video packets of selective transmission are. 3. The intermediary network element sends Selective Transmission Notification Indication to RTP receivers not to request retransmission for those packets which the intermediary network element has taken the initiative to drop. 5. The use case of network congestion Though the algorithm of Queue Management and Congestion Avoidance in the internet [RFC2309](e.g. Tail Drop or Random Early Drop) do not cause as much harm to the throughput and latency of other connections, it inevitably causes packet loss and may seriously degrade video quality. Selective transmission will be an effective way to improve video quality which is caused by other congestion avoidance algorithms (e.g. Tail Drop or Random Early Drop[RFC2309]). The degree of dropping packets depends on network congestion level. For the case of network congestion, more severe network congestion is, more video packets will be dropped. The dropping policy is based on the order from less decoding-sensitive to decoding-sensitive and significant. That is to say, packets of non-reference frames are the least sensitive; packets of reference frames are more sensitive than non-reference frames; packets of intra frame are the best sensitive. In the packets of reference frames, the more a reference frame is cited, the more sensitive it is. Take an example of the following video frame sequence(In order to conveniently calculate, it assumes that I-frame consists of 80 RTP packets, B-frame consists of 25 RTP packets, P-frame consists of 55 RTP packets), in the following GOP from I1 to P13, I1 (intra frame) is the best sensitive; non-reference B-frames (B2, B3, B5, B6, B8, B9, B11 and B12) are the least sensitive, reference P-frames (P4, P7, P10 and P13) are more sensitive than non-reference B-frames. The sensitivity of P4, P7, P10 and P13 decreases in turn ...I1(1000-1079)B2(1080-1104)B3(1105-1129)P4(1130-1184)B5(1185-1209) B6(1210-1234)P7(1235-1289)B8(1290-1314)B9(1315-1339)P10(1340-1394) B11(1395-1419)B12(1420-1444)P13(1445-1499)I14(1500-1579)... Yang & Hu Expires January 10, 2011 [Page 5] Internet-Draft Selective transmission July 2010 If transient congestion will occur at the I1 frame of this video frame sequence, and about ten packets will be dropped, intermediary network element may drop B2 and/or B3 and/or other B-frames in terms of the congestion level. After intermediary network element decides to drop these video packets, it immediately needs to send Selective Transmission Notification Indication to RTP receivers to suppress the retransmission request for these video packets. If the last RTP packet having been dropped is still unknown before intermediary network element sends Selective Transmission Notification Indication, intermediary network element may send a Selective Transmission Notification Indication without the last RTP sequence number. Intermediary network element sends a Selective Transmission Notification Indication again with the last RTP sequence number when it gets the last RTP sequence number 6. RTP Packet Format This section defines the Header Extension for RTP Selective Transmission Notification Indication (STNI) by intermediary network element which notifies RTP receivers not to send the retransmission request for those packets which have been discarded actively when selective transmission occurs. 6.1. Selective Transmission Notification Indication The Selective Transmission Notification Indication is delivered to the RTP Receivers in-band using the "General Mechanism for RTP Header Extensions" [RFC5285]. The format of the Selective Transmission Notification Indication is shown in Figure 1. The Selective Transmission Notification Indication consists of Network Reason of selective transmission, Notification Information Mode (NIM) of selective transmission and Notification Information of selective transmission. Yang & Hu Expires January 10, 2011 [Page 6] Internet-Draft Selective transmission July 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . RTP Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xDE | length=3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | L=0 | Network Reason| ID | L=0 | NIM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (pad) | ID | L= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notification Information Unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notification Information Unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 The format of Selective Transmission Notification Indication Network Reason of selective transmission: Network Reason field is one octet and its length field is equal to zero; Network Reason indicates the reason why selective transmission happens. Network Reason field set to one means network congestion happening. Other Values are Unassigned. 0: Unassigned 1: Network Congestion 2-255: Unassigned Notification Information Mode (NIM) of selective transmission: Notification Information Mode field is one octet and its length field is equal to zero; The Notification Information Mode indicates the structure of notification information field. When Notification Information Mode field is set to one, Notification information field uses sequence pairs of Start Sequence Number and Stop Sequence Number shown in Figure 2 to indicate discarding RTP packets. When Notification Information Mode field is set to two, Notification information field uses Packet Identifier consisting of Start Sequence Number and Bitmask of Following Packets shown in Figure 3 to indicate discarding RTP packets. Other Values are Unassigned. 0: Unassigned 1: Sequence Pairs 2: Packet Identifier 3-255: unassigned Yang & Hu Expires January 10, 2011 [Page 7] Internet-Draft Selective transmission July 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xDE | length=3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | L=0 | Network Reason| ID | L=0 | NIM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (pad) | ID | L= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Sequence Number | Stop Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Sequence Number | Stop Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Notification Information based on Sequence pairs 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xDE | length=3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | L=0 | Network Reason| ID | L=0 | NIM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (pad) | ID | L= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Sequence Number | Bitmask of Following Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Sequence Number | Bitmask of Following Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Notification Information based on Packet Identifier Notification Information of selective transmission: The structure of Notification Information field depends on the Notification Information Mode. The length of Notification Information field is variable, and consists of Notification Information Units. Each Notification Information Unit is four octets. 7. Signaling Information The URI for declaring the selective transmission header extension in an SDP extmap attribute and mapping it to local extension header Yang & Hu Expires January 10, 2011 [Page 8] Internet-Draft Selective transmission July 2010 identifiers are "urn:ietf:params:rtp-hdrext: sel-trans-net- reason,sel-trans-noti-info-mode and sel-trans-noti-inf ". There is no additional setup information needed for this extension (i.e. no extensionattributes). An example attribute line in the SDP might be: a=extmap:4/sendonly urn:ietf:params:rtp-hdrext: sel-trans-netreason a=extmap:5/sendonly urn:ietf:params:rtp-hdrext: sel-trans-notinfmode a=extmap:6/sendonly urn:ietf:params:rtp-hdrext: sel-trans-notinf 8. Security Considerations TBD. 9. IANA Considerations IANA should register three new extension URIs to the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data: Extension URI: urn:ietf:params:rtp-hdrext: sel-trans-netreason Description: Network Reason of selective transmission Contact: Peilin Yang Reference: RFC xxxx Extension URI: urn:ietf:params:rtp-hdrext: sel-trans-notinfmode Description: Notification Information Mode of selective transmission Contact: Peilin Yang Reference: RFC xxxx Extension URI: urn:ietf:params:rtp-hdrext: sel-trans-notinf Description: Notification Information of selective transmission Contact: Peilin Yang Reference: RFC xxxx 10. Acknowledgements TBD. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Yang & Hu Expires January 10, 2011 [Page 9] Internet-Draft Selective transmission July 2010 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008. Authors' Addresses Peilin Yang Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District, Nanjing 210012 P.R.China Phone: +86-25-56622638 Email: yangpeilin@huawei.com Yinliang Hu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District, Nanjing 210012 P.R.China Phone: +86-25-56622642 Email: huyingliang@huawei.com Yang & Hu Expires January 10, 2011 [Page 10]