Internet DRAFT - draft-hdesineni-avt-avpf-ccm-pd-extn
draft-hdesineni-avt-avpf-ccm-pd-extn
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]
