One document matched: draft-singh-xrblock-rtcp-xr-bytes-discarded-metric-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3550 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3611 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc4585 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc4566 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc6390 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6390.xml">
<!ENTITY rfc6776 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6776.xml">
<!ENTITY rfc5481 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5481.xml">
<!ENTITY rfc3711 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc5124 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5124.xml">
<!ENTITY I-D.ietf-xrblock-rtcp-xr-discard PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-xrblock-rtcp-xr-discard.xml">
<!ENTITY I-D.ietf-xrblock-rtcp-xr-burst-gap-discard PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-xrblock-rtcp-xr-burst-gap-discard.xml">
<!ENTITY I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics.xml">
<!ENTITY I-D.ietf-avt-srtp-not-mandatory PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-srtp-not-mandatory.xml">
<!ENTITY I-D.ietf-avtcore-rtp-security-options PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-security-options.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes" ?>
<rfc ipr="trust200902"
docName="draft-singh-xrblock-rtcp-xr-bytes-discarded-metric-00"
category="std">
<!-- What is the category field value-->
<front>
<title abbrev="RTCP XR Bytes Discarded">
RTP Control Protocol (RTCP) Extended Reports (XR) for Bytes Discarded
Metric
</title>
<author fullname="Varun Singh" initials="V" surname="Singh" role="editor">
<organization>Aalto University</organization>
<address>
<postal>
<street>School of Electrical Engineering</street>
<street>Otakaari 5 A</street>
<city>Espoo</city>
<region>FIN</region>
<code>02150</code>
<country>Finland</country>
</postal>
<email>varun@comnet.tkk.fi</email>
<uri>http://www.netlab.tkk.fi/~varun/</uri>
</address>
</author>
<author initials="J." surname="Ott" fullname="Joerg Ott">
<organization>Aalto University</organization>
<address>
<postal>
<street>School of Electrical Engineering</street>
<street>Otakaari 5 A</street>
<city>Espoo</city>
<region>FIN</region><code>02150</code>
<country>Finland</country>
</postal>
<email>jo@comnet.tkk.fi</email>
</address>
</author>
<author initials="I." surname="Curcio" fullname="Igor D.D. Curcio">
<organization>Nokia Research Center</organization>
<address>
<postal>
<street>P.O. Box 1000 (Visiokatu 3)</street>
<city>Tampere</city> <region>FIN</region><code>33721</code>
<country>Finland</country>
</postal>
<email>igor.curcio@nokia.com</email>
</address>
</author>
<date year="2013" />
<area>RAI</area>
<workgroup>XR Block Working Group</workgroup>
<keyword>RTP</keyword>
<keyword>RTCP</keyword>
<keyword>discard metrics</keyword>
<abstract>
<t>
The RTP 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 report computing
the bytes discarded from the de-jitter buffer after successful
reception.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<xref target="RFC3550">RTP</xref> provides a transport for real-time
media flows such as audio and video together with the RTP control
protocol (RTCP) 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)
<xref target="RFC4585"/>. Both long-term and short-term feedback enable
a media sender to adapt its media transmission and/or encoding
dynamically to the observed path characteristics.
</t>
<t>
<xref target="RFC3611">RFC3611</xref> defines RTCP Extended Reports as a
detailed reporting framework to provide more than just the coarse
Receiver Report (RR) statistics. The detailed reporting may enable a
media sender to react more appropriately to the observed networking
conditions as these can be characterized better, although at the expense
of extra overhead.
</t>
<t>
In addition to lost packets, RFC3611 defines the notion of "discarded"
packets: packets that were received but dropped from the de-jitter
buffer because they were either too early (for buffering) or too late
(for playout). The "discard rate" 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 <xref target="RFC3611">RFC3611</xref>.
The discard metric is believed to be applicable to a large class of RTP
applications which use a de-jitter buffer <xref
target="RFC5481">RFC5481</xref>.
</t>
<t>
Recently proposed extensions to the Extended Reports (XR) reporting
suggest enhancing this discard metric:
<list style="symbols">
<t>
Reporting the number of discarded packets in a measurement interval,
i.e., during either the last reporting interval or since the beginning
of the session, as indicated by a flag in the suggested XR report <xref
target="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 <xref
target="I-D.ietf-xrblock-rtcp-xr-discard"/>.
</t>
<t>
Reporting gaps and bursts of discarded packets during a measurement
interval, i.e., the last reporting interval or the duration of the
session <xref target="I-D.ietf-xrblock-rtcp-xr-burst-gap-discard"/>.
</t>
<t>
Reporting run-length encoding of discarded packet during a measurement
interval, i.e., between a set of sequence numbers <xref
target="I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics"/>.
</t>
</list>
</t>
<t>
However, none of these metrics allow a receiver to report precisely the
number of bytes that were discarded. While this information could in
theory be derived from high-frequency reporting on the number of
discarded packets <xref target="I-D.ietf-xrblock-rtcp-xr-discard"/> or
from the Discard RLE report <xref
target="I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics"/>, 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 incurs
significant complexity (by storing a map of sequence numbers and packet
sizes) and reporting overhead.
</t>
<t>
An XR block is defined in this document to indicate the number of bytes
discarded, per interval or for the duration of the session, similar to
other XR report blocks.
</t>
<!-- <t>
Alternatively, if the sender keeps a history of the size of the packets reported
in the measurement interval then the sender can calculate the number of
bytes discarded from the information in the discard RLE block.
</t> -->
</section>
<section title="Terminology" anchor="sec-terminology">
<t>
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,
<xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
The terminology defined in <xref target="RFC3550">RTP</xref> and
in the extensions for XR reporting <xref target="RFC3611"/> applies.
</t>
</section>
<section title="XR Bytes Discarded Report Block" anchor="spec-2">
<t>
The XR Bytes Discarded report block uses the following format which
follows the model of the framework for performance metric development
<xref target="RFC6390" />.
</t>
<t>
<!-- Todo: change I to 2-bits -->
<figure anchor="packet-format-bytes" title="XR Bytes Discarded Report Block">
<artwork><![CDATA[
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=BDR | I |E|reserved | block length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of bytes discarded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
Block Type (BT, 8 bits): A Bytes Discarded Packets Report Block is
identified by the constant BDR.
</t>
<t>
[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.]
</t>
<t>
The Interval Metric flag (I) (2 bits) is used to indicate whether the
discard metric is Interval, or a Cumulative metric, that is, whether the
reported value applies to the most recent measurement interval duration
between successive reports (I=10, the Interval Duration) or to the
accumulation period characteristic of cumulative measurements (I=11, the
Cumulative Duration). Since the bytes discarded are not 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). In addition, the
value I=00 is reserved and MUST NOT be sent, and MUST be discarded
when received.
</t>
<!--[Changed because I bit in MONARCH is 2 bits ]
Numerical values for sampled duration are provided in the
Measurement Identifier block referenced by the tag field below.
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).
Numerical values for both these intervals are provided in the
Measurement Identifier block referenced by the tag field below.
<t>
Measurement Identifier association (Tag) 3 bits:
This field is used to identify the Measurement Identifier block
which describes the sampled measurement. The tag in the corresponding
Measurement Identifier block has the same tag value. Note that there
may be more than one Measurement Identifier block per RTCP packet.
The tag MUST be set to 0 when using cumulative or interval durations.
</t>
-->
<t>
The 'E' bit is introduced to distinguish between packets discarded due to
early arrival and those discarded due to late arrival. The 'E' bit is
set to '1' if it reports bytes discarded due to early arrival and is
set to '0' if it reports bytes discarded due to late arrival. If a
duplicate packet is received and discarded, these duplicate packets are
ignored and not reported. In case both early and late discarded packets
shall be reported, two Bytes Discarded report blocks MUST be included.
</t>
<t>
<!-- These reserved bits (5 bits) MUST be set to zero by media receivers
and MUST be ignored by media senders. -->
reserved (5 bits): This field is reserved for future definition. In the
absence of such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver.
</t>
<t>
block length (16 bits) MUST be set to 2, in accordance with the definition
of this field in <xref target="RFC3611" />. The block MUST be discarded if
the block length is set to a different value.
</t>
<t>
The 'number of bytes discarded' is a 32-bit unsigned integer value
indicating the total number of bytes discarded. Bytes discarded
corresponds to the RTP payload size of every RTP packet that is discarded
(due to early or late arrival). Hence, the bytes discarded ignores the
size of any RTP header extensions and the size of the padding bits. Also
the discarded packet is associated to the interval in which it was
discarded and not when it was expected.
</t>
<t>
If Interval Metric flag (I=11) is set, the value in the field indicates
the number of bytes discarded from the start of the session, if Interval
Metric flag (I=01) is set, it indicates the number of bytes discarded
since the last RTCP XR Byte Discarded Block was received.
</t>
<t>
If the XR block follows a measurement identity block <xref
target="RFC6776"/> in the same RTCP
compound packet then the cumulative (I=11) or the interval (I=10) for this
report block corresponds to the values of the "measurement duration" in
the measurement information block.
</t>
<t>
<!-- Bytes Discarded Report Blocks SHOULD be sent in conjunction with an
RTCP RR as a compound RTCP packet. -->
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 Receiver Report (RR) as a compound RTCP packet.
</t>
<!-- <t>
Editor's note: is it acceptable to use one of the 'reserved' bits for this
purpose or should two block types be used?
</t> -->
</section>
<section title="Protocol Operation" anchor="protocol">
<t>
This section describes the behavior of the reporting node (= media
receiver) and the media sender.
</t>
<section title="Reporting Node (Receiver)">
<t>
Transmission of RTCP XR Bytes Discarded Report is up to the discretion
of the media receiver, as is the reporting granularity. However, it is
RECOMMENDED that the media receiver signals all discarded packets using
the method defined in this document. If all packets over a reporting
period were discarded, the media receiver MAY use the Discard Report
Block <xref target="I-D.ietf-xrblock-rtcp-xr-discard"/> instead.
</t>
<t>
The media receiver MAY send the Bytes Discard Reports as part of the
regularly scheduled RTCP packets as per RFC3550. It MAY also include
Bytes Discard Reports in immediate or early feedback packets as per
RFC4585.
</t>
</section>
<section title="Media Sender">
<t>
The media sender MUST be prepared to operate without receiving any Bytes
Discarded reports. If Bytes Discarded reports are generated by the media
receiver, the media sender cannot rely on all these reports being
received, nor can the media sender rely on a regular generation pattern
from the media receiver.
</t>
<t>
However, if the media sender receives any RTCP reports but no Bytes
Discard report blocks and is aware that the media receiver supports
Bytes Discard report blocks, it MAY assume that no packets were
discarded at the media receiver.
</t>
<t>
The media 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 <xref target="RFC6776"/>. Under all other
circumstances it MUST ignore the block.
</t>
</section>
</section>
<section title="SDP signaling" anchor="sdp">
<!-- <t>
The report blocks specified in this document define extensions 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 reports.
</t> -->
<t>
A participant of a media session MAY use SDP to signal its support for the
report block specified in this document or use them without any prior
signaling (see section 5 of <xref target="RFC3611" />).
</t>
<t>
For signaling in SDP, the RTCP XR attribute as defined in <xref
target="RFC3611" /> MUST be used. The SDP <xref target="RFC4566" />
attribute 'xr-format' defined in RFC3611 is augmented as described in the
following to indicate the bytes discarded metric.
</t>
<t>
<figure>
<artwork><![CDATA[
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)]
CRLF ; defined in [RFC3611]
xr-format =/ xr-discard-bytes
xr-discard-bytes = "discard-bytes"
]]></artwork>
</figure>
</t>
<t>
The parameter 'discard-bytes' to indicate support for the Bytes Discarded
Report Block defined in <xref target="spec-2"/>.
</t>
<t>
When SDP is used in Offer/Answer context, the mechanism defined in <xref
target="RFC3611" /> for unilateral "rtcp-xr" attribute parameters applies
(see section 5.2 of <xref target="RFC3611" />).
</t>
</section>
<section title="Security Considerations" anchor="security">
<t>
The Bytes Discarded block does not provide per-packet statistics, hence
the risk to confidentiality documented in Section 7, paragraph 3 of <xref
target="RFC3611" /> does not apply. In some situations, returning very
detailed error information (e.g., over-range measurement or measurement
unavailable) using this report block can provide an attacker with insight
into the security processing. Implementers should consider the guidance in
<xref target="I-D.ietf-avt-srtp-not-mandatory" /> for using appropriate
security mechanisms, i.e., where security is a concern, the implementation
should apply encryption and authentication to the report block. For
example this can be achieved by using the AVPF profile together with the
Secure RTP profile as defined in <xref target="RFC3711" />; an appropriate
combination of the two profiles (an "SAVPF") is specified in <xref
target="RFC5124" />. However, other mechanisms also exist (documented in
<xref target="I-D.ietf-avtcore-rtp-security-options" />) and might be more
suitable.
</t>
<t>
Additionally, The security considerations of <xref target="RFC3550" />,
<xref target="RFC3611" />, and <xref target="RFC4585" /> apply.
<!-- Since this document offers only a more precise reporting for an
already existing metric, no further security implications are foreseen.
-->
</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>
New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to
<xref target="RFC3611" />.
</t>
<section title="XR Report Block Registration">
<t>
This document extends the IANA "RTP Control Protocol Extended Reports
(RTCP XR) Block Type Registry" by a new value: BDR (Bytes Discarded
Report).
</t>
<t>
[Note to RFC Editor: please replace BDR with the IANA provided RTCP XR
block type for this block here and in the diagrams above. Please remove
this note prior to publication as an RFC.]
</t>
</section>
<section title="SDP Parameter Registration">
<t>
This document registers a new parameters for the Session Description
Protocol (SDP), "discard-bytes" in the "RTP Control Protocol Extended
Reports (RTCP XR) Session Description Protocol (SDP) Parameters
Registry".
</t>
</section>
<section title="Contact information for IANA registrations">
<t>
Varun Singh (varun.singh@iki.fi)
</t>
<t>
Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland.
</t>
</section>
</section>
<section title="Acknowledgments">
<t>
The authors would like to thank
Alan Clark,
Roni Even,
Sam Hartman,
Colin Perkins,
Dan Romascanu,
Dan Wing, and
Qin Wu
for providing valuable feedback on earlier versions of this draft.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3550;
&rfc3611;
&rfc4585;
&rfc4566;
&rfc6390;
&rfc6776;
&I-D.ietf-xrblock-rtcp-xr-discard;
</references>
<references title="Informative References">
&I-D.ietf-xrblock-rtcp-xr-burst-gap-discard;
&I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics;
&rfc5481;
&rfc3711;
&rfc5124;
&I-D.ietf-avt-srtp-not-mandatory;
&I-D.ietf-avtcore-rtp-security-options;
</references>
<section title="Metrics represented using RFC6390 Template">
<t> RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC
number, when assigned. </t>
<t> <list style="letters">
<t> Bytes Discarded Metric
<list style="symbols">
<t> Metric Name: Bytes Discarded Metric </t>
<t> Metric Description: Total number of bytes discarded over the
period covered by this report. </t>
<t> Method of Measurement or Calculation: See section 4, number of
bytes discarded definition [RFCXXXX]. </t>
<t> Units of Measurement: See section 4, number of bytes discarded
definition [RFCXXXX]. </t>
<t> Measurement Point(s) with Potential Measurement Domain: See
section 4, 1st paragraph [RFCXXXX]. </t>
<t> Measurement Timing: See section 4, last three paragraphs of
[RFCXXXX] for measurement timing and for the Interval Metric flag.
</t>
<t>Use and applications: See section 1, paragraph 1 of [RFCXXXX].</t>
<t> Reporting model: See RFC3611. </t>
</list> </t>
</list> </t>
</section>
<section anchor="App-a" title="Change Log">
<t>Note to the RFC-Editor: please remove this section prior to
publication as an RFC.</t>
<section title="changes in
draft-singh-xrblock-rtcp-xr-bytes-discarded-metric-00">
<t><list style="symbols">
<t>Bytes discarded metric split from <xref
target="I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics"
/>.</t>
</list></t>
</section>
</section>
</back>
</rfc>
<!-- LocalWords: xref CDATA -->
| PAFTECH AB 2003-2026 | 2026-04-23 22:02:38 |