Network Working Group H. Desineni Internet-Draft N. Leung Expires: August 28, 2006 Qualcomm February 24, 2006 RTCP feedback messages for packet delay adjustments draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies two RTCP feedback messages which fall under the codec control category of messages defined in "Codec Control Messages in the Audio-Visual Profile with Feedback(AVPF)". They are helpful primarily in point-to-point topology. However they are also usable in smaller multicast and point to multipoint topologies. The extensions discussed are the Packet Delay Adjust Request (PDAR) and Packet Delay Adjust Acknowledgement(PDAA) messages in point-to-point topology. Desineni & Leung Expires August 28, 2006 [Page 1] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Transport Layer Feedback Messages . . . . . . . . . . . . . . 6 4.1. Packet Delay Adjust Request (PDAR) message . . . . . . . . 6 4.1.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Message Format . . . . . . . . . . . . . . . . . . . . 8 4.1.3. Timing Rules . . . . . . . . . . . . . . . . . . . . . 8 4.2. Packet Delay Adjust Acknowledgement(PDAA) message . . . . 9 4.2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Message Format . . . . . . . . . . . . . . . . . . . . 9 4.2.3. Timing Rules . . . . . . . . . . . . . . . . . . . . . 9 5. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. Registration for PDAR . . . . . . . . . . . . . . . . . . 13 7.2. Sub registry for future codec control messages . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Desineni & Leung Expires August 28, 2006 [Page 2] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 1. Introduction When the receiver of an RTP stream observes that RTP media packets are arriving delayed, the receiver can feedback a Packet Delay Adjust Request (PDAR) message to the RTP stream sender requesting that packets need to arrive earlier. The RTP stream sender can interpret this to mean that there is congestion in the network and reduce its transmission rate to adjust for this congestion. The Packet Delay Adjust Acknowledgement (PDAA) message is used by a media sender to acknowledge the receipt of a PDAR message. When the congestion condition clears up and a receiver observes that packets are arriving early, the receiver can indicate to the sender that it can receive packets later than it currently is. This indicates to the sender that the network can deliver packets to this receiver at a higher rate. The PDAR and PDAA codec control messages described in this document are optimized for use in point-to-point topology. However, they can also be used in multicast and point to multipoint topologies. A new version of this draft or a new draft may describe the usage of these messages in multicast and point to multipoint topologies. The SDP defined in [1] has been extended to support the signaling of additional codec control messages defined in this draft. Desineni & Leung Expires August 28, 2006 [Page 3] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 2. Definitions 2.1. Glossary o AVPF - The Extended RTP Profile for RTCP-based Feedback o FCI - Feedback Control Information o FMT - Feedback Message Type 2.2. Terminology 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 [RFC2119]. Desineni & Leung Expires August 28, 2006 [Page 4] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 3. Motivation This section discusses the motivation for defining and using PDAR and PDAA messages 3.1. Use Case For packet-switched multimedia services which are transported over time-varying and/or shared channels, the rate and delay at which media packets can be delivered to the receiver can vary significantly. The channel conditions and/or loading conditions of the shared channel can negatively affect the service quality if the sender is unable to adapt to these changing conditions. In packet-switched wireless networks such as cdma2000 HRPD and HSDPA, the forward/down link is a single channel that is time-division multiplexed between all the terminals in the cell. The forward/down link packet scheduler uses knowledge of the various radio-link conditions at the terminals in the cell to maximize the total forward/down link throughput of the cell while attempting to meet QoS requirements for each terminal's applications. A terminal in poor radio conditions relative to other terminals in the cell places a heavy load on the scheduler because the scheduler can only serve this terminal with relatively lower data rates. A terminal in these conditions can experience more packet delays as the scheduler services the terminal less often and with lower data rates. Also, as the number of terminals being serviced in a cell increases, the congestion at the scheduler will also result in all terminals experiencing more packet delays. In these networks, the wireless link is typically the bottleneck link which can cause significant packet delay and loss. Signaling the early or late arrival of packets as experienced by the receiver will help a sender change its transmission characteristics and adapt to the congestion state in the receiver's cell. Desineni & Leung Expires August 28, 2006 [Page 5] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 4. Transport Layer Feedback Messages Transport layer feedback messages are identified by the value RTPFB(205)as RTCP packet type. This memo specifies two new transport layer feedback messages. These messages fall under the codec control message category defined in [1], which in turn fall under transport layer feedback messages defined in [2]. In [2], one transport level feedback message has been defined. In [1], two more messages were defined. This memo specifies two more messages for a total of five transport level feedback messages. These messages are identified by means of the FMT parameter as follows. 0: unassigned 1: Generic NACK (as per [2]) 2: Maximum Media Bit-Rate Request (as per [1]) 3: Maximum Media Bit-Rate Notification (as per [1]) 4: Packet Delay Adjust Request (PDAR) 5: Packet Delay Adjust Acknowledgement (PDAA) 6-30: unassigned 31: reserved for future expansion of the identifier number space The following subsections describe PDAR and PDAA feedback messages in point-to-point topology and define the formats of the FCI field used by these messages. In a point-to-point topology, multiple PDAR/PDAA feedback messages SHOULD NOT be stacked in a single FCI field. 4.1. Packet Delay Adjust Request (PDAR) message The PDAR is used by the receiver of an RTP stream to request adjustments to the arrival times of the RTP media packets it receives. The PDAR can indicate that the receiver prefers to receive packets earlier or later than they are currently arriving. Procedures to detect early or late arrival of RTP packets are implementation specific to a stream receiver. For example, a receiver can determine this information based on the play out times of received RTP media packets. Allowing the receiver to request these adjustments provides the receiver control of when it will receive packets it needs for proper play out of real-time media. Desineni & Leung Expires August 28, 2006 [Page 6] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 4.1.1. Semantics When the receiver of an RTP stream observes that RTP media packets are arriving late or delayed, the receiver SHOULD feedback a PDAR message to the RTP stream sender requesting that packets need to arrive earlier or faster. The RTP stream sender should interpret this to mean that there is congestion in the network and reduce its transmission rate to adapt to the congestion. When the congestion condition clears up and the receiver observes that packets are arriving earlier or faster than required, the receiver MAY indicate to the sender that it can receive packets later or slower than it currently is. This indicates to the sender that the network can deliver packets to this receiver at a higher data rate. Since individual packet delay measurements are affected by jitter it is recommended that receivers not set their packet delay adjustment requests based on the delay measurements of a few packets. The jitter that is not caused by the loading and/or channel conditions being adapted to should be filtered out by using a smoothing filter on the packet delay measurements at the receiver. The amount of filtering required is left to implementation as it will depend on the nature of the underlying system dynamics. The group delay of this filter is defined as the amount of time it takes for input to this filter to affect the output of the filter. A PDAR message MAY be repeated if no PDAA has been received at the time of transmission of the next RTCP packet. A repeated PDAR message SHALL NOT change any of the SSRC or FCI fields of the request relative to the first transmission with the same sequence number. After sending a PDAR message, the receiver should not send a new PDAR message (i.e., with incremented sequence number) until enough time has passed for adjustments made to the media stream by the sender based on the previous PDAR have affected the delay statistics measured at the receiver. Before sending a new request (i.e., with incremented sequence number) the receiver SHALL wait for the acknowledgement message (PDAA) for the previous request plus the amount of time it would take for adjustments to the media stream to be detected at the receiver (e.g., the group delay of any filtering performed to smoothen statistics measured at the receiver). If the receiver does not receive a PDAA message within one roundtrip time (RTT) plus the group delay of its smoothening filter since the last transmission (retransmission) of a PDAR message, the receiver MAY send a new PDAR message(i.e., with incremented sequence number). If a receiver has no ability to estimate round trip time between Desineni & Leung Expires August 28, 2006 [Page 7] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 itself and a sender, it is recommended to use a constant which reflects the worst case round trip time on the operating network or any other higher value. The time elapsed since the first transmission of a PDAR until the receipt of a corresponding PDAA MAY be used as an approximate value of RTT from the receiver to the sender. If a sender finds that there are multiple outstanding PDAR messages with different adjustments from the same media receiver in a given session, the sender SHOULD adjust to the request with the highest sequence number (modulo 256). 4.1.2. Message Format The Feedback control information (FCI) consists of one PDAR FCI entry with the following syntax. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq. nr | PD Adjust | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - Syntax for the PDAR message Seq. nr: Request sequence number. The sequence number space is unique for each tuple consisting of the SSRC of request source and the SSRC of the request target. The sequence number SHALL be increased by 1 modulo 256 for each new request. A repetition SHALL NOT increase the sequence number. The initial value is arbitrary. PD Adjust: Represented as a two's complement 8-bit binary number in units of 10ms ranging from -1.280s to +1.270s. A negative value indicates how much earlier the receiver requests to receive the media packets. A positive value indicates how much later the receiver can receive the media packets. Reserved: All bits SHALL be set to 0 and SHALL be ignored on reception. 4.1.3. Timing Rules The first transmission of the request message MAY use early or immediate feedback in cases when timeliness is desirable. Any repetition of a request message SHOULD use regular RTCP mode for its transmission timing. Desineni & Leung Expires August 28, 2006 [Page 8] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 4.2. Packet Delay Adjust Acknowledgement(PDAA) message 4.2.1. Semantics This feedback message is used to acknowledge the reception of a PDAR. The acknowledgement SHALL be sent for any received request, even if the request is repeated. The "SSRC of packet sender" field of the PDAA feedback message SHALL be set to the SSRC of the acknowledger. The "SSRC of media source" SHALL be set to the SSRC of the source of the PDAR request that is acknowledged. In a PDAA message, the sequence number identifies the particular PDAR being acknowledged. The media sender SHALL acknowledge only the highest sequence number (modulo 256) if several PDAR requests with different sequence numbers have been received from the same SSRC. 4.2.2. Message Format The PDAA Feedback control information (FCI) entry has the following syntax: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq. nr | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - Syntax for the PDAA message Seq. nr: The sequence number value from the PDAR request that is being acknowledged. Reserved: All bits SHALL be set to 0 and SHALL be ignored on reception. 4.2.3. Timing Rules The acknowledgement SHALL be sent when the sender has begun adjusting its RTP transmission based on the PDAR message to be acknowledged. If the sender decides not to make any adjustments to its RTP transmission, the sender SHALL try to send the acknowledgement immediately. Immediate or early feedback mode MAY be used for this message. Desineni & Leung Expires August 28, 2006 [Page 9] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 5. SDP Definitions The grammar of the ccci parameter defined in section 7.1 of [1] is extended as shown below. ccci-param = "fir" /"tmmbr" /"tstr" /"pdar" /token [SP byte-string] ; for future commands/indications See Section 7.2 for more details on how to add support for new codec control messages. The following subsection gives an example usage of 'pdar' in the SDP offer/answer model. 5.1. Offer-Answer The offer-answer details in section 7.2 of [1] are applicable when signaling the support for packet delay adjustment messages. 5.2. Example In the following example, the offerer wishes to support all the commands and indications of codec control messages. The offered SDP is as follows: -------------> Offer v=0 o=alice 3203093520 3203093520 IN IP4 host.example.com s=Offer/Answer c=IN IP4 172.11.1.124 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVPF 98 a=rtpmap:98 H263-1998/90000 a=rtcp-fb:98 ccm tstr a=rtcp-fb:98 ccm fir a=rtcp-fb:98 ccm tmmbr a=rtcp-fb:98 ccm pdar The answerer only wishes to support TSTR and PDAR messages as the codec control messages. So the answerer SDP is as follows: Desineni & Leung Expires August 28, 2006 [Page 10] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 <--------------- Answer v=0 o=alice 3203093520 3203093524 IN IP4 host.anywhere.com s=Offer/Answer c=IN IP4 189.13.1.37 m=audio 47190 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 53273 RTP/AVPF 98 a=rtpmap:98 H263-1998/90000 a=rtcp-fb:98 ccm tstr a=rtcp-fb:98 ccm pdar Desineni & Leung Expires August 28, 2006 [Page 11] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 6. Security Considerations The defined messages have certain properties that have security implications. These must be addressed and taken into account by the users of these messages. The defined setup signaling mechanism is sensitive to the modification attacks that can result in session creation with sub- optimal configuration, and, in the worst case, session rejection. To prevent this type of attack, authentication and integrity protection of the setup signaling is required. Here are some possible implications from spoofed or maliciously created feedback messages of the types defined in this specification: o A more negative value of packet delay adjustment in a maliciously created or a spoofed PDAR message can mislead a media sender to unnecessarily increase its output bit rate. The increase in the sender's output bit rate may contribute to the congestion in the network. o A more positive value of packet delay adjustment in a maliciously created or a spoofed PDAR message can mislead a media sender to unnecessarily reduce its output bit rate. This may result in unacceptable or very poor media quality at the receiver. o Preventing a PDAR message from reaching a sender and acknowledging with a maliciously created PDAA message can prevent a sender from adapting to the congestion state of the network. To prevent these attacks there is a need to apply authentication and integrity protection on feedback messages. This can be accomplished against a group of external threats using the RTP profile that combines SRTP [10] and AVPF into SAVPF [11]. Desineni & Leung Expires August 28, 2006 [Page 12] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 7. IANA considerations 7.1. Registration for PDAR For use with the 'ccci' parameter defined in [1], the following value needs to be registered. Value name: pdar Long name: Packet Delay Adjust Request Usable with: ccci Reference: RFC XXXX 7.2. Sub registry for future codec control messages A new sub registry needs to be set up to allow registration of to be defined codec control feedback messages. Entries may be registered on a first-come first-serve basis following the "Specification Required" rules as defined in RFC 2434 [7]. Each new registration needs to indicate the parameter name used for the corresponding message. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics and FCI format of the message(s). Desineni & Leung Expires August 28, 2006 [Page 13] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 8. References 8.1. Normative References [1] Wenger, S., "Codec Control Messages in the Audio-Visual Profile with Feedback (AVPF)", Internet Draft , draft-wenger-avt-avpf-ccm-02.txt , Work in progress , January 2006. [2] Ott, J., "Extended RTP Profile for RTCP-based Feedback (RTP/ AVPF)", Internet Draft , draft-ietf-avt-rtcp-feedback-11.txt , Work in progress , Aug 2004. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, March 1997. [5] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [6] Rosenberg, J., "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [7] Narten, T., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [8] Johnston, A., "SDP Offer/Answer Examples", RFC 4317, December 2005. 8.2. Informative References [9] Singer, D., "A general mechanism for RTP Header Extensions", Internet Draft , draft-ietf-avt-rtp-hdrext-00 , Work in progress , August 2005. [10] Baugher, M., "The Secure Real-time Transport Protocol (SRTP)"", RFC 3711, March 2004. [11] Ott, J., "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)"", Internet Draft , draft-ietf-avt-profile-savpf-02.txt , Work in progress , July 2005. Desineni & Leung Expires August 28, 2006 [Page 14] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 Authors' Addresses Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego, CA 92126 USA Phone: +1 858 964 8952 Email: hd@qualcomm.com URI: http://www.qualcomm.com Nikolai Leung Qualcomm 7710 Takoma Ave Takoma Park, MD 20912 USA Phone: +1 858 845 3333 Email: nleung@qualcomm.com URI: http://www.qualcomm.com Desineni & Leung Expires August 28, 2006 [Page 15] Internet-Draft AVPF RTCP-RR packet delay extensions February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Desineni & Leung Expires August 28, 2006 [Page 16]