draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01.txt   draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02.txt 
XR Block Working Group J. Ott XR Block Working Group J. Ott
Internet-Draft V. Singh Internet-Draft V. Singh
Intended status: Standards Track Aalto University Intended status: Standards Track Aalto University
Expires: June 11, 2012 I. Curcio Expires: August 2, 2012 I. Curcio
Nokia Research Center Nokia Research Center
December 9, 2011 January 30, 2012
Real-time Transport Control Protocol (RTCP) Extension Report (XR) for Real-time Transport Control Protocol (RTCP) Extension Report (XR) for
Run Length Encoding of Discarded Packets Run Length Encoding of Discarded Packets
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01.txt draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02.txt
Abstract Abstract
The Real-time Transport Control Protocol (RTCP) is used in The Real-time Transport Control Protocol (RTCP) is used in
conjunction with the Real-time Transport Protocol (RTP) in to provide conjunction with the Real-time Transport Protocol (RTP) in to provide
a variety of short-term and long-term reception statistics. The a variety of short-term and long-term reception statistics. The
available reporting may include aggregate information across longer available reporting may include aggregate information across longer
periods of time as well as individual packet reporting. This periods of time as well as individual packet reporting. This
document specifies a per-packet report metric capturing individual document specifies a per-packet report metric capturing individual
packets discarded from the jitter buffer after successful reception. packets discarded from the jitter buffer after successful reception.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 11, 2012. This Internet-Draft will expire on August 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3. XR Discard RLE Report Block . . . . . . . . . . . . . . . . . 4 3. XR Discard RLE Report Block . . . . . . . . . . . . . . . . . 4
4. XR Bytes Discarded Report Block . . . . . . . . . . . . . . . 5 4. XR Bytes Discarded Report Block . . . . . . . . . . . . . . . 5
5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 6 5.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 6
5.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . . 7
6. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 6. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. XR Report Block Registration . . . . . . . . . . . . . . . 8 8.1. XR Report Block Registration . . . . . . . . . . . . . . . 8
8.2. SDP Parameter Registration . . . . . . . . . . . . . . . . 8 8.2. SDP Parameter Registration . . . . . . . . . . . . . . . . 8
8.3. Contact information for IANA registrations . . . . . . . . 9 8.3. Contact information for IANA registrations . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
A.1. changes in A.1. changes in
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 . . . . 10 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 . . . . 10
A.2. changes in A.2. changes in
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 . . . . 10 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 . . . . 10
A.3. changes in
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
RTP [RFC3550] provides a transport for real-time media flows such as RTP [RFC3550] provides a transport for real-time media flows such as
audio and video together with the RTP control protocol which provides audio and video together with the RTP control protocol which provides
periodic feedback about the media streams received in a specific periodic feedback about the media streams received in a specific
duration. In addition, RTCP can be used for timely feedback about duration. In addition, RTCP can be used for timely feedback about
individual events to report (e.g., packet loss) [RFC4585]. Both individual events to report (e.g., packet loss) [RFC4585]. Both
long-term and short-term feedback enable a sender to adapt its media long-term and short-term feedback enable a sender to adapt its media
skipping to change at page 3, line 35 skipping to change at page 3, line 35
characterization. In addition to lost packets, RFC3611 defines the characterization. In addition to lost packets, RFC3611 defines the
notion of "discarded" packets: packets that were received but dropped notion of "discarded" packets: packets that were received but dropped
from the jitter buffer because they were either too early (for from the jitter buffer because they were either too early (for
buffering) or too late (for playout). This metric is part of the buffering) or too late (for playout). This metric is part of the
VoIP metrics report block even though it is not just applicable to VoIP metrics report block even though it is not just applicable to
audio: it is specified as the fraction of discarded packets since the audio: it is specified as the fraction of discarded packets since the
beginning of the session. See section 4.7.1 of RFC3611 [RFC3611]. beginning of the session. See section 4.7.1 of RFC3611 [RFC3611].
Recently proposed extensions to the XR reporting suggest enhancing Recently proposed extensions to the XR reporting suggest enhancing
this discard metric: this discard metric:
o Reporting the number of discarded packets during either the last o Reporting the number of discarded packets in a measurement
reporting interval or since the beginning of the session, as interval, i.e., during either the last reporting interval or since
indicated by a flag in the suggested XR report the beginning of the session, as indicated by a flag in the
[I-D.ietf-xrblock-rtcp-xr-discard]. suggested XR report [I-D.ietf-xrblock-rtcp-xr-discard].
o Reporting gaps and bursts of discarded packets during the last o Reporting gaps and bursts of discarded packets during a
reporting interval or cumulatively since the beginning of the measurement interval, i.e., the last reporting interval or
session [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. cumulatively since the beginning of the session
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard].
However, none of these metrics allow a receiver to report precisely However, none of these metrics allow a receiver to report precisely
which packets were discarded. While this information could in theory which packets were discarded. While this information could in theory
be derived from high-frequency reporting on the number of discarded be derived from high-frequency reporting on the number of discarded
packets or from the gap/burst report, these two mechanisms do not packets or from the gap/burst report, these two mechanisms do not
appear feasible: The former would require an unduly high amount of appear feasible: The former would require an unduly high amount of
reporting which still might not be sufficient due to the non- reporting which still might not be sufficient due to the non-
deterministic scheduling of RTCP packets. The latter incur deterministic scheduling of RTCP packets. The latter incur
significant complexity and reporting overhead and might still not significant complexity and reporting overhead and might still not
deliver the desired accuracy. deliver the desired accuracy.
This document defines a discard report block following the idea of This document defines a discard report block following the idea of
the run-length encoding applied for lost and received packets in the run-length encoding applied for lost and received packets in
RFC3611 [RFC3611]. RFC3611 [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 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant [RFC2119] and indicate requirement levels for compliant
implementations. implementations.
The terminology defined in RTP [RFC3550] and in the extensions for XR The terminology defined in RTP [RFC3550] and in the extensions for XR
reporting [RFC3611] applies. reporting [RFC3611] applies.
skipping to change at page 5, line 23 skipping to change at page 4, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 | | chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n | | chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: XR Discard Report Block Figure 1: XR Discard Report Block
These reserved bits (2 bits) SHOULD be set to zero by receivers and
MUST be ignored by senders.
The 'E' bit is introduced to distinguish between packets discarded The 'E' bit is introduced to distinguish between packets discarded
due to early arrival and those discarded due to late arrival. The 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 '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. due to too early arrival and MUST be set to '0' otherwise.
In case both early and late discarded packets shall be reported, two In case both early and late discarded packets shall be reported, two
Discard RLE report blocks MUST be included; their sequence number Discard RLE report blocks MUST be included; their sequence number
range MAY overlap, but individual packets MUST only be reported as range MAY overlap, but individual packets MUST only be reported as
either early or late. Packets reported in both MUST be considered as either early or late. Packets reported in both MUST be considered as
discarded without further information available, packets reported in discarded without further information available, packets reported in
skipping to change at page 6, line 8 skipping to change at page 5, line 29
4. XR Bytes Discarded Report Block 4. XR Bytes Discarded Report Block
The XR Bytes Discarded report block uses the following format which The XR Bytes Discarded report block uses the following format which
follows the model of the framework for performance metric development follows the model of the framework for performance metric development
[RFC6390]. [RFC6390].
0 1 2 3 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 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=BDR | I | Tag |E|res| block length=2 | | BT=BDR | I |E|reserved | block length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of bytes discarded | | number of bytes discarded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: XR Bytes Discarded Report Block Figure 2: XR Bytes Discarded Report Block
The Interval Metric flag (I) (2 bits) is used to indicate whether the The Interval Metric flag (I) (2 bits) is used to indicate whether the
discard metric is Sampled, Interval, or a Cumulative metric, that is, discard metric is Sampled, Interval, or a Cumulative metric, that is,
skipping to change at page 6, line 32 skipping to change at page 6, line 6
measurements (I=11, the Cumulative Duration) or is a sampled value measurements (I=11, the Cumulative Duration) or is a sampled value
(I=01). (I=01).
The 'E' bit is introduced to distinguish between packets discarded The 'E' bit is introduced to distinguish between packets discarded
due to early arrival and those discarded due to late arrival. The 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 '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 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 both early and late discarded packets shall be reported, two Bytes
Discarded report blocks MUST be included. Discarded report blocks MUST be included.
These reserved bits (5 bits) SHOULD be set to zero by receivers and
MUST be ignored by senders.
The 'number of bytes discarded' is a 32-bit unsigned integer value The 'number of bytes discarded' is a 32-bit unsigned integer value
indicating the total number of bytes discarded (I=11), or the number indicating the total number of bytes discarded.
If the XR block is not preceded by a measurement identity block
[I-D.ietf-xrblock-rtcp-xr-meas-identity] then the value indicates the
bytes lost from from the start of the session (I=11), or the number
of bytes discarded since the last RTCP XR Bytes Discarded block was of bytes discarded since the last RTCP XR Bytes Discarded block was
sent (I=10), or bytes discarded in a measurement interval (I=01) received (I=10).
[I-D.ietf-xrblock-rtcp-xr-meas-identity].
Bytes Discarded Report Blocks SHOULD be sent in conjunction with an If the XR block follows a measurement identity block
RTCP RR as a compound RTCP packet. [I-D.ietf-xrblock-rtcp-xr-meas-identity] in an RTCP RR packet then
the cumulative (I=11) and interval (I=10) correspond to the values in
the measurement block.
If the receiver sends the Bytes Discarded Report Block without the
measurement identity block then the discard block MUST be sent in
conjunction with an RTCP RR as a compound RTCP packet.
5. Protocol Operation 5. Protocol Operation
This section describes the behavior of the reporting (= receiver) RTP This section describes the behavior of the reporting (= receiver) RTP
node and the sender RTP node. node and the sender RTP node.
5.1. Reporting Node (Receiver) 5.1. Reporting Node (Receiver)
Transmission of RTCP XR Discard RLE Reports is up to the discretion Transmission of RTCP XR Discard RLE Reports is up to the discretion
of the receiver, as is the reporting granularity. However, it is of the receiver, as is the reporting granularity. However, it is
RECOMMENDED that the receiver signals all discarded packets using the RECOMMENDED that the receiver signals all discarded packets using the
method defined in this document. If all packets over a reporting method defined in this document. If all packets over a reporting
period were lost, the receiver MAY use the Discard Report Block period were lost, the receiver MAY use the Discard Report Block
[I-D.ietf-xrblock-rtcp-xr-discard] instead. In case of limited [I-D.ietf-xrblock-rtcp-xr-discard] instead. In case of limited
available reporting bandwidth, it is up to the receiver whether or available reporting bandwidth, it is up to the receiver whether or
not to include RTCP XR Discard RLE reports or not. not to include RTCP XR Discard RLE reports.
The receiver MAY send the Discard RLE Reports as part of the The receiver MAY send the Discard RLE Reports as part of the
regularly scheduled RTCP packets as per RFC3550. It MAY also include regularly scheduled RTCP packets as per RFC3550. It MAY also include
Discard RLE Reports in immediate or early feedback packets as per Discard RLE Reports in immediate or early feedback packets as per
RFC4585. RFC4585.
5.2. Media Sender 5.2. Media Sender
The media sender MUST be prepared to operate without receiving any The media sender MUST be prepared to operate without receiving any
Discard RLE reports. If Discard RLE reports are generated by the Discard RLE reports. If Discard RLE reports are generated by the
receiver, the sender cannot rely on all these reports being received, receiver, the sender cannot rely on all these reports being received,
nor can the sender rely on a regular generation pattern from the nor can the sender rely on a regular generation pattern from the
receiver side. receiver side.
However, if the sender receives any RTCP reports but no Discard RLE However, if the sender receives any RTCP reports but no Discard RLE
report blocks and is aware that the receiver supports Discard RLE report blocks and is aware that the receiver supports Discard RLE
report blocks, it MAY assume that no packets were discarded at the report blocks, it MAY assume that no packets were discarded at the
receiver. receiver.
The sender SHOULD accept the Bytes Discarded Report Block only if it
is received in a compound RTCP receiver report or if it is preceded
by a measurement identity block
[I-D.ietf-xrblock-rtcp-xr-meas-identity]. Under all other
circumstances it MUST ignore the block.
6. SDP signaling 6. SDP signaling
The report blocks specified in this document define extensions to The report blocks specified in this document define extensions to
RTCP XR reporting. Whether or not this specific extended report is RTCP XR reporting. Whether or not this specific extended report is
sent is left to the discretion of the receiver. Its presence may sent is left to the discretion of the receiver. Its presence may
enable better operation of the sender since more detailed information enable better operation of the sender since more detailed information
is available. Not providing this information will make the sender is available. Not providing this information will make the sender
rely on other RTCP report metrics. rely on other RTCP report metrics.
A participant of a media session MAY use SDP to signal its support A participant of a media session MAY use SDP to signal its support
skipping to change at page 10, line 29 skipping to change at page 10, line 21
A.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 A.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00
o Changed the interval flag from 1 to 2 bits in the discarded bytes o Changed the interval flag from 1 to 2 bits in the discarded bytes
report. Also added the measurement identification tag to the report. Also added the measurement identification tag to the
block. block.
o Added this section. o Added this section.
A.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 A.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01
o Removed the measurement identification tag to the block. o Removed the measurement identification tag in the bytes discarded
block.
A.3. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02
o Removed the extra Tag bits from the Discarded bytes XR block.
o Clarified use of measurement identity block in Section 4 and 5.2
Authors' Addresses Authors' Addresses
Joerg Ott Joerg Ott
Aalto University Aalto University
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 Espoo, FIN 02150
Finland Finland
Email: jo@comnet.tkk.fi Email: jo@comnet.tkk.fi
 End of changes. 18 change blocks. 
26 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/