Internet Engineering Task Force Shigeru Fukunaga - Oki Internet Draft Hideaki Kimata - NTT Document: draft-fukunaga-low-delay-rtcp-00.txt July 14, 2000 Low delay RTCP packet format for backward messages Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 http://www.ietf.org/shadow.html. Abstract This document describes a new RTCP packet format for carrying the backward messages for error recovery; such as MPEG-4 Visual upstream messages [2] and H.263 backward messages [3]. As these backward messages are requested to deliver in low delay, a new RTCP profile of low delay is defined. 1. Conventions used in this document 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 RFC-2119 [4]. 2. Introduction For real-time video transmission, using the backward messaging functionality from the receiver to the transmitter is very effective for the error recovery or the error resilience. Therefore many technologies are discussed and developed in the past years. And some valuable tools are included into some international standards. For example, "NEWPRED" is one of the error resilience tools using the backward messages, and it is defined in MPEG-4 Advanced Real Time Simple (ARTS) profile [2] and H.263 Annex N [3]. "Intra refresh (IR)" and "re-transmission" are also famous error resilience tools using Fukunaga/Kimata [page 1] Low delay RTCP format for backward messages July 2000 the backward messages. The backward channel messages of these techniques should be transmitted in the framework of RTCP. The performance of these techniques strongly depends on the delay of the backward message transmission. The longer the transmission delay is, the slower the error recovery is. Therefore it is desirable for the backward messages to be transmitted without any additional delay. On the other hand, however, the normal RTCP packet is defined to send at constant timing with random delay [5]. This rule is an obstacle for the low delay backward messages. This draft defines a new RTCP profile that can transmit the backward messages without any random delay in order to maximize the performance of the error resilient backward messaging tools. The new RTCP will be called "LD-RTCP" in this draft. This draft also describes the congestion control for the LD-RTCP. 3. New profile of low delay RTCP This section specifies the new profile of the low delay RTCP (LD- RTCP). The LD-RTCP SHALL be treated as a completely different RTCP from the normal RTCP; such as SR, RR and so on, in the following points. - Sending timing rule - Prohibition of Multicast - Congestion Control - Calculation of RTCP sending interval - Compound RTCP packet 3.1. Sending timing rule The performance of the error resilience tools using backward messages (such as NEWPRED, IR and re-transmission) is sensitive to the delay of the backward message. Therefore, LD-RTCP packets SHALL be sent as soon as possible, i.e. as soon as a packet loss is detected, without adding any random delay. 3.2. Prohibition of Multicast As the sending interval of LD-RTCP packet may be smaller than that of the normal RTCP, the number of LD-RTCP packets may be larger than that of the normal RTCP packets. In order to avoid additional congestion, LD-RTCP SHALL NOT be used in multicast. 3.3. Congestion control The total amount of traffic of the backward messages in the error resilience tools can be controlled in the receiver. The total amount of the LD-RTCP SHALL be controlled so that it is lower than 5% of the Fukunaga/Kimata [page 2] Low delay RTCP format for backward messages July 2000 amount of the forward video data. Even during the congestion, the amount of the LD-RTCP also SHALL be controlled under 5%. To reduce the number of LD-RTCP packets, multiple backward messages can be concatenated in the payload of one LD-RTCP packet. And although a normal RTCP packet is transmitted with random delay, the LD-RTCP packet transmission interval depends on the interval of the receiving and decoding the forward video data. Both the receiving interval of the video RTP packet and the decoding time for each packet data have some jitter associated with them. Therefore the LD-RTCP transmission interval has some jitter by itself. It is effective for the congestion control, and there is no need to add any random delay. This means that the amount of jitter is enough to avoid another congestion in the case of Unicast. 3.4. Calculation of RTCP sending interval LD-RTCP packets SHALL NOT be included for the calculation of the RTCP sending intervals. All LD-RTCP packets SHALL be ignored when analyzing the information in the sender and receiver reports (SR and RR), and only normal RTCP packets SHALL be used. If the LD-RTCP packets were included in the calculation of RTCP sending interval, the RR packets should be generated in the short timing of the LD-RTCP packets. In this case, the interval of the RR packets would be smaller than 5 seconds, and the number of the normal RTCP packets is much increased. This is bad from the view point of the congestion. 3.5. Compound RTCP packet Multiple LD-RTCP packets MAY be concatenated without any intervening separators to form a compound RTCP packet. Although the normal compound RTCP packet SHOULD start with SR or RR packets, in the case of compound LD-RTCP packet, other normal RTCP packets SHALL NOT be included, and only LD-RTCP packets SHALL be included in one compound LD-RTCP packet. Fukunaga/Kimata [page 3] Low delay RTCP format for backward messages July 2000 4. LD-RTCP packets definition 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| BMT | PT=LD_RTCP | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Backward Messages Payload (byte aligned) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets as in RTP data packets. padding (P): 1 bit If the padding bit is set, this LD-RTCP packet contains some additional padding octets at the end which are not part of the control information. The last octet of the padding is a count of how many padding octets should be ignored. In the case several backward messages are mapped onto one LD-RTCP packet, padding should only be required on the last individual message. backward message type (BMT): 5 bits Identifies the type of the backward messages. 0: forbidden 1: NEWPRED in MPEG-4 ARTS Profile 2: NEWPRED in H.263 Annex N 3-63: reserved In this internet-draft, only the NEWPRED is assigned as the candidate of the BMT for the moment. Some other tools using the backward messages may be assigned in the future. packet type (PT): 8 bits The value of the packet type (PT) identifier is the constant LD_RTCP (TBD). SSRC: 32 bits SSRC is the synchronization source identifier for the sender of this packet. Backward Message Payload: variable The syntax and semantics of the backward messages are usually defined in each standard. For example, the backward message of NEWPRED is defined in ISO/IEC 14496-2 [2] and ITU-T H.263 [3]. All messages are byte aligned. Normally one backward message is mapped onto one LD-RTCP packet, and several messages with same BMT could be continuously mapped onto one LD-RTCP packet. One message SHALL NOT be fragmented into different LD-RTCP packets. Fukunaga/Kimata [page 4] Low delay RTCP format for backward messages July 2000 If the syntax and semantics of some tools are not defined in any standard, the special payload format will be defined here. 5. References 1. Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. 2. ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - Coding of audio-visual objects - Part2: Visual", July 2000. 3. ITU-T Recommendation H.263, "Video Coding for Low Bit Rate Communication," January 1998. 4. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5. Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications", RFC 1889, January 1996. 6. Author's Addresses Shigeru Fukunaga Oki Electric Industry Co., Ltd. 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan. Email: fukunaga444@oki.co.jp Hideaki Kimata Nippon Telegraph and Telephone Corporation 1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa 239-0847 Japan. Email: kimata@nttvdt.hil.ntt.co.jp Fukunaga/Kimata [page 5]