AVT Working Group J. Ott
Internet-Draft Helsinki University of Technology
Intended status: Standards Track I. Curcio
Expires: June 8, 2009 Nokia Research Center
V. Singh
Helsinki University of Technology
December 5, 2008
Real-time Transport Control Protocol Extension Report for Run Length
Encoding of Discarded Packets
draft-ott-avt-rtcp-xt-discard-metrics-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 June 8, 2009.
Abstract
The Real-time Transport Control Protocol (RTCP) is used in
conjunction with the Real-time Transport Protocol (RTP) in to provide
a variety of short-term and long-term reception statistics. The
available reporting may include aggregate information across longer
periods of time as well as individual packet reporting. This
document specifies a per-packet report metric capturing individual
packets discarded from the jitter buffer after successful reception.
Ott, et al. Expires June 8, 2009 [Page 1]
Internet-Draft RTCP XR Discard RLE December 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. XR Discard RLE Report Block . . . . . . . . . . . . . . . . . 4
4. XR Bytes Discarded Report Block . . . . . . . . . . . . . . . 5
5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 6
5.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . . 7
6. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Ott, et al. Expires June 8, 2009 [Page 2]
Internet-Draft RTCP XR Discard RLE December 2008
1. Introduction
RTP [RFC3550] provides a transport for real-time media flows such as
audio and video together with the RTP control protocol which provides
periodic feedback about the media streams received in a specific
duration. In addition, RTCP can be used for timely feedback about
individual events to report (e.g., packet loss) [RFC4585]. Both
long-term and short-term feedback enable a sender to adapt its media
transmission and/or encoding dynamically to the observed path
characteristics.
RFC3611 [RFC3611] defines RTCP eXtension Reports as a detailed
reporting framework to provide more than just the coarse RR
statistics. The detailed reporting may enable a sender to react more
appropriately to the observed networking conditions as these can be
characterized better, albeit at the expense of extra overhead.
Among many other fields, RFC3611 specifies the Loss RLE block which
define runs of packets received and lost with the granularity of
individual packets. This can help both error recovery and path loss
characterization. In addition to lost packets, RFC 3611 defines the
notion of "discarded" packets: packets that were received but dropped
from the jitter buffer because they were either too early (for
buffering) or too late (for playout). This metric is part of the
VoIP metrics report block even though it is not just applicable to
audio: it is specified as the fraction of discarded packets since the
beginning of the session. See section 4.7.1 of RFC3611 [RFC3611].
Recently proposed extensions to the XR reporting suggest enhancing
this discard metric:
o Reporting the number of discarded packets during either the last
reporting interval or since the beginning of the session, as
indicated by a flag in the suggested XR report
[I-D.ietf-avt-rtcp-xr-discard].
o Reporting gaps and bursts of discarded packets during the last
reporting interval or cumulatively since the beginning of the
session [I-D.ietf-avt-rtcp-xr-burst-gap-discard].
However, none of these metrics allow a receiver to report precisely
which packets were discarded. While this information could in theory
be derived from high-frequency reporting on the number of discarded
packets or from the gap/burst report, these two mechanisms do not
appear feasible: The former would require an unduly high amount of
reporting which still might not be sufficient due to the non-
deterministic scheduling of RTCP packets. The latter incur
significant complexity and reporting overhead and might still not
deliver the desired accuracy.
Ott, et al. Expires June 8, 2009 [Page 3]
Internet-Draft RTCP XR Discard RLE December 2008
This document defines a discard report block following the idea of
the run-length encoding applied for lost and received packets in
RFC3611.
Complementary to or instead of the indication which packets were
lost, an XR block is defined to indicate the number of bytes lost,
per interval or for the duration of the session, similar to other XR
report blocks.
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 BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant
implementations.
The terminology defined in RTP [RFC3550] and in the extensions for XR
reporting [RFC3611] applies.
3. XR Discard RLE Report Block
The XR Discard RLE report block uses the same format as specified for
the loss and duplicate report blocks in RFC3611 [RFC3611]. Figure
Figure 1 recaps the packet format. The fields "BT", "T", "block
length", "SSRC of source", "begin_seq", and "end_seq" SHALL have the
same semantics and representation as defined in RFC3611. The
"chunks" encoding the run length SHALL have the same representation
as in RFC3611, but encode discarded packets.
Ott, et al. Expires June 8, 2009 [Page 4]
Internet-Draft RTCP XR Discard RLE December 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD |rsvd |E| T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: XR Discard Report Block
The 'E' bit is introduced to distinguish between packets discarded
due to early arrival and those discarded due to late arrival. The
'E' bit MUST be set to '1' if the chunks represent packets discarded
due to too early arrival and MUST be set to '0' otherwise.
In case both early and late discarded packets shall be reported, two
Discard RLE report blocks MUST be included; their sequence number
range MAY overlap, but individual packets MUST only be reported as
either early or late. Packets reported in both MUST be considered as
discarded without further information available, packets reported in
neither are considered to be properly received and not discarded.
Editor's node: is it acceptable to use one of the 'reserved' bits for
this purpose or should two block types be used?
4. XR Bytes Discarded Report Block
The XR Bytes Discarded report block uses the following format:
Ott, et al. Expires June 8, 2009 [Page 5]
Internet-Draft RTCP XR Discard RLE December 2008
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD. |I|E| resv | block length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of bytes discarded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: XR Bytes Discarded Report Block
The Interval Metric flag (I) (1 bit) is used to indicate whether the
Post-Repair Loss metric is an Interval or a Cumulative metric, that
is, whether the reported value applies to the most recent measurement
interval duration between successive metrics reports (I=1) (the
Interval Duration) or to the accumulation period characteristic of
cumulative measurements (I=0) (the Cumulative Duration).
The 'E' flag (1 bit) is introduced to distinguish between bytes
discarded due to early arrival and bytes discarded due to late
arrival. The 'E' bit MUST be set to '1' if the 'number of bytes
discarded' represents bytes discarded due to too early arrival and
MUST be set to '0' otherwise. In case both early and late discarded
packets shall be reported, two Bytes Discarded report blocks MUST be
included.
The 'number of bytes discarded' (32 bits) is an unsigned integer
value indicating the total number of bytes discarded (I=0) or the
number of bytes discarded since the last RTCP XR Bytes Discarded
block was sent (I=1).
Editor's note: is it acceptable to use one of the 'reserved' bits for
this purpose or should two block types be used?
5. Protocol Operation
This section describes the behavior of the reporting (= receiver) RTP
node and the sender RTP node.
5.1. Reporting Node (Receiver)
Any of the Discard RLE and the Bytes Discarded RLE report blocks
SHOULD be sent in conjunction with an RTCP RR as a compound RTCP
packet. Nevertheless, the Discard RLE Report Block MAY be sent as a
non-compound packet [I-D.ietf-avt-rtcp-non-compound] to expedite
reporting or to increase the reporting frequency.
Ott, et al. Expires June 8, 2009 [Page 6]
Internet-Draft RTCP XR Discard RLE December 2008
Transmission of RTCP XR Discard RLE and Bytes Discarded reports is up
to the discretion of the receiver, as is the reporting granularity.
They MAY sent independently of each other or together in a single
datagram.
However, for the Discard RLE report blocks, it is RECOMMENDED that
the receiver signals all discarded packets using the method defined
in this document. If all packets over a reporting period were
discarded, the receiver MAY use the Discard Report Block
[I-D.ietf-avt-rtcp-xr-discard] instead. In case of limited available
reporting bandwidth, it is up to the receiver whether or not to
include RTCP XR Discard RLE reports or not.
The receiver MAY send the Discard RLE and the Bytes Discarded reports
as part of the regularly scheduled RTCP packets as per RFC3550. It
MAY also include Discard RLE Reports in immediate or early feedback
packets as per RFC4585.
5.2. Media Sender
The media sender MUST be prepared to operate without receiving any
Discard RLE or Bytes Discarded reports. If Discard RLE reports are
generated by the receiver, the sender cannot rely on all these
reports being received, nor can the sender rely on a regular
generation pattern from the receiver side.
However, if the sender receives any RTCP reports but no Discard RLE
report blocks and is aware that the receiver supports Discard RLE or
Bytes Discarded report blocks, it SHOULD assume that no packets were
discarded at the receiver.
6. SDP signaling
The present report blocks define an extension to RTCP XR reporting.
Whether or not this specific extended report is sent is left to the
discretion of the receiver. Its presence may enable better operation
of the sender since more detailed information is available. Not
providing this information will make the sender rely on other RTCP
report metrics. Whether there is a need to signal this optimization
is left for further study at this point. If the receiver knows that
the sender supports this metric, it may decide to include such
reports as deemed necessary and not send them otherwise to save
reporting bandwidth. Hence, there is some value.
Editor's node: There is ample precedence for signaling such
capabilities (and even required support) in SDP, so that defining the
corresponding attributes is a straightforward exercise should the
Ott, et al. Expires June 8, 2009 [Page 7]
Internet-Draft RTCP XR Discard RLE December 2008
need be confirmed.
7. Security Considerations
The security considerations of RFC3550, RFC3611, and RFC4585 apply.
Since this document offers only a more precise reporting for an
already existing metric, no further security implications are
foreseen.
8. IANA Considerations
One or two IANA actions are expected, depending on the future
evolution of this document: Registration of two XR report blocks and,
optionally, registration of SDP attributes for indicating support for
these XR Report Blocks.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 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.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003.
[I-D.ietf-avt-rtcpssm]
Ott, J., "RTCP Extensions for Single-Source Multicast
Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17
(work in progress), January 2008.
[I-D.ietf-avt-rtcp-xr-discard]
Hunt, G. and A. Clark, "RTCP XR Report Block for Discard
Ott, et al. Expires June 8, 2009 [Page 8]
Internet-Draft RTCP XR Discard RLE December 2008
metric Reporting", draft-ietf-avt-rtcp-xr-discard-00 (work
in progress), October 2008.
[I-D.ietf-avt-rtcp-xr-burst-gap-discard]
Hunt, G. and A. Clark, "RTCP XR Report Block for Burst/Gap
Discard metric Reporting",
draft-ietf-avt-rtcp-xr-burst-gap-discard-00 (work in
progress), October 2008.
[I-D.ietf-avt-rtcp-non-compound]
Johansson, I. and M. Westerlund, "Support for Reduced-Size
RTCP, Opportunities and Consequences",
draft-ietf-avt-rtcp-non-compound-08 (work in progress),
November 2008.
Authors' Addresses
Joerg Ott
Helsinki University of Technology
Otakaari 5 A
Espoo, FIN 02150
Finland
Email: jo@netlab.hut.fi
Igor D.D. Curcio
Nokia Research Center
P.O. Box 1000 (Visiokatu 1)
Tampere, FIN 33721
Finland
Email: igor.curcio (at) nokia.com
Varun Singh
Helsinki University of Technology
Otakaari 5 A
Espoo, FIN 02150
Finland
Email: varun@netlab.tkk.fi
Ott, et al. Expires June 8, 2009 [Page 9]
Internet-Draft RTCP XR Discard RLE December 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Ott, et al. Expires June 8, 2009 [Page 10]