draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03.txt   draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04.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: August 5, 2012 I. Curcio Expires: January 6, 2013 I. Curcio
Nokia Research Center Nokia Research Center
February 2, 2012 July 5, 2012
Real-time Transport Control Protocol (RTCP) Extension Report (XR) for RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length
Run Length Encoding of Discarded Packets Encoding (RLE) of Discarded Packets
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03.txt draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04.txt
Abstract Abstract
The Real-time Transport Control Protocol (RTCP) is used in The RTP Control Protocol (RTCP) is used in conjunction with the Real-
conjunction with the Real-time Transport Protocol (RTP) in to provide time Transport Protocol (RTP) in to provide a variety of short-term
a variety of short-term and long-term reception statistics. The and long-term reception statistics. The available reporting may
available reporting may include aggregate information across longer include aggregate information across longer periods of time as well
periods of time as well as individual packet reporting. This as individual packet reporting. This document specifies a per-packet
document specifies a per-packet report metric capturing individual report metric capturing individual packets discarded from the jitter
packets discarded from the jitter buffer after successful reception. buffer after successful reception.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 5, 2012. This Internet-Draft will expire on January 6, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . 7 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 7 5.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 7
5.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . . 7
6. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 6. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. XR Report Block Registration . . . . . . . . . . . . . . . 9 8.1. XR Report Block Registration . . . . . . . . . . . . . . . 9
8.2. SDP Parameter Registration . . . . . . . . . . . . . . . . 9 8.2. SDP Parameter Registration . . . . . . . . . . . . . . . . 9
8.3. Contact information for IANA registrations . . . . . . . . 9 8.3. Contact information for IANA registrations . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
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 . . . . 11
A.2. changes in A.2. changes in
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 . . . . 11 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 . . . . 11
A.3. changes in A.3. changes in
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 . . . . 11 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 . . . . 11
A.4. changes in A.4. changes in
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 . . . . 11 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 . . . . 11
A.5. changes in
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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 (e.g., packet loss) [RFC4585]. Both long-term and
long-term and short-term feedback enable a sender to adapt its media short-term feedback enable a sender to adapt its media transmission
transmission and/or encoding dynamically to the observed path and/or encoding dynamically to the observed path characteristics.
characteristics.
RFC3611 [RFC3611] defines RTCP eXtension Reports as a detailed RFC3611 [RFC3611] defines RTCP Extended Reports as a detailed
reporting framework to provide more than just the coarse RR reporting framework to provide more than just the coarse RR
statistics. The detailed reporting may enable a sender to react more statistics. The detailed reporting may enable a sender to react more
appropriately to the observed networking conditions as these can be appropriately to the observed networking conditions as these can be
characterized better, albeit at the expense of extra overhead. characterized better, although at the expense of extra overhead.
Among many other fields, RFC3611 specifies the Loss RLE block which Among many other report blocks, RFC3611 specifies the Loss RLE block
define runs of packets received and lost with the granularity of which reports runs of packets received and lost with the granularity
individual packets. This can help both error recovery and path loss of individual packets. This can help both error recovery and path
characterization. In addition to lost packets, RFC3611 defines the loss characterization. In addition to lost packets, RFC3611 defines
notion of "discarded" packets: packets that were received but dropped the notion of "discarded" packets: packets that were received but
from the jitter buffer because they were either too early (for dropped from the jitter buffer because they were either too early
buffering) or too late (for playout). This metric is part of the (for buffering) or too late (for playout). The "discard rate" metric
VoIP metrics report block even though it is not just applicable to is part of the VoIP metrics report block even though it is not just
audio: it is specified as the fraction of discarded packets since the applicable to audio: it is specified as the fraction of discarded
beginning of the session. See section 4.7.1 of RFC3611 [RFC3611]. packets since the 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 in a measurement o Reporting the number of discarded packets in a measurement
interval, i.e., during either the last reporting interval or since interval, i.e., during either the last reporting interval or since
the beginning of the session, as indicated by a flag in the the beginning of the session, as indicated by a flag in the
suggested XR report [I-D.ietf-xrblock-rtcp-xr-discard]. suggested XR report [I-D.ietf-xrblock-rtcp-xr-discard]. If an
endpoint needs to report packet discard due to other reasons than
early- and late-arrival (for example, discard due to duplication,
redundancy, etc.) then it should consider using the Discarded
Packets Report Block [I-D.ietf-xrblock-rtcp-xr-discard].
o Reporting gaps and bursts of discarded packets during a o Reporting gaps and bursts of discarded packets during a
measurement interval, i.e., the last reporting interval or measurement interval, i.e., the last reporting interval or the
cumulatively since the beginning of the session duration of the session
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. [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 [I-D.ietf-xrblock-rtcp-xr-discard] or from the gap/burst
appear feasible: The former would require an unduly high amount of report [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], these two
reporting which still might not be sufficient due to the non- mechanisms do not appear feasible: The former would require an unduly
deterministic scheduling of RTCP packets. The latter incur 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 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].
Complementary to or instead of the indication which packets were Complementary to or instead of the indication which packets were
discarded, an XR block is defined to indicate the number of bytes discarded, an XR block is defined to indicate the number of bytes
discarded, per interval or for the duration of the session, similar discarded, per interval or for the duration of the session, similar
to other XR report blocks. 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.
3. XR Discard RLE Report Block 3. XR Discard RLE Report Block
The XR Discard RLE report block uses the same format as specified for The XR Discard RLE report block uses the same format as specified for
the loss and duplicate report blocks in RFC3611 [RFC3611]. Figure the loss and duplicate report blocks in [RFC3611]. Figure 1 recaps
Figure 1 recaps the packet format. The fields "BT", "T", "block the packet format. The fields "BT", "T", "block length", "SSRC of
length", "SSRC of source", "begin_seq", and "end_seq" SHALL have the source", "begin_seq", and "end_seq" SHALL have the same semantics and
same semantics and representation as defined in RFC3611 [RFC3611]. representation as defined in [RFC3611]. The "chunks" encoding the
The "chunks" encoding the run length SHALL have the same run length SHALL have the same representation as in RFC3611, but
representation as in RFC3611, but encode discarded packets. encode discarded packets.
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=DRLE |rsvd |E| T | block length | | BT=DRLE |rsvd |E| T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Block Type (BT, 8 bits): A Run-length encoded Discarded Packets
MUST be ignored by senders. Report Block is identified by the constant DRLE.
[Note to RFC Editor: please replace DRLE with the IANA provided RTCP
XR block type for this block. Please remove this note prior to
publication as an RFC.]
rsvd (3 bits): These reserved 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 and not appear marked in both. Packets reported
discarded without further information available, packets reported in in neither are considered to be properly received and not discarded.
neither are considered to be properly received and not discarded.
Discard RLE Report Blocks SHOULD be sent in conjunction with an RTCP Discard RLE Report Blocks SHOULD be sent in conjunction with an RTCP
RR as a compound RTCP packet. RR as a compound RTCP packet.
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].
skipping to change at page 6, line 17 skipping to change at page 6, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=BDR | I |E|reserved | 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
Block Type (BT, 8 bits): A Bytes Discarded Packets Report Block is
identified by the constant BDR.
[Note to RFC Editor: please replace BDR with the IANA provided RTCP
XR block type for this block. Please remove this note prior to
publication as an RFC.]
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 Interval, or a Cumulative metric, that is, whether
whether the reported value applies to the most recent measurement the reported value applies to the most recent measurement interval
interval duration between successive reports (I=10, the Interval duration between successive reports (I=10, the Interval Duration) or
Duration) or to the accumulation period characteristic of cumulative to the accumulation period characteristic of cumulative measurements
measurements (I=11, the Cumulative Duration) or is a sampled value (I=11, the Cumulative Duration). Since the bytes discarded are not
(I=01). measured at a particular time instance but over one or several
reporting intervals, the metric MUST NOT be reported as a Sampled
Metric (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 it reports bytes discarded due to early
due to too early arrival and MUST be set to '0' otherwise. In case arrival and MUST be set to '0' if it reports bytes discarded due to
both early and late discarded packets shall be reported, two Bytes late arrival. In case both early and late discarded packets shall be
Discarded report blocks MUST be included. reported, two Bytes Discarded report blocks MUST be included.
These reserved bits (5 bits) SHOULD be set to zero by receivers and These reserved bits (5 bits) SHOULD be set to zero by receivers and
MUST be ignored by senders. MUST be ignored by senders.
block length (16 bits) MUST be set to 2, in accordance with the block length (16 bits) MUST be set to 2, in accordance with the
definition of this field in RFC3611 [RFC3611]. The block MUST be definition of this field in [RFC3611]. The block MUST be discarded
discarded if the block length is set to a different value. if the block length is set to a different value.
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. indicating the total number of bytes discarded.
If the XR block is not preceded by a measurement identity block If Interval Metric flag (I=11) is set, the value in the field
[I-D.ietf-xrblock-rtcp-xr-meas-identity] then the value indicates the indicates the number of bytes discarded from the start of the
bytes lost from from the start of the session (I=11), or the number session, if Interval Metric flag (I=01) is set, it indicates the
of bytes discarded since the last RTCP XR Bytes Discarded block was number of bytes discarded since the last RTCP XR Byte Discarded Block
received (I=10). was received.
If the XR block follows a measurement identity block If the XR block follows a measurement identity block
[I-D.ietf-xrblock-rtcp-xr-meas-identity] in an RTCP RR packet then [I-D.ietf-xrblock-rtcp-xr-meas-identity] in the same RTCP compound
the cumulative (I=11) and interval (I=10) correspond to the values in packet then the cumulative (I=11) or the interval (I=10) for this
the measurement block. report block corresponds to the values of the "measurement duration"
in the measurement information block.
If the receiver sends the Bytes Discarded Report Block without the If the receiver sends the Bytes Discarded Report Block without the
measurement identity block then the discard block MUST be sent in measurement identity block then the discard block MUST be sent in
conjunction with an RTCP RR as a compound RTCP packet. 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)
node and the sender RTP node. node and the media sender.
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
skipping to change at page 8, line 12 skipping to change at page 8, line 18
[I-D.ietf-xrblock-rtcp-xr-meas-identity]. Under all other [I-D.ietf-xrblock-rtcp-xr-meas-identity]. Under all other
circumstances it MUST ignore the block. 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 reports.
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
for this attribute. In this case, the RTCP XR attribute as defined for this attribute. In this case, the RTCP XR attribute as defined
in RFC3611 [RFC3611] MUST be used. The SDP RFC4566 [RFC4566] in RFC3611 [RFC3611] MUST be used. The SDP RFC4566 [RFC4566]
attribute 'xr-format' defined in RFC3611 is augmented as described in attribute 'xr-format' defined in RFC3611 is augmented as described in
the following to indicate the discard metric. the following to indicate the RLE discard metric and bytes discarded
metric.
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)]
CRLF ; defined in [RFC3611] CRLF ; defined in [RFC3611]
xr-format =/ xr-discard-rle xr-format =/ xr-discard-rle
/ xr-discard-bytes / xr-discard-bytes
xr-discard-rle = "discard-rle" xr-discard-rle = "discard-rle"
xr-discard-bytes = "discard-bytes" xr-discard-bytes = "discard-bytes"
The literal 'discard-rle' MUST be used to indicate support for the The parameter 'discard-rle' MUST be used to indicate support for the
Discard RLE Report Block defined in section Section 3, the literal Discard RLE Report Block defined in Section 3, the parameter
'discard-bytes' to indicate support for the Bytes Discarded Report 'discard-bytes' to indicate support for the Bytes Discarded Report
Block defined in section Section 4 Block defined in Section 4
For signaling support for the discard metric, the rules defined in For signaling support of the RLE discard metric and bytes discarded
RFC3611 apply. Generally, senders and receivers SHOULD indicate this metric, the rules defined in RFC3611 apply. Generally, senders and
capability if they support this metric and would like to use it in receivers SHOULD indicate this capability if they support these
the specific media session being signaled. The receiver MAY decide metrics and would like to use it in the specific media session being
not to send discard information unless it knows about the sender's signaled. The receiver MAY decide not to send discard information
support to save on RTCP reporting bandwidth. unless it knows about the sender's support to save on RTCP reporting
bandwidth.
A participant in a media session MAY use the two report blocks A participant in a media session MAY use the two report blocks
specified in this document without any explicit (SDP) signaling. specified in this document without any explicit (SDP) signaling.
7. Security Considerations 7. Security Considerations
The security considerations of RFC3550 [RFC3550], RFC3611 [RFC3611], The security considerations of RFC3550 [RFC3550], RFC3611 [RFC3611],
and RFC4585 [RFC4585] apply. Since this document offers only a more and RFC4585 [RFC4585] apply. Since this document offers only a more
precise reporting for an already existing metric, no further security precise reporting for an already existing metric, no further security
implications are foreseen. implications are foreseen.
skipping to change at page 9, line 18 skipping to change at page 9, line 25
general guidelines on IANA considerations for RTCP XR, refer to general guidelines on IANA considerations for RTCP XR, refer to
RFC3611 [RFC3611]. RFC3611 [RFC3611].
8.1. XR Report Block Registration 8.1. XR Report Block Registration
This document extends the IANA "RTCP XR Block Type Registry" by two This document extends the IANA "RTCP XR Block Type Registry" by two
new values: DRLE and BDR. new values: DRLE and BDR.
[Note to RFC Editor: please replace DRLE and BDR with the IANA [Note to RFC Editor: please replace DRLE and BDR with the IANA
provided RTCP XR block type for this block here and in the diagrams provided RTCP XR block type for this block here and in the diagrams
above.] above. Please remove this note prior to publication as an RFC.]
8.2. SDP Parameter Registration 8.2. SDP Parameter Registration
This document registers two new parameters for the Session This document registers two new parameters for the Session
Description Protocol (SDP), "discard-rle" and "discard-bytes", in the Description Protocol (SDP), "discard-rle" and "discard-bytes", in the
"RTCP XR SDP Parameters Registry". "RTCP XR SDP Parameters Registry".
8.3. Contact information for IANA registrations 8.3. Contact information for IANA registrations
Joerg Ott (jo@comnet.tkk.fi) Joerg Ott (jo@comnet.tkk.fi)
Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland. Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland.
9. Acknowledgements 9. Acknowledgements
Thanks to Qin Wu and Roni Even for providing valuable feedback on Thanks to Qin Wu, Colin Perkins, Dan Romascanu, and Roni Even for
earlier versions of this draft providing valuable feedback on earlier versions of this draft
10. Normative References 10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. 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, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003. November 2003.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [I-D.ietf-xrblock-rtcp-xr-meas-identity]
Protocol (RTCP) Extensions for Single-Source Multicast Hunt, G., Clark, A., and W. Wu, "Measurement Identity and
Sessions with Unicast Feedback", RFC 5760, February 2010. information Reporting using SDES item and XR Block",
draft-ietf-xrblock-rtcp-xr-meas-identity-07 (work in
progress), January 2012.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
October 2011.
10.2. Informative References
[I-D.ietf-xrblock-rtcp-xr-discard] [I-D.ietf-xrblock-rtcp-xr-discard]
Hunt, G., Clark, A., Zorn, G., and W. Wu, "RTCP XR Report Hunt, G., Clark, A., Zorn, G., and W. Wu, "RTCP XR Report
Block for Discard metric Reporting", Block for Discard metric Reporting",
draft-ietf-xrblock-rtcp-xr-discard-00 (work in progress), draft-ietf-xrblock-rtcp-xr-discard-04 (work in progress),
October 2011. December 2011.
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]
Hunt, G., Clark, A., Huang, R., and W. Wu, "RTCP XR Report Hunt, G., Clark, A., Huang, R., and W. Wu, "RTCP XR Report
Block for Burst/Gap Discard metric Reporting", Block for Burst/Gap Discard metric Reporting",
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-00 (work in draft-ietf-xrblock-rtcp-xr-burst-gap-discard-03 (work in
progress), October 2011.
[I-D.ietf-xrblock-rtcp-xr-meas-identity]
Hunt, G., Clark, A., and W. Wu, "Measurement Identity and
information Reporting using SDES item and XR Block",
draft-ietf-xrblock-rtcp-xr-meas-identity-01 (work in
progress), October 2011. progress), October 2011.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
October 2011.
Appendix A. Change Log Appendix A. Change Log
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
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.
skipping to change at page 11, line 22 skipping to change at page 11, line 27
A.3. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 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 Removed the extra Tag bits from the Discarded bytes XR block.
o Clarified use of measurement identity block in Section 4 and 5.2 o Clarified use of measurement identity block in Section 4 and 5.2
A.4. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 A.4. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03
o Added explanation for block length in bytes discarded block o Added explanation for block length in bytes discarded block
o Added an acknowledgement section o Added an acknowledgement section
A.5. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04
o Added Block Type definition to each XRBlock
o Made changes requested in WGLC
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
Varun Singh Varun Singh
Aalto University Aalto University
School of Science and Technology School of Science and Technology
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 Espoo, FIN 02150
Finland Finland
Email: varun@comnet.tkk.fi Email: varun@comnet.tkk.fi
URI: http://www.netlab.tkk.fi/~varun/ URI: http://www.netlab.tkk.fi/~varun/
 End of changes. 42 change blocks. 
109 lines changed or deleted 136 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/