rfc8868xml2.original.xml   rfc8868.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. ensus="true" docName="draft-ietf-rmcat-eval-criteria-14" indexInclude="true" ipr
RFC.2119.xml"> ="trust200902" number="8868" prepTime="2021-01-19T00:08:29" scripts="Common,Lati
<!ENTITY rfc3550 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. n" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude=
RFC.3550.xml"> "true" xml:lang="en">
<!ENTITY rfc3551 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <link href="https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria-14
RFC.3551.xml"> " rel="prev"/>
<!ENTITY rfc3611 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <link href="https://dx.doi.org/10.17487/rfc8868" rel="alternate"/>
RFC.3611.xml"> <link href="urn:issn:2070-1721" rel="alternate"/>
<!ENTITY rfc4585 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <front>
RFC.4585.xml"> <title abbrev="Evaluating Congestion Control for Interactive Real-Time Media
<!ENTITY rfc5506 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. ">Evaluating Congestion Control for Interactive Real-Time Media</title>
RFC.5506.xml"> <seriesInfo name="RFC" value="8868" stream="IETF"/>
<!ENTITY rfc5166 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <author initials="V." surname="Singh" fullname="Varun Singh">
RFC.5166.xml"> <organization abbrev="callstats.io" showOnFrontPage="true">CALLSTATS I/O O
<!ENTITY rfc5033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. y</organization>
RFC.5033.xml"> <address>
<!ENTITY rfc8593 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <postal>
RFC.8593.xml"> <street>Rauhankatu 11 C</street>
<!-- <!ENTITY rfc5681 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/refer <code>00100</code>
ence.RFC.5681.xml"> --> <city>Helsinki</city>
<!ENTITY rfc8083 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <country>Finland</country>
RFC.8083.xml"> </postal>
<!ENTITY I-D.ietf-rmcat-cc-requirements PUBLIC "" <email>varun.singh@iki.fi</email>
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-cc-requirem <uri>https://www.callstats.io/</uri>
ents.xml"> </address>
<!ENTITY I-D.ietf-avtcore-rtp-circuit-breakers PUBLIC "" </author>
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circu <author initials="J." surname="Ott" fullname="Jörg Ott">
it-breakers.xml"> <organization showOnFrontPage="true">Technical University of Munich</organ
<!ENTITY I-D.ietf-netvc-testing PUBLIC "" ization>
"https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netvc-test <address>
ing.xml"> <postal>
<!ENTITY I-D.ietf-rmcat-eval-test PUBLIC "" <extaddr>Department of Informatics</extaddr>
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-eval-test.x <extaddr>Chair of Connected Mobility</extaddr>
ml"> <street>Boltzmannstrasse 3</street>
<!ENTITY I-D.ietf-rmcat-wireless-tests PUBLIC "" <city>Garching</city>
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-wireless-te <code>85748</code>
sts.xml"> <country>Germany</country>
]> </postal>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <email>ott@in.tum.de</email>
<?rfc toc="yes" ?> </address>
<?rfc compact="yes" ?> </author>
<?rfc symrefs="yes" ?> <author fullname="Stefan Holmer" initials="S." surname="Holmer">
<rfc ipr="trust200902" docName="draft-ietf-rmcat-eval-criteria-14" category="inf <organization abbrev="Google" showOnFrontPage="true">Google</organization>
o"> <address>
<!-- What is the category field value--> <postal>
<front> <street>Kungsbron 2</street>
<title abbrev="Evaluating Congestion Control for RMCAT"> <code>11122</code>
Evaluating Congestion Control for Interactive Real-time Media <city>Stockholm</city>
<!--Evaluation Criteria for RTP Congestion Avoidance Techniques --> <country>Sweden</country>
</title> </postal>
<email>holmer@google.com</email>
<author initials="V." surname="Singh" fullname="Varun Singh"> </address>
<organization abbrev="callstats.io"> </author>
CALLSTATS I/O Oy <date month="01" year="2021"/>
</organization> <area>TSV</area>
<address> <workgroup>RMCAT</workgroup>
<postal> <keyword>RTP</keyword>
<street>Runeberginkatu 4c A 4</street> <keyword>RTCP</keyword>
<code>00100</code> <city>Helsinki</city> <keyword>Congestion Control</keyword>
<country>Finland</country> <abstract pn="section-abstract">
</postal> <t indent="0" pn="section-abstract-1">The Real-Time Transport Protocol (RT
<email>varun.singh@iki.fi</email> P) is used to transmit
<uri>
https://www.callstats.io/about
</uri>
</address>
</author>
<author initials="J." surname="Ott" fullname="Joerg Ott">
<organization>Technical University of Munich</organization>
<address>
<postal>
<street>Faculty of Informatics</street>
<street>Boltzmannstrasse 3</street>
<city>Garching bei München</city>
<region>DE</region>
<code>85748</code>
<country>Germany</country>
</postal>
<email>ott@in.tum.de</email>
</address>
</author>
<author fullname="Stefan Holmer" initials="S." surname="Holmer">
<organization abbrev="Google">Google</organization>
<address>
<postal>
<street>Kungsbron 2</street>
<code>11122</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>holmer@google.com</email>
</address>
</author>
<date year="2020" month="3"/>
<area>TSV</area>
<workgroup>RMCAT WG</workgroup>
<keyword>RTP</keyword>
<keyword>RTCP</keyword>
<keyword>Congestion Control</keyword>
<abstract>
<t>The Real-time Transport Protocol (RTP) is used to transmit
media in telephony and video conferencing applications. This media in telephony and video conferencing applications. This
document describes the guidelines to evaluate new congestion document describes the guidelines to evaluate new congestion
control algorithms for interactive point-to-point real-time control algorithms for interactive point-to-point real-time
media.</t> media.</t>
</abstract> </abstract>
</front> <boilerplate>
<middle> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<section title="Introduction"> "exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<t>This memo describes the guidelines to help with evaluating >
<t indent="0" pn="section-boilerplate.1-1">
This document is not an Internet Standards Track specification; it i
s
published for informational purposes.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8868" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
erminology</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-metrics">Metrics</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><
xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rt
p-log-format">RTP Log Format</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-list-of-network-parameters">List o
f Network Parameters</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-one-way-propagation-de
lay">One-Way Propagation Delay</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-end-to-end-loss">End-t
o-End Loss</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-drop-tail-router-queue
-leng">Drop-Tail Router Queue Length</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
"4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-loss-generation-model"
>Loss Generation Model</xref></t>
</li>
<li pn="section-toc.1-1.4.2.5">
<t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent=
"4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-jitter-models">Jitter
Models</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.5.2">
<li pn="section-toc.1-1.4.2.5.2.1">
<t indent="0" pn="section-toc.1-1.4.2.5.2.1.1"><xref derived
Content="4.5.1" format="counter" sectionFormat="of" target="section-4.5.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-random-bou
nded-pdv-rbpdv">Random Bounded PDV (RBPDV)</xref></t>
</li>
<li pn="section-toc.1-1.4.2.5.2.2">
<t indent="0" pn="section-toc.1-1.4.2.5.2.2.1"><xref derived
Content="4.5.2" format="counter" sectionFormat="of" target="section-4.5.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-approximat
ely-random-subjec">Approximately Random Subject to No-Reordering Bounded PDV (NR
-BPDV)</xref></t>
</li>
<li pn="section-toc.1-1.4.2.5.2.3">
<t indent="0" pn="section-toc.1-1.4.2.5.2.3.1"><xref derived
Content="4.5.3" format="counter" sectionFormat="of" target="section-4.5.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-recommende
d-distribution">Recommended Distribution</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-traffic-models">Traffic Models</xr
ef></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-tcp-traffic-model">TCP
Traffic Model</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rtp-video-model">RTP V
ideo Model</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-background-udp">Backgr
ound UDP</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-contributors">Contributors</xref
></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">This memo describes the guidelines to help
with evaluating
new congestion control algorithms for interactive new congestion control algorithms for interactive
point-to-point real time media. The requirements for the point-to-point real-time media. The requirements for the
congestion control algorithm are outlined in <xref congestion control algorithm are outlined in <xref target="RFC8836"
target="I-D.ietf-rmcat-cc-requirements" />). This document format="default" sectionFormat="of" derivedContent="RFC8836"/>. This document
builds upon previous work at the IETF: <xref builds upon previous work at the IETF: <xref target="RFC5033" format
target="RFC5033">Specifying New Congestion Control ="default" sectionFormat="of" derivedContent="RFC5033">Specifying New Congestion
Algorithms</xref> and <xref target="RFC5166">Metrics for the Control
Algorithms</xref> and <xref target="RFC5166" format="default" sectio
nFormat="of" derivedContent="RFC5166">Metrics for the
Evaluation of Congestion Control Algorithms</xref>.</t> Evaluation of Congestion Control Algorithms</xref>.</t>
<t indent="0" pn="section-1-2">The guidelines proposed in the document are
<t>The guidelines proposed in the document are intended to help intended to help
prevent a congestion collapse, promote fair capacity usage and prevent a congestion collapse, to promote fair capacity usage, and
optimize the media flow's throughput. Furthermore, the proposed to optimize the media flow's throughput. Furthermore, the proposed
congestion control algorithms are expected to operate within the env elope of the congestion control algorithms are expected to operate within the env elope of the
circuit breakers defined in <xref target="RFC8083">RFC8083</xref>.</ circuit breakers defined in RFC 8083 <xref target="RFC8083" format="
t> default" sectionFormat="of" derivedContent="RFC8083"/>.</t>
<t indent="0" pn="section-1-3">This document only provides the broad set o
<t>This document only provides the broad set of network f network
parameters and and traffic models for evaluating a new parameters and traffic models for evaluating a new
congestion control algorithm. The minimal requirements congestion control algorithm. The minimal requirement
for congestion control proposals is to produce or present for congestion control proposals is to produce or present
results for the test scenarios described in <xref results for the test scenarios described in <xref target="RFC8867" f
target="I-D.ietf-rmcat-eval-test" /> (Basic Test Cases), ormat="default" sectionFormat="of" derivedContent="RFC8867"/> (Basic Test Cases)
,
which also defines the specifics for the test cases. which also defines the specifics for the test cases.
Additionally, proponents may produce evaluation results Additionally, proponents may produce evaluation results
for the <xref target="I-D.ietf-rmcat-wireless-tests"> for the <xref target="RFC8869" format="default" sectionFormat="of" d erivedContent="RFC8869">
wireless test scenarios</xref>. wireless test scenarios</xref>.
</t> </t>
<t indent="0" pn="section-1-4">
<t>
This document does not cover application-specific This document does not cover application-specific
implications of congestion control algorithms and how implications of congestion control algorithms and how
those could be evaluated. Therefore, no quality metrics those could be evaluated. Therefore, no quality metrics
are defined for performance evaluation; quality metrics are defined for performance evaluation; quality metrics
and algorithms to infer those vary between media types. and the algorithms to infer those vary between media types.
Metrics and algorithms to assess, e.g., quality of Metrics and algorithms to assess, e.g., the quality of
experience evolve continuously so that determining experience, evolve continuously so that determining
suitable choices is left for future work. However, there suitable choices is left for future work. However, there
is consensus that each congestion control algorithm is consensus that each congestion control algorithm
should be able to show that it is useful for interactive should be able to show that it is useful for interactive
video by performing analysis using a real codecs and video by performing analysis using real codecs and
video sequences and state-of-the-art quality metrics. video sequences and state-of-the-art quality metrics.
</t> </t>
<t> <t indent="0" pn="section-1-5">
Beyond optimizing individual metrics, real-time Beyond optimizing individual metrics, real-time
applications may have further options to trade off applications may have further options to trade off
performance, e.g., across multiple media; refer to the performance, e.g., across multiple media; refer to the
<xref target="I-D.ietf-rmcat-cc-requirements">RMCAT <xref target="RFC8836" format="default" sectionFormat="of" derivedC ontent="RFC8836">RMCAT
requirements</xref> document. Such trade-offs may be requirements</xref> document. Such trade-offs may be
defined in the future. defined in the future.
</t> </t>
</section>
</section> <section anchor="sec-terminology" numbered="true" toc="include" removeInRFC=
"false" pn="section-2">
<section title="Terminology" anchor="sec-terminology"> <name slugifiedName="name-terminology">Terminology</name>
<!--<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", <t indent="0" pn="section-2-1"> The terminology defined in <xref target="R
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and FC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTP</xref>,
"OPTIONAL" in this document are to be interpreted as described <xref target="RFC3551" format="default" sectionFormat="of" derivedCo
in BCP 14, <xref target="RFC2119" /> and indicate requirement ntent="RFC3551">RTP Profile for Audio and Video Conferences
levels for compliant implementations. </t> --> with Minimal Control</xref>, <xref target="RFC3611" format="default"
sectionFormat="of" derivedContent="RFC3611">RTCP Extended
<t> The terminology defined in <xref target="RFC3550">RTP</xref>, Report (XR)</xref>, <xref target="RFC4585" format="default" sectionF
<xref target="RFC3551">RTP Profile for Audio and Video Conferences ormat="of" derivedContent="RFC4585">Extended RTP Profile
with Minimal Control</xref>, <xref target="RFC3611">RTCP Extended for RTCP-Based Feedback (RTP/AVPF)</xref> and <xref target="RFC5506"
Report (XR)</xref>, <xref target="RFC4585">Extended RTP Profile format="default" sectionFormat="of" derivedContent="RFC5506">Support for Reduce
for RTCP-based Feedback (RTP/AVPF)</xref> and <xref d-Size RTCP</xref> applies.</t>
target="RFC5506">Support for Reduced-Size RTCP</xref> apply.</t> </section>
</section> <section anchor="cc-metrics" numbered="true" toc="include" removeInRFC="fals
e" pn="section-3">
<section title="Metrics" anchor="cc-metrics"> <name slugifiedName="name-metrics">Metrics</name>
<t indent="0" pn="section-3-1"> This document specifies testing criteria f
<!-- <t><xref target="RFC5166" /> describes the basic metrics for or evaluating
congestion control. Metrics that are of interest for interactive
multimedia are:
<list style="symbols">
<t>Throughput.</t>
<t>Minimizing oscillations in the transmission rate (stability)
when the end-to-end capacity varies slowly.</t>
<t>Delay.</t>
<t>Reactivity to transient events.</t>
<t>Packet losses and discards.</t>
<t>Users' quality of experience</t>
<t>Section 2.1 of <xref target="RFC5166" /> discusses the tradeoff
between throughput, delay and loss.</t>
</list></t> -->
<t> This document specifies testing criteria for evaluating
congestion control algorithms for RTP media flows. Proposed congestion control algorithms for RTP media flows. Proposed
algorithms are to prove their performance by means of algorithms are to prove their performance by means of
simulation and/or emulation experiments for all the cases simulation and/or emulation experiments for all the cases
described.</t> described.</t>
<t indent="0" pn="section-3-2">Each experiment is expected to log every in
<t>Each experiment is expected to log every incoming and outgoing coming and outgoing
packet (the RTP logging format is described in <xref packet (the RTP logging format is described in <xref target="rtp-loggin
target="rtp-logging" />). The logging can be done inside the g" format="default" sectionFormat="of" derivedContent="Section 3.1"/>). The logg
ing can be done inside the
application or at the endpoints using PCAP (packet capture, e.g., application or at the endpoints using PCAP (packet capture, e.g.,
tcpdump <xref target="tcpdump"/>, wireshark <xref target="wireshark"/>) . tcpdump <xref target="tcpdump" format="default" sectionFormat="of" deri vedContent="tcpdump"/>, Wireshark <xref target="wireshark" format="default" sect ionFormat="of" derivedContent="wireshark"/>).
The following metrics are calculated based on the The following metrics are calculated based on the
information in the packet logs: information in the packet logs:
<list style="numbers"> </t>
<t>Sending rate, Receiver rate, Goodput (measured at 200ms intervals <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3-3"
)</t> >
<t>Packets sent, Packets received</t> <li pn="section-3-3.1" derivedCounter="1.">Sending rate, receiver rate,
<t>Bytes sent, bytes received</t> goodput (measured at 200ms intervals)</li>
<t>Packet delay</t> <li pn="section-3-3.2" derivedCounter="2.">Packets sent, packets receive
<t>Packets lost, Packets discarded (from the playout or de-jitter bu d</li>
ffer)</t> <li pn="section-3-3.3" derivedCounter="3.">Bytes sent, bytes received</l
<t>If using, retransmission or FEC: post-repair loss</t> i>
<li pn="section-3-3.4" derivedCounter="4.">Packet delay</li>
<!-- <t>[Editor's note: How to handle packet re-transmissions? loss befo <li pn="section-3-3.5" derivedCounter="5.">Packets lost, packets discard
re ed (from the playout or de-jitter buffer)</li>
retransmission, after retransmission?]</t> --> <li pn="section-3-3.6" derivedCounter="6.">If using retransmission or FE
<!-- t>Fairness or Unfairness: Experiments testing the performance C: post-repair loss</li>
of an RMCAT proposal against any cross-traffic must define its <li pn="section-3-3.7" derivedCounter="7.">
expected criteria for fairness. The "unfairness" test guideline <t indent="0" pn="section-3-3.7.1">Self-fairness and fairness with res
(measured at 1s intervals) is:<vspace /> pect to cross
1. Does not trigger the circuit breaker.<vspace />
2. No RMCAT stream achieves more than 3 times the average throug
hput
of the RMCAT stream with the lowest average throughput, for a ca
se
when the competing streams have similar RTTs.<vspace />
3. RTT should not grow by a factor of 3 for the existing flows w
hen a
new flow is added.
<vspace />
-->
<t>Self-Fairness and Fairness with respect to cross
traffic: Experiments testing a given congestion control proposal must traffic: Experiments testing a given congestion control proposal must
report on relative ratios of the average throughput report on relative ratios of the average throughput
(measured at coarser time intervals) obtained by each (measured at coarser time intervals) obtained by each
RTP media stream. In the presence of background cross-traffic RTP media stream. In the presence of background cross-traffic
such as TCP, the report must also include the relative such as TCP, the report must also include the relative
ratio between average throughput of RTP media streams and ratio between average throughput of RTP media streams and
cross-traffic streams. cross-traffic streams.
<vspace/> </t>
<t indent="0" pn="section-3-3.7.2">
During static periods of a test (i.e., when bottleneck During static periods of a test (i.e., when bottleneck
bandwidth is constant and no arrival/departure of bandwidth is constant and no arrival/departure of
streams), these report on relative ratios serve as an streams), these reports on relative ratios serve as an
indicator of how fair the RTP streams share bandwidth indicator of how fairly the RTP streams share bandwidth
amongst themselves and against cross-traffic streams. The amongst themselves and against cross-traffic streams. The
throughput measurement interval should be set at a few throughput measurement interval should be set at a few
values (for example, at 1s, 5s, and 20s) in order to values (for example, at 1 s, 5 s, and 20 s) in order to
measure fairness across different time scales. measure fairness across different timescales.
<vspace/> </t>
As a general guideline, the relative ratio between congestion control <t indent="0" pn="section-3-3.7.3">
led RTP As a general guideline, the relative ratio between congestion-control
led RTP
flows with the same priority level and similar path RTT flows with the same priority level and similar path RTT
should be bounded between (0.333 and 3.) For example, see should be bounded between 0.333 and 3. For example, see
the test scenarios described in <xref the test scenarios described in <xref target="RFC8867" format="defaul
target="I-D.ietf-rmcat-eval-test" />.</t> t" sectionFormat="of" derivedContent="RFC8867"/>.</t>
</li>
<t>Convergence time: The time taken to reach a stable rate at startu <li pn="section-3-3.8" derivedCounter="8.">Convergence time: The time ta
p, ken to reach a stable rate at startup,
after the available link capacity changes, or when new flows get add ed after the available link capacity changes, or when new flows get add ed
to the bottleneck link.</t> to the bottleneck link.</li>
<li pn="section-3-3.9" derivedCounter="9.">Instability or oscillation in
<t>Instability or oscillation in the sending rate: The frequency or the sending rate: The frequency or
number of instances when the sending rate oscillates between an number of instances when the sending rate oscillates between an
high watermark level and a low watermark level, or vice-versa in high watermark level and a low watermark level, or vice-versa in
a defined time window. For example, the watermarks can be set at 4x a defined time window. For example, the watermarks can be set at 4x
interval: 500 Kbps, 2 Mbps, and a time window of 500ms.</t> interval: 500 Kbps, 2 Mbps, and a time window of 500 ms.</li>
<li pn="section-3-3.10" derivedCounter="10.">Bandwidth utilization, defi
<!-- ned as the ratio of the instantaneous
<t>[Open issue (2): Convergence time was discussed briefly in the sending rate to the instantaneous bottleneck capacity: This metric i
design meetings. It is defined as: the time it takes the congestion s
control to reach a stable rate (at startup or after new RMCAT flows useful only when a congestion-controlled RTP flow is by itself or is
are added). What is a stable rate?]</t> competing with similar
--> cross-traffic.</li>
<t>Bandwidth Utilization, defined as ratio of the instantaneous </ol>
sending rate to the instantaneous bottleneck capacity. This metric i <t indent="0" pn="section-3-4">
s
useful only when a congestion controlled RTP flow is by itself or co
mpeting with similar
cross-traffic.</t>
</list></t>
<t>
Note that the above metrics are all objective Note that the above metrics are all objective
application-independent metrics. Refer to Section 3, in application-independent metrics. Refer to
<xref target="I-D.ietf-netvc-testing" /> for objective <xref target="I-D.ietf-netvc-testing" section="3" sectionFormat="of" fo
metrics for evaluating codecs. rmat="default" derivedLink="https://tools.ietf.org/html/draft-ietf-netvc-testing
</t> -09#section-3" derivedContent="netvc-testing"/>
for objective metrics for evaluating codecs.
<t>From the logs the statistical measures (min, max, mean, standard </t>
deviation and variance) for the whole duration or any specific part of <t indent="0" pn="section-3-5">From the logs, the statistical measures (mi
n, max, mean, standard
deviation, and variance) for the whole duration or any specific part of
the session can be calculated. Also the metrics (sending rate, the session can be calculated. Also the metrics (sending rate,
receiver rate, goodput, latency) can be visualized in graphs as receiver rate, goodput, latency) can be visualized in graphs as
variation over time, the measurements in the plot are at 1 second variation over time; the measurements in the plot are at one-second
intervals. Additionally, from the logs it is possible to plot the intervals. Additionally, from the logs, it is possible to plot the
histogram or CDF of packet delay.</t> histogram or cumulative distribution function (CDF) of packet delay.</t>
<section anchor="rtp-logging" numbered="true" toc="include" removeInRFC="f
<!-- t>[Open issue (1): Using Jain-fairness index (JFI) for measuring alse" pn="section-3.1">
self-fairness between RTP flows? measured at what intervals? <name slugifiedName="name-rtp-log-format">RTP Log Format</name>
visualized as a CDF or a time series? Additionally: Use JFI <t indent="0" pn="section-3.1-1">
for comparing fairness between RTP and long TCP flows? Having a common log format simplifies running analyses across
]</t --> different measurement setups and comparing their results.
<!-- <t> <list style="empty">
<t>(i) Bandwidth Utilization: is the
ratio of the encoding rate to the (available) end-to-end path
capacity.
<list style="symbols">
<t>Under-utilization: is the period of time when the endpoint's
encoding rate is lower than the end-to-end capacity, i.e., the
bandwidth utilization is less than 1.</t>
<t>Overuse: is the period of time when the endpoint's encoding
rate is higher than the end-to-end capacity, i.e., the bandwidth
utilization is greater than 1.</t>
<t>Steady-state: is the period of time when the endpoint's
encoding rate is relatively stable, i.e., the bandwidth
utilization is constant.</t>
</list></t>
<t></t>
<t>(ii) Packet Loss and Discard Rate.</t> <t></t>
<t>(iii) Fair Share. </t> <t></t>
<t>[Editor's Note: This metric should match the ones defined in the
<xref target="I-D.ietf-rmcat-cc-requirements">RMCAT requirements</xref>
document.]</t>
<t></t>
<t>(iv) Quality: There are many different types of quality metrics for
audio and video. Audio quality is often expressed by a MOS ("Mean
Opinion Score") and can be calculated using an objective algorithm
(E-model/R-model). Section 4.7 of <xref target="RFC3611" /> can also
be used for VoIP metrics. Similarly, there exist several metrics to
measure video quality, for example Peak Signal to Noise Ratio (PSNR).
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-3.1-2">
<t>[Editor's Note: Should the algorithm compare average PSNR of test Send or receive timestamp (Unix): &lt;int&gt;.&lt;int&gt; -- sec.usec decimal
video sequences or what other video quality metric can be used? If RTP payload type &lt;int&gt; -- decimal
Quality is used as a metric, it should not be the only metric used to SSRC &lt;int&gt; -- hexadecimal
compare rate-control schemes. Also, algorithms using different codecs RTP sequence no &lt;int&gt; -- decimal
cannot be compared]. </t> RTP timestamp &lt;int&gt; -- decimal
</list>
</t>
-->
<section title="RTP Log Format" anchor="rtp-logging">
<t>
Having a common log format simplifies running analyses
across and comparing different measurements. The log file
should be tab or comma separated containing the following
details:
</t>
<figure><artwork><![CDATA[
Send or receive timestamp (Unix): <int>.<int> -- sec.usec decimal
RTP payload type <int> -- decimal
SSRC <int> -- hexadecimal
RTP sequence no <int> -- decimal
RTP timestamp <int> -- decimal
marker bit 0|1 -- character marker bit 0|1 -- character
Payload size <int> -- # bytes, decimal Payload size &lt;int&gt; -- # bytes, decimal
]]></artwork></figure> </artwork>
<t indent="0" pn="section-3.1-3">Each line of the log file should be ter
<t>Each line of the log file should be terminated with CRLF, minated with CRLF,
CR, or LF characters. Empty lines are disregarded.</t> CR, or LF characters. Empty lines are disregarded.</t>
<t>If the congestion control implements retransmissions or FEC, the <t indent="0" pn="section-3.1-4">If the congestion control implements re transmissions or Forward Error Correction (FEC), the
evaluation should report both packet loss (before applying evaluation should report both packet loss (before applying
error-resilience) and residual packet loss (after applying error resilience) and residual packet loss (after applying
error-resilience).</t> error resilience).</t>
<t indent="0" pn="section-3.1-5">These data should suffice to compute th
<t>These data should suffice to compute the media-encoding independent e media-encoding independent
metrics described above. Use of a common log will allow simplified metrics described above. Use of a common log will allow simplified
post-processing and analysis across different implementations. post-processing and analysis across different implementations.
</t> </t>
<!-- <t>The retransmissions for post-repair loss metric be logged in a
separate file, as the repair streams have different payload type
and/or SSRC.</t> -->
</section>
</section>
<!--
<section title="Congestion control requirements" anchor="cc-require">
<t> </t>
</section>
-->
<!--
<section title="Guidelines" anchor="cc-guidelines">
<t>A congestion control algorithm should be tested in
simulation or a testbed environment, and the experiments should
be repeated multiple times to infer statistical significance.
The following guidelines are considered for evaluation:</t>
<section title="Avoiding Congestion Collapse">
<t>The congestion control algorithm is expected to take an action,
such as reducing the sending rate, when it detects congestion.
Typically, it should intervene before the circuit breaker <xref
target="I-D.ietf-avtcore-rtp-circuit-breakers" /> is engaged. </t>
<t>Does the congestion control propose any changes to (or diverge
from) the circuit breaker conditions defined in <xref
target="I-D.ietf-avtcore-rtp-circuit-breakers" />.</t> </section>
<section title="Stability">
<t>The congestion control should be assessed for its stability
when the path characteristics do not change over time. Changing
the media encoding rate estimate too often or by too much may
adversely affect the application layer performance.</t>
</section>
<section title ="Media Traffic">
<t>The congestion control algorithm should be assessed with
different types of media behavior, i.e., the media should contain
idle and data-limited periods. For example, periods of silence for
audio, varying amount of motion for video, or bursty nature of
I-frames. </t>
<t>The evaluation may be done in two stages. In the first stage,
the endpoint generates traffic at the rate calculated by the
congestion controller. In the second stage, real codecs or models
of video codecs are used to mimic application-limited data periods
and varying video frame sizes.</t>
</section>
<section title="Start-up Behavior">
<t>The congestion control algorithm should be assessed with
different start-rates. The main reason is to observe the behavior
of the congestion control in different test scenarios, such
as when competing with varying amount of cross-traffic or how
quickly does the congestion control algorithm achieve a stable
sending rate.</t>
</section>
<section title="Diverse Environments">
<t>The congestion control algorithm should be assessed in
heterogeneous environments, containing both wired and wireless
paths. Examples of wireless access technologies are: 802.11, GPRS,
HSPA, or LTE. One of the main challenges of the wireless
environments for the congestion control algorithm is to
distinguish between congestion induced loss and transmission
(bit-error) loss. Congestion control algorithms may
incorrectly identify transmission loss as congestion loss and
reduce the media encoding rate by too much, which may cause
oscillatory behavior and deteriorate the users' quality of
experience. Furthermore, packet loss may induce additional delay
in networks with wireless paths due to link-layer
retransmissions.</t>
</section>
<section title="Varying Path Characteristics">
<t>The congestion control algorithm should be evaluated for a
range of path characteristics such as, different end-to-end
capacity and latency, varying amount of cross traffic on a
bottleneck link and a router's queue length. For the moment, only
Drop Tail queues are used. However, if new Active Queue Management
(AQM) schemes become available, the performance of the congestion
control algorithm should be again evaluated.</t>
<t>In an experiment, if the media only flows in a single
direction, the feedback path should also be tested with varying
amounts of impairment.</t>
<t>The main motivation for the previous and current criteria is to
identify situations in which the proposed congestion control is
less performant.</t>
</section>
<section title="Reacting to Transient Events or Interruptions">
<t>The congestion control algorithm should be able to handle
changes in end-to-end capacity and latency. Latency may change
due to route updates, link failures, hand-overs etc. In mobile
environment the end-to-end capacity may vary due to the
interference, fading, hand-overs, etc. In wired networks the
end-to-end capacity may vary due to changes in resource
reservation.</t>
</section>
<section title="Fairness With Similar Cross-Traffic">
<t>The congestion control algorithm should be evaluated when
competing with other RTP flows using the same or another candidate
congestion control algorithm. The proposal should highlight the
bottleneck capacity share of each RTP flow.</t>
</section>
<section title="Impact on Cross-Traffic">
<t>The congestion control algorithm should be evaluated when
competing with standard TCP. Short TCP flows may be considered
as transient events and the RTP flow may give way to the short
TCP flow to complete quickly. However, long-lived TCP flows may
starve out the RTP flow depending on router queue length. </t>
<t>The proposal should also measure the impact on varied number
of cross-traffic sources, i.e., few and many competing flows,
or mixing various amounts of TCP and similar cross-traffic.</t>
</section>
<section title="Extensions to RTP/RTCP">
<t>The congestion control algorithm should indicate if any
protocol extensions are required to implement it and should
carefully describe the impact of the extension.</t>
</section>
</section> -->
<section anchor="add-params" title="List of Network Parameters">
<t>The implementors initially are encouraged to choose evaluation settings
from the following values:</t>
<section anchor="scen-delay" title="One-way Propagation Delay">
<!-- -->
<t>Experiments are expected to verify that the congestion control is
able to work across a broad range of path characteristics, also includin
g challenging situations, for example over
trans-continental and/or satellite links. Tests thus account for the fo
llowing different latencies:
<list style="numbers">
<t>Very low latency: 0-1ms</t>
<t>Low latency: 50ms</t>
<t>High latency: 150ms</t>
<t>Extreme latency: 300ms</t>
</list></t>
</section> </section>
</section>
<section anchor="add-params" numbered="true" toc="include" removeInRFC="fals
e" pn="section-4">
<name slugifiedName="name-list-of-network-parameters">List of Network Para
meters</name>
<t indent="0" pn="section-4-1">The implementors are encouraged to choose e
valuation settings
from the following values initially:</t>
<section anchor="scen-delay" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-4.1">
<name slugifiedName="name-one-way-propagation-delay">One-Way Propagation
Delay</name>
<t indent="0" pn="section-4.1-1">Experiments are expected to verify that
the congestion control is
able to work across a broad range of path characteristics, including cha
llenging situations, for example, over
transcontinental and/or satellite links. Tests thus account for the fol
lowing different latencies:
<section anchor="scen-loss" title="End-to-end Loss"> </t>
<t>Many paths in the Internet today are largely lossless but, <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.
with wireless networks and interference, towards remote 1-2">
regions, or in scenarios featuring high/fast mobility, media <li pn="section-4.1-2.1" derivedCounter="1.">Very low latency: 0-1 ms<
flows may exhibit substantial packet loss. This variety needs /li>
<li pn="section-4.1-2.2" derivedCounter="2.">Low latency: 50 ms</li>
<li pn="section-4.1-2.3" derivedCounter="3.">High latency: 150 ms</li>
<li pn="section-4.1-2.4" derivedCounter="4.">Extreme latency: 300 ms</
li>
</ol>
</section>
<section anchor="scen-loss" numbered="true" toc="include" removeInRFC="fal
se" pn="section-4.2">
<name slugifiedName="name-end-to-end-loss">End-to-End Loss</name>
<t indent="0" pn="section-4.2-1"> Many paths in the Internet today are
largely lossless;
however, in scenarios featuring interference in wireless
networks, sending to and receiving from remote regions,
or high/fast mobility, media flows may exhibit substantial
packet loss. This variety needs
to be reflected appropriately by the tests.</t> to be reflected appropriately by the tests.</t>
<t indent="0" pn="section-4.2-2">To model a wide range of lossy links, t
<t>To model a wide range of lossy links, the experiments can choose one he experiments can choose one of the
of the following loss rates; the fractional loss is the ratio of packets lost
following loss rates, the fractional loss is the ratio of packets lost and packets sent: </t>
and packets sent. <list style="numbers"> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.
<t>no loss: 0%</t> 2-3">
<li pn="section-4.2-3.1" derivedCounter="1.">no loss: 0%</li>
<t>1%</t> <li pn="section-4.2-3.2" derivedCounter="2.">1%</li>
<li pn="section-4.2-3.3" derivedCounter="3.">5%</li>
<t>5%</t> <li pn="section-4.2-3.4" derivedCounter="4.">10%</li>
<li pn="section-4.2-3.5" derivedCounter="5.">20%</li>
<t>10%</t> </ol>
<t>20%</t>
</list></t>
</section> </section>
<section anchor="scen-queue" numbered="true" toc="include" removeInRFC="fa
<section anchor="scen-queue" title="Drop Tail Router Queue Length"> lse" pn="section-4.3">
<t>Routers should be configured to use Drop Trail queues in <name slugifiedName="name-drop-tail-router-queue-leng">Drop-Tail Router
Queue Length</name>
<t indent="0" pn="section-4.3-1">Routers should be configured to use dro
p-tail queues in
the experiments due to their (still) prevalent nature. the experiments due to their (still) prevalent nature.
Experimentation with AQM schemes is encouraged but not mandatory. Experimentation with Active Queue Management (AQM) schemes is encouraged
</t> but not mandatory.
</t>
<t>The router queue length is measured as the time taken to drain the <t indent="0" pn="section-4.3-2">The router queue length is measured as
the time taken to drain the
FIFO queue. It has been noted in various discussions that the queue FIFO queue. It has been noted in various discussions that the queue
length in the current deployed Internet varies significantly. While length in the currently deployed Internet varies significantly. While
the core backbone network has very short queue length, the home the core backbone network has very short queue length, the home
gateways usually have larger queue length. Those various queue lengths gateways usually have larger queue length. Those various queue lengths
can be categorized in the following way: <list style="numbers"> can be categorized in the following way: </t>
<t>QoS-aware (or short): 70ms</t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.
3-3">
<t>Nominal: 300-500ms</t> <li pn="section-4.3-3.1" derivedCounter="1.">QoS-aware (or short): 70
ms</li>
<t>Buffer-bloated: 1000-2000ms</t> <li pn="section-4.3-3.2" derivedCounter="2.">Nominal: 300-500 ms</li>
</list> Here the size of the queue is measured in bytes or packets <li pn="section-4.3-3.3" derivedCounter="3.">Buffer-bloated: 1000-2000
and to convert the queue length measured in seconds to queue length in ms</li>
</ol>
<t indent="0" pn="section-4.3-4"> Here the size of the queue is measured
in bytes or packets.
To convert the queue length measured in seconds to queue length in
bytes:</t> bytes:</t>
<t indent="0" pn="section-4.3-5">QueueSize (in bytes) = QueueSize (in se
<t>QueueSize (in bytes) = QueueSize (in sec) x Throughput (in c) x Throughput (in
bps)/8</t> bps)/8</t>
<!-- <t>and 2) queue length in packets:</t>
<t>QueueSize (in pkts) = QueueSize (in bytes)/MTU,
MTU=1500</t> -->
<!-- <t>[Open issue (11): Confirm the above values, do we need to
define parameters for other types of queues?]</t> -->
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.4
<section title="Loss generation model"> ">
<t> <name slugifiedName="name-loss-generation-model">Loss Generation Model</
Many models for generating packet loss are available, some name>
yield correlated, others independent losses; losses can also <t indent="0" pn="section-4.4-1">
be extracted from packet traces. As a (simple) minimum loss Many models for generating packet loss are available: some
generate correlated packet losses, others generate independent packet losses.
In addition,
packet losses can also be extracted from packet traces.
As a (simple) minimum loss
model with minimal parameterization (i.e., the loss rate), model with minimal parameterization (i.e., the loss rate),
independent random losses must be used in the evaluation. independent random losses must be used in the evaluation.
</t> </t>
<t> <t indent="0" pn="section-4.4-2">
It is known that independent loss models may reflect reality It is known that independent loss models may reflect reality poorly,
poorly and hence more sophisticated loss models could be and hence more sophisticated loss models could be
considered. Suitable models for correlated losses includes considered.
the Gilbert-Elliot model <xref target="gilbert-elliott"/> and Suitable models for correlated losses include the Gilbert-Elliot
losses generated by modeling a queue including its model <xref target="gilbert-elliott" format="default" sectionFormat="of" deri
(different) drop behaviors. vedContent="gilbert-elliott"/> and models that generate losses by
</t> modeling a queue with its (different) drop behaviors.
</t>
</section> </section>
<section anchor="JM" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="JM" title="Jitter models"> "section-4.5">
<t>This section defines jitter models for the purposes of this <name slugifiedName="name-jitter-models">Jitter Models</name>
document. When jitter is to be applied to both the congestion controlled <t indent="0" pn="section-4.5-1">This section defines jitter models for
RTP flow and any the purposes of this
document. When jitter is to be applied to both the congestion-controlled
RTP flow and any
competing flow (such as a TCP competing flow), the competing flow will competing flow (such as a TCP competing flow), the competing flow will
use the jitter definition below that does not allow for re-ordering of use the jitter definition below that does not allow for reordering of
packets on the competing flow (see NR-RBPDV definition below).</t> packets on the competing flow (see NR-BPDV definition below).</t>
<t indent="0" pn="section-4.5-2">Jitter is an overloaded term in communi
<t>Jitter is an overloaded term in communications. It is cations. It is
typically used to refer to the variation of a metric (e.g., typically used to refer to the variation of a metric (e.g.,
delay) with respect to some reference metric (e.g., average delay) with respect to some reference metric (e.g., average
delay or minimum delay). For example, RFC 3550 jitter is delay or minimum delay). For example in RFC 3550, jitter is
computed as the smoothed difference in packet arrival times computed as the smoothed difference in packet arrival times
relative to their respective expected arrival times, which is relative to their respective expected arrival times, which is
particularly meaningful if the underlying packet delay particularly meaningful if the underlying packet delay
variation was caused by a Gaussian random process.</t> variation was caused by a Gaussian random process.</t>
<t indent="0" pn="section-4.5-3">Because jitter is an overloaded term, w
<t>Because jitter is an overloaded term, we use the term e use the term
Packet Delay Variation (PDV) instead to describe the variation Packet Delay Variation (PDV) instead to describe the variation
of delay of individual packets in the same sense as the IETF of delay of individual packets in the same sense as the IETF
IPPM WG has defined PDV in their documents (e.g., RFC 3393) IP Performance Metrics (IPPM) working group has defined PDV in their doc uments (e.g., RFC 3393)
and as the ITU-T SG16 has defined IP Packet Delay Variation and as the ITU-T SG16 has defined IP Packet Delay Variation
(IPDV) in their documents (e.g., Y.1540).</t> (IPDV) in their documents (e.g., Y.1540).</t>
<t indent="0" pn="section-4.5-4">Most PDV distributions in packet networ
<t>Most PDV distributions in packet network systems are k systems are
one-sided distributions, the measurement of which with a one-sided distributions, the measurement of which with a
finite number of measurement samples results in one-sided finite number of measurement samples results in one-sided
histograms. In the usual packet network transport case, there histograms. In the usual packet network transport case, there
is typically one packet that transited the network with the is typically one packet that transited the network with the
minimum delay; a (large) number of packets transit the network minimum delay; a (large) number of packets transit the network
within some (smaller) positive variation from this minimum within some (smaller) positive variation from this minimum
delay, and a (small) number of the packets transit the network delay, and a (small) number of the packets transit the network
with delays higher than the median or average transit time with delays higher than the median or average transit time
(these are outliers). Although infrequent, outliers can cause (these are outliers). Although infrequent, outliers can cause
significant deleterious operation in adaptive systems and significant deleterious operation in adaptive systems and
should be considered in rate adaptation designs for RTP should be considered in rate adaptation designs for RTP
congestion control.</t> congestion control.</t>
<t indent="0" pn="section-4.5-5">In this section we define two different
<t>In this section we define two different bounded PDV bounded PDV
characteristics, 1) Random Bounded PDV and 2) Approximately Random characteristics, 1) Random Bounded PDV and 2) Approximately Random
Subject to No-Reordering Bounded PDV.</t> Subject to No-Reordering Bounded PDV.</t>
<t indent="0" pn="section-4.5-6">The former, 1) Random Bounded PDV, is p
<t>The former, 1) Random Bounded PDV is presented for resented for
information only, while the latter, 2) Approximately Random information only, while the latter, 2) Approximately Random
Subject to No-Reordering Bounded PDV, must be used in the Subject to No-Reordering Bounded PDV, must be used in the
evaluation.</t> evaluation.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4
<section title="Random Bounded PDV (RBPDV)"> .5.1">
<name slugifiedName="name-random-bounded-pdv-rbpdv">Random Bounded PDV
<t>The RBPDV probability distribution function (PDF) is specified to (RBPDV)</name>
be of some mathematically describable function which includes some <t indent="0" pn="section-4.5.1-1">The RBPDV probability distribution
function (PDF) is specified to
be of some mathematically describable function that includes some
practical minimum and maximum discrete values suitable for testing. practical minimum and maximum discrete values suitable for testing.
For example, the minimum value, x_min, might be specified as the For example, the minimum value, x_min, might be specified as the
minimum transit time packet and the maximum value, x_max, might be minimum transit time packet, and the maximum value, x_max, might be
defined to be two standard deviations higher than the mean.</t> defined to be two standard deviations higher than the mean.</t>
<t indent="0" pn="section-4.5.1-2">Since we are typically interested i
<t>Since we are typically interested in the distribution relative to n the distribution relative to
the mean delay packet, we define the zero mean PDV sample, z(n), to be the mean delay packet, we define the zero mean PDV sample, z(n), to be
z(n) = x(n) - x_mean, where x(n) is a sample of the RBPDV random z(n) = x(n) - x_mean, where x(n) is a sample of the RBPDV random
variable x and x_mean is the mean of x.</t> variable x and x_mean is the mean of x.</t>
<t indent="0" pn="section-4.5.1-3">We assume here that s(n) is the ori
<t>We assume here that s(n) is the original source time of packet n ginal source time of packet n
and the post-jitter induced emission time, j(n), for packet n is: and the post-jitter induced emission time, j(n), for packet n is:
</t> </t>
<t>j(n) = {[z(n) + x_mean] + s(n)}.</t> <t indent="0" pn="section-4.5.1-4">j(n) = {[z(n) + x_mean] + s(n)}.</t
<t> >
<t indent="0" pn="section-4.5.1-5">
It follows that the separation in the post-jitter time of It follows that the separation in the post-jitter time of
packets n and n+1 is {[s(n+1)-s(n)] - [z(n)-z(n+1)]}. Since packets n and n+1 is {[s(n+1)-s(n)] - [z(n)-z(n+1)]}. Since
the first term is always a positive quantity, we note that the first term is always a positive quantity, we note that
packet reordering at the receiver is possible whenever the packet reordering at the receiver is possible whenever the
second term is greater than the first. Said another way, second term is greater than the first. Said another way,
whenever the difference in possible zero mean PDV sample whenever the difference in possible zero mean PDV sample
delays (i.e., [x_max-x_min]) exceeds the inter-departure delays (i.e., [x_max-x_min]) exceeds the inter-departure
time of any two sent packets, we have the possibility of time of any two sent packets, we have the possibility of
packet re-ordering.</t> packet reordering.</t>
<t indent="0" pn="section-4.5.1-6">There are important use cases in re
<t>There are important use cases in real networks where packets can al networks where packets can
become re-ordered such as in load balancing topologies and during become reordered, such as in load-balancing topologies and during
route changes. However, for the vast majority of cases there is no route changes. However, for the vast majority of cases, there is no
packet re-ordering because most of the time packets follow the same packet reordering because most of the time packets follow the same
path. Due to this, if a packet becomes overly delayed, the packets path. Due to this, if a packet becomes overly delayed, the packets
after it on that flow are also delayed. This is especially true for after it on that flow are also delayed. This is especially true for
mobile wireless links where there are per-flow queues prior to base mobile wireless links where there are per-flow queues prior to base
station scheduling. Owing to this important use case, we define station scheduling. Owing to this important use case, we define
another PDV profile similar to the above, but one that does not allow another PDV profile similar to the above, but one that does not allow
for re-ordering within a flow.</t> for reordering within a flow.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4
<section title="Approximately Random Subject to No-Reordering Bounded PD .5.2">
V <name slugifiedName="name-approximately-random-subjec">Approximately R
(NR-RPVD)"> andom Subject to No-Reordering Bounded PDV (NR-BPDV)</name>
<t indent="0" pn="section-4.5.2-1">No Reordering BPDV, NR-BPDV, is def
<t>No Reordering RPDV, NR-RPVD, is defined similarly to the above with ined similarly to the above with
one important exception. Let serial(n) be defined as the serialization one important exception. Let serial(n) be defined as the serialization
delay of packet n at the lowest bottleneck link rate (or other delay of packet n at the lowest bottleneck link rate (or other
appropriate rate) in a given test. Then we produce all the post-jitter appropriate rate) in a given test. Then we produce all the post-jitter
values for j(n) for n = 1, 2, ... N, where N is the length of the values for j(n) for n = 1, 2, ... N, where N is the length of the
source sequence s to be offset-ed. The exception can be stated as source sequence s to be offset. The exception can be stated as
follows: We revisit all j(n) beginning from index n=2, and if j(n) is follows: We revisit all j(n) beginning from index n=2, and if j(n) is
determined to be less than [j(n-1)+serial(n-1)], we redefine j(n) to determined to be less than [j(n-1)+serial(n-1)], we redefine j(n) to
be equal to [j(n-1)+serial(n-1)] and continue for all remaining n be equal to [j(n-1)+serial(n-1)] and continue for all remaining n
(i.e., n = 3, 4, .. N). This models the case where the packet n is (i.e., n = 3, 4, .. N). This models the case where the packet n is
sent immediately after packet (n-1) at the bottleneck link rate. sent immediately after packet (n-1) at the bottleneck link rate.
Although this is generally the theoretical minimum in that it assumes Although this is generally the theoretical minimum in that it assumes
that no other packets from other flows are in-between packet n and n+1 that no other packets from other flows are in between packet n and n+1
at the bottleneck link, it is a reasonable assumption for per flow at the bottleneck link, it is a reasonable assumption for per-flow
queuing.</t> queuing.</t>
<t indent="0" pn="section-4.5.2-2">We note that this assumption holds
<t>We note that this assumption holds for some important exception for some important exception
cases, such as packets immediately following outliers. There are a cases, such as packets immediately following outliers. There are a
multitude of software controlled elements common on end-to-end multitude of software-controlled elements common on end-to-end
Internet paths (such as firewalls, ALGs and other middleboxes) which Internet paths (such as firewalls, application-layer gateways, and oth
er middleboxes) that
stop processing packets while servicing other functions (e.g., garbage stop processing packets while servicing other functions (e.g., garbage
collection). Often these devices do not drop packets, but rather queue collection). Often these devices do not drop packets, but rather queue
them for later processing and cause many of the outliers. Thus NR-RPVD them for later processing and cause many of the outliers. Thus NR-BPDV
models this particular use case (assuming serial(n+1) is defined models this particular use case (assuming serial(n+1) is defined
appropriately for the device causing the outlier) and thus is believed appropriately for the device causing the outlier) and is believed
to be important for adaptation development for congestion controlled R to be important for adaptation development for congestion-controlled R
TP streams.</t> TP streams.</t>
</section> </section>
<section title="Recommended distribution"> <section numbered="true" toc="include" removeInRFC="false" pn="section-4
<t>Whether Random Bounded PDV or Approximately Random .5.3">
<name slugifiedName="name-recommended-distribution">Recommended Distri
bution</name>
<t indent="0" pn="section-4.5.3-1">Whether Random Bounded PDV or Appro
ximately Random
Subject to No-Reordering Bounded PDV, it is recommended that Subject to No-Reordering Bounded PDV, it is recommended that
z(n) is distributed according to a truncated Gaussian for z(n) is distributed according to a truncated Gaussian for
the above jitter models:</t> the above jitter models:</t>
<t>z(n) ~ |max(min(N(0, std^2), N_STD * std), -N_STD * std)|</t> <t indent="0" pn="section-4.5.3-2">z(n) ~ |max(min(N(0, std<sup>2</sup
<t>where N(0, std^2) is the Gaussian distribution with zero mean and >), N_STD * std), -N_STD * std)|</t>
standard deviation std. Recommended values:</t> <t indent="0" pn="section-4.5.3-3">where N(0, std<sup>2</sup>) is the
<t><list style="symbols"> Gaussian distribution with zero mean and
<t>std = 5 ms</t> std is standard deviation. Recommended values:</t>
<t>N_STD = 3</t> <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-
</list></t> 4.5.3-4">
<li pn="section-4.5.3-4.1">std = 5 ms</li>
<li pn="section-4.5.3-4.2">N_STD = 3</li>
</ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="app-additional" numbered="true" toc="include" removeInRFC="
<!-- false" pn="section-5">
<section title="WiFi or Cellular Links"> <name slugifiedName="name-traffic-models">Traffic Models</name>
<t> <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1
<xref target="I-D.ietf-rmcat-wireless-tests" /> describes the test ">
cases to simulate networks with wireless links. The document <name slugifiedName="name-tcp-traffic-model">TCP Traffic Model</name>
describes mechanism to simulate both cellular and WiFi networks. <t indent="0" pn="section-5.1-1">Long-lived TCP flows will download data
</t> throughout the
</section>
-->
<section anchor="app-additional" title="Traffic Models">
<section title="TCP traffic model">
<t>Long-lived TCP flows will download data throughout the
session and are expected to have infinite amount of data to session and are expected to have infinite amount of data to
send or receive. This roughly applies, for example, when send or receive. This roughly applies, for example, when
downloading software distributions.</t> downloading software distributions.</t>
<t indent="0" pn="section-5.1-2">Each short TCP flow is modeled as a seq
<t>Each short TCP flow is modeled as a sequence of file downloads uence of file downloads
interleaved with idle periods. Not all short TCP flows start at the sam e interleaved with idle periods. Not all short TCP flows start at the sam e
time, i.e., some start in the ON state while others start in the OFF time, i.e., some start in the ON state while others start in the OFF
state.</t> state.</t>
<t indent="0" pn="section-5.1-3">The short TCP flows can be modeled as f
<t>The short TCP flows can be modeled as follows: 30 ollows: 30
connections start simultaneously fetching small (30-50 KB) connections start simultaneously fetching small (30-50 KB)
amounts of data, evenly distributed. This covers the case amounts of data, evenly distributed. This covers the case
where the short TCP flows are fetching web page resources rather where the short TCP flows are fetching web page resources rather
than video files.</t> than video files.</t>
<t indent="0" pn="section-5.1-4">The idle period between bursts of start
<t>The idle period between bursts of starting a group of TCP flows is ing a group of TCP flows is
typically derived from an exponential distribution with the mean value o f typically derived from an exponential distribution with the mean value o f
10 seconds.</t> 10 seconds.</t>
<aside pn="section-5.1-5">
<t>[These values were picked based on the data available at <t indent="0" pn="section-5.1-5.1">These values were picked based on t
http://httparchive.org/interesting.php as of October 2015].</t> he data available at
<eref target="https://httparchive.org/reports/state-of-the-web?start=2015
<t> _10_01&amp;end=2015_11_01&amp;view=list" brackets="angle"/>
as of October 2015.</t>
</aside>
<t indent="0" pn="section-5.1-6">
Many different TCP congestion control schemes are deployed Many different TCP congestion control schemes are deployed
today. Therefore, experimentation with a range of different today. Therefore, experimentation with a range of different
schemes, especially including CUBIC, is encouraged. schemes, especially including CUBIC <xref target="RFC8312" format="defa ult" sectionFormat="of" derivedContent="RFC8312"/>, is encouraged.
Experiments must document in detail which congestion control Experiments must document in detail which congestion control
schemes they tested against and which parameters were used. schemes they tested against and which parameters were used.
</t> </t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.2
<section title="RTP Video model"> ">
<t> <name slugifiedName="name-rtp-video-model">RTP Video Model</name>
<xref target="RFC8593"/> <t indent="0" pn="section-5.2-1">
<xref target="RFC8593" format="default" sectionFormat="of" derivedCont
ent="RFC8593"/>
describes two describes two
types of video traffic models for evaluating candidate algorithms for RTP congestion control. types of video traffic models for evaluating candidate algorithms for RTP congestion control.
The first model statistically characterizes the behavior of a video The first model statistically characterizes the behavior of a video
encoder, whereas the second model uses video traces. encoder, whereas the second model uses video traces.
</t> </t>
<t> <t indent="0" pn="section-5.2-2">
Sample video test sequences are available at <xref Sample video test sequences are available at <xref target="xiph-seq" fo
target="xiph-seq"></xref>. The following two video streams rmat="default" sectionFormat="of" derivedContent="xiph-seq"/>. The following tw
o video streams
are the recommended minimum for testing: Foreman (CIF are the recommended minimum for testing: Foreman (CIF
sequence) and FourPeople (720p); both come as raw video data sequence) and FourPeople (720p); both come as raw video data
to be encoded dynamically. As these video sequences are to be encoded dynamically. As these video sequences are
short (300 and 600 frames, respectively, they shall be short (300 and 600 frames, respectively), they shall be
stitched together repeatedly until the desired length is stitched together repeatedly until the desired length is
reached. reached.
</t> </t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.3
<section title="Background UDP"> ">
<t>Background UDP flow is modeled as a constant <name slugifiedName="name-background-udp">Background UDP</name>
<t indent="0" pn="section-5.3-1">Background UDP flow is modeled as a con
stant
bit rate (CBR) flow. It will download data at a particular CBR bit rate (CBR) flow. It will download data at a particular CBR
rate for the complete session, or will change to particular for the complete session, or will change to particular
CBR rate at predefined intervals. The inter packet interval is CBR at predefined intervals. The inter-packet interval is
calculated based on the CBR and the packet size (is typically calculated based on the CBR and the packet size (typically
set to the path MTU size, the default value can be 1500 bytes). set to the path MTU size, the default value can be 1500 bytes).
</t> </t>
<t indent="0" pn="section-5.3-2">Note that new transport protocols such
<t>Note that new transport protocols such as QUIC may use UDP as QUIC may use UDP;
but, due to their congestion control algorithms, will exhibit however, due to their congestion control algorithms, they will exhibit
behavior conceptually similar in nature to TCP flows above and behavior conceptually similar in nature to TCP flows above and
can thus be subsumed by the above, including the division into can thus be subsumed by the above, including the division into
short- and long-lived flows. As QUIC evolves independently of short-lived and long-lived flows. As QUIC evolves independently of
TCP congestion control algorithms, its future congestion TCP congestion control algorithms, its future congestion
control should be considered as competing traffic as appropriate. control should be considered as competing traffic as appropriate.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6">
<section title="Security Considerations"> <name slugifiedName="name-security-considerations">Security Considerations
<t> </name>
<t indent="0" pn="section-6-1">
This document specifies evaluation criteria and parameters This document specifies evaluation criteria and parameters
for assessing and comparing the performance of congestion for assessing and comparing the performance of congestion
control protocols and algorithms for real-time control protocols and algorithms for real-time
communication. This memo itself is thus not subject to communication. This memo itself is thus not subject to
security considerations but the protocols and algorithms security considerations but the protocols and algorithms
evaluated may be. In particular, successful operation evaluated may be. In particular, successful operation
under all tests defined in this document may suffice for a under all tests defined in this document may suffice for a
comparative evaluation but must not be interpreted that comparative evaluation but must not be interpreted that
the protocol is free of risks when deployed on the the protocol is free of risks when deployed on the
Internet as briefly described in the following by example. Internet as briefly described in the following by example.
</t> </t>
<t> <t indent="0" pn="section-6-2">
Such evaluations are expected to be Such evaluations are expected to be
carried out in controlled environments for limited numbers carried out in controlled environments for limited numbers
of parallel flows. As such, these evaluations are by of parallel flows. As such, these evaluations are by
definition limited and will not be able to systematically definition limited and will not be able to systematically
consider possible interactions or very large groups of consider possible interactions or very large groups of
communicating nodes under all possible circumstances, so communicating nodes under all possible circumstances, so
that careful protocol design is advised to avoid that careful protocol design is advised to avoid
incidentally contributing traffic that could lead to incidentally contributing traffic that could lead to
unstable networks, e.g., (local) congestion collapse. unstable networks, e.g., (local) congestion collapse.
</t> </t>
<t> <t indent="0" pn="section-6-3">
This specification focuses on assessing the regular This specification focuses on assessing the regular
operation of the protocols and algorithms under operation of the protocols and algorithms under
considerations. It does not suggest checks against consideration. It does not suggest checks against
malicious use of the protocols -- by the sender, the malicious use of the protocols -- by the sender, the
receiver, or intermediate parties, e.g., through faked, receiver, or intermediate parties, e.g., through faked,
dropped, replicated, or modified congestion signals. It is dropped, replicated, or modified congestion signals. It is
up to the protocol specifications themselves to ensure that up to the protocol specifications themselves to ensure that
authenticity, integrity, and/or plausibility of received authenticity, integrity, and/or plausibility of received
signals are checked and the appropriate actions (or signals are checked, and the appropriate actions (or
non-actions) are taken. non-actions) are taken.
</t> </t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
<section title="IANA Considerations"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>There are no IANA impacts in this memo.</t> <t indent="0" pn="section-7-1">This document has no IANA actions.</t>
</section> </section>
</middle>
<section anchor="contrib" title="Contributors"> <back>
<t>The content and concepts within this document are a product of <displayreference target="I-D.ietf-netvc-testing" to="netvc-testing"/>
<references pn="section-8">
<name slugifiedName="name-references">References</name>
<references pn="section-8.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3
550" quoteTitle="true" derivedAnchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Frederick" fullname="R. Frederick">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="July"/>
<abstract>
<t indent="0">This memorandum describes RTP, the real-time transpo
rt protocol. RTP provides end-to-end network transport functions suitable for a
pplications transmitting real-time data, such as audio, video or simulation data
, over multicast or unicast network services. RTP does not address resource res
ervation and does not guarantee quality-of- service for real-time services. The
data transport is augmented by a control protocol (RTCP) to allow monitoring of
the data delivery in a manner scalable to large multicast networks, and to prov
ide minimal control and identification functionality. RTP and RTCP are designed
to be independent of the underlying transport and network layers. The protocol
supports the use of RTP-level translators and mixers. Most of the text in this
memorandum is identical to RFC 1889 which it obsoletes. There are no changes in
the packet formats on the wire, only changes to the rules and algorithms govern
ing how the protocol is used. The biggest change is an enhancement to the scalab
le timer algorithm for calculating when to send RTCP packets in order to minimiz
e transmission in excess of the intended rate when many participants join a sess
ion simultaneously. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<reference anchor="RFC3551" target="https://www.rfc-editor.org/info/rfc3
551" quoteTitle="true" derivedAnchor="RFC3551">
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal Cont
rol</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="July"/>
<abstract>
<t indent="0">This document describes a profile called "RTP/AVP" f
or the use of the real-time transport protocol (RTP), version 2, and the associa
ted control protocol, RTCP, within audio and video multiparticipant conferences
with minimal control. It provides interpretations of generic fields within the
RTP specification suitable for audio and video conferences. In particular, this
document defines a set of default mappings from payload type numbers to encodin
gs. This document also describes how audio and video data may be carried within
RTP. It defines a set of standard encodings and their names when used within RT
P. The descriptions provide pointers to reference implementations and the detai
led standards. This document is meant as an aid for implementors of audio, vide
o and other real-time multimedia applications. This memorandum obsoletes RFC 189
0. It is mostly backwards-compatible except for functions removed because two i
nteroperable implementations were not found. The additions to RFC 1890 codify e
xisting practice in the use of payload formats under this profile and include ne
w payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="65"/>
<seriesInfo name="RFC" value="3551"/>
<seriesInfo name="DOI" value="10.17487/RFC3551"/>
</reference>
<reference anchor="RFC3611" target="https://www.rfc-editor.org/info/rfc3
611" quoteTitle="true" derivedAnchor="RFC3611">
<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<author initials="T." surname="Friedman" fullname="T. Friedman" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Caceres" fullname="R. Caceres" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Clark" fullname="A. Clark" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="November"/>
<abstract>
<t indent="0">This document defines the Extended Report (XR) packe
t type for the RTP Control Protocol (RTCP), and defines how the use of XR packet
s can be signaled by an application if it employs the Session Description Protoc
ol (SDP). XR packets are composed of report blocks, and seven block types are d
efined here. The purpose of the extended reporting format is to convey informat
ion 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 applic
ations, such as multicast inference of network characteristics (MINC) or voice o
ver IP (VoIP) monitoring, require other and more detailed statistics. In additi
on 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>
<seriesInfo name="RFC" value="3611"/>
<seriesInfo name="DOI" value="10.17487/RFC3611"/>
</reference>
<reference anchor="RFC4585" target="https://www.rfc-editor.org/info/rfc4
585" quoteTitle="true" derivedAnchor="RFC4585">
<front>
<title>Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)</title>
<author initials="J." surname="Ott" fullname="J. Ott">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Wenger" fullname="S. Wenger">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Sato" fullname="N. Sato">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Burmeister" fullname="C. Burmeister">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Rey" fullname="J. Rey">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="July"/>
<abstract>
<t indent="0">Real-time media streams that use RTP are, to some de
gree, resilient against packet losses. Receivers may use the base mechanisms of
the Real-time Transport Control Protocol (RTCP) to report packet reception stat
istics and thus allow a sender to adapt its transmission behavior in the mid-ter
m. This is the sole means for feedback and feedback-based error repair (besides
a few codec-specific mechanisms). This document defines an extension to the Au
dio-visual Profile (AVP) that enables receivers to provide, statistically, more
immediate feedback to the senders and thus allows for short-term adaptation and
efficient feedback-based repair mechanisms to be implemented. This early feedba
ck profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves
scalability to large groups. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4585"/>
<seriesInfo name="DOI" value="10.17487/RFC4585"/>
</reference>
<reference anchor="RFC5506" target="https://www.rfc-editor.org/info/rfc5
506" quoteTitle="true" derivedAnchor="RFC5506">
<front>
<title>Support for Reduced-Size Real-Time Transport Control Protocol
(RTCP): Opportunities and Consequences</title>
<author initials="I." surname="Johansson" fullname="I. Johansson">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="April"/>
<abstract>
<t indent="0">This memo discusses benefits and issues that arise w
hen allowing Real-time Transport Protocol (RTCP) packets to be transmitted with
reduced size. The size can be reduced if the rules on how to create compound pa
ckets outlined in RFC 3550 are removed or changed. Based on that analysis, this
memo defines certain changes to the rules to allow feedback messages to be sent
as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (
Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC
4585). This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5506"/>
<seriesInfo name="DOI" value="10.17487/RFC5506"/>
</reference>
<reference anchor="RFC8083" target="https://www.rfc-editor.org/info/rfc8
083" quoteTitle="true" derivedAnchor="RFC8083">
<front>
<title>Multimedia Congestion Control: Circuit Breakers for Unicast R
TP Sessions</title>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Singh" fullname="V. Singh">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="March"/>
<abstract>
<t indent="0">The Real-time Transport Protocol (RTP) is widely use
d in telephony, video conferencing, and telepresence applications. Such applica
tions are often run on best-effort UDP/IP networks. If congestion control is no
t implemented in these applications, then network congestion can lead to uncontr
olled packet loss and a resulting deterioration of the user's multimedia experie
nce. The congestion control algorithm acts as a safety measure by stopping RTP
flows from using excessive resources and protecting the network from overload.
At the time of this writing, however, while there are several proprietary soluti
ons, there is no standard algorithm for congestion control of interactive RTP fl
ows.</t>
<t indent="0">This document does not propose a congestion control
algorithm. It instead defines a minimal set of RTP circuit breakers: conditions
under which an RTP sender needs to stop transmitting media data to protect the
network from excessive congestion. It is expected that, in the absence of long-
lived excessive congestion, RTP applications running on best-effort IP networks
will be able to operate without triggering these circuit breakers. To avoid tri
ggering the RTP circuit breaker, any Standards Track congestion control algorith
ms defined for RTP will need to operate within the envelope set by these RTP cir
cuit breaker algorithms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8083"/>
<seriesInfo name="DOI" value="10.17487/RFC8083"/>
</reference>
<reference anchor="RFC8593" target="https://www.rfc-editor.org/info/rfc8
593" quoteTitle="true" derivedAnchor="RFC8593">
<front>
<title>Video Traffic Models for RTP Congestion Control Evaluations</
title>
<author initials="X." surname="Zhu" fullname="X. Zhu">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Mena" fullname="S. Mena">
<organization showOnFrontPage="true"/>
</author>
<author initials="Z." surname="Sarker" fullname="Z. Sarker">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="May"/>
<abstract>
<t indent="0">This document describes two reference video traffic
models for evaluating RTP congestion control algorithms. The first model statis
tically characterizes the behavior of a live video encoder in response to changi
ng requests on the target video rate. The second model is trace-driven and emul
ates the output of actual encoded video frame sizes from a high-resolution test
sequence. Both models are designed to strike a balance between simplicity, repe
atability, and authenticity in modeling the interactions between a live video tr
affic source and the congestion control module. Finally, the document describes
how both approaches can be combined into a hybrid model.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8593"/>
<seriesInfo name="DOI" value="10.17487/RFC8593"/>
</reference>
<reference anchor="RFC8836" target="https://www.rfc-editor.org/info/rfc8
836" quoteTitle="true" derivedAnchor="RFC8836">
<front>
<title>Congestion Control Requirements for Interactive Real-Time Med
ia</title>
<author initials="R" surname="Jesup" fullname="Randell Jesup">
<organization showOnFrontPage="true"/>
</author>
<author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker"
role="editor">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8836"/>
<seriesInfo name="DOI" value="10.17487/RFC8836"/>
</reference>
</references>
<references pn="section-8.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="gilbert-elliott" target="https://ieeexplore.ieee.org/
document/5755057" quoteTitle="true" derivedAnchor="gilbert-elliott">
<front>
<title>The Gilbert-Elliott Model for Packet Loss in Real Time Servic
es on the Internet</title>
<author surname="Hasslinger" fullname="Gerhard Hasslinger">
<organization showOnFrontPage="true"/>
</author>
<author surname="Hohlfeld" fullname="Oliver Hohlfeld">
<organization showOnFrontPage="true"/>
</author>
<date month="3" year="2008"/>
<abstract>
<t indent="0">The estimation of quality for real-time services ove
r telecommunication networks requires realistic models for impairments and failu
res during transmission. We focus on the classical Gilbert-Elliott model whose s
econd order statistics is derived over arbitrary time scales and used to fit pac
ket loss processes of traffic traces measured in the IP back- bone of Deutsche T
elekom. The results show that simple Markov models are appropriate to capture th
e observed loss pattern.
</t>
</abstract>
</front>
<refcontent>14th GI/ITG Conference - Measurement, Modelling and Evalut
ation [sic] of Computer and Communication Systems</refcontent>
</reference>
<reference anchor="I-D.ietf-netvc-testing" quoteTitle="true" target="htt
ps://tools.ietf.org/html/draft-ietf-netvc-testing-09" derivedAnchor="netvc-testi
ng">
<front>
<title>Video Codec Testing and Quality Measurement</title>
<author initials="T" surname="Daede" fullname="Thomas Daede">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Norkin" fullname="Andrey Norkin">
<organization showOnFrontPage="true"/>
</author>
<author initials="I" surname="Brailovskiy" fullname="Ilya Brailovski
y">
<organization showOnFrontPage="true"/>
</author>
<date month="January" day="31" year="2020"/>
<abstract>
<t indent="0">This document describes guidelines and procedures fo
r evaluating a video codec. This covers subjective and objective tests, test co
nditions, and materials used for the test.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netvc-testing-09"/
>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
etf-netvc-testing-09.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC5033" target="https://www.rfc-editor.org/info/rfc5
033" quoteTitle="true" derivedAnchor="RFC5033">
<front>
<title>Specifying New Congestion Control Algorithms</title>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="August"/>
<abstract>
<t indent="0">The IETF's standard congestion control schemes have
been widely shown to be inadequate for various environments (e.g., high-speed ne
tworks). Recent research has yielded many alternate congestion control schemes
that significantly differ from the IETF's congestion control principles. Using
these new congestion control schemes in the global Internet has possible ramific
ations to both the traffic using the new congestion control and to traffic using
the currently standardized congestion control. Therefore, the IETF must procee
d with caution when dealing with alternate congestion control proposals. The go
al of this document is to provide guidance for considering alternate congestion
control algorithms within the IETF. This document specifies an Internet Best Cu
rrent Practices for the Internet Community, and requests discussion and suggesti
ons for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="133"/>
<seriesInfo name="RFC" value="5033"/>
<seriesInfo name="DOI" value="10.17487/RFC5033"/>
</reference>
<reference anchor="RFC5166" target="https://www.rfc-editor.org/info/rfc5
166" quoteTitle="true" derivedAnchor="RFC5166">
<front>
<title>Metrics for the Evaluation of Congestion Control Mechanisms</
title>
<author initials="S." surname="Floyd" fullname="S. Floyd" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="March"/>
<abstract>
<t indent="0">This document discusses the metrics to be considered
in an evaluation of new or modified congestion control mechanisms for the Inter
net. These include metrics for the evaluation of new transport protocols, of pr
oposed modifications to TCP, of application-level congestion control, and of Act
ive Queue Management (AQM) mechanisms in the router. This document is the first
in a series of documents aimed at improving the models that we use in the evalu
ation of transport protocols.</t>
<t indent="0">This document is a product of the Transport Modeling
Research Group (TMRG), and has received detailed feedback from many members of
the Research Group (RG). As the document tries to make clear, there is not nece
ssarily a consensus within the research community (or the IETF community, the ve
ndor community, the operations community, or any other community) about the metr
ics that congestion control mechanisms should be designed to optimize, in terms
of trade-offs between throughput and delay, fairness between competing flows, an
d the like. However, we believe that there is a clear consensus that congestion
control mechanisms should be evaluated in terms of trade-offs between a range o
f metrics, rather than in terms of optimizing for a single metric. This memo pr
ovides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5166"/>
<seriesInfo name="DOI" value="10.17487/RFC5166"/>
</reference>
<reference anchor="RFC8312" target="https://www.rfc-editor.org/info/rfc8
312" quoteTitle="true" derivedAnchor="RFC8312">
<front>
<title>CUBIC for Fast Long-Distance Networks</title>
<author initials="I." surname="Rhee" fullname="I. Rhee">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Xu" fullname="L. Xu">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Ha" fullname="S. Ha">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Zimmermann" fullname="A. Zimmermann">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Scheffenegger" fullname="R. Scheffene
gger">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="February"/>
<abstract>
<t indent="0">CUBIC is an extension to the current TCP standards.
It differs from the current TCP standards only in the congestion control algori
thm on the sender side. In particular, it uses a cubic function instead of a li
near window increase function of the current TCP standards to improve scalabilit
y and stability under fast and long-distance networks. CUBIC and its predecesso
r algorithm have been adopted as defaults by Linux and have been used for many y
ears. This document provides a specification of CUBIC to enable third-party imp
lementations and to solicit community feedback through experimentation on the pe
rformance of CUBIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8312"/>
<seriesInfo name="DOI" value="10.17487/RFC8312"/>
</reference>
<reference anchor="RFC8867" target="https://www.rfc-editor.org/info/rfc8
867" quoteTitle="true" derivedAnchor="RFC8867">
<front>
<title>Test Cases for Evaluating Congestion Control for Interactive
Real-Time Media</title>
<author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="V" surname="Singh" fullname="Varun Singh">
<organization showOnFrontPage="true"/>
</author>
<author initials="X" surname="Zhu" fullname="Xiaoqing Zhu">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Ramalho" fullname="Michael A. Ramalho"
>
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8867"/>
<seriesInfo name="DOI" value="10.17487/RFC8867"/>
</reference>
<reference anchor="RFC8869" target="https://www.rfc-editor.org/info/rfc8
869" quoteTitle="true" derivedAnchor="RFC8869">
<front>
<title>Evaluation Test Cases for Interactive Real-Time Media over Wi
reless Networks</title>
<author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="X" surname="Zhu" fullname="Xiaoqing Zhu">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Fu" fullname="Jiantao Fu">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8869"/>
<seriesInfo name="DOI" value="10.17487/RFC8869"/>
</reference>
<reference anchor="tcpdump" target="https://www.tcpdump.org/index.html"
quoteTitle="true" derivedAnchor="tcpdump">
<front>
<title>Homepage of tcpdump and libpcap</title>
<author>
<organization showOnFrontPage="true"/>
</author>
</front>
</reference>
<reference anchor="wireshark" target="https://www.wireshark.org" quoteTi
tle="true" derivedAnchor="wireshark">
<front>
<title>Homepage of Wireshark</title>
<author>
<organization showOnFrontPage="true"/>
</author>
</front>
</reference>
<reference anchor="xiph-seq" target="https://media.xiph.org/video/derf/"
quoteTitle="true" derivedAnchor="xiph-seq">
<front>
<title>Video Test Media Set</title>
<author fullname="Daede, T." initials="T." surname="Daede"/>
</front>
</reference>
</references>
</references>
<section anchor="contrib" numbered="false" toc="include" removeInRFC="false"
pn="section-appendix.a">
<name slugifiedName="name-contributors">Contributors</name>
<t indent="0" pn="section-appendix.a-1">The content and concepts within th
is document are a product of
the discussion carried out in the Design Team.</t> the discussion carried out in the Design Team.</t>
<t indent="0" pn="section-appendix.a-2"><contact fullname="Michael Ramalho
<t>Michael Ramalho provided the text for the Jitter model.</t> "/> provided the text for the jitter models (<xref target="JM" format="default"
</section> sectionFormat="of" derivedContent="Section 4.5"/>).</t>
</section>
<section title="Acknowledgments"> <section numbered="false" toc="include" removeInRFC="false" pn="section-appe
<t> Much of this document is derived from previous work on ndix.b">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.b-1"> Much of this document is derived
from previous work on
congestion control at the IETF.</t> congestion control at the IETF.</t>
<t> The authors would like to thank <t indent="0" pn="section-appendix.b-2"> The authors would like to thank
Harald Alvestrand, <contact fullname="Harald Alvestrand"/>,
Anna Brunstrom, <contact fullname="Anna Brunstrom"/>,
Luca De Cicco, <contact fullname="Luca De Cicco"/>,
Wesley Eddy, <contact fullname="Wesley Eddy"/>,
Lars Eggert, <contact fullname="Lars Eggert"/>,
Kevin Gross, <contact fullname="Kevin Gross"/>,
Vinayak Hegde, <contact fullname="Vinayak Hegde"/>,
Randell Jesup, <contact fullname="Randell Jesup"/>,
Mirja Kuehlewind, <contact fullname="Mirja Kühlewind"/>,
Karen Nielsen, <contact fullname="Karen Nielsen"/>,
Piers O'Hanlon, <contact fullname="Piers O'Hanlon"/>,
Colin Perkins, <contact fullname="Colin Perkins"/>,
Michael Ramalho, <contact fullname="Michael Ramalho"/>,
Zaheduzzaman Sarker, <contact fullname="Zaheduzzaman Sarker"/>,
Timothy B. Terriberry, <contact fullname="Timothy B. Terriberry"/>,
Michael Welzl, <contact fullname="Michael Welzl"/>,
Mo Zanaty, and <contact fullname="Mo Zanaty"/>, and
Xiaoqing Zhu <contact fullname="Xiaoqing Zhu"/>
for providing valuable feedback on earlier versions of this draft. for providing valuable feedback on draft versions of this document.
Additionally, also thank the participants of the design team for Additionally, thanks to the participants of the Design Team for
their comments and discussion related to the evaluation their comments and discussion related to the evaluation
criteria.</t> criteria.</t>
</section> </section>
</middle> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
<back> ="include" pn="section-appendix.c">
<references title="Normative References"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<!--&rfc2119;--> <author initials="V." surname="Singh" fullname="Varun Singh">
<!-- RTP related --> <organization abbrev="callstats.io" showOnFrontPage="true">CALLSTATS I/O
&rfc3550; Oy</organization>
&rfc3551; <address>
&rfc3611; <postal>
&rfc4585; <street>Rauhankatu 11 C</street>
&rfc5506; <code>00100</code>
<!--RMCAT related --> <city>Helsinki</city>
&rfc8083; <country>Finland</country>
&rfc8593; </postal>
&I-D.ietf-rmcat-cc-requirements; <email>varun.singh@iki.fi</email>
</references> <uri>https://www.callstats.io/</uri>
</address>
<references title="Informative References"> </author>
&rfc5033; <!-- CC Evaluation --> <author initials="J." surname="Ott" fullname="Jörg Ott">
&rfc5166; <!-- CC Metrics --> <organization showOnFrontPage="true">Technical University of Munich</org
<!-- &rfc5681; Standard TCP --> anization>
&I-D.ietf-rmcat-eval-test; <address>
&I-D.ietf-rmcat-wireless-tests; <postal>
&I-D.ietf-netvc-testing; <extaddr>Department of Informatics</extaddr>
<reference anchor="gilbert-elliott"> <extaddr>Chair of Connected Mobility</extaddr>
<front> <street>Boltzmannstrasse 3</street>
<title>The Gilbert-Elliott Model for Packet Loss in Real Tim <city>Garching</city>
e Services on the Internet</title> <code>85748</code>
<author surname="Hasslinger" fullname="Gerhard Hasslinger"> <country>Germany</country>
<organization/> </postal>
</author> <email>ott@in.tum.de</email>
<author surname="Hohlfeld" fullname="Oliver Hohlfeld"> </address>
<organization /> </author>
</author> <author fullname="Stefan Holmer" initials="S." surname="Holmer">
<date month="3" year="2008" /> <organization abbrev="Google" showOnFrontPage="true">Google</organizatio
<abstract> n>
<t>The estimation of quality for real-time services over tel <address>
ecommunication networks requires realistic models for impairments and failures d <postal>
uring transmission. We focus on the classical Gilbert-Elliott model whose second <street>Kungsbron 2</street>
order statistics is derived over arbitrary time scales and used to fit packet l <code>11122</code>
oss processes of traffic traces measured in the IP back- bone of Deutsche Teleko <city>Stockholm</city>
m. The results show that simple Markov models are appropriate to capture the obs <country>Sweden</country>
erved loss pattern. </postal>
</t></abstract> <email>holmer@google.com</email>
</front> </address>
<seriesInfo name="14th GI/ITG Conference - Measurement, Modellin </author>
g and Evalutation of Computer and Communication Systems" value=""/> </section>
</reference> </back>
<reference anchor="tcpdump">
<front>
<title>Homepage of tcpdump and libpcap</title>
<author>
<organization/>
</author>
<date month="" year="" />
</front>
<seriesInfo name="https://www.tcpdump.org/index.html" value=""/>
</reference>
<reference anchor="wireshark">
<front>
<title>Homepage of Wireshark</title>
<author>
<organization/>
</author>
<date month="" year="" />
</front>
<seriesInfo name="https://www.wireshark.org" value=""/>
</reference>
<!-- <?rfc include="reference.3GPP.R1.081955"?>
<reference anchor="SA4-EVAL">
<front>
<title>LTE Link Level Throughput Data for SA4 Evaluation Fra
mework</title>
<author initials="3GPP" surname="R1-081955" fullname="3GPP R
1-081955">
<organization />
</author>
<date month="5" year="2008" />
<abstract>
<t>In R1-081720, 3GPP SA4 has requested RAN1 and RAN2 for li
nk
level throughput traces to be used in an evaluation framewor
k
they are developing for dynamic video rate adaptation.
</t></abstract>
</front>
<seriesInfo name="3GPP" value="R1-081955" />
<format type='ZIP' octets='3459875' target='http://www.3gpp.net/
ftp/tsg_ran/WG1_RL1/TSGR1_53/Docs/R1-081955.zip' />
</reference>
-->
<!--
<reference anchor="SA4-LR">
<front>
<title>Error Patterns for MBMS Streaming over UTRAN and GERA
N</title>
<author initials="3GPP" surname="S4-050560" fullname="3GPP S
4-050560">
<organization />
</author>
<date month="5" year="2008" />
</front>
<seriesInfo name="3GPP" value="S4-050560" />
<format type='ZIP' octets='335322' target='http://www.3gpp.org/F
TP/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050560.zip' />
</reference>
<!--
<reference anchor="TCP-eval-suite">
<front>
<title>Towards a Common TCP Evaluation Suite</title>
<author initials="A." surname="Lachlan" fullname="Andrew Lachl
an"/>
<author initials="C." surname="Marcondes" fullname="Cesar Marcon
des"/>
<author initials="S." surname="Floyd" fullname="Sally Floyd"/>
<author initials="L." surname="Dunn" fullname="Lawrence Dunn"/>
<author initials="R." surname="Guillier" fullname="Romeric Guil
lier"/>
<author initials="W." surname="Gang" fullname="Wang Gang"/>
<author initials="L." surname="Eggert" fullname="Lars Eggert"/>
<author initials="S." surname="Ha" fullname="Sangtae Ha"/>
<author initials="I." surname="Rhee" fullname="Injong Rhee"/>
<date month="August" year="2008"/>
</front>
<seriesInfo name="Proc. PFLDnet." value="2008"/>
</reference>
<reference anchor="xiph-seq">
<front>
<title>Video Test Media Set</title>
<author fullname="Daede, T." initials="T." surname="Daede"></a
uthor>
<date month="" year="" />
</front>
<seriesInfo name="https://media.xiph.org/video/derf/" value="" /
>
</reference>
<!-- <reference anchor="HEVC-seq">
<front>
<title>Test Sequences</title>
<author fullname="" initials="" surname="HEVC"></author>
<date month="" year="" />
</front>
<seriesInfo name="http://www.netlab.tkk.fi/~varun/test_sequences
/"
value="" />
</reference>
</references>
<!--
<section anchor="misc" title="Application Trade-off">
<t>Application trade-off is yet to be defined. see <xref
target="I-D.ietf-rmcat-cc-requirements">RMCAT requirements</xref>
document. Perhaps each experiment should define the application's
expectation or trade-off.</t>
<section anchor="misc-2" title="Measuring Quality">
<t>No quality metric is defined for performance evaluation, it is
currently an open issue. However, there is consensus that
congestion control algorithm should be able to show that it is
useful for interactive video by performing analysis using a real
codec and video sequences. </t>
</section>
</section>
<section anchor="App-cl" 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-ietf-rmcat-eval-criteria-07">
<t>Updated the draft according to the discussion at IETF-101.</t>
<t><list style="symbols">
<t>Updated the discussion on fairness. Thanks to Xiaoqing Zhu for
providing text.</t>
<t>Fixed a simple loss model and provided pointers to more sophisti
cated ones.</t>
<t>Fixed the choice of the jitter model.</t>
</list></t>
</section>
<section title="Changes in draft-ietf-rmcat-eval-criteria-06">
<t><list style="symbols">
<t>Updated Jitter.</t>
</list></t>
</section>
<section title="Changes in draft-ietf-rmcat-eval-criteria-05">
<t><list style="symbols">
<t>Improved text surrounding wireless tests, video sequences,
and short-TCP model.</t>
</list></t>
</section>
<section title="Changes in draft-ietf-rmcat-eval-criteria-04">
<t><list style="symbols">
<t>Removed the guidelines section, as most of the sections
are now covered: wireless tests, video model, etc.</t>
<t>Improved Short TCP model based on the suggestion to use
httparchive.org.</t>
</list></t>
</section>
<section title="Changes in draft-ietf-rmcat-eval-criteria-03">
<t><list style="symbols">
<t>Keep-alive version.</t>
<t>Moved link parameters and traffic models from eval-test</t>
</list></t>
</section>
<section title="Changes in draft-ietf-rmcat-eval-criteria-02">
<t><list style="symbols">
<t>Incorporated fairness test as a working test.</t>
<t>Updated text on mimimum evaluation requirements.</t>
</list></t>
</section>
<section title="Changes in draft-ietf-rmcat-eval-criteria-01">
<t><list style="symbols">
<t>Removed Appendix B.</t>
<t>Removed Section on Evaluation Parameters.</t>
</list></t>
</section>
<section title="Changes in draft-ietf-rmcat-eval-criteria-00">
<t><list style="symbols">
<t>Updated references.</t>
<t>Resubmitted as WG draft.</t>
</list></t>
</section>
<section title="Changes in draft-singh-rmcat-cc-eval-04">
<t><list style="symbols">
<t>Incorporate feedback from IETF 87, Berlin.</t>
<t>Clarified metrics: convergence time, bandwidth
utilization.</t>
<t>Changed fairness criteria to fairness test.</t>
<t>Added measuring pre- and post-repair loss.</t>
<t>Added open issue of measuring video quality to
appendix.</t>
<t>clarified use of DropTail and AQM.</t>
<t>Updated text in "Minimum Requirements for Evaluation"</t>
</list></t>
</section>
<section title="Changes in draft-singh-rmcat-cc-eval-03">
<t><list style="symbols">
<t>Incorporate the discussion within the design team.</t>
<t>Added a section on evaluation parameters, it describes the
flow and network characteristics.</t>
<t>Added Appendix with self-fairness experiment.</t>
<t>Changed bottleneck parameters from a proposal to an example
set.</t>
<t></t>
</list></t>
</section>
<section title="Changes in draft-singh-rmcat-cc-eval-02">
<t><list style="symbols">
<t>Added scenario descriptions.</t>
</list></t>
</section>
<section title="Changes in draft-singh-rmcat-cc-eval-01">
<t><list style="symbols">
<t>Removed QoE metrics.</t>
<t>Changed stability to steady-state.</t>
<t>Added measuring impact against few and many
flows.</t>
<t>Added guideline for idle and data-limited periods.</t>
<t>Added reference to TCP evaluation suite in example
evaluation scenarios.</t>
</list></t>
</section>
</section>
</back>
</rfc> </rfc>
 End of changes. 89 change blocks. 
983 lines changed or deleted 1252 lines changed or added

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