One document matched: draft-huang-xrblock-rtcweb-rtcp-xr-metrics-04.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 rfc4588 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4588.xml">
<!ENTITY rfc5725 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5725.xml">
<!ENTITY rfc6776 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6776.xml">
<!ENTITY rfc6798 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6798.xml">
<!ENTITY rfc6958 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6958.xml">
<!ENTITY rfc7002 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7002.xml">
<!ENTITY rfc7003 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7003.xml">
<!ENTITY rfc7004 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7004.xml">
<!ENTITY rfc7005 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7005.xml">
<!ENTITY rfc7097 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7097.xml">
<!ENTITY rfc7243 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7243.xml">
<!ENTITY I-D.ietf-rtcweb-use-cases-and-requirements PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-use-cases-and-requirements.xml">
<!ENTITY I-D.ietf-rtcweb-rtp-usage PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-rtp-usage.xml">
<!ENTITY I-D.alvestrand-rtcweb-stats-registry PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.alvestrand-rtcweb-stats-registry.xml">
<!ENTITY I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count PUBLIC ""
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count.xml">
<!ENTITY I-D.ietf-rtcweb-security PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-security.xml">
<!ENTITY W3C.WD-webrtc-20130910 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml-w3c/reference.W3C.WD-webrtc-20130910.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-huang-xrblock-rtcweb-rtcp-xr-metrics-04"
category="std">
<!-- What is the category field value-->
<front>
<title abbrev="RTCP XR Metrics for RTCWEB">
Considerations for Selecting RTCP Extended Report (XR) Metrics for the RTCWEB Statistics API
</title>
<author initials="R." surname="Huang" fullname="Rachel Huang">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city> <region>CN</region><code>210012</code>
<country>China</country>
</postal>
<email>rachel.huang@huawei.com</email>
</address>
</author>
<author initials="R." surname="Even" fullname="Roni Even">
<organization>Huawei</organization>
<address>
<postal>
<street>14 David Hamelech</street>
<city>Tel Aviv</city> <region></region><code>64953</code>
<country>Israel</country>
</postal>
<email>roni.even@mail01.huawei.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>
<uri>http://www.netlab.tkk.fi/~varun/</uri>
</address>
</author>
<author initials="D." surname="Romascanu" fullname="Dan Romascanu">
<organization>Avaya</organization>
<address>
<postal>
<street>Park Atidim, Bldg. #3</street>
<city>Tel Aviv</city> <region></region><code>61581</code>
<country>Israel</country>
</postal>
<email>dromasca@avaya.com</email>
</address>
</author>
<author initials="L." surname="Deng" fullname="Lingli Deng">
<organization>China Mobile</organization>
<address>
<email>denglingli@chinamobile.com</email>
</address>
</author>
<date />
<area>RAI</area>
<workgroup>XR Block Working Group</workgroup>
<keyword>WebRTC</keyword>
<keyword>RTCP</keyword>
<keyword>statistics</keyword>
<abstract>
<t>
This document describes monitoring features related to RTCWEB.
It provides a list of RTCP XR metrics, which are useful and may
need to be supported in some RTCWEB implementations.
It also describes a list of additional identifiers for
WebRTC's statistics API. These identifiers are a set of RTCP
XR metrics related to the transport of multimedia flows.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Web-based real-time communication (WebRTC) deployments are emerging and
applications need to be able to estimate the service quality. If
sufficient information (metrics or statistics) are provided to the
applications, it can attempt to improve the media quality. <xref
target="I-D.ietf-rtcweb-use-cases-and-requirements" /> specifies a
requirement for statistics:
</t>
<figure align="left" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
F38 The browser must be able to collect statistics, related to the
transport of audio and video between peers, needed to estimate
quality of experience.
]]></artwork></figure>
<t>
The <xref target="I-D.alvestrand-rtcweb-stats-registry" />
describes a registration procedure for metrics reported by the
WebRTC <xref target="W3C.WD-webrtc-20130910">Stats API</xref>.
It currently lists basic metrics reported in the <xref target="RFC3550">
RTCP Sender and Receiver Report (SR/RR)</xref> to fulfill this requirement.
However, the basic metrics from RTCP SR/RR are not sufficient for precise
quality monitoring, or diagnosing potential issues. </t>
<t>
In this document, we provide some guidelines on choosing additional
RTP metrics for the <xref target="W3C.WD-webrtc-20130910" >WebRTC Stats API</xref>.
Furthermore, we expose additional RTCP XR metrics to complement the identifiers
that already exist in the
<xref target="I-D.alvestrand-rtcweb-stats-registry" >statistics registry</xref>.
</t>
</section>
<section anchor="terms" title="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 <xref target="RFC2119" />.
</t>
</section>
<section anchor="rtp-stats" title="RTP Statistics in WebRTC Implementations">
<!--
The statistics are generated by the browser's WebRTC implementation for
each of the local (sent) and remote (received) media streams, and exposed
to the WebRTC application via the <xref target="W3C.WD-webrtc-20130910">Stats
API</xref>. The RTP-related statistics can be divided into 3 categories:
stream level, session level, and other aspects. -->
<t>
Currently, the <xref target="I-D.alvestrand-rtcweb-stats-registry">statistics
registry</xref> exposes the basic RTCP SR and RR metrics for the local and
remote media streams. The exposed identifiers are: SentPacketCount, SentOctetCount,
packetsLost, Jitter, ReceivedPacketCount, ReceivedOctetCount. However, these
metrics provides only partial or limited information, which may not be sufficient
for diagnosing problems or quality monitoring. For example, it may be useful to
distinguish between packets lost and packets discarded due to late arrival,
even though they have the same impact on the multimedia quality, it helps
in diagnosing and identifying issues.
</t>
<t>
<xref target="RFC3611">RTP Control Protocol Extended Reports</xref> and other
extensions discussed in the XRBLOCK working group provide more detailed
statistics, which complement the basic metrics reported in the RTCP Sender
and Receiver Reports. Section <xref target="cand-metrics" /> discusses the
use of XR metrics that may be useful for monitoring the performance of WebRTC
applications.
</t>
<!-- However, it should be noted that the use of RTCP XRs is currently
not mandated in RTCWEB <xref target="I-D.ietf-rtcweb-rtp-usage" />, but if
successfully negotiated between endpoints (via SDP), thereafter
the application has access to both local and remote statistics.
we consider
only those XR metrics that can be measured at a local endpoint and useful for a
range of WebRTC implementations. -->
<!-- TODO: VS -->
<t>
The WebRTC application extracts the statistic from the browser by querying
the <xref target="W3C.WD-webrtc-20130910">Stats API</xref>, but the browser
currently only reports the local variables i.e., the statistics related
to the outgoing RTP media streams and the incoming RTP media streams.
Without the support of RTCP XRs or some other signaling mechianism, the WebRTC
application cannot expose the remote endpoints' statistics.
At the moment <xref target="I-D.ietf-rtcweb-rtp-usage" /> does not mandate
the use of any RTCP XRs and since their usage is optional. If the use of
RTCP XRs is successfully negotiated between endpoints (via SDP), thereafter
the application has access to both local and remote statistics.
Alternatively, once the WebRTC application gets the local information,
they can report it to an application server or a third-party monitoring
system, which provides quality estimations or diagnosis services for application
developers. The exchange of statistics between endpoints or between
a monitoring server and an endpoint is outside the scope of this document.
</t>
<!--
<t>
Statistics can be extracted by the application from the local browser by JavaScript applications using an API. Once the JavaScript application gets this information, they can report it to application servers or 3rd party monitoring systems, which provide quality estimations or diagnosis services for application developers. The endpoint may use some standard protocol e.g., RTCP XR, or a private protocol to send the metrics to a measurement server. But this part is outside the scope of this memo, also outside the scope of RTCWEB, and will not be discussed in more detail.
</t>
-->
</section>
<section anchor="mm-int" title="Considerations for Impact of Measurement Interval">
<t>
RTCP extensions like RTCP XR usually share the same timing interval with
the RTCP SR/RR, i.e., they are sent as compound packets, together with
the RTCP SR/RR. Alternatively, if the RTCP XR uses a different measurement
interval, all XRs using the same measurement interval are compounded together
and the measurement interval is indicated in a specific measurement information
block defined in <xref target="RFC6776" />.
</t>
<t>
When using WebRTC Statistics APIs (see section 7 of
<xref target="W3C.WD-webrtc-20130910" />), the applications can query
this information at arbitrary intervals. For the statistics reported
by the remote endpoint, e.g., those conveyed in an RTCP SR/RR/XR, these
will not change until the next RTCP report is received. Some applications
may choose 1 second or a different polling interval, but the statistics
from the remote endpoint may not change when using intervals shorter than
the average RTCP reporting interval. However, statistics generated
by the local endpoint have no such restrictions as long as the endpoint
is sending and receiving media.
</t>
</section>
<!-- Guidelines -->
<section anchor="cand-metrics" title="Candidate Metrics">
<t>
Since following metrics are all defined in RTCP XR which is not mandated in WebRTC, all of them are local. However, if RTCP XR is supported by negotiation between two browsers, following metrics can also be generated remotely and be sent to local by RTCP XR packets.
</t>
<t>
Following metrics are classified into 3 categories: network impact metrics, application impact metrics and recovery metrics. Network impact metrics are the statistics recording the information only for network transmission. They are useful for network problem diagnosis. Application impact metrics mainly collect the information in the viewpoint of application, e.g., bitrate, frames rate or jitter buffers. Recovery metrics reflect how well the repair mechanisms, e.g. loss concealment, retransmission or FEC, perform. All of the 3 types of metrics are useful for quality estimations of services in WebRTC implementations. WebRTC application can use these metrics to better calculate MoS values or Media Delivery Index (MDI) for their services.
</t>
<section anchor="net-imp-met" title="Network Impact Metrics">
<t> </t>
<section anchor="loss-disc-cnt" title="Loss and Discard Packet Count Metric">
<t>
In multimedia transport, packets which are received abnormally
are classified into 3 types: lost, discarded and duplicate packets.
Packet loss may be caused by network device breakdown, bit-error
corruption or network congestion (packets dropped by an intermediate
router queue). Duplicate packets may be a result of network
delays, which causes the sender to retransmit the original packets.
Discarded packets are packets that have been delayed long enough
(perhaps they missed the playout time) and are considered useless
by the receiver. Lost and discarded packets cause problems for multimedia
services, as missing data and long delays can cause degradation in
service quality, e.g., missing large blocks of contiguous packets
(lost or discarded) may cause choppy audio, and long network
transmission delay time may cause audio or video buffering. The
RTCP SR/RR defines a metric for counting the total number of
RTP data packets that have been lost since the beginning of reception.
But this statistic does not distinguish lost packets from discarded
and duplicate packets. Packets that arrive late will be discarded and
are not reported as lost, and duplicate packets will be regarded as a
normally received packet. Hence, the loss metric can be misleading if
many duplicate packets are received or packets are discarded, which
causes the quality of the media transport to appear okay from the
statistic point of view, but meanwhile the users may actually be
experiencing bad service quality. So in such cases, it is better to
use more accurate metrics in addition to those defined in RTCP SR/RR.
</t>
<t>
The lost packets and duplicated packets metrics defined in Statistics Summary Report Block of <xref target="RFC3611" /> extend the information of loss carried in standard RTCP SR/RR. They explicitly give an account of lost and duplicated packets. Lost packets counts are useful for network problem diagnosis. It is better to use the loss packets metrics of <xref target="RFC3611" /> to indicate the packet lost count instead of the cumulative number of packets lost metric of <xref target="RFC3550" />. Duplicated packets are usually rare and have little effect on QoS evaluation. So it may not be suitable for use in WebRTC.
</t>
<t>
Using loss metrics without considering discard metrics may result in inaccurate quality evaluation, as packet discard due to jitter is often more prevalent than packet loss in modern IP networks. The discarded metric specified in <xref target="RFC7002" /> counts the number of packets discarded due to the jitter. It augments the loss statistics metrics specified in standard RTCP SR/RR. For those RTCWEB services with jitter buffer requiring precise quality evaluation and accurate troubleshooting, this metric is useful as a complement to the metrics of RTCP SR/RR.
</t>
</section>
<section anchor="bg-loss-disc" title="Burst/Gap Pattern Metrics for Loss and Discard">
<t>
RTCP SR/RR defines coarse metrics regarding loss statistics, the metrics are all about per call statistics and are not detailed enough to capture some transitory nature of the impairments like bursty packet loss. Even if the average packet loss rate is low, the lost packets may occur during short dense periods, resulting in short periods of degraded quality. Distributed burst provides a higher subjective quality than a non-burst distribution for low packet loss rates whereas for high packet loss rates the converse is true. So capturing burst gap information is very helpful for quality evaluation and locating impairments. If the WebRTC application needs to evaluate the services quality, burst gap metrics provides more accurate information than RTCP SR/RR.
</t>
<t>
<xref target="RFC3611" /> introduces burst gap metrics in VoIP report block. These metrics record the density and duration of burst and gap periods, which are helpful in isolating network problems since bursts correspond to periods of time during which the packet loss/discard rate is high enough to produce noticeable degradation in audio or video quality. Burst gap related metrics are also introduced in <xref target="RFC7003" /> and <xref target="RFC6958" /> which define two new report blocks for usage in a range of RTP applications beyond those described in <xref target="RFC3611" />. These metrics distinguish discarded packets from loss packets that occur in the bursts period and provides more information for diagnosing network problems. Additionally, the block reports the frequency of burst events which is useful information for evaluating the quality of experience. Hence, if WebRTC application need to do quality evaluation and observe when and why quality degrades, these metrics should be considered.
</t>
</section>
<section anchor="rle-loss-disc" title="Run Length Encoded Metrics for Loss, Discard">
<t>
Run-length encoding uses a bit vector to encode information about the packet. Each bit in the vector represents a packet and depending on the signaled metric it defines if the packet was lost, duplicated, discarded, or repaired. An endpoint typically uses the run length encoding to accurately communicate the status of each packet in the interval to the other endpoint. <xref target="RFC3611" />, <xref target="RFC7097" /> define run-length encoding for lost and duplicate packets, and discarded packets, respectively.
</t>
<t>
The WebRTC application could benefit from the additional information. If losses occur after discards, an endpoint may be able to correlate the two run length vectors to identify congestion-related losses, i.e., a router queue became overloaded causing delays and then overflowed. If the losses are independent, it may indicate bit-error corruption. For the WebRTC StatsAPI, these types of metrics are not recommended for use due to the large amount of data and the computation involved.
<!-- Whereas, for local case, it's fine to have them. -->
</t>
</section>
<!-- <section anchor="" title="ECN related Metrics">
<t>
ECN can be used to minimize the impact of congestion on real-time multimedia traffic. The use of ECN provides a way for the network to send congestion control signals to the media transport without having to impair the media. Unlike packet loss, ECN signals unambiguously indicate congestion to the transport as quickly as feedback delays allow and without confusing congestion with losses that might have occurred for other reasons such as transmission errors.
ECN related metrics, such as ECN-CE Counter found in [RFC6679], could be used to show the cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that were ECN-CE marked, including ECN-CE marks in any duplicate packets. It is useful for detecting network congestion status before the actual packet loss occurs. Media senders can control how they reduce their transmission rate and hence media quality, rather than responding to and trying to conceal the effects of unpredictable packet loss.
It is hence recommended that ECN related metrics (either ECN Feedback Report and ECN Summary Report) be considered for RTCWEB applications in ECN-enabled networks. The definition of these metrics could be found in [RFC6679].
</t>
</section> -->
</section>
<section anchor="app-met" title="Application Impact Metrics">
<t> </t>
<section anchor="disc-oct" title="Discard Octets Metric">
<t>
The metric reports the cumulative size of the packets discarded in the interval, it is complementary to number of discarded packets. An application measures sent octets and received octets to calculate sending rate and receiving rate, respectively. The application can calculate the actual bitrate in a particular interval by subtracting the discarded octets from the received octets.
</t>
<t>
For WebRTC, discarded octets supplements the sent and received octets and provides an accurate method for calculating the actual bitrate which is an important parameter to reflect the quality of the media. The discarded bytes metric is defined in <xref target="RFC7243" />.
</t>
</section>
<section anchor="fr-imp" title="Frame Impairment Summary Metrics">
<t>
RTP has different framing mechanisms for different payload types. For audio streams, a single RTP packet may contain one or multiple audio frames, each of which has a fixed length. On the other hand, in video streams, a single video frame may be transmitted in multiple RTP packets. The size of each packet is limited by the Maximum Transmission Unit (MTU) of the underlying network. However, statistics from standard SR/RR only collect information from transport layer, which may not fully reflect the quality observed by the application. Video is typically encoded using two frame types i.e., key frames and derived frames. Key frames are normally just spatially compressed, i.e., without prediction from other pictures. The derived frames are temporally compressed, i.e., depend on the key frame for decoding. Hence, Key frames are much larger in size than derived frames. The loss of these key frames results in a substantial reduction in video quality. Thus it is reasonable to consider this application layer information in WebRTC implementations, which influence sender strategies to mitigate the problem or require the accurate assessment of users' quality of experience.
</t>
<t>
The following metrics can also be considered for WebRTC's Statistics API: number of discarded key frames, number of lost key frames, number of discarded derived frames, number of lost derived frames. These metrics can be used to calculate Media Loss Rate (MLR) of MDI. Details of the definition of these metrics are described in <xref target="RFC7003" />. Additionally, the metric provides the rendered frame rate, an important parameter for quality estimation.
</t>
</section>
<section anchor="jb" title="Jitter Buffer Metrics">
<t>
The size of the jitter buffer affects the end-to-end delay on the network and also the packet discard rate. When the buffer size is too small, slower packets are not played out and dropped, while when the buffer size is too large, packets are held longer than necessary and consequently reduce conversational quality. Measurement of jitter buffer should not be ignored in the evaluation of end user perception of conversational quality. Jitter buffer related metrics, such as maximum and nominal jitter buffer, could be used to show how the jitter buffer behaves at the receiving endpoint. They are useful for providing better end-user quality of experience (QoE) when jitter buffer factors are used as inputs to calculate MoS values. Thus for those cases, jitter buffer metrics should be considered. The definition of these metrics is provided in <xref target="RFC7005" />.
</t>
</section>
</section>
<section anchor="rec-met" title="Recovery metrics">
<t>[Editor's Note: Concealment Metrics are currently not considered.]</t>
<section anchor="pr-cnt" title="Post-repair Packet Count Metrics">
<t>
Error-resilience mechanisms, like RTP retransmission or FEC, are optional in RTCWEB because the overhead of the repair bits adding to the original streams. But they do help to greatly reduce the impact of packet loss and enhance the quality of transmission. Web applications could support certain repair mechanism after negotiation between both sides of browsers when needed. For these web applications using repair mechanisms, providing some statistic information for the performance of their repair mechanisms could help to have a more accurate quality evaluation.
</t>
<t>
The un-repaired packets count and repaired loss count defined in <xref target="I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count" /> provide the recovery information of the error-resilience mechanisms to the monitoring application or the sending endpoint. The endpoint can use these metrics to ascertain the ratio of repaired packets to lost packets. Including this kind of metrics helps the application evaluate the effectiveness of the applied repair mechanisms.
</t>
</section>
<section anchor="rle-prl" title="Run Length Encoded Metric for Post-repair">
<t>
<xref target="RFC5725" /> defines run-length encoding for post-repair packets. When using error-resilience mechanisms, the endpoint can correlate the loss run length with this metric to ascertain where the losses and repairs occurred in the interval. This provides more accurate information for recovery mechanisms evaluation than those in Section 5.3.1. However, it is not suggested to use due to their enormous amount of data when RTCP XR are supported.
</t>
<t>
For WebRTC, the application may benefit from the additional information. If losses occur after discards, an endpoint may be able to correlate the two run length vectors to identify congestion-related losses, i.e., a router queue became overloaded causing delays and then overflowed. If the losses are independent, it may indicate bit-error corruption. Lastly, when using error-resilience mechanisms, the endpoint can correlate the loss and post-repair run lengths to ascertain where the losses and repairs occurred in the interval. For example, consecutive losses are likely not to be repaired by a simple FEC scheme.
</t>
</section>
</section>
<!-- end of ection -->
</section>
<section anchor="add-stats" title="Candidate XR Block Metrics for WebRTC Statistics API">
<t>
This document describes a list of additional identifiers to complement
the identifiers in Section 4.1 of <xref
target="I-D.alvestrand-rtcweb-stats-registry" /> and these group of
identifiers are defined on a ReportGroup corresponding to an SSRC.
In practice the application MUST be able to query the statistic
identifiers on both an incoming (remote) and outgoing (local) media
stream. Depending on the support of the corresponding XR report the
endpoint MAY be able to query the reception statistics for its
outgoing (local) media stream.
</t>
<t>The following contact information is used for all registrations in
this document:
<figure>
<artwork><![CDATA[
Contact: Varun Singh
mailto:varun.singh@iki.fi
tel:+358-9-470-24785
]]></artwork>
</figure></t>
<section title="Variables from XR Blocks">
<t></t>
<!-- -
<section title="Cumulative Number of Packets Lost">
<t>Name: LostPacketCount</t>
<t>Definition: section 6.4.1 in <xref target="RFC3550" /></t>
</section>
-->
<section title="Packets and Octets Discarded">
<!-- ######## -->
<t>Name: PacketsDiscarded</t>
<t>Definition: Cumulative Number of RTP packets discarded due
to late or early-arrival, Appendix A (a) of <xref target="RFC7002" />.</t>
<!-- ######## -->
<t>Name: OctetsDiscarded</t>
<t>Definition: Cumulative Number of octets discarded due to late or
early-arrival, Appendix A of
<xref target="RFC7243" /></t>
</section>
<!-- VS: Missing ref to retx packet count RFC4588? -->
<!-- <section title="Cumulative Number of Retransmitted Packets">
<t>Name: PacketsRetxReceived</t>
<t>Definition: See Appendix A of this document, [RFCXXXX].</t>
<t> RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC
number, when assigned and remove this note.</t>
<t>Name: PacketsRetxSent</t>
<t>Definition: See Appendix B of this document, [RFCXXXX].</t>
<t> RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC
number, when assigned and remove this note.</t>
</section> -->
<section title="Cumulative Number of Packets Repaired">
<!-- ######## -->
<t>Name: PacketsRepaired</t>
<t>Definition: The cumulative number of lost RTP packets repaired
after applying a error-resilience mechanism, Appendix A (b) of <xref
target="I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count" />. To clarify,
the value is upper bound to the cumulative number of lost packets.</t>
</section>
<section title="Burst Packet Loss or Discarded">
<!-- ######## -->
<t>Name: BurstPacketDiscarded</t>
<t>Definition: The total number of RTP packets discarded during discard
bursts, Appendix A (b) of <xref target="RFC7003" />.</t>
<!-- ######## -->
<t>Name: BurstPacketLost</t>
<t>Definition: The total number of RTP packets lost during loss bursts,
Appendix A (c) of <xref target="RFC6958" />.</t>
<t>Name: BurstCount</t>
<t>Definition: The cumulative number of bursts of lost RTP
packets, Appendix A (e) of <xref target="RFC6958" />.</t>
<t><xref target="RFC3611" /> recommends a Gmin value of 16.</t>
</section>
<section title="Frame Impairment Metrics">
<!-- ######## -->
<t>Name: FullFramesLostCount</t>
<t>Definition: Number of full frames lost, Appendix A (i) of <xref
target="RFC7004" /></t>
<!-- VS: Partial frames lost? -->
<!-- ######## -->
<t>Name: PartialFramesLostCount</t>
<t>Definition: Number of frames partially lost, Appendix A (j) of
<xref target="RFC7004" /></t>
<!-- ######## -->
<t>Name: FramesDiscardedCount</t>
<t>Definition: Number of full frames discarded, Appendix A (g) of
<xref target="RFC7004" /></t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document requests IANA to update the registry described in <xref
target="I-D.alvestrand-rtcweb-stats-registry" /> with the identifiers
defined in <xref target="add-stats"></xref>.
</t>
<!-- <t></t> -->
</section>
<section anchor="Security" title="Security Considerations">
<t>
The monitoring activities are implemented between two browsers or
between a browser and a server. Therefore encryption procedures, such as
the ones suggested for a Secure RTCP (SRTCP), need to be used. Currently,
the monitoring in RTCWEB introduces no new security considerations beyond
those described in <xref target="I-D.ietf-rtcweb-rtp-usage" />,
<xref target="I-D.ietf-rtcweb-security" />, and
<xref target="I-D.alvestrand-rtcweb-stats-registry" />.
</t>
<!-- <t>
In some situations, returning very detailed error information (e.g.,
over-range measurement or measurement unavailable) exposed by the
statistics API can provide an attacker with insight into the media
processing.
</t> -->
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<!-- <t>
This document is a product of discussion in XRBLOCK WG, initial
motivation for this documented is discussed in <xref
target="I-D.huang-xrblock-rtcweb-rtcp-xr-metrics" />
</t> -->
<t>
The authors would like to thank
Bernard Aboba
, Al Morton
, Colin Perkins
, and Shida Schubert
, for their valuable comments and suggestions on earlier version of this
document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119; <!-- keywords -->
&I-D.alvestrand-rtcweb-stats-registry;
&rfc3550;
&rfc3611;
&rfc4588;
&rfc5725;
&rfc6776;
&rfc6958;
&rfc7002;
&rfc7003;
&rfc7004;
&rfc7005;
&rfc7097;
&rfc7243;
&I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count;
<!-- &rfc6798; -->
</references>
<references title="Informative References">
&I-D.ietf-rtcweb-use-cases-and-requirements;
&W3C.WD-webrtc-20130910;
&I-D.ietf-rtcweb-rtp-usage;
&I-D.ietf-rtcweb-security;
</references>
<!-- <section title="Metrics represented using RFC6390 Template">
<t> RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC
number, when assigned and remove this note.</t>
<t> <list style="letters">
<t> Number of Packets Retransmitted Metric
<list style="symbols">
<t> Metric Name: Cumulative number of RTP Packets retransmitted </t>
<t> Metric Description: Total number of packets retransmitted from the
beginning of the session. </t>
<t> Method of Measurement or Calculation:
Cumulative number of retransmitted packets received from the beginning
of the session. The measured value is an unsigned value. If the
measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE MUST be
reported to indicate an over-range measurement. If the measurement is
unavailable, the value 0xFFFFFFFF MUST be reported.
</t>
<t> Units of Measurement: The counter is increased by one for every
retransmitted RTP packet that is received. </t>
<t> Measurement Point(s) with Potential Measurement Domain:
This metric reports the number of retransmitted RTP packets received
by the receiver. The measurement of these metrics are made at the
receiving end of the retransmission stream and the association of the
retransmission and original streams should refer to section 5.3 of
<xref target="RFC4588" />.
</t>
<t> Measurement Timing: This metric is applicable to cumulative
measurements, which may be the duration of the ongoing RTP session.
</t>
<t>Use and applications: See section 1 of [RFCXXXX].</t>
<t>Reporting model: Queried periodically by the WebRTC Statistics API.
</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-huang-xrblock-rtcweb-rtcp-xr-metrics-04">
<t><list style="symbols">
<t>Addressed comments from the London IETF meeting:</t>
<t>Removed ECN metrics.</t>
<t>Merged draft-singh-xrblock-webrtc-additional-stats-01</t>
</list></t>
</section>
</section>
<!-- Change Log v00 2013-10-01 Varun Initial version -->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 23:35:26 |