One document matched: draft-ietf-xrblock-rtcp-xr-jb-14.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-ietf-xrblock-rtcp-xr-jb-14.txt"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="RTCP XR Jitter Buffer">RTP Control Protocol (RTCP) Extended
Report (XR) Block for De-Jitter Buffer Metric Reporting</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization abbrev="Telchemy">Telchemy Incorporated</organization>
<address>
<postal>
<street>2905 Premiere Parkway, Suite 280</street>
<city>Duluth</city>
<region>GA</region>
<code>30097</code>
<country>USA</country>
</postal>
<email>alan.d.clark@telchemy.com</email>
</address>
</author>
<author fullname="Varun Singh" initials="V" surname="Singh">
<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>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<date year="2013" />
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>Audio/Video Transport Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Real Time Control Protocol</keyword>
<abstract>
<t>This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) Block that allows the reporting of De-Jitter Buffer metrics for a
range of RTP applications.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<section title="De-Jitter Buffer Metrics Block">
<t>This document defines a new block type to augment those defined in
<xref target="RFC3611"></xref>, for use in a range of RTP
applications.</t>
<t>The new block type provides information on jitter buffer
configuration and performance.</t>
<t>The metric belongs to the class of transport-related end system
metrics defined in <xref target="RFC6792"></xref>.</t>
<t>Instances of this metrics block refer by Synchronization source
(SSRC) to the separate auxiliary Measurement Information block <xref
target="RFC6776"></xref> which contains information such as the SSRC
of the measured stream, and RTP sequence numbers and time intervals
indicating the span of the report.</t>
</section>
<section title="RTCP and RTCP XR Reports">
<t>The use of RTCP for reporting is defined in <xref
target="RFC3550"></xref>. <xref target="RFC3611"></xref> defines an
extensible structure for reporting using an RTCP Extended Report (XR).
This document defines a new Extended Report block for use with <xref
target="RFC3550"></xref> and <xref target="RFC3611"></xref>.</t>
</section>
<section title="Performance Metrics Framework">
<t>The Performance Metrics Framework <xref target="RFC6390"></xref>
provides guidance on the definition and specification of performance
metrics. The RTP Monitoring Architectures <xref
target="RFC6792"></xref> provides guideline for reporting block format
using RTCP XR. Metrics described in this draft are in accordance with
the guidelines in <xref target="RFC6390"></xref>and <xref
target="RFC6792"></xref>.</t>
</section>
<section title="Applicability">
<t>Real-time applications employ a de-jitter buffer <xref
target="RFC5481"></xref> to absorb jitter introduced on the path from
source to destination. These metrics are used to report how the
de-jitter buffer at the receiving end of RTP stream behaves as a
result of jitter in the network; and they are applicable to a range of
RTP applications.</t>
<t>These metrics are corresponding to terminal related factors that
affect real-time application quality and are useful to provide better
end-user quality of experience (QoE) when these terminal-related
factors are used as inputs to calculate QoE metrics [QMB].</t>
</section>
</section>
<section title="Terminology">
<section title="Standards Language">
<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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="De-Jitter Buffer Operation">
<t>A de-jitter buffer is required to absorb delay variation in network
delivery of media packets. A de-jitter buffer works by holding media
data for a period of time after it is received and before it is played
out. Packets that arrive early are held in the de-jitter buffer longer.
If packets arrive too early they may be discarded if there is no
available de-jitter buffer space. If packets are delayed excessively by
the network they may be discarded if they miss their playout time.</t>
<t>The de-jitter buffer can be considered as a time window with early
edge aligned with the delay corresponding to the earliest arriving
packet and late edge representing the maximum permissible delay before a
late arriving packet would be discarded. The delay applied to packets
that arrive on time or at their expected arrival time is known as the
Nominal Delay and this is equivalent to the time difference/ buffer size
difference between the on-time packets insertion point and the point at
which packets are read out.</t>
<t>The reference for the expected arrival time may, for example, be the
first packet in the session or the running average delay. If all packets
arrived at their expected arrival time, then every packet would be held
in the de-jitter buffer exactly the Nominal Delay.</t>
<t>The de-jitter buffer maximum delay is the delay that is applied to an
earliest arriving packet that is not discarded and corresponds to the
early edge of the de-jitter buffer time window.</t>
<section title="Idealized De-Jitter Buffer">
<t>In practice de-jitter buffer implementations vary considerably
however they should behave in a manner conceptually consistent with an
idealized de-jitter buffer described as follows:<list>
<t>(i). Receive the first packet and delay playout by D ms. Keep
the RTP timestamp and receive time as a reference.<vspace
blankLines="1" />RTP Timestamp(TS)[1]<vspace
blankLines="1" />receive time[1]<vspace blankLines="1" />Assume
that both are normalized in ticks (there are 10 000 ticks in a
millisecond).</t>
<t>(ii). Receive the next packet</t>
<t>(iii). Calculate r = RTP TS[n] - RTP TS[1] and t = receive
time[n] - receive time[1]. If r == t then the packet arrived on
time. If r < t then the packet arrived late and if r > t
then the packet arrived early.</t>
<t>(iv). Delay playout of packet by D + (r-t)</t>
<t>(v). Go back to (ii)</t>
</list></t>
<t>Note that this idealized implementation assumes that the sender's
RTP clock is synchronized to the clock in the receiver which is used
to timestamp packet arrivals. If there is no such inherent
synchronization, the system may need to use an adaptive de-jitter
buffer or other techniques to ensure reliable reception.</t>
</section>
<section title="Fixed De-Jitter Buffer">
<t>A fixed de-jitter buffer lacks provision to track network condition
and has a fixed size and packets leaving the de-jitter buffer have a
constant delay. For fixed de-jitter buffer implementation, the nominal
delay is set to a constant value corresponding to the packets that
arrive at their expected arrival time while the maximum delay is set
to a constant value corresponding to the fixed size of the de-jitter
buffer.</t>
</section>
<section title="Adaptive De-Jitter Buffer">
<t>An adaptive de-jitter buffer can adapt to the change in the
network’s delay and has variable size or variable delay. It allows the
nominal delay to be set to a low value initially, to minimize user
perceived delay, however can automatically extend the late edge (and
possibly also retract the early edge) of buffer window if a
significant proportion of packets are arriving late (and hence being
discarded).</t>
</section>
</section>
<section title="De-Jitter Buffer Metrics Block">
<t>This block describes the configuration and operating parameters of
the de-jitter buffer in the receiver of the RTP end system or RTP mixer
which sends the report. Instances of this metrics block refer by SSRC to
the separate auxiliary Measurement Information Block <xref
target="RFC6776"></xref> which describes the measurement interval in
use. This metrics block relies on the measurement interval in the
Measurement Information Block indicating the span of the report and MUST
be sent in the same compound RTCP packet as the Measurement Information
Block. If the measurement interval is not received in the same compound
RTCP packet as this metrics block, this metrics block MUST be
discarded.</t>
<section title="Report Block Structure">
<t>De-Jitter Buffer (DJB) Metrics Block<figure
title="Figure 1: Report Block Structure">
<artwork>
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=DJB | I |C| Rsvd. | block length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DJB nominal | DJB maximum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DJB high water mark | DJB low water mark |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
</section>
<section title="Definition of Fields in De-Jitter Buffer Metrics Block">
<t><list style="hanging">
<t hangText="Block type (BT): 8 bits"><vspace blankLines="1" /> A
de-jitter buffer Metrics Report Block is identified by the
constant DJB.<vspace blankLines="1" /> [Note to RFC Editor: please
replace DJB with the IANA provided RTCP XR block type for this
block.]<vspace blankLines="1" /></t>
<t hangText="Interval Metric flag (I): 2 bits"><vspace
blankLines="1" />This field is used to indicate whether the
de-jitter buffer metrics are Sampled, Interval or Cumulative
metrics: <list>
<t>I=01: Sampled Value - the reported value is a sampled
instantaneous value.</t>
<t>I=10: Interval Duration - the reported value applies to the
most recent measurement interval duration between successive
metrics reports.</t>
<t>I=11: Cumulative Duration - the reported value applies to
the accumulation period characteristic of cumulative
measurements.</t>
</list>In this document, de-jitter buffer Metrics can only be
sampled , and cannot be measured over definite intervals. Also,
the value I=00 is reserved for future use. Senders MUST NOT use
the values I=00 or I=10 or I=11. If a block is received with I=00
or I=10 or I=11, the receiver MUST discard the block.<vspace
blankLines="1" /></t>
<t hangText="Jitter Buffer Configuration (C): 1 bit"><vspace
blankLines="1" /> This field is used to identify the de-jitter
buffer method in use at the receiver, according to the following
code:<list>
<t>0 = Fixed de-jitter buffer</t>
<t>1 = Adaptive de-jitter buffer</t>
</list><vspace blankLines="1" /></t>
<t hangText="Reserved (Rsvd.): 5 bits"><vspace
blankLines="1" />These bits are reserved. They MUST be set to zero
by senders ignored by receivers (See <xref
target="RFC6709"></xref> section 4.2). <vspace
blankLines="1" /></t>
<t hangText="Block Length: 16 bits"><vspace blankLines="1" />The
length of this report block in 32-bit words, minus one, in
accordance with the definition in <xref target="RFC3611"></xref>.
This field MUST be set to 3 to match the fixed length of the
report block. <vspace blankLines="1" /></t>
<t
hangText="de-jitter buffer nominal delay (DJB nominal): 16 bits"><vspace
blankLines="1" />This is the current nominal de-jitter buffer
delay in milliseconds, which corresponds to the nominal de-jitter
buffer delay for packets that arrive exactly on time. It is
calculated based on the time spent in the de-jitter buffer for the
packet that arrives exactly on time. This parameter MUST be
provided for both fixed and adaptive de-jitter buffer
implementations. <vspace blankLines="1" />The measured value is
unsigned value. If the measured value exceeds 0xFFFD, the value
0xFFFE MUST be reported to indicate an over-range measurement. If
the measurement is unavailable, the value 0xFFFF MUST be
reported.<vspace blankLines="1" /></t>
<t
hangText="de-jitter buffer maximum delay (DJB maximum): 16 bits"><vspace
blankLines="1" />This is the current maximum de-jitter buffer
delay in milliseconds which corresponds to the earliest arriving
packet that would not be discarded. It is calculated based on the
time spent in the de-jitter buffer for the earliest arriving
packet In simple queue implementations this may correspond to the
size of the de-jitter buffer. In adaptive de-jitter buffer
implementations, this value may vary dynamically. This parameter
MUST be provided for both fixed and adaptive de-jitter buffer
implementations. <vspace blankLines="1" />The measured value is
unsigned value. If the measured value exceeds 0xFFFD, the value
0xFFFE MUST be reported to indicate an over-range measurement. If
the measurement is unavailable, the value 0xFFFF MUST be
reported.<vspace blankLines="1" /></t>
<t
hangText="de-jitter buffer high water mark (DJB high water mark): 16 bits"><vspace
blankLines="1" />This is the highest value of the de-jitter buffer
nominal delay in milliseconds which occurred at any time during
the reporting interval. This parameter MUST be provided for
adaptive de-jitter buffer implementations and its value MUST be
set to JB maximum for fixed de-jitter buffer implementations.
<vspace blankLines="1" />The measured value is unsigned value. If
the measured value exceeds 0xFFFD, the value 0xFFFE MUST be
reported to indicate an over-range measurement. If the measurement
is unavailable, the value 0xFFFF MUST be reported.<vspace
blankLines="1" /></t>
<t
hangText="de-jitter buffer low water mark (DJB low water mark): 16 bits"><vspace
blankLines="1" />This is the lowest value of the de-jitter buffer
nominal delay in milliseconds which occurred at any time during
the reporting interval. This parameter MUST be provided for
adaptive de-jitter buffer implementations and its value MUST be
set to JB maximum for fixed de-jitter buffer implementations.
<vspace blankLines="1" />The measured value is unsigned value. If
the measured value exceeds 0xFFFD, the value 0xFFFE MUST be
reported to indicate an over-range measurement. If the measurement
is unavailable, the value 0xFFFF MUST be reported.<vspace
blankLines="1" /></t>
</list></t>
</section>
</section>
<section title="SDP Signaling">
<t>[RFC3611] defines the use of SDP (Session Description Protocol) <xref
target="RFC4566"></xref> for signaling the use of XR blocks. However XR
blocks MAY be used without prior signaling (see section 5 of
RFC3611).</t>
<section title="SDP rtcp-xr-attrib Attribute Extension">
<t>This section augments the SDP <xref target="RFC4566"></xref>
attribute "rtcp-xr" defined in <xref target="RFC3611"></xref> by
providing an additional value of "xr-format" to signal the use of the
report block defined in this document.<figure>
<artwork>
xr-format =/ xr-djb-block
xr-djb-block = "de-jitter-buffer"
</artwork>
</figure></t>
</section>
<section title="Offer/Answer Usage">
<t>When SDP is used in offer-answer context <xref
target="RFC3264"></xref>, the SDP Offer/Answer usage defined in <xref
target="RFC3611"></xref> for unilateral "rtcp-xr" attribute parameters
applies. For detailed usage of Offer/Answer for unilateral parameter,
refer to section 5.2 of <xref target="RFC3611"></xref>.</t>
</section>
</section>
<section title="IANA Considerations">
<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"></xref>.</t>
<section title="New RTCP XR Block Type value">
<t>This document assigns the block type value DJB in the IANA "RTP
Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
the "De-Jitter Buffer Metrics Block".</t>
<t>[Note to RFC Editor: please replace DJB with the IANA provided RTCP
XR block type for this block.]</t>
</section>
<section title="New RTCP XR SDP Parameter">
<t>This document also registers a new parameter "de-jitter-buffer" in
the "RTP Control Protocol Extended Reports (RTCP XR) Session
Description Protocol (SDP) Parameters Registry".</t>
</section>
<section title="Contact information for registrations">
<t>The contact information for the registrations is:<figure>
<artwork>
Qin Wu (sunseawq@huawei.com)
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
</artwork>
</figure><vspace blankLines="1" /></t>
</section>
</section>
<section title="Security Considerations">
<t>It is believed that this proposed RTCP XR report block introduces no
new security considerations beyond those described in <xref
target="RFC3611"></xref>. This block does not provide per-packet
statistics so the risk to confidentiality documented in Section 7,
paragraph 3 of <xref target="RFC3611"></xref> does not apply.</t>
</section>
<section title="Contributors">
<t>Geoff Hunt wrote the initial draft of this document.</t>
</section>
<section title="Acknowledgments">
<t>The authors gratefully acknowledge reviews and feedback provided by
Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor, Claus
Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi, Tom Hock,
Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, Mohamed Mostafa,
Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Albrecht
Schwarz, Tom Taylor, Hideaki Yamada,Claire Bi,Colin Perkin, Dan
Romascanu, Kevin Gross ,Glen Zorn, Spencer Dawkins and Benoit
Claise.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<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 RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3611">
<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<author fullname="T. Friedman" initials="T." surname="Friedman">
<organization></organization>
</author>
<author fullname="R. Caceres" initials="R." surname="Caceres">
<organization></organization>
</author>
<author fullname="A. Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<date month="November" year="2003" />
<abstract>
<t>This document defines the Extended Report (XR) packet type for
the RTP Control Protocol (RTCP), and defines how the use of XR
packets can be signaled by an application if it employs the
Session Description Protocol (SDP). XR packets are composed of
report blocks, and seven block types are defined here. The purpose
of the extended reporting format is to convey information that
supplements the six statistics that are contained in the report
blocks used by RTCP's Sender Report (SR) and Receiver Report (RR)
packets. Some applications, such as multicast inference of network
characteristics (MINC) or voice over IP (VoIP) monitoring, require
other and more detailed statistics. In addition to the block types
defined here, additional block types may be defined in the future
by adhering to the framework that this document provides.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization></organization>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<date month="July" year="2006" />
<abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP
is intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of
multimedia session initiation. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization>Columbia University</organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="RFC" value="3550" />
<format type="TXT" />
</reference>
<reference anchor="RFC6776">
<front>
<title>Measurement Identity and information Reporting using SDES
item and XR Block</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization></organization>
</author>
<date month="August" year="2012" />
</front>
<seriesInfo name="RFC" value="6776" />
<format type="TXT" />
</reference>
<reference anchor="RFC3264">
<front>
<title>An Offer/Answer Model with the Session Description Protocol
(SDP)</title>
<author fullname="J.Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H.Schulzrinne" initials="H." surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2002" />
</front>
<seriesInfo name="RFC" value="3264" />
<format type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC6792">
<front>
<title>Monitoring Architectures for RTP</title>
<author fullname="Geoff Hunt" initials="G." surname="Hunt">
<organization></organization>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization></organization>
</author>
<author fullname="Philip Arden" initials="P." surname="Arden">
<organization></organization>
</author>
<date month="November" year="2012" />
</front>
<seriesInfo name="RFC" value="6792" />
<format type="TXT" />
</reference>
<reference anchor="RFC6390">
<front>
<title>Framework for Performance Metric Development</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<author fullname="Benoit Claise " initials="B." surname="Claise">
<organization></organization>
</author>
<date month="October" year="2011" />
</front>
<seriesInfo name="RFC" value="6390" />
</reference>
<reference anchor="RFC6709">
<front>
<title>Design Considerations for Protocol Extensions</title>
<author fullname="B.Carpenter" initials="B." surname="Carpenter">
<organization></organization>
</author>
<author fullname="B.Aboba" initials="B." surname="Aboba">
<organization></organization>
</author>
<author fullname="S.Cheshire" initials="S." surname="Cheshire">
<organization></organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="RFC" value="6709" />
<format type="TXT" />
</reference>
<reference anchor="RFC5481">
<front>
<title>Packet Delay Variation Applicability Statement</title>
<author fullname="A.,Morton" initials="A." surname="Morton">
<organization></organization>
</author>
<author fullname="B.,Claise" initials="B." surname="Claise">
<organization></organization>
</author>
<date month="March" year="2009" />
</front>
<seriesInfo name="RFC" value="5481" />
</reference>
<reference anchor="QMB">
<front>
<title>RTP Control Protocol (RTCP) Extended Report (XR) Blocks for
QoE Metric Reporting</title>
<author fullname="A.Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<date month="May" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-xrblock-rtcp-xr-qoe-08" />
</reference>
</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>de-jitter buffer nominal delay Metric<vspace
blankLines="1" /><list style="symbols">
<t>Metric Name: de-jitter buffer nominal delay in RTP<vspace
blankLines="1" /></t>
<t>Metric Description: The "expected arrival time" is the time
that a RTP packet would arrive if there was no delay variation.
The delay applied to packets that arrive at their expected time
is known as the Nominal Delay. <vspace blankLines="1" /></t>
<t>Method of Measurement or Calculation: See section 4.2,
de-jitter buffer nominal delay definition [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Units of Measurement: See section 4.2, de-jitter buffer
nominal delay definition [RFCXXXX].<vspace blankLines="1" /></t>
<t>Measurement Point(s) with Potential Measurement Domain: See
section 4, 1st paragraph [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Measurement Timing: See section 4, 1st paragraph [RFCXXXX]
for measurement timing and section 4.2 paragraph [RFCXXXX] for
Interval Metric flag. <vspace blankLines="1" /></t>
<t>Use and applications: See section 1.4 [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Reporting model: See RFC3611.<vspace blankLines="1" /></t>
</list></t>
<t>de-jitter buffer maximum delay Metric<vspace
blankLines="1" /><list style="symbols">
<t>Metric Name: de-jitter buffer maximum delay in RTP<vspace
blankLines="1" /></t>
<t>Metric Description: It is the current maximum de-jitter
buffer delay for RTP traffic which corresponds to the earliest
arriving packet that would not be discarded. <vspace
blankLines="1" /></t>
<t>Method of Measurement or Calculation: See section 4.2,
de-jitter buffer maximum delay definition and section 3, the
last paragraph [RFCXXXX].<vspace blankLines="1" /></t>
<t>Units of Measurement: See section 4.2, de-jitter buffer
maximum delay definition [RFCXXXX].<vspace blankLines="1" /></t>
<t>Measurement Point(s) with Potential Measurement Domain: See
section 4, 1st paragraph [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Measurement Timing: See section 4, 1st paragraph [RFCXXXX]
for measurement timing and section 4.2 paragraph [RFCXXXX] for
Interval Metric flag. <vspace blankLines="1" /></t>
<t>Use and applications: See section 1.4 [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Reporting model: See RFC3611.<vspace blankLines="1" /></t>
</list></t>
<t>de-jitter buffer high water mark Metric<vspace
blankLines="1" /><list style="symbols">
<t>Metric Name: de-jitter buffer high water mark in RTP<vspace
blankLines="1" /></t>
<t>Metric Description: It is the highest value of the de-jitter
buffer nominal delay for RTP traffic which occurred at any time
during the reporting interval. <vspace blankLines="1" /></t>
<t>Method of Measurement or Calculation: See section 4.2,
de-jitter buffer high water mark definition [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Units of Measurement: See section 4.2, de-jitter buffer
nominal delay definition [RFCXXXX].<vspace blankLines="1" /></t>
<t>Measurement Point(s) with Potential Measurement Domain: See
section 4, 1st paragraph [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Measurement Timing: See section 4, 1st paragraph [RFCXXXX]
for measurement timing and section 4.2 paragraph [RFCXXXX] for
Interval Metric flag. <vspace blankLines="1" /></t>
<t>Use and applications: See section 1.4 [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Reporting model: See RFC3611.<vspace blankLines="1" /></t>
</list></t>
<t>de-jitter buffer low water mark Metric<vspace
blankLines="1" /><list style="symbols">
<t>Metric Name: de-jitter buffer low water mark in RTP<vspace
blankLines="1" /></t>
<t>Metric Description: It is the lowest value of the de-jitter
buffer nominal delay for RTP traffic which occurred at any time
during the reporting interval. <vspace blankLines="1" /></t>
<t>Method of Measurement or Calculation: See section 4.2,
de-jitter buffer low water mark definition [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Units of Measurement: See section 4.2, de-jitter buffer low
water mark definition [RFCXXXX].<vspace blankLines="1" /></t>
<t>Measurement Point(s) with Potential Measurement Domain: See
section 4, 1st paragraph [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Measurement Timing: See section 4, 1st paragraph [RFCXXXX]
for measurement timing and section 4.2 paragraph [RFCXXXX] for
Interval Metric flag. <vspace blankLines="1" /></t>
<t>Use and applications: See section 1.4 [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Reporting model: See RFC3611.<vspace blankLines="1" /></t>
</list></t>
</list></t>
</section>
<section title="Change Log">
<t>Note to the RFC-Editor: please remove this section prior to
publication as an RFC.</t>
<section title="draft-ietf-xrblock-rtcp-xr-jb-12">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Editorial changes based on recieved comments.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-jb-11">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Comments in WGLC and from PM-DIR review are addressed in this
version.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-jb-10">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Add some text to section 3.2 to clarify how fixed de-jitter
buffer is used.</t>
<t>Other Editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-jb-09">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Incorporate proposed changes by Kevin and proposed text by Alan
to address interoperability report issue.</t>
<t>Add new appendix to format metrics using RFC6390 template.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-jb-08">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Rewrote descriptive text and definitions for clarification.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-jb-07">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Add one new section to discuss de-jitter buffer operation.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-jb-05">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Some editorial change changes based on the discussion with Glen
and Kevin on the list.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-jb-03">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Reduce the "jb cfg" to 1-bit based on discussion in the
WGLC.</t>
<t>Other editorial change changes aligning with PDV,Delay
draft.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-jb-02">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Add some explanation text in the SDP offer/answer section.</t>
<t>Add some text in applicability section to explain the use to
report de-jitter buffer metrics.</t>
<t>Other editorial change changes aligning with PDV,Delay
draft.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-jb-01">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Outdated reference update</t>
<t>Add one Editor notes to ask clarification on the use of
reporting de-jitter buffer metrics.</t>
<t>Other Editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-jb-00">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Boilerplate updates.</t>
<t>references updates</t>
<t>allocate 32 bit field in report block for SSRC</t>
<t>Other editorial changes to get alignment with MONARCH
draft.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 11:23:35 |