rfc8867xml2.original.xml   rfc8867.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?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://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe ensus="true" docName="draft-ietf-rmcat-eval-test-10" indexInclude="true" ipr="tr
rence.RFC.2119.xml"> ust200902" number="8867" prepTime="2021-01-18T23:57:30" scripts="Common,Latin" s
<!ENTITY rfc3550 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe ortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="tru
rence.RFC.3550.xml"> e" xml:lang="en">
<!ENTITY rfc3551 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <link href="https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-test-10" re
rence.RFC.3551.xml"> l="prev"/>
<!ENTITY rfc3611 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <link href="https://dx.doi.org/10.17487/rfc8867" rel="alternate"/>
rence.RFC.3611.xml"> <link href="urn:issn:2070-1721" rel="alternate"/>
<!ENTITY rfc4585 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.4585.xml">
<!ENTITY rfc5506 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5506.xml">
<!ENTITY rfc5166 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5166.xml">
<!ENTITY rfc5033 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5033.xml">
<!ENTITY rfc5681 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5681.xml">
<!ENTITY I-D.ietf-rmcat-cc-requirements PUBLIC "" "http://xml2rfc.tools.ietf.org
/public/rfc/bibxml3/reference.I-D.ietf-rmcat-cc-requirements.xml">
<!ENTITY I-D.ietf-avtcore-rtp-circuit-breakers PUBLIC "" "http://xml2rfc.tools.i
etf.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circuit-breakers.xml">
<!ENTITY I-D.ietf-rmcat-eval-criteria PUBLIC "" "http://xml2rfc.tools.ietf.org/p
ublic/rfc/bibxml3/reference.I-D.ietf-rmcat-eval-criteria.xml">
<!ENTITY I-D.ietf-rtcweb-use-cases-and-requirements PUBLIC "" "http://xml2rfc.to
ols.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-use-cases-and-requirem
ents.xml">
<!ENTITY I-D.ietf-rmcat-wireless-tests PUBLIC "" "http://xml2rfc.tools.ietf.org/
public/rfc/bibxml3/reference.I-D.ietf-rmcat-wireless-tests.xml">
<!ENTITY I-D.ietf-rmcat-video-traffic-model PUBLIC "" "http://xml2rfc.tools.ietf
.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-video-traffic-model.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="info" docName="draft-ietf-rmcat-eval-test-10" ipr="trust200902">
<!---->
<front> <front>
<title abbrev="Test Scenarios for RMCAT">Test Cases for Evaluating RMCAT <title abbrev="Test Scenarios for RMCAT">Test Cases for Evaluating Congestio
Proposals</title> n Control for Interactive Real-Time Media</title>
<seriesInfo name="RFC" value="8867" stream="IETF"/>
<author fullname="Zaheduzzaman Sarker" initials="Z" surname="Sarker"> <author fullname="Zaheduzzaman Sarker" initials="Z" surname="Sarker">
<organization>Ericsson AB</organization> <organization showOnFrontPage="true">Ericsson AB</organization>
<address> <address>
<postal> <postal>
<street>Torshamnsgatan 23</street> <street>Torshamnsgatan 23</street>
<city>Stockholm</city> <city>Stockholm</city>
<region>SE</region>
<code>164 83</code> <code>164 83</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<phone>+46 10 717 37 43</phone> <phone>+46 10 717 37 43</phone>
<email>zaheduzzaman.sarker@ericsson.com</email> <email>zaheduzzaman.sarker@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Varun Singh" initials="V" surname="Singh"> <author fullname="Varun Singh" initials="V" surname="Singh">
<organization abbrev="callstats.io">Nemu Dialogue Systems <organization abbrev="callstats.io" showOnFrontPage="true">CALLSTATS I/O O
Oy</organization> y</organization>
<address> <address>
<postal> <postal>
<street>Runeberginkatu 4c A 4</street> <street>Rauhankatu 11 C</street>
<city>Helsinki</city> <city>Helsinki</city>
<code>00100</code> <code>00100</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>varun.singh@iki.fi</email> <email>varun.singh@iki.fi</email>
<uri>http://www.callstats.io/</uri> <uri>http://www.callstats.io/</uri>
</address> </address>
</author> </author>
<author fullname="Xiaoqing Zhu" initials="X" surname="Zhu"> <author fullname="Xiaoqing Zhu" initials="X" surname="Zhu">
<organization>Cisco Systems</organization> <organization showOnFrontPage="true">Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>12515 Research Blvd</street> <street>12515 Research Blvd</street>
<city>Austin</city>
<city>Austing</city>
<region>TX</region> <region>TX</region>
<code>78759</code> <code>78759</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>xiaoqzhu@cisco.com</email> <email>xiaoqzhu@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Michael A. Ramalho" initials="M." surname="Ramalho">
<author fullname="Michael A. Ramalho" initials="M. A." surname="Ramalho"> <organization abbrev="AcousticComms" showOnFrontPage="true">AcousticComms
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization> Consulting</organization>
<address> <address>
<postal> <postal>
<street>6310 Watercrest Way Unit 203</street> <street>6310 Watercrest Way Unit 203</street>
<city>Lakewood Ranch</city> <city>Lakewood Ranch</city>
<region>FL</region> <region>FL</region>
<code>34202-5211</code> <code>34202-5211</code>
<country>USA</country> <country>USA</country>
</postal> </postal>
<phone>+1 732 832 9723</phone>
<phone>+1 919 476 2038</phone> <email>mar42@cornell.edu</email>
<uri>http://ramalho.webhop.info/</uri>
<email>mramalho@cisco.com</email>
</address> </address>
</author> </author>
<date month="01" year="2021"/>
<date day="23" month="May" year="2019"/>
<area>TSV</area> <area>TSV</area>
<keyword>Multimedia</keyword> <keyword>Multimedia</keyword>
<keyword>Test cases</keyword> <keyword>Test cases</keyword>
<keyword>Congestion Control</keyword> <keyword>Congestion Control</keyword>
<abstract pn="section-abstract">
<abstract> <t indent="0" pn="section-abstract-1">The Real-time Transport Protocol (RT
<t>The Real-time Transport Protocol (RTP) is used to transmit media in P) is used to transmit media in
multimedia telephony applications. These applications are typically multimedia telephony applications. These applications are typically
required to implement congestion control. This document describes the required to implement congestion control. This document describes the
test cases to be used in the performance evaluation of such congestion test cases to be used in the performance evaluation of such congestion
control algorithms in a controlled environment.</t> control algorithms in a controlled environment.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<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/rfc8867" 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" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-structure-of-t
est-cases">Structure of Test Cases</xref></t>
</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-recommended-evaluation-sett">Recom
mended Evaluation Settings</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-evaluation-metrics">Ev
aluation Metrics</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-path-characteristics">
Path Characteristics</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-media-source">Media So
urce</xref></t>
</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-basic-test-cases">Basic Test Cases
</xref></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-variable-available-cap
acity">Variable Available Capacity with a Single Flow</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-variable-available-cap
acity-">Variable Available Capacity with Multiple Flows</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-congested-feedback-lin
k-wit">Congested Feedback Link with Bi-directional Media Flows</xref></t>
</li>
<li pn="section-toc.1-1.5.2.4">
<t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent=
"5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-competing-media-flows-
with-">Competing Media Flows with the Same Congestion Control Algorithm</xref></
t>
</li>
<li pn="section-toc.1-1.5.2.5">
<t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent=
"5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-round-trip-time-fairne
ss">Round Trip Time Fairness</xref></t>
</li>
<li pn="section-toc.1-1.5.2.6">
<t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent=
"5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-media-flow-competing-w
ith-a">Media Flow Competing with a Long TCP Flow</xref></t>
</li>
<li pn="section-toc.1-1.5.2.7">
<t indent="0" pn="section-toc.1-1.5.2.7.1"><xref derivedContent=
"5.7" format="counter" sectionFormat="of" target="section-5.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-media-flow-competing-w
ith-s">Media Flow Competing with Short TCP Flows</xref></t>
</li>
<li pn="section-toc.1-1.5.2.8">
<t indent="0" pn="section-toc.1-1.5.2.8.1"><xref derivedContent=
"5.8" format="counter" sectionFormat="of" target="section-5.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-media-pause-and-resume
">Media Pause and Resume</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-other-potential-test-cases">Other
Potential Test Cases</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-media-flows-with-prior
ity">Media Flows with Priority</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-explicit-congestion-no
tific">Explicit Congestion Notification Usage</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3">
<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
"6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-multiple-bottlenecks">
Multiple Bottlenecks</xref></t>
</li>
</ul>
</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-wireless-access-links">Wireless Ac
cess Links</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-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent
="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</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.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<t>This memo describes a set of test cases for evaluating congestion <name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">This memo describes a set of test cases for
evaluating congestion
control algorithm proposals in controlled environments for real-time control algorithm proposals in controlled environments for real-time
interactive media. It is based on the guidelines enumerated in <xref interactive media. It is based on the guidelines enumerated in <xref targe
target="I-D.ietf-rmcat-eval-criteria"/> and the requirements discussed t="RFC8868" format="default" sectionFormat="of" derivedContent="RFC8868"/> and t
in <xref target="I-D.ietf-rmcat-cc-requirements"/>. The test cases cover he requirements discussed
in <xref target="RFC8836" format="default" sectionFormat="of" derivedConte
nt="RFC8836"/>. The test cases cover
basic usage scenarios and are described using a common structure, which basic usage scenarios and are described using a common structure, which
allows for additional test cases to be added to those described herein allows for additional test cases to be added to those described herein
to accommodate other topologies and/or the modelling of different path to accommodate other topologies and/or the modeling of different path
characteristics. The described test cases in this memo should be used to characteristics. The described test cases in this memo should be used to
evaluate any proposed congestion control algorithm for real-time evaluate any proposed congestion control algorithm for real-time
interactive media.</t> interactive media.</t>
</section> </section>
<section anchor="sec-terminology" numbered="true" toc="include" removeInRFC=
<section anchor="sec-terminology" title="Terminology"> "false" pn="section-2">
<!--The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", <name slugifiedName="name-terminology">Terminology</name>
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and <t indent="0" pn="section-2-1">The terminology defined in <xref target="RF
"OPTIONAL" in this document are to be interpreted as described C3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTP</xref>,
in BCP 14, <xref target="RFC2119" /> and indicate requirement <xref target="RFC3551" format="default" sectionFormat="of" derivedContent=
levels for compliant implementations.--> "RFC3551">RTP Profile for Audio and Video Conferences with
Minimal Control</xref>, <xref target="RFC3611" format="default" sectionFor
<t>The terminology defined in <xref target="RFC3550">RTP</xref>, <xref mat="of" derivedContent="RFC3611">RTCP Extended Report
target="RFC3551">RTP Profile for Audio and Video Conferences with (XR)</xref>, <xref target="RFC4585" format="default" sectionFormat="of" de
Minimal Control</xref>, <xref target="RFC3611">RTCP Extended Report rivedContent="RFC4585">Extended RTP Profile for RTCP-based
(XR)</xref>, <xref target="RFC4585">Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)</xref>, and <xref target="RFC5506" format="default" se
Feedback (RTP/AVPF)</xref>, and <xref target="RFC5506">Support for ctionFormat="of" derivedContent="RFC5506">Support for
Reduced-Size RTCP</xref> apply.</t> Reduced-Size RTCP</xref> applies.</t>
</section> </section>
<section anchor="TS" numbered="true" toc="include" removeInRFC="false" pn="s
<section anchor="TS" title="Structure of Test cases"> ection-3">
<t>All the test cases in this document follow a basic structure allowing <name slugifiedName="name-structure-of-test-cases">Structure of Test Cases
</name>
<t indent="0" pn="section-3-1">All the test cases in this document follow
a basic structure allowing
implementers to describe a new test scenario without repeatedly implementers to describe a new test scenario without repeatedly
explaining common attributes. The structure includes a general explaining common attributes. The structure includes a general
description section that describes the test case and its motivation. description section that describes the test case and its motivation.
Additionally the test case defines a set of attributes that characterize Additionally the test case defines a set of attributes that characterize
the testbed, for example, the network path between communicating peers the testbed, for example, the network path between communicating peers
and the diverse traffic sources.</t> and the diverse traffic sources.</t>
<dl spacing="normal" indent="3" newline="false" pn="section-3-2">
<t><list style="symbols"> <dt pn="section-3-2.1">Define the test case:</dt>
<t>Define the test case: <list style="symbols"> <dd pn="section-3-2.2">
<t>General description: describes the motivation and the goals <t indent="0" pn="section-3-2.2.1"><br/></t>
of the test case.</t> <dl spacing="normal" indent="3" newline="false" pn="section-3-2.2.2">
<dt pn="section-3-2.2.2.1">General description:</dt>
<t>Expected behavior: describes the desired rate adaptation <dd pn="section-3-2.2.2.2">describes the motivation and the goals
behavior.</t> of the test case.</dd>
<dt pn="section-3-2.2.2.3">Expected behavior:</dt>
<t>Define a list of metrics to evaluate the desired behavior: <dd pn="section-3-2.2.2.4">describes the desired rate adaptation
behavior.</dd>
<dt pn="section-3-2.2.2.5">List of metrics to evaluate the desired b
ehavior:</dt>
<dd pn="section-3-2.2.2.6">
this indicates the minimum set of metrics (e.g., link this indicates the minimum set of metrics (e.g., link
utilization, media sending rate) that a proposed algorithm needs utilization, media sending rate) that a proposed algorithm needs
to measure to validate the expected rate adaptation behavior. It to measure to validate the expected rate adaptation behavior. It
should also indicate the time granularity (e.g., averaged over should also indicate the time granularity (e.g., averaged over
10ms, 100ms, or 1s) for measuring certain metrics. Typical 10 ms, 100 ms, or 1 s) for measuring certain metrics. Typical
measurement interval is 200ms.</t> measurement interval is 200 ms.</dd>
</dl>
<!-- we agreed this should be 200ms or was it based on some IPPM d </dd>
oc? --> <dt pn="section-3-2.3">Define testbed topology:</dt>
</list></t> <dd pn="section-3-2.4">
<t indent="0" pn="section-3-2.4.1"><br/></t>
<t>Define testbed topology: every test case needs to define an <t indent="0" pn="section-3-2.4.2">Every test case needs to define an
evaluation testbed topology. <xref target="fig-eval-topo"/> shows evaluation testbed topology. <xref target="fig-eval-topo" format="defa
ult" sectionFormat="of" derivedContent="Figure 1"/> shows
such an evaluation topology. In this evaluation topology, S1..Sn are such an evaluation topology. In this evaluation topology, S1..Sn are
traffic sources. These sources generate media traffic and use the traffic sources. These sources generate media traffic and use the
congestion control algorithm(s) under investigation. R1..Rn are the congestion control algorithm(s) under investigation. R1..Rn are the
corresponding receivers. A test case can have one or more such corresponding receivers. A test case can have one or more such
traffic sources (S) and their corresponding receivers (R). The path traffic sources (S) and their corresponding receivers (R). The path
from the source to destination is denoted as "forward" and the path from the source to destination is denoted as "forward", and the path
from a destination to a source is denoted as "backward". The from a destination to a source is denoted as "backward". The
following basic structure of the test case has been described from following basic structure of the test case has been described from
the perspective of media generating endpoints attached on the the perspective of media-generating endpoints attached on the
left-hand side of <xref target="fig-eval-topo"/>. In this setup, the left-hand side of <xref target="fig-eval-topo" format="default" sectio
media flows are transported in forward direction and corresponding nFormat="of" derivedContent="Figure 1"/>. In this setup, the
media flows are transported in the forward direction, and the correspo
nding
feedback/control messages are transported in the backward direction. feedback/control messages are transported in the backward direction.
However, it is also possible to set up the test with media in both However, it is also possible to set up the test with media in both
forward and backward directions. In that case, unless otherwise forward and backward directions. In that case, unless otherwise
specified by the test case, it is expected that the backward path specified by the test case, it is expected that the backward path
does not introduce any congestion related impairments and has enough does not introduce any congestion-related impairments and has enough
capacity to accommodate both media and feedback/control messages. It capacity to accommodate both media and feedback/control messages. It
should be noted that depending on the test cases it is possible to should be noted that, depending on the test cases, it is possible to
have different path characteristics in either of the have different path characteristics in either of the
directions.<figure anchor="fig-eval-topo" directions.</t>
title="Example of A Testbed Topology"> <figure anchor="fig-eval-topo" align="left" suppress-title="false" pn=
<artwork><![CDATA[ "figure-1">
+---+ +---+ <name slugifiedName="name-example-of-a-testbed-topolo">Example of a
|S1 |====== \ Forward --> / =======|R1 | Testbed Topology</name>
+---+ \\ // +---+ <artwork name="" type="" align="left" alt="" pn="section-3-2.4.3.1">
\\ // +---+ +---+
+---+ +-----+ +-----+ +---+ |S1 |====== \ Forward --&gt; / =======|R1 |
|S2 |=======| A |------------------------------>| B |=======|R2 | +---+ \\ // +---+
+---+ | |<------------------------------| | +---+ \\ //
+-----+ +-----+ +---+ +-----+ +-----+ +---+
(...) // \\ (...) |S2 |=======| A |---------------------------&gt;| B |=======|R2 |
// <-- Backward \\ +---+ | |&lt;---------------------------| | +---+
+---+ // \\ +---+ +-----+ +-----+
|Sn |====== / \ ======|Rn | (...) // \\ (...)
+---+ +---+ // &lt;-- Backward \\
]]></artwork> +---+ // \\ +---+
</figure>In a testbed environment with real equipments, there may |Sn |====== / \ ======|Rn |
+---+ +---+
</artwork>
</figure>
<t indent="0" pn="section-3-2.4.4">In a testbed environment with real
equipment, there may
exist a significant amount of unwanted traffic on the portions of exist a significant amount of unwanted traffic on the portions of
the network path between the endpoints. Some of this traffic may be the network path between the endpoints. Some of this traffic may be
generated by other processes on the endpoints themselves (e.g., generated by other processes on the endpoints themselves (e.g.,
discovery protocols) or by other endpoints not presently under test. discovery protocols) or by other endpoints not presently under test.
Such unwanted traffic should be removed or avoided to the greatest Such unwanted traffic should be removed or avoided to the greatest
extent possible.</t> extent possible.</t>
</dd>
<t>Define testbed attributes: <list style="symbols"> <dt pn="section-3-2.5">Define testbed attributes:</dt>
<t>Duration: defines the duration of the test in seconds.</t> <dd pn="section-3-2.6">
<t indent="0" pn="section-3-2.6.1"><br/></t>
<t>Path characteristics: defines the end-to-end transport level <dl spacing="normal" indent="3" newline="false" pn="section-3-2.6.2">
<dt pn="section-3-2.6.2.1">Duration:</dt>
<dd pn="section-3-2.6.2.2">defines the duration of the test in secon
ds.</dd>
<dt pn="section-3-2.6.2.3">Path characteristics:</dt>
<dd pn="section-3-2.6.2.4">
<t indent="0" pn="section-3-2.6.2.4.1">defines the end-to-end tran
sport level
path characteristics of the testbed for a particular test case. path characteristics of the testbed for a particular test case.
Two sets of attributes describe the path characteristics, one Two sets of attributes describe the path characteristics, one
for the forward path and the other for the backward path. The for the forward path and the other for the backward path. The
path characteristics for a particular path direction is path characteristics for a particular path direction are
applicable to all the Sources "S" sending traffic on that path. applicable to all the sources "S" sending traffic on that path.
If only one attribute is specified, it is used for both path If only one attribute is specified, it is used for both path
directions, however, unless specified the reverse path has no directions; however, unless specified the reverse path has no
capacity restrictions and no path loss.<list style="symbols"> capacity restrictions and no path loss.</t>
<t>Path direction: forward or backward.</t> <dl spacing="normal" indent="3" newline="false" pn="section-3-2.6.
2.4.2">
<t>Minimum bottleneck-link capacity: defines minimum capacity <dt pn="section-3-2.6.2.4.2.1">Path direction:</dt>
of the <dd pn="section-3-2.6.2.4.2.2">forward or backward.</dd>
end-to-end path</t> <dt pn="section-3-2.6.2.4.2.3">Minimum bottleneck-link capacity:
</dt>
<t>Reference bottleneck capacity: defines a reference value <dd pn="section-3-2.6.2.4.2.4">defines the minimum capacity of t
he
end-to-end path.</dd>
<dt pn="section-3-2.6.2.4.2.5">Reference bottleneck capacity:</d
t>
<dd pn="section-3-2.6.2.4.2.6">defines a reference value
for the bottleneck capacity for test cases with time-varying for the bottleneck capacity for test cases with time-varying
bottleneck capacities. All bottleneck capacities will be bottleneck capacities. All bottleneck capacities will be
specified as a ratio with respect to the reference capacity specified as a ratio with respect to the reference capacity
value.</t> value.</dd>
<dt pn="section-3-2.6.2.4.2.7">One-way propagation delay:</dt>
<t>One-way propagation delay: describes the end-to-end <dd pn="section-3-2.6.2.4.2.8">describes the end-to-end
latency along the path when network queues are empty, i.e., latency along the path when network queues are empty, i.e.,
the time it takes for a packet to go from the sender to the the time it takes for a packet to go from the sender to the
receiver without encountering any queuing delay.</t> receiver without encountering any queuing delay.</dd>
<dt pn="section-3-2.6.2.4.2.9">Maximum end-to-end jitter:</dt>
<t>Maximum end-to-end jitter: defines the maximum jitter <dd pn="section-3-2.6.2.4.2.10">defines the maximum jitter
that can be observed along the path.</t> that can be observed along the path.</dd>
<dt pn="section-3-2.6.2.4.2.11">Bottleneck queue type:</dt>
<t>Bottleneck queue type: for example, "tail drop" <xref <dd pn="section-3-2.6.2.4.2.12">for example, "tail drop" <xref t
target="RFC7567"/>, Flow Queue -CoDel (FQ-CoDel)<xref arget="RFC7567" format="default" sectionFormat="of" derivedContent="RFC7567"/>,
target="RFC8290"/>, or Proportional Integral controller Flow Queue Controlled Delay (FQ-CoDel) <xref target="RFC8290"
Enhanced (PIE)<xref target="RFC8033"/>.</t> format="default" sectionFormat="of" derivedContent="RFC8290"/>,
or Proportional Integral controller Enhanced (PIE)
<t>Bottleneck queue size: defines the size of queue in terms <xref target="RFC8033" format="default" sectionFormat="of" der
ivedContent="RFC8033"/>.</dd>
<dt pn="section-3-2.6.2.4.2.13">Bottleneck queue size:</dt>
<dd pn="section-3-2.6.2.4.2.14">defines the size of queue in ter
ms
of queuing time when the queue is full (in of queuing time when the queue is full (in
milliseconds).</t> milliseconds).</dd>
<dt pn="section-3-2.6.2.4.2.15">Path loss ratio:</dt>
<t>Path loss ratio: characterizes the non-congested, <dd pn="section-3-2.6.2.4.2.16">characterizes the non-congested,
additive, losses to be generated on the end-to-end path. additive losses to be generated on the end-to-end path.
This must describe the loss pattern or loss model used to This must describe the loss pattern or loss model used to
generate the losses.</t> generate the losses.</dd>
</list></t> </dl>
</dd>
<t>Application-related: defines the traffic source behavior for <dt pn="section-3-2.6.2.5">Application-related:</dt>
implementing the test case <list style="symbols"> <dd pn="section-3-2.6.2.6">
<t>Media traffic Source: defines the characteristics of the <t indent="0" pn="section-3-2.6.2.6.1">defines the traffic source
behavior for
implementing the test case:</t>
<dl spacing="normal" indent="3" newline="false" pn="section-3-2.6.
2.6.2">
<dt pn="section-3-2.6.2.6.2.1">Media traffic source:</dt>
<dd pn="section-3-2.6.2.6.2.2">
<t indent="0" pn="section-3-2.6.2.6.2.2.1">defines the charact
eristics of the
media sources. When using more than one media source, the media sources. When using more than one media source, the
different attributes are enumerated separately for each different attributes are enumerated separately for each
different media source. <list style="symbols"> different media source. </t>
<t>Media type: Video/Voice</t> <dl spacing="normal" indent="3" newline="false" pn="section-3-
2.6.2.6.2.2.2">
<t>Media flow direction: forward, backward or both.</t> <dt pn="section-3-2.6.2.6.2.2.2.1">Media type:</dt>
<dd pn="section-3-2.6.2.6.2.2.2.2">Video/Voice.</dd>
<t>Number of media sources: defines the total number of <dt pn="section-3-2.6.2.6.2.2.2.3">Media flow direction:</dt
media sources</t> >
<dd pn="section-3-2.6.2.6.2.2.2.4">forward, backward, or bot
<t>Media codec: Constant Bit Rate (CBR) or Variable Bit h.</dd>
Rate (VBR)</t> <dt pn="section-3-2.6.2.6.2.2.2.5">Number of media sources:<
/dt>
<t>Media source behavior: describes the media encoder <dd pn="section-3-2.6.2.6.2.2.2.6">defines the total number
of
media sources.</dd>
<dt pn="section-3-2.6.2.6.2.2.2.7">Media codec:</dt>
<dd pn="section-3-2.6.2.6.2.2.2.8">Constant Bit Rate (CBR) o
r Variable Bit
Rate (VBR).</dd>
<dt pn="section-3-2.6.2.6.2.2.2.9">Media source behavior:</d
t>
<dd pn="section-3-2.6.2.6.2.2.2.10">
<t indent="0" pn="section-3-2.6.2.6.2.2.2.10.1">describes
the media encoder
behavior. It defines the main parameters that affect the behavior. It defines the main parameters that affect the
adaptation behavior. This may include but is not limited adaptation behavior. This may include but is not limited
to: <list style="symbols"> to the following: </t>
<t>Adaptability: describes the adaptation options. <dl spacing="normal" indent="3" newline="false" pn="sectio
For example, in the case of video it defines the n-3-2.6.2.6.2.2.2.10.2">
<dt pn="section-3-2.6.2.6.2.2.2.10.2.1">Adaptability:</d
t>
<dd pn="section-3-2.6.2.6.2.2.2.10.2.2">describes the ad
aptation options.
For example, in the case of video, it defines the
following ranges of adaptation: bit rate, frame following ranges of adaptation: bit rate, frame
rate, video resolution. Similarly, in the case of rate, and video resolution. Similarly, in the case of
voice, it defines the range of bit rate adaptation, voice, it defines the range of bit rate adaptation,
the sampling rate variation, and the variation in the sampling rate variation, and the variation in
packetization interval.</t> packetization interval.</dd>
<dt pn="section-3-2.6.2.6.2.2.2.10.2.3">Output variation
<t>Output variation : for a VBR encoder it defines :</dt>
<dd pn="section-3-2.6.2.6.2.2.2.10.2.4">for a VBR encode
r, it defines
the encoder output variation from the average target the encoder output variation from the average target
rate over a particular measurement interval. For rate over a particular measurement interval. For
example, on average the encoder output may vary example, on average the encoder output may vary
between 5% to 15% above or below the average target between 5% to 15% above or below the average target
bit rate when measured over a 100 ms time window. bit rate when measured over a 100 ms time window.
The time interval over which the variation is The time interval over which the variation is
specified must be provided.</t> specified must be provided.</dd>
<dt pn="section-3-2.6.2.6.2.2.2.10.2.5">Responsiveness t
<!-- --> o a new bit rate request:</dt>
<dd pn="section-3-2.6.2.6.2.2.2.10.2.6">the lag
<t>Responsiveness to a new bit rate request: the lag
in time between a new bit rate request from the in time between a new bit rate request from the
congestion control algorithm and actual rate changes congestion control algorithm and actual rate changes
in encoder output. Depending on the encoder, this in encoder output. Depending on the encoder, this
value may be specified in absolute time (e.g. 10ms value may be specified in absolute time (e.g., 10 ms
to 1000ms) or other appropriate metric (e.g. next to 1000 ms) or other appropriate metric (e.g., next
frame interval time).</t> frame interval time).</dd>
</list> More detailed discussions on expected media </dl>
<t indent="0" pn="section-3-2.6.2.6.2.2.2.10.3"> More deta
iled discussions on expected media
source behavior, including those from synthetic video source behavior, including those from synthetic video
traffic sources, is at <xref traffic sources, can be found in <xref target="RFC8593" fo
target="I-D.ietf-rmcat-video-traffic-model"/>.</t> rmat="default" sectionFormat="of" derivedContent="RFC8593"/>.</t>
</dd>
<t>Media content: describes the chosen video scenario. <dt pn="section-3-2.6.2.6.2.2.2.11">Media content:</dt>
For example, video test sequences are available at: <dd pn="section-3-2.6.2.6.2.2.2.12">describes the chosen vid
<xref target="xiph-seq"/> and <xref target="HEVC-seq"/>. eo scenario.
Different video scenarios give different distribution of For example, video test sequences are available at
<xref target="xiph-seq" format="default" sectionFormat="of
" derivedContent="xiph-seq"/> and <xref target="HEVC-seq" format="default" secti
onFormat="of" derivedContent="HEVC-seq"/>.
Different video scenarios give different distributions of
video frames produced by the video encoder. Hence, it is video frames produced by the video encoder. Hence, it is
important to specify the media content used in a important to specify the media content used in a
particular test. If a synthetic video traffic souce particular test. If a synthetic video traffic source
<xref target="I-D.ietf-rmcat-video-traffic-model"/> is <xref target="RFC8593" format="default" sectionFormat="of"
derivedContent="RFC8593"/> is
used, then the synthetic video traffic source needs to used, then the synthetic video traffic source needs to
configure according to the characteristics of the media be configured according to the characteristics of the medi
content specified.</t> a
content specified.</dd>
<t>Media timeline: describes the point when the media <dt pn="section-3-2.6.2.6.2.2.2.13">Media timeline:</dt>
<dd pn="section-3-2.6.2.6.2.2.2.14">describes the point when
the media
source is introduced and removed from the testbed. For source is introduced and removed from the testbed. For
example, the media source may start transmitting example, the media source may start transmitting
immediately when the test case begins, or after a few immediately when the test case begins, or after a few
seconds.</t> seconds.</dd>
<dt pn="section-3-2.6.2.6.2.2.2.15">Startup behavior:</dt>
<t>Startup behavior: the media starts at a defined bit <dd pn="section-3-2.6.2.6.2.2.2.16">the media starts at a de
fined bit
rate, which may be the minimum, maximum bit rate, or a rate, which may be the minimum, maximum bit rate, or a
value in between (in Kbps).</t> value in between (in Kbps).</dd>
</list></t> </dl>
</dd>
<t>Competing traffic source: describes the characteristics <dt pn="section-3-2.6.2.6.2.3">Competing traffic source:</dt>
<dd pn="section-3-2.6.2.6.2.4">
<t indent="0" pn="section-3-2.6.2.6.2.4.1">describes the chara
cteristics
of the competing traffic source, the different types of of the competing traffic source, the different types of
competing flows are enumerated in <xref competing flows are enumerated in <xref target="RFC8868" forma
target="I-D.ietf-rmcat-eval-criteria"/>. <list t="default" sectionFormat="of" derivedContent="RFC8868"/>. </t>
style="symbols"> <dl spacing="normal" indent="3" newline="false" pn="section-3-
<t>Traffic direction: forward, backward or both.</t> 2.6.2.6.2.4.2">
<dt pn="section-3-2.6.2.6.2.4.2.1">Traffic direction:</dt>
<t>Type of sources: defines the types of competing <dd pn="section-3-2.6.2.6.2.4.2.2">forward, backward, or bot
h.</dd>
<dt pn="section-3-2.6.2.6.2.4.2.3">Type of sources:</dt>
<dd pn="section-3-2.6.2.6.2.4.2.4">defines the types of comp
eting
traffic sources. Types of competing traffic flows are traffic sources. Types of competing traffic flows are
listed in <xref target="I-D.ietf-rmcat-eval-criteria"/>. listed in <xref target="RFC8868" format="default" sectionF ormat="of" derivedContent="RFC8868"/>.
For example, the number of TCP flows connected to a web For example, the number of TCP flows connected to a web
browser, the mean size and distribution of the content browser, the mean size and distribution of the content
downloaded.</t> downloaded.</dd>
<dt pn="section-3-2.6.2.6.2.4.2.5">Number of sources:</dt>
<t>Number of sources: defines the total number of <dd pn="section-3-2.6.2.6.2.4.2.6">defines the total number
of
competing sources of each media type per traffic competing sources of each media type per traffic
direction.</t> direction.</dd>
<dt pn="section-3-2.6.2.6.2.4.2.7">Congestion control:</dt>
<t>Congestion control: enumerates the congestion control <dd pn="section-3-2.6.2.6.2.4.2.8">enumerates the congestion
used by each type of competing traffic.</t> control
used by each type of competing traffic.</dd>
<t>Traffic timeline: describes when the competing <dt pn="section-3-2.6.2.6.2.4.2.9">Traffic timeline:</dt>
traffic starts and ends in the test case.</t> <dd pn="section-3-2.6.2.6.2.4.2.10">describes when the compe
</list></t> ting
</list></t> traffic starts and ends in the test case.</dd>
</dl>
<t>Additional attributes: describes attributes essential for </dd>
implementing a test case which are not included in the above </dl>
</dd>
<dt pn="section-3-2.6.2.7">Additional attributes:</dt>
<dd pn="section-3-2.6.2.8">describes attributes essential for
implementing a test case that are not included in the above
structure. These attributes must be well defined, so that the structure. These attributes must be well defined, so that the
other implementers of that particular test case are able to other implementers of that particular test case are able to
implement it easily.</t> implement it easily.</dd>
</list></t> </dl>
</list></t> </dd>
</dl>
<t>Any attribute can have a set of values (enclosed within "[]"). Each <t indent="0" pn="section-3-3">Any attribute can have a set of values (enc
losed within "[]"). Each
member value of such a set must be treated as different value for the member value of such a set must be treated as different value for the
same attribute. It is desired to run separate tests for each such same attribute. It is desired to run separate tests for each such
attribute value.</t> attribute value.</t>
<t indent="0" pn="section-3-4">The test cases described in this document f
<t>The test cases described in this document follow the above ollow the above
structure.</t> structure.</t>
</section> </section>
<section anchor="sec-rec-eval" numbered="true" toc="include" removeInRFC="fa
<section anchor="sec-rec-eval" title="Recommended Evaluation Settings"> lse" pn="section-4">
<t>This section describes recommended test case settings and could be <name slugifiedName="name-recommended-evaluation-sett">Recommended Evaluat
ion Settings</name>
<t indent="0" pn="section-4-1">This section describes recommended test cas
e settings and could be
overwritten by the respective test cases.</t> overwritten by the respective test cases.</t>
<section anchor="EM" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="EM" title="Evaluation metrics"> "section-4.1">
<t>To evaluate the performance of the candidate algorithms the <name slugifiedName="name-evaluation-metrics">Evaluation Metrics</name>
<t indent="0" pn="section-4.1-1">To evaluate the performance of the cand
idate algorithms, the
implementers must log enough information to visualize the following implementers must log enough information to visualize the following
metrics at a fine enough time granularity: <list style="numbers"> metrics at a fine enough time granularity: </t>
<t>Flow level: <list style="letters"> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.
<t>End-to-end delay for the congestion controlled media 1-2">
flow(s). For example - end-to-end delay observed on IP packet <li pn="section-4.1-2.1" derivedCounter="1.">
level, video frame level.</t> <t indent="0" pn="section-4.1-2.1.1">Flow level: </t>
<ol spacing="normal" type="A" indent="adaptive" start="1" pn="sectio
<t>Variation in sending bit rate and throughput. Mainly n-4.1-2.1.2">
observing the frequency and magnitude of oscillations.</t> <li pn="section-4.1-2.1.2.1" derivedCounter="A.">End-to-end delay
for the congestion-controlled media
<t>Packet losses observed at the receiving endpoint.</t> flow(s). For example, end-to-end delay observed on the IP packet
level and the video frame level.</li>
<t>Feedback message overhead.</t> <li pn="section-4.1-2.1.2.2" derivedCounter="B.">Variation in send
ing bit rate and throughput. Mainly
<t>Convergence time - time to reach steady state for the observing the frequency and magnitude of oscillations.</li>
congestion controlled media flow(s). Each occurrence of <li pn="section-4.1-2.1.2.3" derivedCounter="C.">Packet losses obs
convergence during the test period need to be presented.</t> erved at the receiving endpoint.</li>
</list></t> <li pn="section-4.1-2.1.2.4" derivedCounter="D.">Feedback message
overhead.</li>
<t>Transport level: <list style="letters"> <li pn="section-4.1-2.1.2.5" derivedCounter="E.">Convergence time.
<t>Bandwidth utilization.</t> Time to reach steady state for the
congestion-controlled media flow(s). Each occurrence of
<t>Queue length (milliseconds at specified path capacity).</t> convergence during the test period needs to be presented.</li>
</list></t> </ol>
</list></t> </li>
<li pn="section-4.1-2.2" derivedCounter="2.">
<t indent="0" pn="section-4.1-2.2.1">Transport level: </t>
<ol spacing="normal" type="A" indent="adaptive" start="1" pn="sectio
n-4.1-2.2.2">
<li pn="section-4.1-2.2.2.1" derivedCounter="A.">Bandwidth utiliza
tion.</li>
<li pn="section-4.1-2.2.2.2" derivedCounter="B.">Queue length (mil
liseconds at specified path capacity).</li>
</ol>
</li>
</ol>
</section> </section>
<section anchor="PC" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="PC" title="Path characteristics"> "section-4.2">
<t>Each path between a sender and receiver as described in <xref <name slugifiedName="name-path-characteristics">Path Characteristics</na
target="fig-eval-topo"/> have the following characteristics unless me>
otherwise specified in the test case. <list style="symbols"> <t indent="0" pn="section-4.2-1">Each path between a sender and receiver
<t>Path direction: forward and backward.</t> as described in
<xref target="fig-eval-topo" format="default" sectionFormat="of" derivedContent=
<t>Reference bottleneck capacity: 1Mbps.</t> "Figure 1"/> has the following characteristics unless
otherwise specified in the test case: </t>
<t>One-Way propagation delay: 50ms. Implementers are encouraged to <dl newline="false" spacing="normal" indent="3" pn="section-4.2-2">
<dt pn="section-4.2-2.1">Path direction: </dt>
<dd pn="section-4.2-2.2">forward and backward.</dd>
<dt pn="section-4.2-2.3">Reference bottleneck capacity: </dt>
<dd pn="section-4.2-2.4">1 Mbps.</dd>
<dt pn="section-4.2-2.5">One-way propagation delay: </dt>
<dd pn="section-4.2-2.6">50 ms. Implementers are encouraged to
run the experiment with additional propagation delays mentioned in run the experiment with additional propagation delays mentioned in
<xref target="I-D.ietf-rmcat-eval-criteria"/></t> <xref target="RFC8868" format="default" sectionFormat="of" derivedCo
ntent="RFC8868"/>.</dd>
<t>Maximum end-to-end jitter: 30ms. Jitter models are described in <dt pn="section-4.2-2.7">Maximum end-to-end jitter: </dt>
<xref target="I-D.ietf-rmcat-eval-criteria"/></t> <dd pn="section-4.2-2.8">30 ms. Jitter models are described in
<xref target="RFC8868" format="default" sectionFormat="of" derivedCo
<t>Bottleneck queue type: "tail drop". Implementers are encouraged ntent="RFC8868"/>.</dd>
to run the experiment with other AQM schemes, such as FQ-CoDel and <dt pn="section-4.2-2.9">Bottleneck queue type: </dt>
PIE.</t> <dd pn="section-4.2-2.10">"tail drop". Implementers are encouraged
to run the experiment with other Active Queue Management (AQM) schem
<t>Bottleneck queue size: 300ms.</t> es, such as FQ-CoDel and
PIE.</dd>
<t>Path loss ratio: 0%.</t> <dt pn="section-4.2-2.11">Bottleneck queue size: </dt>
</list></t> <dd pn="section-4.2-2.12">300 ms.</dd>
<dt pn="section-4.2-2.13">Path loss ratio: </dt>
<t>Examples of additional network parameters are discussed in <xref <dd pn="section-4.2-2.14">0%.</dd>
target="I-D.ietf-rmcat-eval-criteria"/>.</t> </dl>
<t indent="0" pn="section-4.2-3">Examples of additional network paramete
<t>For test cases involving time-varying bottleneck capacity, all rs are discussed in <xref target="RFC8868" format="default" sectionFormat="of" d
erivedContent="RFC8868"/>.</t>
<t indent="0" pn="section-4.2-4">For test cases involving time-varying b
ottleneck capacity, all
capacity values are specified as a ratio with respect to a reference capacity values are specified as a ratio with respect to a reference
capacity value, so as to allow flexible scaling of capacity values capacity value, so as to allow flexible scaling of capacity values
along with media source rate range. There exist two different along with media source rate range. There exist two different
mechanisms for inducing path capacity variation: a) by explicitly mechanisms for inducing path capacity variation: a) by explicitly
modifying the value of physical link capacity; or b) by introducing modifying the value of physical link capacity, or b) by introducing
background non-adaptive UDP traffic with time-varying traffic rate. background non-adaptive UDP traffic with time-varying traffic rate.
Implementers are encouraged to run the experiments with both Implementers are encouraged to run the experiments with both
mechanisms for test cases specified in <xref target="VACS"/>, <xref mechanisms for test cases specified in <xref target="VACS" format="defau
target="VACM"/>, and <xref target="CFL"/>.</t> lt" sectionFormat="of" derivedContent="Section 5.1"/>, <xref target="VACM" forma
t="default" sectionFormat="of" derivedContent="Section 5.2"/>, and <xref target=
"CFL" format="default" sectionFormat="of" derivedContent="Section 5.3"/>.</t>
</section> </section>
<section anchor="MS" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="MS" title="Media source"> "section-4.3">
<t>Unless otherwise specified, each test case will include one or more <name slugifiedName="name-media-source">Media Source</name>
media sources as described below. <list style="symbols"> <t indent="0" pn="section-4.3-1">Unless otherwise specified, each test c
<t>Media type: Video <list style="symbols"> ase will include one or more
<t>Media codec: VBR</t> media sources as described below: </t>
<dl newline="false" spacing="normal" indent="3" pn="section-4.3-2">
<t>Media source behavior: <list style="symbols"> <dt pn="section-4.3-2.1">Media type:</dt>
<t>Adaptability: <list style="symbols"> <dd pn="section-4.3-2.2">
<t>Bit rate range: 150 Kbps - 1.5 Mbps. In real-life <t indent="0" pn="section-4.3-2.2.1">Video</t>
applications the bit rate range can vary a lot <dl newline="false" spacing="normal" indent="3" pn="section-4.3-2.2.
depending on the provided service, for example, the 2">
maximum bit rate can be up to 4Mbps. However, for <dt pn="section-4.3-2.2.2.1">Media codec:</dt>
<dd pn="section-4.3-2.2.2.2">VBR</dd>
<dt pn="section-4.3-2.2.2.3">Media source behavior:</dt>
<dd pn="section-4.3-2.2.2.4">
<t indent="0" pn="section-4.3-2.2.2.4.1"><br/></t>
<dl newline="false" spacing="normal" indent="3" pn="section-4.3-
2.2.2.4.2">
<dt pn="section-4.3-2.2.2.4.2.1">Adaptability:</dt>
<dd pn="section-4.3-2.2.2.4.2.2">
<t indent="0" pn="section-4.3-2.2.2.4.2.2.1"><br/></t>
<dl newline="false" spacing="normal" indent="3" pn="section-
4.3-2.2.2.4.2.2.2">
<dt pn="section-4.3-2.2.2.4.2.2.2.1">Bit rate range:</dt>
<dd pn="section-4.3-2.2.2.4.2.2.2.2">
150 Kbps - 1.5 Mbps. In real-life
applications, the bit rate range can vary a lot
depending on the provided service; for example, the
maximum bit rate can be up to 4 Mbps. However, for
running tests to evaluate the congestion control running tests to evaluate the congestion control
algorithms it is more important to have a look at how algorithms, it is more important to have a look at how
they are reacting to certain amount of bandwidth they react to a certain amount of bandwidth
change. Also it is possible that the media traffic change. Also it is possible that the media traffic
generator used in a particular simulator or testbed is generator used in a particular simulator or testbed is
not capable of generating higher bit rate. Hence we not capable of generating a higher bit rate. Hence, we
have selected a suitable bit rate range typical of have selected a suitable bit rate range typical of
consumer-grade video conferencing applications in consumer-grade video conferencing applications in
designing the test case. If a different bit rate range designing the test case. If a different bit rate range
is used in the test cases, then the end-to-end path is used in the test cases, then the end-to-end path
capacity values will also need to be scaled capacity values will also need to be scaled
accordingly.</t> accordingly.</dd>
<dt pn="section-4.3-2.2.2.4.2.2.2.3">Frame resolution: </d
<t>Frame resolution: 144p - 720p (or 1080p). This t>
<dd pn="section-4.3-2.2.2.4.2.2.2.4">144p - 720p (or 1080p
). This
resolution range is selected based on the bit rate resolution range is selected based on the bit rate
range. If a different bit rate range is used in the range. If a different bit rate range is used in the
test cases then the frame resolution range also need test cases, then a suitable frame resolution range also
to be selected suitably.</t> needs
to be selected.</dd>
<t>Frame rate: 10fps - 30fps. This frame rate range is <dt pn="section-4.3-2.2.2.4.2.2.2.5">Frame rate: </dt>
<dd pn="section-4.3-2.2.2.4.2.2.2.6">10 fps - 30 fps. This
frame rate range is
selected based on the bit rate range. If a different selected based on the bit rate range. If a different
bit rate range is used in the test cases then the bit rate range is used in the test cases, then the
frame rate range also need to be adjusted frame rate range also needs to be suitably adjusted.</dd
suitably.</t> >
</list></t> </dl>
</dd>
<t>Variation from target bit rate: +/-5%. Unless otherwise <dt pn="section-4.3-2.2.2.4.2.3">Variation from target bit rat
e: </dt>
<dd pn="section-4.3-2.2.2.4.2.4">+/-5%. Unless otherwise
specified in the test case(s), bit rate variation should specified in the test case(s), bit rate variation should
be calculated over one (1) second period of time.</t> be calculated over a one (1) second period of time.</dd>
<dt pn="section-4.3-2.2.2.4.2.5">Responsiveness to new bit rat
<t>Responsiveness to new bit rate request: 100ms</t> e request: </dt>
</list></t> <dd pn="section-4.3-2.2.2.4.2.6">100 ms</dd>
</dl>
<t>Media content: The media content should represent a typical </dd>
<dt pn="section-4.3-2.2.2.5">Media content:</dt>
<dd pn="section-4.3-2.2.2.6">The media content should represent a
typical
video conversational scenario with head and shoulder movement. video conversational scenario with head and shoulder movement.
We recommend to use Foreman video sequence<xref We recommend using the Foreman video sequence <xref target="xiph
target="xiph-seq"/>.</t> -seq" format="default" sectionFormat="of" derivedContent="xiph-seq"/>.</dd>
<dt pn="section-4.3-2.2.2.7">Media startup behavior:</dt>
<t>Media startup behavior: 150Kbps. It should be noted that <dd pn="section-4.3-2.2.2.8">150 Kbps. It should be noted that
applications can use smart ways to select an optimal startup applications can use smart ways to select an optimal startup
bit rate value for a certain network condition. In such cases bit rate value for a certain network condition. In such cases,
the candidate proposals may show the effectiveness of such the candidate proposals may show the effectiveness of such a
smart approach as an additional information for the evaluation smart approach as additional information for the evaluation
process.</t> process.</dd>
</list></t> </dl>
</list><list style="symbols"> </dd>
<t>Media type: Audio<list style="symbols"> <dt pn="section-4.3-2.3">Media type:</dt>
<t>Media codec: CBR</t> <dd pn="section-4.3-2.4">
<t indent="0" pn="section-4.3-2.4.1">Audio</t>
<t>Media bit rate: 20Kbps</t> <dl spacing="normal" indent="3" newline="false" pn="section-4.3-2.4.
</list></t> 2">
</list></t> <dt pn="section-4.3-2.4.2.1">Media codec: </dt>
<dd pn="section-4.3-2.4.2.2">CBR</dd>
<dt pn="section-4.3-2.4.2.3">Media bit rate:</dt>
<dd pn="section-4.3-2.4.2.4">20 Kbps</dd>
</dl>
</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="TC" numbered="true" toc="include" removeInRFC="false" pn="s
<section anchor="TC" title="Basic Test Cases"> ection-5">
<section anchor="VACS" <name slugifiedName="name-basic-test-cases">Basic Test Cases</name>
title="Variable Available Capacity with a Single Flow"> <section anchor="VACS" numbered="true" toc="include" removeInRFC="false" p
<t>In this test case the minimum bottleneck-link capacity between the tw n="section-5.1">
o <name slugifiedName="name-variable-available-capacity">Variable Availabl
e Capacity with a Single Flow</name>
<t indent="0" pn="section-5.1-1">In this test case, the minimum bottlene
ck-link capacity between the two
endpoints varies over time. This test is designed to measure the endpoints varies over time. This test is designed to measure the
responsiveness of the candidate algorithm. This test tries to address responsiveness of the candidate algorithm. This test tries to address
the requirements in <xref target="I-D.ietf-rmcat-cc-requirements"/>, the requirements in <xref target="RFC8836" format="default" sectionForma t="of" derivedContent="RFC8836"/>,
which requires the algorithm to adapt the flow(s) and provide lower which requires the algorithm to adapt the flow(s) and provide lower
end-to-end latency when there exists: <list style="symbols"> end-to-end latency when there exists: </t>
<t>an intermediate bottleneck</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5
.1-2">
<t>change in available capacity (e.g., due to interface change, <li pn="section-5.1-2.1">an intermediate bottleneck</li>
<li pn="section-5.1-2.2">change in available capacity (e.g., due to in
terface change,
routing change, abrupt arrival/departure of background routing change, abrupt arrival/departure of background
non-adaptive traffic).</t> non-adaptive traffic)</li>
<li pn="section-5.1-2.3">maximum media bit rate is greater than link c
<t>maximum media bit rate is greater than link capacity. In this apacity. In this
case, when the application tries to ramp up to its maximum bit case, when the application tries to ramp up to its maximum bit
rate, since the link capacity is limited to a value lower, the rate, since the link capacity is limited to a lower value, the
congestion control scheme is expected to stabilize the sending bit congestion control scheme is expected to stabilize the sending bit
rate close to the available bottleneck capacity.</t> rate close to the available bottleneck capacity.</li>
</ul>
<!-- --> <t indent="0" pn="section-5.1-3">It should be noted that the exact varia
</list>It should be noted that the exact variation in available tion in available
capacity due to any of the above depends on the underlying capacity due to any of the above depends on the underlying
technologies. Hence, we describe a set of known factors, which may be technologies. Hence, we describe a set of known factors, which may be
extended to devise a more specific test case targeting certain extended to devise a more specific test case targeting certain
behaviors in a certain network environment.</t> behaviors in a certain network environment.</t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.1-4">
<t>Expected behavior: the candidate algorithm is expected to detect <dt pn="section-5.1-4.1">Expected behavior:</dt>
<dd pn="section-5.1-4.2">The candidate algorithm is expected to detect
the path capacity constraint, converge to the bottleneck link's the path capacity constraint, converge to the bottleneck link's
capacity and adapt the flow to avoid unwanted media rate oscillation capacity, and adapt the flow to avoid unwanted media rate oscillation
when the sending bit rate is approaching the bottleneck link's when the sending bit rate is approaching the bottleneck link's
capacity. Such oscillations might occur when the media flow(s) capacity. Such oscillations might occur when the media flow(s)
attempts to reach its maximum bit rate but overshoots the usage of the attempts to reach its maximum bit rate but overshoots the usage of the
available bottleneck capacity then to rectify, it reduces the bit rate available bottleneck capacity, then to rectify, it reduces the bit rate
and starts to ramp up again.</t> and starts to ramp up again.</dd>
<dt pn="section-5.1-4.3">Evaluation metrics:</dt>
<t>Evaluation metrics : as described in <xref target="EM"/>.</t> <dd pn="section-5.1-4.4">As described in <xref target="EM" format="def
ault" sectionFormat="of" derivedContent="Section 4.1"/>.</dd>
<t>Testbed topology: One media source S1 is connected to the <dt pn="section-5.1-4.5">Testbed topology:</dt>
<dd pn="section-5.1-4.6">One media source S1 is connected to the
corresponding R1. The media traffic is transported over the forward corresponding R1. The media traffic is transported over the forward
path and corresponding feedback/control traffic is transported over path and corresponding feedback/control traffic is transported over
the backward path. <figure anchor="fig-eval-topo-4-2" the backward path. </dd>
title="Testbed Topology for Limited Link Capacity"> </dl>
<artwork><![CDATA[ <figure anchor="fig-eval-topo-4-2" align="left" suppress-title="false" p
n="figure-2">
Forward --> <name slugifiedName="name-testbed-topology-for-limite">Testbed Topolog
y for Limited Link Capacity</name>
<artwork name="" type="" align="left" alt="" pn="section-5.1-5.1">
Forward --&gt;
+---+ +-----+ +-----+ +---+ +---+ +-----+ +-----+ +---+
|S1 |=======| A |------------------------------>| B |=======|R1 | |S1 |=======| A |------------------------------&gt;| B |=======|R1 |
+---+ | |<------------------------------| | +---+ +---+ | |&lt;------------------------------| | +---+
+-----+ +-----+ +-----+ +-----+
<-- Backward ---+ | <span class="insert">|&amp;lt;------------------------------|</
]]></artwork> span> | +---+
</figure></t> &lt;-- Backward
</artwork>
<t>Testbed attributes:</t> </figure>
<dl spacing="normal" indent="3" newline="false" pn="section-5.1-6">
<t><list style="symbols"> <dt pn="section-5.1-6.1">Testbed attributes:</dt>
<t>Test duration: 100s</t> <dd pn="section-5.1-6.2">
<t indent="0" pn="section-5.1-6.2.1"><br/></t>
<t>Path characteristics: as described in <xref target="PC"/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.1-6.2.
2">
<t>Application-related: <list style="symbols"> <dt pn="section-5.1-6.2.2.1">Test duration:</dt>
<t>Media Traffic:<list style="symbols"> <dd pn="section-5.1-6.2.2.2">100 s</dd>
<t>Media type: Video<list style="symbols"> <dt pn="section-5.1-6.2.2.3">Path characteristics:</dt>
<t>Media direction: forward.</t> <dd pn="section-5.1-6.2.2.4">as described in <xref target="PC" for
mat="default" sectionFormat="of" derivedContent="Section 4.2"/></dd>
<t>Number of media sources: one (1)</t> <dt pn="section-5.1-6.2.2.5">Application-related:</dt>
<dd pn="section-5.1-6.2.2.6">
<t>Media timeline: <list style="symbols"> <t indent="0" pn="section-5.1-6.2.2.6.1"><br/></t>
<t>Start time: 0s.</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.1-
6.2.2.6.2">
<t>End time: 99s.</t> <dt pn="section-5.1-6.2.2.6.2.1">Media Traffic:</dt>
</list></t> <dd pn="section-5.1-6.2.2.6.2.2">
</list></t> <t indent="0" pn="section-5.1-6.2.2.6.2.2.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
<t>Media type: Audio<list style="symbols"> 5.1-6.2.2.6.2.2.2">
<t>Media direction: forward.</t> <dt pn="section-5.1-6.2.2.6.2.2.2.1">Media type:</dt>
<dd pn="section-5.1-6.2.2.6.2.2.2.2">
<t>Number of media sources: one (1)</t> <t indent="0" pn="section-5.1-6.2.2.6.2.2.2.2.1">Video</
t>
<t>Media timeline: <list style="symbols"> <dl spacing="normal" indent="3" newline="false" pn="sect
<t>Start time: 0s.</t> ion-5.1-6.2.2.6.2.2.2.2.2">
<dt pn="section-5.1-6.2.2.6.2.2.2.2.2.1">Media directi
<t>End time: 99s.</t> on:</dt>
</list></t> <dd pn="section-5.1-6.2.2.6.2.2.2.2.2.2">forward</dd>
</list></t> <dt pn="section-5.1-6.2.2.6.2.2.2.2.2.3">Number of med
</list></t> ia sources:</dt>
<dd pn="section-5.1-6.2.2.6.2.2.2.2.2.4">one (1)</dd>
<t>Competing traffic: <list style="symbols"> <dt pn="section-5.1-6.2.2.6.2.2.2.2.2.5">Media timelin
<t>Number of sources : zero (0)</t> e:</dt>
</list></t> <dd pn="section-5.1-6.2.2.6.2.2.2.2.2.6">
</list></t> <t indent="0" pn="section-5.1-6.2.2.6.2.2.2.2.2.6.1"
><br/></t>
<t>Test Specific Information: <list style="symbols"> <dl spacing="normal" indent="3" newline="false" pn="
<t>One-way propagation delay: [ 50 ms, 100 ms]. on the forward section-5.1-6.2.2.6.2.2.2.2.2.6.2">
path direction</t> <dt pn="section-5.1-6.2.2.6.2.2.2.2.2.6.2.1">Start
time:</dt>
<t>This test uses bottleneck path capacity variation as listed <dd pn="section-5.1-6.2.2.6.2.2.2.2.2.6.2.2">0 s</
in <xref target="VACS_US"/></t> dd>
<dt pn="section-5.1-6.2.2.6.2.2.2.2.2.6.2.3">End t
<t>When using background non-adaptive UDP traffic to induce ime:</dt>
time-varying bottleneck , the physical path capacity remains <dd pn="section-5.1-6.2.2.6.2.2.2.2.2.6.2.4">99 s<
at 4Mbps and the UDP traffic source rate changes over time as /dd>
(4 - (Y x r)), where r is the Reference bottleneck capacity in </dl>
Mbps and Y is the path capacity ratio specified in <xref </dd>
target="VACS_US"/></t> </dl>
</list></t> </dd>
</list></t> <dt pn="section-5.1-6.2.2.6.2.2.2.3">Media type:</dt>
<dd pn="section-5.1-6.2.2.6.2.2.2.4">
<texttable anchor="VACS_US" <t indent="0" pn="section-5.1-6.2.2.6.2.2.2.4.1">Audio</
title="Path capacity variation pattern for forward direction" t>
> <dl spacing="normal" indent="3" newline="false" pn="sect
<ttcol>Variation pattern index</ttcol> ion-5.1-6.2.2.6.2.2.2.4.2">
<dt pn="section-5.1-6.2.2.6.2.2.2.4.2.1">Media directi
<ttcol>Path direction</ttcol> on:</dt>
<dd pn="section-5.1-6.2.2.6.2.2.2.4.2.2">forward</dd>
<ttcol>Start time</ttcol> <dt pn="section-5.1-6.2.2.6.2.2.2.4.2.3">Number of med
ia sources:</dt>
<ttcol>Path capacity ratio</ttcol> <dd pn="section-5.1-6.2.2.6.2.2.2.4.2.4">one (1)</dd>
<dt pn="section-5.1-6.2.2.6.2.2.2.4.2.5">Media timelin
<c>One</c> e:</dt>
<dd pn="section-5.1-6.2.2.6.2.2.2.4.2.6">
<c>Forward</c> <t indent="0" pn="section-5.1-6.2.2.6.2.2.2.4.2.6.1"
><br/></t>
<c>0s</c> <dl spacing="normal" indent="3" newline="false" pn="
section-5.1-6.2.2.6.2.2.2.4.2.6.2">
<c>1.0</c> <dt pn="section-5.1-6.2.2.6.2.2.2.4.2.6.2.1">Start
time:</dt>
<c>Two</c> <dd pn="section-5.1-6.2.2.6.2.2.2.4.2.6.2.2">0 s</
dd>
<c>Forward</c> <dt pn="section-5.1-6.2.2.6.2.2.2.4.2.6.2.3">End t
ime:</dt>
<c>40s</c> <dd pn="section-5.1-6.2.2.6.2.2.2.4.2.6.2.4">99 s<
/dd>
<c>2.5</c> </dl>
</dd>
<c>Three</c> </dl>
</dd>
<c>Forward</c> </dl>
</dd>
<c>60s</c> <dt pn="section-5.1-6.2.2.6.2.3">Competing traffic:</dt>
<dd pn="section-5.1-6.2.2.6.2.4">
<c>0.6</c> <t indent="0" pn="section-5.1-6.2.2.6.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
<c>Four</c> 5.1-6.2.2.6.2.4.2">
<dt pn="section-5.1-6.2.2.6.2.4.2.1">Number of sources:</d
<c>Forward</c> t>
<dd pn="section-5.1-6.2.2.6.2.4.2.2">zero (0)</dd>
<c>80s</c> </dl>
</dd>
<c>1.0</c> </dl>
</dd>
<!-- <postamble>Table 1: Path capacity variation pattern for </dl>
forward direction</postamble> --> </dd>
</texttable> <dt pn="section-5.1-6.3">Test-specific information:</dt>
<dd pn="section-5.1-6.4">
<t/> <t indent="0" pn="section-5.1-6.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.1-6.4.
2">
<dt pn="section-5.1-6.4.2.1">One-way propagation delay:</dt>
<dd pn="section-5.1-6.4.2.2">[50 ms, 100 ms]. On the forward path
direction.</dd>
</dl>
<t indent="0" pn="section-5.1-6.4.3">This test uses bottleneck path
capacity variation as listed
in <xref target="VACS_US" format="default" sectionFormat="of
" derivedContent="Table 1"/>.</t>
<t indent="0" pn="section-5.1-6.4.4">When using background non-adapt
ive UDP traffic to induce a
time-varying bottleneck, the physical path capacity remains
at 4 Mbps, and the UDP traffic source rate changes over time
as
(4 - (Y x r)), where r is the Reference bottleneck capacity
in
Mbps, and Y is the path capacity ratio specified in
<xref target="VACS_US" format="default" sectionFormat="of" d
erivedContent="Table 1"/>.</t>
</dd>
</dl>
<table anchor="VACS_US" align="center" pn="table-1">
<name slugifiedName="name-path-capacity-variation-pat">Path Capacity V
ariation Pattern for the Forward Direction</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Variation pattern index</
th>
<th align="left" colspan="1" rowspan="1">Path direction</th>
<th align="left" colspan="1" rowspan="1">Start time</th>
<th align="left" colspan="1" rowspan="1">Path capacity ratio</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">One</td>
<td align="left" colspan="1" rowspan="1">Forward</td>
<td align="left" colspan="1" rowspan="1">0 s</td>
<td align="left" colspan="1" rowspan="1">1.0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">Two</td>
<td align="left" colspan="1" rowspan="1">Forward</td>
<td align="left" colspan="1" rowspan="1">40 s</td>
<td align="left" colspan="1" rowspan="1">2.5</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">Three</td>
<td align="left" colspan="1" rowspan="1">Forward</td>
<td align="left" colspan="1" rowspan="1">60 s</td>
<td align="left" colspan="1" rowspan="1">0.6</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">Four</td>
<td align="left" colspan="1" rowspan="1">Forward</td>
<td align="left" colspan="1" rowspan="1">80 s</td>
<td align="left" colspan="1" rowspan="1">1.0</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-5.1-8"/>
</section> </section>
<section anchor="VACM" numbered="true" toc="include" removeInRFC="false" p
<section anchor="VACM" n="section-5.2">
title="Variable Available Capacity with Multiple Flows"> <name slugifiedName="name-variable-available-capacity-">Variable Availab
<t>This test case is similar to <xref target="VACS"/>. However in le Capacity with Multiple Flows</name>
addition this test will also consider persistent network load due to <t indent="0" pn="section-5.2-1">This test case is similar to <xref targ
et="VACS" format="default" sectionFormat="of" derivedContent="Section 5.1"/>. Ho
wever,
this test will also consider persistent network load due to
competing traffic.</t> competing traffic.</t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.2-2">
<t>Expected behavior: the candidate algorithm is expected to detect <dt pn="section-5.2-2.1">Expected behavior:</dt>
<dd pn="section-5.2-2.2">The candidate algorithm is expected to detect
the variation in available capacity and adapt the media stream(s) the variation in available capacity and adapt the media stream(s)
accordingly. The flows stabilize around their maximum bit rate as the accordingly. The flows stabilize around their maximum bit rate as the
maximum link capacity is large enough to accommodate the flows. When maximum link capacity is large enough to accommodate the flows. When
the available capacity drops, the flows adapt by decreasing their the available capacity drops, the flows adapt by decreasing their
sending bit rate, and when congestion disappears, the flows are again sending bit rate, and when congestion disappears, the flows are again
expected to ramp up.</t> expected to ramp up.</dd>
<dt pn="section-5.2-2.3">Evaluation metrics:</dt>
<t>Evaluation metrics : as described in <xref target="EM"/>.</t> <dd pn="section-5.2-2.4">As described in <xref target="EM" format="def
ault" sectionFormat="of" derivedContent="Section 4.1"/>.</dd>
<t>Testbed Topology: Two (2) media sources S1 and S2 are connected to <dt pn="section-5.2-2.5">Testbed topology:</dt>
<dd pn="section-5.2-2.6">Two (2) media sources S1 and S2 are connected
to
their corresponding destinations R1 and R2. The media traffic is their corresponding destinations R1 and R2. The media traffic is
transported over the forward path and corresponding feedback/control transported over the forward path and corresponding feedback/control
traffic is transported over the backward path. <figure traffic is transported over the backward path. </dd>
anchor="fig-eval-topo-4-1" </dl>
title="Testbed Topology for Variable Available Capacity"> <figure anchor="fig-eval-topo-4-1" align="left" suppress-title="false" p
<artwork><![CDATA[ n="figure-3">
<name slugifiedName="name-testbed-topology-for-variab">Testbed Topolog
y for Variable Available Capacity</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2-3.1">
+---+ +---+ +---+ +---+
|S1 |===== \ / =======|R1 | |S1 |===== \ / =======|R1 |
+---+ \\ Forward --> // +---+ +---+ \\ Forward --&gt; // +---+
\\ // \\ //
+-----+ +-----+ +-----+ +-----+
| A |------------------------------>| B | | A |------------------------------&gt;| B |
| |<------------------------------| | | |&lt;------------------------------| |
+-----+ +-----+ +-----+ +-----+
// \\ // \\
// <-- Backward \\ // &lt;-- Backward \\
+---+ // \\ +---+ +---+ // \\ +---+
|S2 |====== / \ ======|R2 | |S2 |====== / \ ======|R2 |
+---+ +---+ +---+ +---+
]]></artwork> </artwork>
</figure></t> </figure>
<dl spacing="normal" indent="3" newline="false" pn="section-5.2-4">
<t>Testbed attributes:</t> <dt pn="section-5.2-4.1">Testbed attributes:</dt>
<dd pn="section-5.2-4.2">Testbed attributes are similar to those descr
<t>Testbed attributes are similar as described in <xref ibed in <xref target="VACS" format="default" sectionFormat="of" derivedContent="
target="VACS"/> except the test specific capacity variation setup.</t> Section 5.1"/>,
except for the test-specific capacity variation setup.</dd>
<t>Test Specific Information: This test uses path capacity variation <dt pn="section-5.2-4.3">Test-specific information:</dt>
as listed in <xref target="VACM_US"/> with a corresponding end time of <dd pn="section-5.2-4.4">This test uses path capacity variation
125 seconds. The reference bottleneck capacity is 2Mbps. When using as listed in <xref target="VACM_US" format="default" sectionFormat="of"
derivedContent="Table 2"/> with a corresponding end time of
125 seconds. The reference bottleneck capacity is 2 Mbps. When using
background non-adaptive UDP traffic to induce time-varying bottleneck background non-adaptive UDP traffic to induce time-varying bottleneck
for congestion controlled media flows, the physical path capacity is for congestion-controlled media flows, the physical path capacity is
4Mbps and the UDP traffic source rate changes over time as (4 - (Y x 4 Mbps, and the UDP traffic source rate changes over time as (4 - (Y x
r)), where r is the Reference bottleneck capacity in Mbps and Y is the r)), where r is the Reference bottleneck capacity in Mbps, and Y is the
path capacity ratio specified in <xref target="VACM_US"/>.</t> path capacity ratio specified in <xref target="VACM_US" format="default"
sectionFormat="of" derivedContent="Table 2"/>.</dd>
<texttable anchor="VACM_US" </dl>
title="Path capacity variation pattern for forward direction" <table anchor="VACM_US" align="center" pn="table-2">
> <name slugifiedName="name-path-capacity-variation-patt">Path Capacity
<ttcol>Variation pattern index</ttcol> Variation Pattern for the Forward Direction</name>
<thead>
<ttcol>Path direction</ttcol> <tr>
<th align="left" colspan="1" rowspan="1">Variation pattern index</
<ttcol>Start time</ttcol> th>
<th align="left" colspan="1" rowspan="1">Path direction</th>
<ttcol>Path capacity ratio</ttcol> <th align="left" colspan="1" rowspan="1">Start time</th>
<th align="left" colspan="1" rowspan="1">Path capacity ratio</th>
<c>One</c> </tr>
</thead>
<c>Forward</c> <tbody>
<tr>
<c>0s</c> <td align="left" colspan="1" rowspan="1">One</td>
<td align="left" colspan="1" rowspan="1">Forward</td>
<c>2.0</c> <td align="left" colspan="1" rowspan="1">0 s</td>
<td align="left" colspan="1" rowspan="1">2.0</td>
<c>Two</c> </tr>
<tr>
<c>Forward</c> <td align="left" colspan="1" rowspan="1">Two</td>
<td align="left" colspan="1" rowspan="1">Forward</td>
<c>25s</c> <td align="left" colspan="1" rowspan="1">25 s</td>
<td align="left" colspan="1" rowspan="1">1.0</td>
<c>1.0</c> </tr>
<tr>
<c>Three</c> <td align="left" colspan="1" rowspan="1">Three</td>
<td align="left" colspan="1" rowspan="1">Forward</td>
<c>Forward</c> <td align="left" colspan="1" rowspan="1">50 s</td>
<td align="left" colspan="1" rowspan="1">1.75</td>
<c>50s</c> </tr>
<tr>
<c>1.75</c> <td align="left" colspan="1" rowspan="1">Four</td>
<td align="left" colspan="1" rowspan="1">Forward</td>
<c>Four</c> <td align="left" colspan="1" rowspan="1">75 s</td>
<td align="left" colspan="1" rowspan="1">0.5</td>
<c>Forward</c> </tr>
<tr>
<c>75s</c> <td align="left" colspan="1" rowspan="1">Five</td>
<td align="left" colspan="1" rowspan="1">Forward</td>
<c>0.5</c> <td align="left" colspan="1" rowspan="1">100 s</td>
<td align="left" colspan="1" rowspan="1">1.0</td>
<c>Five</c> </tr>
</tbody>
<c>Forward</c> </table>
<c>100s</c>
<c>1.0</c>
<!-- <postamble>Table 2: Path capacity variation pattern for
forward direction</postamble> -->
</texttable>
</section> </section>
<section anchor="CFL" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="CFL" ="section-5.3">
title="Congested Feedback Link with Bi-directional Media Flows"> <name slugifiedName="name-congested-feedback-link-wit">Congested Feedbac
<t>Real-time interactive media uses RTP hence it is assumed that RTCP, k Link with Bi-directional Media Flows</name>
RTP header extension or such would be used by the congestion control <t indent="0" pn="section-5.3-1">Real-time interactive media uses RTP; h
algorithm in the backchannel. Due to the asymmetric nature of the link ence it is assumed that RTCP,
between communicating peers it is possible for a participating peer to RTP header extension, or such would be used by the congestion control
algorithm in the back channel. Due to the asymmetric nature of the link
between communicating peers, it is possible for a participating peer to
not receive such feedback information due to an impaired or congested not receive such feedback information due to an impaired or congested
backchannel (even when the forward channel might not be impaired). back channel (even when the forward channel might not be impaired).
This test case is designed to observe the candidate congestion control This test case is designed to observe the candidate congestion control
behavior in such an event.</t> behavior in such an event.</t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.3-2">
<t>Expected behavior: It is expected that the candidate algorithms are <dt pn="section-5.3-2.1">Expected behavior:</dt>
able to cope with the lack of feedback information and adapt to <dd pn="section-5.3-2.2">
<t indent="0" pn="section-5.3-2.2.1">It is expected that the candida
te algorithms are
able to cope with the lack of feedback information and to adapt to
minimize the performance degradation of media flows in the forward minimize the performance degradation of media flows in the forward
channel.</t> channel.</t>
<t indent="0" pn="section-5.3-2.2.2">It should be noted that for thi
<t>It should be noted that for this test case: logs are compared with s test case, logs are compared with
the reference case, i.e, when the backward channel has no the reference case, i.e., when the backward channel has no
impairments.</t> impairments.</t>
</dd>
<t>Evaluation metrics : as described in <xref target="EM"/>.</t> <dt pn="section-5.3-2.3">Evaluation metrics:</dt>
<dd pn="section-5.3-2.4">As described in <xref target="EM" format="def
<t>Testbed topology: One (1) media source S1 is connected to ault" sectionFormat="of" derivedContent="Section 4.1"/>.</dd>
<dt pn="section-5.3-2.5">Testbed topology:</dt>
<dd pn="section-5.3-2.6">One (1) media source S1 is connected to
corresponding R1, but both endpoints are additionally receiving and corresponding R1, but both endpoints are additionally receiving and
sending data, respectively. The media traffic (S1-&gt;R1) is sending data, respectively. The media traffic (S1-&gt;R1) is
transported over the forward path and corresponding feedback/control transported over the forward path, and the corresponding feedback/contro
traffic is transported over the backward path. Likewise media traffic l
(S2-&gt;R2) is transported over the backward path and corresponding traffic is transported over the backward path. Likewise, media traffic
feedback/control traffic is transported over the forward path.</t> (S2-&gt;R2) is transported over the backward path, and the corresponding
feedback/control traffic is transported over the forward path.</dd>
<t><figure anchor="fig-eval-topo-4-6" </dl>
title="Testbed Topology for Congested Feedback Link"> <figure anchor="fig-eval-topo-4-6" align="left" suppress-title="false" p
<artwork><![CDATA[ n="figure-4">
+---+ +---+ <name slugifiedName="name-testbed-topology-for-conges">Testbed Topolog
|S1 |===== \ Forward --> / =======|R1 | y for Congested Feedback Link</name>
+---+ \\ // +---+ <artwork name="" type="" align="left" alt="" pn="section-5.3-3.1">
\\ // +---+ +---+
+-----+ +-----+ |S1 |====== \ Forward --&gt; / =======|R1 |
| A |------------------------------>| B | +---+ \\ // +---+
| |<------------------------------| | \\ //
+-----+ +-----+ +-----+ +-----+
// \\ | A |------------------------------&gt;| B |
// <-- Backward \\ | |&lt;------------------------------| |
+---+ // \\ +---+ +-----+ +-----+
|R2 |===== / \ ======|S2 | // \\
+---+ +---+ // &lt;-- Backward \\
]]></artwork> +---+ // \\ +---+
</figure></t> |R2 |===== / \ ======|S2 |
+---+ +---+
<t>Testbed attributes:</t> </artwork>
</figure>
<t><list style="symbols"> <dl spacing="normal" indent="3" newline="false" pn="section-5.3-4">
<t>Test duration: 100s</t> <dt pn="section-5.3-4.1">Testbed attributes:</dt>
<dd pn="section-5.3-4.2">
<t>Path characteristics: <list style="symbols"> <t indent="0" pn="section-5.3-4.2.1"><br/></t>
<t>Reference bottleneck capacity: 1Mbps.</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.3-4.2.
</list></t> 2">
<dt pn="section-5.3-4.2.2.1">Test duration:</dt>
<t>Application-related: <list style="symbols"> <dd pn="section-5.3-4.2.2.2">100 s</dd>
<t>Media Source: <list style="symbols"> <dt pn="section-5.3-4.2.2.3">Path characteristics:</dt>
<t>Media type: Video<list style="symbols"> <dd pn="section-5.3-4.2.2.4">
<t>Media direction: forward and backward</t> <t indent="0" pn="section-5.3-4.2.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.3-
<t>Number of media sources: two (2)</t> 4.2.2.4.2">
<dt pn="section-5.3-4.2.2.4.2.1">Reference bottleneck capacity
<t>Media timeline: <list style="symbols"> :</dt>
<t>Start time: 0s.</t> <dd pn="section-5.3-4.2.2.4.2.2">1 Mbps</dd>
</dl>
<t>End time: 99s.</t> </dd>
</list></t> <dt pn="section-5.3-4.2.2.5">Application-related:</dt>
</list></t> <dd pn="section-5.3-4.2.2.6">
<t indent="0" pn="section-5.3-4.2.2.6.1"><br/></t>
<t>Media type: Audio<list style="symbols"> <dl spacing="normal" indent="3" newline="false" pn="section-5.3-
<t>Media direction: forward and backward</t> 4.2.2.6.2">
<dt pn="section-5.3-4.2.2.6.2.1">Media source:</dt>
<t>Number of media sources: two (2)</t> <dd pn="section-5.3-4.2.2.6.2.2">
<t indent="0" pn="section-5.3-4.2.2.6.2.2.1"><br/></t>
<t>Media timeline: <list style="symbols"> <dl spacing="normal" indent="3" newline="false" pn="section-
<t>Start time: 0s.</t> 5.3-4.2.2.6.2.2.2">
<dt pn="section-5.3-4.2.2.6.2.2.2.1">Media type:</dt>
<t>End time: 99s.</t> <dd pn="section-5.3-4.2.2.6.2.2.2.2">
</list></t> <t indent="0" pn="section-5.3-4.2.2.6.2.2.2.2.1">Video</
</list></t> t>
</list></t> <dl spacing="normal" indent="3" newline="false" pn="sect
ion-5.3-4.2.2.6.2.2.2.2.2">
<t>Competing traffic: <list style="symbols"> <dt pn="section-5.3-4.2.2.6.2.2.2.2.2.1">Media directi
<t>Number of sources : zero (0)</t> on:</dt>
</list></t> <dd pn="section-5.3-4.2.2.6.2.2.2.2.2.2">forward and b
</list></t> ackward</dd>
<dt pn="section-5.3-4.2.2.6.2.2.2.2.2.3">Number of med
<t>Test Specific Information: this test uses path capacity ia sources:</dt>
variations to create congested feedback link. <xref <dd pn="section-5.3-4.2.2.6.2.2.2.2.2.4">two (2)</dd>
target="CFL_US"> </xref> lists the variation patterns applied to <dt pn="section-5.3-4.2.2.6.2.2.2.2.2.5">Media timelin
the forward path and <xref target="CFL_DS"/> lists the variation e:</dt>
<dd pn="section-5.3-4.2.2.6.2.2.2.2.2.6">
<t indent="0" pn="section-5.3-4.2.2.6.2.2.2.2.2.6.1"
><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="
section-5.3-4.2.2.6.2.2.2.2.2.6.2">
<dt pn="section-5.3-4.2.2.6.2.2.2.2.2.6.2.1">Start
time:</dt>
<dd pn="section-5.3-4.2.2.6.2.2.2.2.2.6.2.2">0 s</
dd>
<dt pn="section-5.3-4.2.2.6.2.2.2.2.2.6.2.3">End t
ime:</dt>
<dd pn="section-5.3-4.2.2.6.2.2.2.2.2.6.2.4">99 s<
/dd>
</dl>
</dd>
</dl>
</dd>
<dt pn="section-5.3-4.2.2.6.2.2.2.3">Media type:</dt>
<dd pn="section-5.3-4.2.2.6.2.2.2.4">
<t indent="0" pn="section-5.3-4.2.2.6.2.2.2.4.1">Audio</
t>
<dl spacing="normal" indent="3" newline="false" pn="sect
ion-5.3-4.2.2.6.2.2.2.4.2">
<dt pn="section-5.3-4.2.2.6.2.2.2.4.2.1">Media directi
on:</dt>
<dd pn="section-5.3-4.2.2.6.2.2.2.4.2.2">forward and b
ackward</dd>
<dt pn="section-5.3-4.2.2.6.2.2.2.4.2.3">Number of med
ia sources:</dt>
<dd pn="section-5.3-4.2.2.6.2.2.2.4.2.4">two (2)</dd>
<dt pn="section-5.3-4.2.2.6.2.2.2.4.2.5">Media timelin
e: </dt>
<dd pn="section-5.3-4.2.2.6.2.2.2.4.2.6">
<t indent="0" pn="section-5.3-4.2.2.6.2.2.2.4.2.6.1"
><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="
section-5.3-4.2.2.6.2.2.2.4.2.6.2">
<dt pn="section-5.3-4.2.2.6.2.2.2.4.2.6.2.1">Start
time:</dt>
<dd pn="section-5.3-4.2.2.6.2.2.2.4.2.6.2.2">0 s</
dd>
<dt pn="section-5.3-4.2.2.6.2.2.2.4.2.6.2.3">End t
ime:</dt>
<dd pn="section-5.3-4.2.2.6.2.2.2.4.2.6.2.4">99 s<
/dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</dd>
<dt pn="section-5.3-4.2.2.6.2.3">Competing traffic: </dt>
<dd pn="section-5.3-4.2.2.6.2.4">
<t indent="0" pn="section-5.3-4.2.2.6.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
5.3-4.2.2.6.2.4.2">
<dt pn="section-5.3-4.2.2.6.2.4.2.1">Number of sources:</d
t>
<dd pn="section-5.3-4.2.2.6.2.4.2.2">zero (0)</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</dd>
<dt pn="section-5.3-4.3">Test-specific information:</dt>
<dd pn="section-5.3-4.4">This test uses path capacity
variations to create a congested feedback link. <xref target="CFL_US
" format="default" sectionFormat="of" derivedContent="Table 3"/>
lists the variation patterns applied to
the forward path, and <xref target="CFL_DS" format="default" section
Format="of" derivedContent="Table 4"/> lists the variation
patterns applied to the backward path. When using background patterns applied to the backward path. When using background
non-adaptive UDP traffic to induce time-varying bottleneck for non-adaptive UDP traffic to induce a time-varying bottleneck for
congestion controlled media flows, the physical path capacity is congestion-controlled media flows, the physical path capacity is
4Mbps for both directions and the UDP traffic source rate changes 4 Mbps for both directions, and the UDP traffic source rate changes
over time as (4-x)Mbps in each direction, where x is the over time as (4-x) Mbps in each direction, where x is the
bottleneck capacity specified in <xref target="CFL_DS"/>.</t> bottleneck capacity specified in <xref target="CFL_DS" format="defau
</list></t> lt" sectionFormat="of" derivedContent="Table 4"/>.</dd>
</dl>
<texttable anchor="CFL_US" <table anchor="CFL_US" align="center" pn="table-3">
title="Path capacity variation pattern for forward direction" <name slugifiedName="name-path-capacity-variation-patte">Path Capacity
> Variation Pattern for the Forward Direction</name>
<ttcol>Variation pattern index</ttcol> <thead>
<tr>
<ttcol>Path direction</ttcol> <th align="left" colspan="1" rowspan="1">Variation pattern index</
th>
<ttcol>Start time</ttcol> <th align="left" colspan="1" rowspan="1">Path direction</th>
<th align="left" colspan="1" rowspan="1">Start time</th>
<ttcol>Path capacity ratio</ttcol> <th align="left" colspan="1" rowspan="1">Path capacity ratio</th>
</tr>
<c>One</c> </thead>
<tbody>
<c>Forward</c> <tr>
<td align="left" colspan="1" rowspan="1">One</td>
<c>0s</c> <td align="left" colspan="1" rowspan="1">Forward</td>
<td align="left" colspan="1" rowspan="1">0 s</td>
<c>2.0</c> <td align="left" colspan="1" rowspan="1">2.0</td>
</tr>
<c>Two</c> <tr>
<td align="left" colspan="1" rowspan="1">Two</td>
<c>Forward</c> <td align="left" colspan="1" rowspan="1">Forward</td>
<td align="left" colspan="1" rowspan="1">20 s</td>
<c>20s</c> <td align="left" colspan="1" rowspan="1">1.0</td>
</tr>
<c>1.0</c> <tr>
<td align="left" colspan="1" rowspan="1">Three</td>
<c>Three</c> <td align="left" colspan="1" rowspan="1">Forward</td>
<td align="left" colspan="1" rowspan="1">40 s</td>
<c>Forward</c> <td align="left" colspan="1" rowspan="1">0.5</td>
</tr>
<c>40s</c> <tr>
<td align="left" colspan="1" rowspan="1">Four</td>
<c>0.5</c> <td align="left" colspan="1" rowspan="1">Forward</td>
<td align="left" colspan="1" rowspan="1">60 s</td>
<c>Four</c> <td align="left" colspan="1" rowspan="1">2.0</td>
</tr>
<c>Forward</c> </tbody>
</table>
<c>60s</c> <t indent="0" pn="section-5.3-6"/>
<table anchor="CFL_DS" align="center" pn="table-4">
<c>2.0</c> <name slugifiedName="name-path-capacity-variation-patter">Path Capacit
y Variation Pattern for the Backward Direction</name>
<!-- <postamble>Table 3: Path capacity variation pattern for <thead>
forward direction</postamble> --> <tr>
</texttable> <th align="left" colspan="1" rowspan="1">Variation pattern index</
th>
<t/> <th align="left" colspan="1" rowspan="1">Path direction</th>
<th align="left" colspan="1" rowspan="1">Start time</th>
<texttable anchor="CFL_DS" <th align="left" colspan="1" rowspan="1">Path capacity ratio</th>
title="Path capacity variation pattern for backward direction </tr>
"> </thead>
<ttcol>Variation pattern index</ttcol> <tbody>
<tr>
<ttcol>Path direction</ttcol> <td align="left" colspan="1" rowspan="1">One</td>
<td align="left" colspan="1" rowspan="1">Backward</td>
<ttcol>Start time</ttcol> <td align="left" colspan="1" rowspan="1">0 s</td>
<td align="left" colspan="1" rowspan="1">2.0</td>
<ttcol>Path capacity ratio</ttcol> </tr>
<tr>
<c>One</c> <td align="left" colspan="1" rowspan="1">Two</td>
<td align="left" colspan="1" rowspan="1">Backward</td>
<c>Backward</c> <td align="left" colspan="1" rowspan="1">35 s</td>
<td align="left" colspan="1" rowspan="1">0.8</td>
<c>0s</c> </tr>
<tr>
<c>2.0</c> <td align="left" colspan="1" rowspan="1">Three</td>
<td align="left" colspan="1" rowspan="1">Backward</td>
<c>Two</c> <td align="left" colspan="1" rowspan="1">70 s</td>
<td align="left" colspan="1" rowspan="1">2.0</td>
<c>Backward</c> </tr>
</tbody>
<c>35s</c> </table>
<c>0.8</c>
<c>Three</c>
<c>Backward</c>
<c>70s</c>
<c>2.0</c>
<!-- <postamble>Table 4: Path capacity variation pattern for
backward direction</postamble> -->
</texttable>
</section> </section>
<section anchor="competing-rmcat-flow" numbered="true" toc="include" remov
<section anchor="competing-rmcat-flow" eInRFC="false" pn="section-5.4">
title="Competing Media Flows with same Congestion Control Algorit <name slugifiedName="name-competing-media-flows-with-">Competing Media F
hm"> lows with the Same Congestion Control Algorithm</name>
<t>In this test case, more than one media flow share the bottleneck <t indent="0" pn="section-5.4-1">In this test case, more than one media
link and each of them uses the same congestion control algorithm. This flow share the bottleneck
link, and each of them uses the same congestion control algorithm. This
is a typical scenario where a real-time interactive application sends is a typical scenario where a real-time interactive application sends
more than one media flow to the same destination and these flows are more than one media flow to the same destination, and these flows are
multiplexed over the same port. In such a scenario it is likely that multiplexed over the same port. In such a scenario, it is likely that
the flows will be routed via the same path and need to share the the flows will be routed via the same path and need to share the
available bandwidth amongst themselves. For the sake of simplicity it available bandwidth amongst themselves. For the sake of simplicity, it
is assumed that there are no other competing traffic sources in the is assumed that there are no other competing traffic sources in the
bottleneck link and that there is sufficient capacity to accommodate bottleneck link and that there is sufficient capacity to accommodate
all the flows individually. While this appears to be a variant of the all the flows individually. While this appears to be a variant of the
test case defined in <xref target="VACM"/>, it focuses on the capacity test case defined in <xref target="VACM" format="default" sectionFormat=
sharing aspect of the candidate algorithm. The previous test case, on "of" derivedContent="Section 5.2"/>, it focuses
on the capacity-sharing aspect of the candidate algorithm. The previous
test case, on
the other hand, measures adaptability, stability, and responsiveness the other hand, measures adaptability, stability, and responsiveness
of the candidate algorithm.</t> of the candidate algorithm.</t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.4-2">
<t>Expected behavior: It is expected that the competing flows will <dt pn="section-5.4-2.1">Expected behavior:</dt>
<dd pn="section-5.4-2.2">It is expected that the competing flows will
converge to an optimum bit rate to accommodate all the flows with converge to an optimum bit rate to accommodate all the flows with
minimum possible latency and loss. Specifically, the test introduces minimum possible latency and loss. Specifically, the test introduces
three media flows at different time instances, when the second flow three media flows at different time instances. When the second flow
appears there should still be room to accommodate another flow on the appears, there should still be room to accommodate another flow on the
bottleneck link. Lastly, when the third flow appears the bottleneck bottleneck link. Lastly, when the third flow appears, the bottleneck
link should be saturated.</t> link should be saturated.</dd>
<dt pn="section-5.4-2.3">Evaluation metrics:</dt>
<t>Evaluation metrics : as described in <xref target="EM"/>.</t> <dd pn="section-5.4-2.4">As described in <xref target="EM" format="def
ault" sectionFormat="of" derivedContent="Section 4.1"/>.</dd>
<t>Testbed topology: Three media sources S1, S2, S3 are connected to <dt pn="section-5.4-2.5">Testbed topology: </dt>
R1, R2, R3 respectively. The media traffic is transported over the <dd pn="section-5.4-2.6">Three media sources S1, S2, and S3 are connec
forward path and corresponding feedback/control traffic is transported ted to
over the backward path. <figure anchor="fig-eval-topo-4-3" R1, R2, and R3, respectively. The media traffic is transported over the
title="Testbed Topology for Multiple congestion controlled media Flo forward path, and the corresponding feedback/control traffic is transpor
ws"> ted
<artwork><![CDATA[ over the backward path. </dd>
</dl>
<figure anchor="fig-eval-topo-4-3" align="left" suppress-title="false" p
n="figure-5">
<name slugifiedName="name-testbed-topology-for-multip">Testbed Topolog
y for Multiple Congestion-Controlled Media Flows</name>
<artwork name="" type="" align="left" alt="" pn="section-5.4-3.1">
+---+ +---+ +---+ +---+
|S1 |===== \ Forward --> / =======|R1 | |S1 |===== \ Forward --&gt; / =======|R1 |
+---+ \\ // +---+ +---+ \\ // +---+
\\ // \\ //
+---+ +-----+ +-----+ +---+ +---+ +-----+ +-----+ +---+
|S2 |=======| A |------------------------------>| B |=======|R2 | |S2 |=======| A |------------------------------&gt;| B |=======|R2 |
+---+ | |<------------------------------| | +---+ +---+ | |&lt;------------------------------| | +---+
+-----+ +-----+ +-----+ +-----+
// <-- Backward \\ ---+ | <span class="insert">|&amp;lt;------------------------------|</
span> | +---+
// &lt;-- Backward \\
+---+ // \\ +---+ +---+ // \\ +---+
|S3 |===== / \ ======|R3 | |S3 |===== / \ ======|R3 |
+---+ +---+ +---+ +---+
]]></artwork> </artwork>
</figure></t> </figure>
<dl spacing="normal" indent="3" newline="false" pn="section-5.4-4">
<t>Testbed attributes:</t> <dt pn="section-5.4-4.1">Testbed attributes:</dt>
<dd pn="section-5.4-4.2">
<t><list style="symbols"> <t indent="0" pn="section-5.4-4.2.1"><br/></t>
<t>Test duration: 120s</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.4-4.2.
2">
<t>Path characteristics: <list style="symbols"> <dt pn="section-5.4-4.2.2.1">Test duration:</dt>
<t>Reference bottleneck capacity: 3.5Mbps</t> <dd pn="section-5.4-4.2.2.2">120 s</dd>
<dt pn="section-5.4-4.2.2.3">Path characteristics:</dt>
<t>Path capacity ratio: 1.0</t> <dd pn="section-5.4-4.2.2.4">
<t indent="0" pn="section-5.4-4.2.2.4.1"><br/></t>
<!-- <t>One-Way propagation delay: [10ms, 50ms]</t> --> <dl spacing="normal" indent="3" newline="false" pn="section-5.4-
</list></t> 4.2.2.4.2">
<dt pn="section-5.4-4.2.2.4.2.1">Reference bottleneck capacity
<t>Application-related: <list style="symbols"> :</dt>
<t>Media Source: <list style="symbols"> <dd pn="section-5.4-4.2.2.4.2.2">3.5 Mbps</dd>
<t>Media type: Video<list style="symbols"> <dt pn="section-5.4-4.2.2.4.2.3">Path capacity ratio:</dt>
<t>Media direction: forward.</t> <dd pn="section-5.4-4.2.2.4.2.4">1.0</dd>
</dl>
<t>Number of media sources: three (3)</t> </dd>
<dt pn="section-5.4-4.2.2.5">Application-related: </dt>
<t>Media timeline: new media flows are added <dd pn="section-5.4-4.2.2.6">
sequentially, at short time intervals. See test <t indent="0" pn="section-5.4-4.2.2.6.1"><br/></t>
specific setup below.</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.4-
</list></t> 4.2.2.6.2">
<dt pn="section-5.4-4.2.2.6.2.1">Media Source: </dt>
<t>Media type: Audio<list style="symbols"> <dd pn="section-5.4-4.2.2.6.2.2">
<t>Media direction: forward.</t> <t indent="0" pn="section-5.4-4.2.2.6.2.2.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
<t>Number of media sources: three (3)</t> 5.4-4.2.2.6.2.2.2">
<dt pn="section-5.4-4.2.2.6.2.2.2.1">Media type:</dt>
<t>Media timeline: new media flows are added <dd pn="section-5.4-4.2.2.6.2.2.2.2">
sequentially, at short time intervals. See test <t indent="0" pn="section-5.4-4.2.2.6.2.2.2.2.1">Video</
specific setup below.</t> t>
</list></t> <dl spacing="normal" indent="3" newline="false" pn="sect
</list></t> ion-5.4-4.2.2.6.2.2.2.2.2">
<dt pn="section-5.4-4.2.2.6.2.2.2.2.2.1">Media directi
<t>Competing traffic: <list style="symbols"> on:</dt>
<t>Number of sources : zero (0)</t> <dd pn="section-5.4-4.2.2.6.2.2.2.2.2.2">forward</dd>
</list></t> <dt pn="section-5.4-4.2.2.6.2.2.2.2.2.3">Number of med
</list></t> ia sources:</dt>
<dd pn="section-5.4-4.2.2.6.2.2.2.2.2.4">three (3)</dd
<t>Test Specific Information: <xref target="MTL_CF"/> defines the >
media timeline for both media type.</t> <dt pn="section-5.4-4.2.2.6.2.2.2.2.2.5">Media timelin
</list></t> e:</dt>
<dd pn="section-5.4-4.2.2.6.2.2.2.2.2.6">New media flo
<texttable anchor="MTL_CF" ws are added
title="Media Timeline for Video and Audio media sources"> sequentially, at short time intervals. See the
<ttcol>Flow ID</ttcol> test-specific setup below.</dd>
</dl>
<ttcol>Media type</ttcol> </dd>
<dt pn="section-5.4-4.2.2.6.2.2.2.3">Media type:</dt>
<ttcol>Start time</ttcol> <dd pn="section-5.4-4.2.2.6.2.2.2.4">
<t indent="0" pn="section-5.4-4.2.2.6.2.2.2.4.1">Audio</
<ttcol>End time</ttcol> t>
<dl spacing="normal" indent="3" newline="false" pn="sect
<c>1</c> ion-5.4-4.2.2.6.2.2.2.4.2">
<dt pn="section-5.4-4.2.2.6.2.2.2.4.2.1">Media directi
<c>Video</c> on:</dt>
<dd pn="section-5.4-4.2.2.6.2.2.2.4.2.2">forward</dd>
<c>0s</c> <dt pn="section-5.4-4.2.2.6.2.2.2.4.2.3">Number of med
ia sources:</dt>
<c>119s</c> <dd pn="section-5.4-4.2.2.6.2.2.2.4.2.4">three (3)</dd
>
<c>2</c> <dt pn="section-5.4-4.2.2.6.2.2.2.4.2.5">Media timelin
e:</dt>
<c>Video</c> <dd pn="section-5.4-4.2.2.6.2.2.2.4.2.6">New media flo
ws are added
<c>20s</c> sequentially, at short time intervals. See the test-spec
ific setup below.</dd>
<c>119s</c> </dl>
</dd>
<c>3</c> </dl>
</dd>
<c>Video</c> <dt pn="section-5.4-4.2.2.6.2.3">Competing traffic: </dt>
<dd pn="section-5.4-4.2.2.6.2.4">
<c>40s</c> <t indent="0" pn="section-5.4-4.2.2.6.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
<c>119s</c> 5.4-4.2.2.6.2.4.2">
<dt pn="section-5.4-4.2.2.6.2.4.2.1">Number of sources:</d
<c>4</c> t>
<dd pn="section-5.4-4.2.2.6.2.4.2.2">zero (0)</dd>
<c>Audio</c> </dl>
</dd>
<c>0s</c> </dl>
</dd>
<c>119s</c> </dl>
</dd>
<c>5</c> <dt pn="section-5.4-4.3">Test-specific information:</dt>
<dd pn="section-5.4-4.4">
<c>Audio</c> <xref target="MTL_CF" format="default" sectionFormat="of" derivedCon
tent="Table 5"/> defines the
<c>20s</c> media timeline for both media types.</dd>
</dl>
<c>119s</c> <table anchor="MTL_CF" align="center" pn="table-5">
<name slugifiedName="name-media-timelines-for-video-a">Media Timelines
<c>6</c> for Video and Audio Media Sources</name>
<thead>
<c>Audio</c> <tr>
<th align="left" colspan="1" rowspan="1">Flow ID</th>
<c>40s</c> <th align="left" colspan="1" rowspan="1">Media type</th>
<th align="left" colspan="1" rowspan="1">Start time</th>
<c>119s</c> <th align="left" colspan="1" rowspan="1">End time</th>
</texttable> </tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">Video</td>
<td align="left" colspan="1" rowspan="1">0 s</td>
<td align="left" colspan="1" rowspan="1">119 s</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">Video</td>
<td align="left" colspan="1" rowspan="1">20 s</td>
<td align="left" colspan="1" rowspan="1">119 s</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">Video</td>
<td align="left" colspan="1" rowspan="1">40 s</td>
<td align="left" colspan="1" rowspan="1">119 s</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">Audio</td>
<td align="left" colspan="1" rowspan="1">0 s</td>
<td align="left" colspan="1" rowspan="1">119 s</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">Audio</td>
<td align="left" colspan="1" rowspan="1">20 s</td>
<td align="left" colspan="1" rowspan="1">119 s</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">Audio</td>
<td align="left" colspan="1" rowspan="1">40 s</td>
<td align="left" colspan="1" rowspan="1">119 s</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.5
<section title="Round Trip Time Fairness"> ">
<t>In this test case, multiple media flows share the bottleneck link, <name slugifiedName="name-round-trip-time-fairness">Round Trip Time Fair
ness</name>
<t indent="0" pn="section-5.5-1">In this test case, multiple media flows
share the bottleneck link,
but the one-way propagation delay for each flow is different. For the but the one-way propagation delay for each flow is different. For the
sake of simplicity it is assumed that there are no other competing sake of simplicity, it is assumed that there are no other competing
traffic sources in the bottleneck link and that there is sufficient traffic sources in the bottleneck link and that there is sufficient
capacity to accommodate all the flows. While this appears to be a capacity to accommodate all the flows. While this appears to be a
variant of test case 5.2, it focuses on the capacity sharing aspect of variant of test case 5.2 (<xref target="VACM" format="default" sectionFo
rmat="of" derivedContent="Section 5.2"/>),
it focuses on the capacity-sharing aspect of
the candidate algorithm under different RTTs.</t> the candidate algorithm under different RTTs.</t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.5-2">
<t>Expected behavior: It is expected that the competing flows will <dt pn="section-5.5-2.1">Expected behavior:</dt>
<dd pn="section-5.5-2.2">It is expected that the competing flows will
converge to bit rates to accommodate all the flows with minimum converge to bit rates to accommodate all the flows with minimum
possible latency and loss. The effectiveness of the algorithm depends possible latency and loss. The effectiveness of the algorithm depends
on how fast and fairly the competing flows converge to their steady on how fast and fairly the competing flows converge to their steady
states irrespective of the RTT observed.</t> states irrespective of the RTT observed.</dd>
<dt pn="section-5.5-2.3">Evaluation metrics:</dt>
<t>Evaluation metrics : as described in <xref target="EM"/>.</t> <dd pn="section-5.5-2.4">As described in <xref target="EM" format="def
ault" sectionFormat="of" derivedContent="Section 4.1"/>.</dd>
<t>Testbed Topology: Five (5) media sources S1,S2,..,S5 are connected <dt pn="section-5.5-2.5">Testbed topology: </dt>
to their corresponding media sinks R1,R2,..,R5. The media traffic is <dd pn="section-5.5-2.6">Five (5) media sources S1..S5 are connected
transported over the forward path and corresponding feedback/control to their corresponding media sinks R1..R5. The media traffic is
transported over the forward path, and the corresponding feedback/contro
l
traffic is transported over the backward path. The topology is the traffic is transported over the backward path. The topology is the
same as in <xref target="competing-rmcat-flow"/>.</t> same as in <xref target="competing-rmcat-flow" format="default" sectionF
ormat="of" derivedContent="Section 5.4"/>.</dd>
<t>Testbed attributes:</t> <dt pn="section-5.5-2.7">Testbed attributes: </dt>
<dd pn="section-5.5-2.8">
<t><list style="symbols"> <t indent="0" pn="section-5.5-2.8.1"><br/></t>
<t>Test duration: 300s</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.5-2.8.
2">
<t>Path characteristics: <list style="symbols"> <dt pn="section-5.5-2.8.2.1">Test duration:</dt>
<t>Reference bottleneck capacity: 4Mbps</t> <dd pn="section-5.5-2.8.2.2">300 s</dd>
<dt pn="section-5.5-2.8.2.3">Path characteristics: </dt>
<t>Path capacity ratio: 1.0</t> <dd pn="section-5.5-2.8.2.4">
<t indent="0" pn="section-5.5-2.8.2.4.1"><br/></t>
<t>One-Way propagation delay for each flow: 10ms for S1-R1, <dl spacing="normal" indent="3" newline="false" pn="section-5.5-
25ms for S2-R2, 50ms for S3-R3, 100ms for S4-R4, and 150ms 2.8.2.4.2">
S5-R5.</t> <dt pn="section-5.5-2.8.2.4.2.1">Reference bottleneck capacity
</list></t> :</dt>
<dd pn="section-5.5-2.8.2.4.2.2">4 Mbps</dd>
<t>Application-related: <list style="symbols"> <dt pn="section-5.5-2.8.2.4.2.3">Path capacity ratio:</dt>
<t>Media Source: <list style="symbols"> <dd pn="section-5.5-2.8.2.4.2.4">1.0</dd>
<t>Media type: Video<list style="symbols"> <dt pn="section-5.5-2.8.2.4.2.5">One-way propagation delay for
<t>Media direction: forward</t> each flow:</dt>
<dd pn="section-5.5-2.8.2.4.2.6">10 ms for S1-R1,
<t>Number of media sources: five (5)</t> 25 ms for S2-R2, 50 ms for S3-R3, 100 ms for S4-R4, and 150 ms
S5-R5.</dd>
<t>Media timeline: new media flows are added </dl>
sequentially, at short time intervals. See test </dd>
specific setup below.</t> <dt pn="section-5.5-2.8.2.5">Application-related: </dt>
</list></t> <dd pn="section-5.5-2.8.2.6">
<t indent="0" pn="section-5.5-2.8.2.6.1"><br/></t>
<t>Media type: Audio<list style="symbols"> <dl spacing="normal" indent="3" newline="false" pn="section-5.5-
<t>Media direction: forward.</t> 2.8.2.6.2">
<dt pn="section-5.5-2.8.2.6.2.1">Media source: </dt>
<t>Number of media sources: five (5)</t> <dd pn="section-5.5-2.8.2.6.2.2">
<t indent="0" pn="section-5.5-2.8.2.6.2.2.1"><br/></t>
<t>Media timeline: new media flows are added <dl spacing="normal" indent="3" newline="false" pn="section-
sequentially, at short time intervals. See test 5.5-2.8.2.6.2.2.2">
specific setup below.</t> <dt pn="section-5.5-2.8.2.6.2.2.2.1">Media type:</dt>
</list></t> <dd pn="section-5.5-2.8.2.6.2.2.2.2">
</list></t> <t indent="0" pn="section-5.5-2.8.2.6.2.2.2.2.1">Video</
t>
<t>Competing traffic: <list style="symbols"> <dl spacing="normal" indent="3" newline="false" pn="sect
<t>Number of sources : zero (0)</t> ion-5.5-2.8.2.6.2.2.2.2.2">
</list></t> <dt pn="section-5.5-2.8.2.6.2.2.2.2.2.1">Media directi
</list></t> on:</dt>
<dd pn="section-5.5-2.8.2.6.2.2.2.2.2.2">forward</dd>
<t>Test Specific Information: <xref target="MTL_RTT"/> defines the <dt pn="section-5.5-2.8.2.6.2.2.2.2.2.3">Number of med
media timeline for both media type.</t> ia sources:</dt>
</list></t> <dd pn="section-5.5-2.8.2.6.2.2.2.2.2.4">five (5)</dd>
<dt pn="section-5.5-2.8.2.6.2.2.2.2.2.5">Media timelin
<texttable anchor="MTL_RTT" e:</dt>
title="Media Timeline for Video and Audio media sources"> <dd pn="section-5.5-2.8.2.6.2.2.2.2.2.6">New media flo
<ttcol>Flow IF</ttcol> ws are added
sequentially, at short time intervals. See the
<ttcol>Media type</ttcol> test-specific setup below.</dd>
</dl>
<ttcol>Start time</ttcol> </dd>
<dt pn="section-5.5-2.8.2.6.2.2.2.3">Media type:</dt>
<ttcol>End time</ttcol> <dd pn="section-5.5-2.8.2.6.2.2.2.4">
<t indent="0" pn="section-5.5-2.8.2.6.2.2.2.4.1">Audio</
<c>1</c> t>
<dl spacing="normal" indent="3" newline="false" pn="sect
<c>Video</c> ion-5.5-2.8.2.6.2.2.2.4.2">
<dt pn="section-5.5-2.8.2.6.2.2.2.4.2.1">Media directi
<c>0s</c> on:</dt>
<dd pn="section-5.5-2.8.2.6.2.2.2.4.2.2">forward</dd>
<c>299s</c> <dt pn="section-5.5-2.8.2.6.2.2.2.4.2.3">Number of med
ia sources:</dt>
<c>2</c> <dd pn="section-5.5-2.8.2.6.2.2.2.4.2.4"> five (5)</dd
>
<c>Video</c> <dt pn="section-5.5-2.8.2.6.2.2.2.4.2.5">Media timelin
e:</dt>
<c>10s</c> <dd pn="section-5.5-2.8.2.6.2.2.2.4.2.6">New media flo
ws are added
<c>299s</c> sequentially, at short time intervals. See the
test-specific setup below.</dd>
<c>3</c> </dl>
</dd>
<c>Video</c> </dl>
</dd>
<c>20s</c> <dt pn="section-5.5-2.8.2.6.2.3">Competing traffic: </dt>
<dd pn="section-5.5-2.8.2.6.2.4">
<c>299s</c> <t indent="0" pn="section-5.5-2.8.2.6.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
<c>4</c> 5.5-2.8.2.6.2.4.2">
<dt pn="section-5.5-2.8.2.6.2.4.2.1">Number of sources:</d
<c>Video</c> t>
<dd pn="section-5.5-2.8.2.6.2.4.2.2">zero (0)</dd>
<c>30s</c> </dl>
</dd>
<c>299s</c> </dl>
</dd>
<c>5</c> </dl>
</dd>
<c>Video</c> <dt pn="section-5.5-2.9">Test-specific information: </dt>
<dd pn="section-5.5-2.10">
<c>40s</c> <xref target="MTL_RTT" format="default" sectionFormat="of" derivedCo
ntent="Table 6"/> defines the
<c>299s</c> media timeline for both media types.</dd>
</dl>
<c>6</c> <table anchor="MTL_RTT" align="center" pn="table-6">
<name slugifiedName="name-media-timeline-for-video-an">Media Timeline
<c>Audio</c> for Video and Audio Media Sources</name>
<thead>
<c>0</c> <tr>
<th align="left" colspan="1" rowspan="1">Flow ID</th>
<c>299s</c> <th align="left" colspan="1" rowspan="1">Media type</th>
<th align="left" colspan="1" rowspan="1">Start time</th>
<c>7</c> <th align="left" colspan="1" rowspan="1">End time</th>
</tr>
<c>Audio</c> </thead>
<tbody>
<c>10s</c> <tr>
<td align="left" colspan="1" rowspan="1">1</td>
<c>299s</c> <td align="left" colspan="1" rowspan="1">Video</td>
<td align="left" colspan="1" rowspan="1">0 s</td>
<c>8</c> <td align="left" colspan="1" rowspan="1">299 s</td>
</tr>
<c>Audio</c> <tr>
<td align="left" colspan="1" rowspan="1">2</td>
<c>20s</c> <td align="left" colspan="1" rowspan="1">Video</td>
<td align="left" colspan="1" rowspan="1">10 s</td>
<c>299s</c> <td align="left" colspan="1" rowspan="1">299 s</td>
</tr>
<c>9</c> <tr>
<td align="left" colspan="1" rowspan="1">3</td>
<c>Audio</c> <td align="left" colspan="1" rowspan="1">Video</td>
<td align="left" colspan="1" rowspan="1">20 s</td>
<c>30s</c> <td align="left" colspan="1" rowspan="1">299 s</td>
</tr>
<c>299s</c> <tr>
<td align="left" colspan="1" rowspan="1">4</td>
<c>10</c> <td align="left" colspan="1" rowspan="1">Video</td>
<td align="left" colspan="1" rowspan="1">30 s</td>
<c>Audio</c> <td align="left" colspan="1" rowspan="1">299 s</td>
</tr>
<c>40s</c> <tr>
<td align="left" colspan="1" rowspan="1">5</td>
<c>299s</c> <td align="left" colspan="1" rowspan="1">Video</td>
</texttable> <td align="left" colspan="1" rowspan="1">40 s</td>
<td align="left" colspan="1" rowspan="1">299 s</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">Audio</td>
<td align="left" colspan="1" rowspan="1">0 s</td>
<td align="left" colspan="1" rowspan="1">299 s</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">Audio</td>
<td align="left" colspan="1" rowspan="1">10 s</td>
<td align="left" colspan="1" rowspan="1">299 s</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">Audio</td>
<td align="left" colspan="1" rowspan="1">20 s</td>
<td align="left" colspan="1" rowspan="1">299 s</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">Audio</td>
<td align="left" colspan="1" rowspan="1">30 s</td>
<td align="left" colspan="1" rowspan="1">299 s</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">10</td>
<td align="left" colspan="1" rowspan="1">Audio</td>
<td align="left" colspan="1" rowspan="1">40 s</td>
<td align="left" colspan="1" rowspan="1">299 s</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.6
<section title="Media Flow Competing with a Long TCP Flow"> ">
<t>In this test case, one or more media flows share the bottleneck <name slugifiedName="name-media-flow-competing-with-a">Media Flow Compet
link with at least one long lived TCP flow. Long lived TCP flows ing with a Long TCP Flow</name>
<t indent="0" pn="section-5.6-1">In this test case, one or more media fl
ows share the bottleneck
link with at least one long-lived TCP flow. Long-lived TCP flows
download data throughout the session and are expected to have infinite download data throughout the session and are expected to have infinite
amount of data to send and receive. This is a scenario where a amount of data to send and receive. This is a scenario where a
multimedia application co-exists with a large file download. The test multimedia application coexists with a large file download. The test
case measures the adaptivity of the candidate algorithm to competing case measures the adaptivity of the candidate algorithm to competing
traffic. It addresses the requirement 3 in <xref traffic. It addresses requirement 3 in <xref target="RFC8836" section="2
target="I-D.ietf-rmcat-cc-requirements"/>.</t> " sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rf
c8836#section-2" derivedContent="RFC8836"/>.</t>
<t>Expected behavior: depending on the convergence observed in test <dl spacing="normal" indent="3" newline="false" pn="section-5.6-2">
case 5.1 and 5.2, the candidate algorithm may be able to avoid <dt pn="section-5.6-2.1">Expected behavior:</dt>
<dd pn="section-5.6-2.2">Depending on the convergence observed in test
cases 5.1 and 5.2, the candidate algorithm may be able to avoid
congestion collapse. In the worst case, the media stream will fall to congestion collapse. In the worst case, the media stream will fall to
the minimum media bit rate.</t> the minimum media bit rate.</dd>
<dt pn="section-5.6-2.3">Evaluation metrics:</dt>
<t>Evaluation metrics : following metrics in addition to as described <dd pn="section-5.6-2.4">
in <xref target="EM"/>. <list style="numbers"> <t indent="0" pn="section-5.6-2.4.1">Includes the following metrics
<t>Flow level: <list style="letters"> in addition to those described
<t>TCP throughput.</t> in <xref target="EM" format="default" sectionFormat="of" derivedContent=
"Section 4.1"/>: </t>
<t>Loss for the TCP flow</t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="sectio
</list></t> n-5.6-2.4.2">
</list></t> <li pn="section-5.6-2.4.2.1" derivedCounter="1.">
<t indent="0" pn="section-5.6-2.4.2.1.1">Flow level: </t>
<t>Testbed topology: One (1) media source S1 is connected to the <ol spacing="normal" type="a" indent="adaptive" start="1" pn="se
corresponding media sink, R1. In addition, there is a long-live TCP ction-5.6-2.4.2.1.2">
<li pn="section-5.6-2.4.2.1.2.1" derivedCounter="a.">TCP thro
ughput</li>
<li pn="section-5.6-2.4.2.1.2.2" derivedCounter="b.">Loss for
the TCP flow</li>
</ol>
</li>
</ol>
</dd>
<dt pn="section-5.6-2.5">Testbed topology:</dt>
<dd pn="section-5.6-2.6">One (1) media source S1 is connected to the
corresponding media sink, R1. In addition, there is a long-lived TCP
flow sharing the same bottleneck link. The media traffic is flow sharing the same bottleneck link. The media traffic is
transported over the forward path and corresponding feedback/control transported over the forward path, and the corresponding feedback/contro l
traffic is transported over the backward path. The TCP traffic goes traffic is transported over the backward path. The TCP traffic goes
over the forward path from, S_tcp with acknowledgment packets go over over the forward path from S_tcp with acknowledgment packets going over
the backward path from, R_tcp.</t> the backward path from R_tcp.</dd>
</dl>
<t><figure anchor="fig-eval-topo-4-4" <figure anchor="fig-eval-topo-4-4" align="left" suppress-title="false" p
title="Testbed Topology for TCP vs congestion controlled media Flows n="figure-6">
"> <name slugifiedName="name-testbed-topology-for-tcp-vs">Testbed Topolog
<artwork><![CDATA[ y for TCP vs Congestion-Controlled Media Flows</name>
+--+ +--+ <artwork name="" type="" align="left" alt="" pn="section-5.6-3.1">
|S1|===== \ Forward --> / =====|R1| +--+ +--+
+--+ \\ // +--+ |S1|===== \ Forward --&gt; / =====|R1|
\\ // +--+ \\ // +--+
+-----+ +-----+ \\ //
| A |---------------------------->| B | +-----+ +-----+
| |<----------------------------| | | A |----------------------------&gt;| B |
+-----+ +-----+ | |&lt;----------------------------| |
// <-- Backward \\ +-----+ +-----+
+-----+ // \\ +-----+ // &lt;-- Backward \\
|S_tcp|=== / \ ===|R_tcp| +-----+ // \\ +-----+
+-----+ +-----+ |S_tcp|=== / \ ===|R_tcp|
]]></artwork> +-----+ +-----+
</figure></t> </artwork>
</figure>
<t>Testbed attributes:</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.6-4">
<dt pn="section-5.6-4.1">Testbed attributes:</dt>
<t><list style="symbols"> <dd pn="section-5.6-4.2">
<t>Test duration: 120s</t> <t indent="0" pn="section-5.6-4.2.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.6-4.2.
<t>Path characteristics: <list style="symbols"> 2">
<t>Reference bottleneck capacity: 2Mbps</t> <dt pn="section-5.6-4.2.2.1">Test duration:</dt>
<dd pn="section-5.6-4.2.2.2">120 s</dd>
<t>Path capacity ratio: 1.0</t> <dt pn="section-5.6-4.2.2.3">Path characteristics:</dt>
<dd pn="section-5.6-4.2.2.4">
<!-- <t>One-Way propagation delay: [10ms, 150ms]</t> --> <t indent="0" pn="section-5.6-4.2.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.6-
<t>Bottleneck queue size: [300ms, 1000ms]</t> 4.2.2.4.2">
</list></t> <dt pn="section-5.6-4.2.2.4.2.1">Reference bottleneck capacity
:</dt>
<t>Application-related: <list style="symbols"> <dd pn="section-5.6-4.2.2.4.2.2">2 Mbps</dd>
<t>Media Source: <list style="symbols"> <dt pn="section-5.6-4.2.2.4.2.3">Path capacity ratio:</dt>
<t>Media type: Video<list style="symbols"> <dd pn="section-5.6-4.2.2.4.2.4">1.0</dd>
<t>Media direction: forward</t> <dt pn="section-5.6-4.2.2.4.2.5">Bottleneck queue size:</dt>
<dd pn="section-5.6-4.2.2.4.2.6">[300 ms, 1000 ms]</dd>
<t>Number of media sources: one (1)</t> </dl>
</dd>
<t>Media timeline: <list style="symbols"> <dt pn="section-5.6-4.2.2.5">Application-related:</dt>
<t>Start time: 5s.</t> <dd pn="section-5.6-4.2.2.6">
<t indent="0" pn="section-5.6-4.2.2.6.1"><br/></t>
<t>End time: 119s.</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.6-
</list></t> 4.2.2.6.2">
</list></t> <dt pn="section-5.6-4.2.2.6.2.1">Media source:</dt>
<dd pn="section-5.6-4.2.2.6.2.2">
<t>Media type: Audio<list style="symbols"> <t indent="0" pn="section-5.6-4.2.2.6.2.2.1"><br/></t>
<t>Media direction: forward</t> <dl spacing="normal" indent="3" newline="false" pn="section-
5.6-4.2.2.6.2.2.2">
<t>Number of media sources: one (1)</t> <dt pn="section-5.6-4.2.2.6.2.2.2.1">Media type:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.2">
<t>Media timeline: <list style="symbols"> <t indent="0" pn="section-5.6-4.2.2.6.2.2.2.2.1">Video</
<t>Start time: 5s.</t> t>
<dl spacing="normal" indent="3" newline="false" pn="sect
<t>End time: 119s.</t> ion-5.6-4.2.2.6.2.2.2.2.2">
</list></t> <dt pn="section-5.6-4.2.2.6.2.2.2.2.2.1">Media directi
</list></t> on:</dt>
</list></t> <dd pn="section-5.6-4.2.2.6.2.2.2.2.2.2">forward</dd>
<dt pn="section-5.6-4.2.2.6.2.2.2.2.2.3">Number of med
<t>Additionally, implementers are encouraged to run the ia sources:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.2.2.4">one (1)</dd>
<dt pn="section-5.6-4.2.2.6.2.2.2.2.2.5">Media timelin
e:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.2.2.6">
<t indent="0" pn="section-5.6-4.2.2.6.2.2.2.2.2.6.1"
><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="
section-5.6-4.2.2.6.2.2.2.2.2.6.2">
<dt pn="section-5.6-4.2.2.6.2.2.2.2.2.6.2.1">Start
time:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.2.2.6.2.2">5 s</
dd>
<dt pn="section-5.6-4.2.2.6.2.2.2.2.2.6.2.3">End t
ime:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.2.2.6.2.4">119 s
</dd>
</dl>
</dd>
</dl>
</dd>
<dt pn="section-5.6-4.2.2.6.2.2.2.3">Media type:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.4">
<t indent="0" pn="section-5.6-4.2.2.6.2.2.2.4.1">Audio</
t>
<dl spacing="normal" indent="3" newline="false" pn="sect
ion-5.6-4.2.2.6.2.2.2.4.2">
<dt pn="section-5.6-4.2.2.6.2.2.2.4.2.1">Media directi
on:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.4.2.2">forward</dd>
<dt pn="section-5.6-4.2.2.6.2.2.2.4.2.3">Number of med
ia sources:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.4.2.4">one (1)</dd>
<dt pn="section-5.6-4.2.2.6.2.2.2.4.2.5">Media timelin
e:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.4.2.6">
<t indent="0" pn="section-5.6-4.2.2.6.2.2.2.4.2.6.1"
><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="
section-5.6-4.2.2.6.2.2.2.4.2.6.2">
<dt pn="section-5.6-4.2.2.6.2.2.2.4.2.6.2.1">Start
time:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.4.2.6.2.2">5 s</
dd>
<dt pn="section-5.6-4.2.2.6.2.2.2.4.2.6.2.3">End t
ime:</dt>
<dd pn="section-5.6-4.2.2.6.2.2.2.4.2.6.2.4">119 s
</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
<t indent="0" pn="section-5.6-4.2.2.6.2.2.3">Additionally, i
mplementers are encouraged to run the
experiment with multiple media sources.</t> experiment with multiple media sources.</t>
</dd>
<t>Competing traffic: <list style="symbols"> <dt pn="section-5.6-4.2.2.6.2.3">Competing traffic:</dt>
<t>Number and Types of sources : one (1) and long-lived <dd pn="section-5.6-4.2.2.6.2.4">
TCP</t> <t indent="0" pn="section-5.6-4.2.2.6.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
<t>Traffic direction : forward</t> 5.6-4.2.2.6.2.4.2">
<dt pn="section-5.6-4.2.2.6.2.4.2.1">Number and types of s
<t>Congestion control: default TCP congestion control<xref ources:</dt>
target="RFC5681"/>. Implementers are also encouraged to <dd pn="section-5.6-4.2.2.6.2.4.2.2">one (1) and long-live
run the experiment with alternative TCP congestion control d TCP</dd>
algorithm.<!----></t> <dt pn="section-5.6-4.2.2.6.2.4.2.3">Traffic direction:</d
t>
<t>Traffic timeline: <list style="symbols"> <dd pn="section-5.6-4.2.2.6.2.4.2.4">forward</dd>
<t>Start time: 0s.</t> <dt pn="section-5.6-4.2.2.6.2.4.2.5">Congestion control:</
dt>
<!----> <dd pn="section-5.6-4.2.2.6.2.4.2.6">default TCP congestio
n control
<t>End time: 119s.</t> <xref target="RFC5681" format="default" sectionFormat="of
</list></t> " derivedContent="RFC5681"/>. Implementers are also encouraged to
</list></t> run the experiment with alternative TCP congestion contro
</list></t> l algorithms.</dd>
<dt pn="section-5.6-4.2.2.6.2.4.2.7">Traffic timeline: </d
<t>Test Specific Information: none</t> t>
</list></t> <dd pn="section-5.6-4.2.2.6.2.4.2.8">
<t indent="0" pn="section-5.6-4.2.2.6.2.4.2.8.1"><br/></
t>
<dl spacing="normal" indent="3" newline="false" pn="sect
ion-5.6-4.2.2.6.2.4.2.8.2">
<dt pn="section-5.6-4.2.2.6.2.4.2.8.2.1">Start time:</
dt>
<dd pn="section-5.6-4.2.2.6.2.4.2.8.2.2">0 s</dd>
<dt pn="section-5.6-4.2.2.6.2.4.2.8.2.3">End time:</dt
>
<dd pn="section-5.6-4.2.2.6.2.4.2.8.2.4">119 s</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</dd>
<dt pn="section-5.6-4.3">Test-specific information:</dt>
<dd pn="section-5.6-4.4">none</dd>
</dl>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.7
<section title="Media Flow Competing with Short TCP Flows"> ">
<t>In this test case, one or more congestion controlled media flow <name slugifiedName="name-media-flow-competing-with-s">Media Flow Compet
shares the bottleneck link with multiple short-lived TCP flows. ing with Short TCP Flows</name>
Short-lived TCP flows resemble the on/off pattern observed in the web <t indent="0" pn="section-5.7-1">In this test case, one or more congesti
on-controlled media flows
share the bottleneck link with multiple short-lived TCP flows.
Short-lived TCP flows resemble the on/off pattern observed in web
traffic, wherein clients (for example, browsers) connect to a server traffic, wherein clients (for example, browsers) connect to a server
and download a resource (typically a web page, few images, text files, and download a resource (typically a web page, few images, text files,
etc.) using several TCP connections. This scenario shows the etc.) using several TCP connections. This scenario shows the
performance of a multimedia application when several browser windows performance of a multimedia application when several browser windows
are active. The test case measures the adaptivity of the candidate are active. The test case measures the adaptivity of the candidate
algorithm to competing web traffic, it addresses the requirements 1.E algorithm to competing web traffic, and it addresses requirement 1.E
in <xref target="I-D.ietf-rmcat-cc-requirements"/>.</t> in <xref target="RFC8836" section="2" sectionFormat="of" format="default
" derivedLink="https://rfc-editor.org/rfc/rfc8836#section-2" derivedContent="RFC
<t>Depending on the number of short TCP flows, the cross-traffic 8836"/>.</t>
either appears as a short burst flow or resembles a long TCP flow. The <t indent="0" pn="section-5.7-2">Depending on the number of short TCP fl
intention of this test is to observe the impact of short-term burst on ows, the cross traffic
either appears as a short burst flow or resembles a long-lived TCP flow.
The
intention of this test is to observe the impact of a short-term burst on
the behavior of the candidate algorithm.</t> the behavior of the candidate algorithm.</t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.7-3">
<t>Expected behavior: The candidate algorithm is expected to avoid <dt pn="section-5.7-3.1">Expected behavior:</dt>
<dd pn="section-5.7-3.2"> The candidate algorithm is expected to avoid
flow starvation during the presence of short and bursty competing TCP flow starvation during the presence of short and bursty competing TCP
flows, streaming at least at the minimum media bit rate. After flows, streaming at least at the minimum media bit rate. After
competing TCP flows terminate, the media streams are expected to be competing TCP flows terminate, the media streams are expected to be
robust enough to eventually recover to previous steady state behavior, robust enough to eventually recover to previous steady state behavior,
and at the very least, avoid persistent starvation.</t> and at the very least, avoid persistent starvation.</dd>
<dt pn="section-5.7-3.3">Evaluation metrics:</dt>
<t>Evaluation metrics : following metrics in addition to as described <dd pn="section-5.7-3.4">
in <xref target="EM"/>.<list style="numbers"> <t indent="0" pn="section-5.7-3.4.1">Includes the following metrics
<t>Flow level: <list style="letters"> in addition to those described
<t>Variation in the sending rate of the TCP flow.</t> in <xref target="EM" format="default" sectionFormat="of" derivedContent=
"Section 4.1"/>:</t>
<t>TCP throughput.</t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="sectio
</list></t> n-5.7-3.4.2">
</list></t> <li pn="section-5.7-3.4.2.1" derivedCounter="1.">
<t indent="0" pn="section-5.7-3.4.2.1.1">Flow level: </t>
<t>Testbed topology: The topology described here is same as the one <ol spacing="normal" type="A" indent="adaptive" start="1" pn="se
described in <xref target="fig-eval-topo-4-4"/>.</t> ction-5.7-3.4.2.1.2">
<li pn="section-5.7-3.4.2.1.2.1" derivedCounter="A.">Variation in t
<t>Testbed attributes:</t> he sending rate of the TCP flow</li>
<li pn="section-5.7-3.4.2.1.2.2" derivedCounter="B.">TCP throu
<t><list style="symbols"> ghput</li>
<t>Test duration: 300s</t> </ol>
</li>
<t>Path characteristics: <list style="symbols"> </ol>
<t>Reference bottleneck capacity: 2.0Mbps</t> </dd>
<dt pn="section-5.7-3.5">Testbed topology:</dt>
<t>Path capacity ratio: 1.0</t> <dd pn="section-5.7-3.6">The topology described here is the same as th
e one
<!-- <t>One-Way propagation delay: [10ms, 150ms]</t> --> described in <xref target="fig-eval-topo-4-4" format="default" sectionFo
</list></t> rmat="of" derivedContent="Figure 6"/>.</dd>
<dt pn="section-5.7-3.7">Testbed attributes:</dt>
<t>Application-related: <list style="symbols"> <dd pn="section-5.7-3.8">
<t>Media source: <list style="symbols"> <t indent="0" pn="section-5.7-3.8.1"><br/></t>
<t>Media type: Video<list style="symbols"> <dl spacing="normal" indent="3" newline="false" pn="section-5.7-3.8.
<t>Media direction: forward</t> 2">
<dt pn="section-5.7-3.8.2.1">Test duration:</dt>
<t>Number of media sources: two (2)</t> <dd pn="section-5.7-3.8.2.2">300 s</dd>
<dt pn="section-5.7-3.8.2.3">Path characteristics:</dt>
<t>Media timeline: <list style="symbols"> <dd pn="section-5.7-3.8.2.4">
<t>Start time: 5s.</t> <t indent="0" pn="section-5.7-3.8.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.7-
<t>End time: 299s.</t> 3.8.2.4.2">
</list></t> <dt pn="section-5.7-3.8.2.4.2.1">Reference bottleneck capacity
</list></t> :</dt>
<dd pn="section-5.7-3.8.2.4.2.2">2.0 Mbps</dd>
<t>Media type: Audio<list style="symbols"> <dt pn="section-5.7-3.8.2.4.2.3">Path capacity ratio:</dt>
<t>Media direction: forward</t> <dd pn="section-5.7-3.8.2.4.2.4">1.0</dd>
</dl>
<t>Number of media sources: two (2)</t> </dd>
<dt pn="section-5.7-3.8.2.5">Application-related: </dt>
<t>Media timeline: <list style="symbols"> <dd pn="section-5.7-3.8.2.6">
<t>Start time: 5s.</t> <t indent="0" pn="section-5.7-3.8.2.6.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.7-
<t>End time: 299s.</t> 3.8.2.6.2">
</list></t> <dt pn="section-5.7-3.8.2.6.2.1">Media source: </dt>
</list></t> <dd pn="section-5.7-3.8.2.6.2.2">
</list></t> <t indent="0" pn="section-5.7-3.8.2.6.2.2.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
<t>Competing traffic: <list style="symbols"> 5.7-3.8.2.6.2.2.2">
<t>Number and Types of sources : ten (10), short-lived TCP <dt pn="section-5.7-3.8.2.6.2.2.2.1">Media type:</dt>
flows.</t> <dd pn="section-5.7-3.8.2.6.2.2.2.2">
<t indent="0" pn="section-5.7-3.8.2.6.2.2.2.2.1">Video</
<t>Traffic direction : forward</t> t>
<dl spacing="normal" indent="3" newline="false" pn="sect
<t>Congestion algorithm: default TCP Congestion control ion-5.7-3.8.2.6.2.2.2.2.2">
<xref target="RFC5681"/>. Implementers are also encouraged <dt pn="section-5.7-3.8.2.6.2.2.2.2.2.1">Media directi
to run the experiment with alternative TCP congestion on:</dt>
control algorithm.</t> <dd pn="section-5.7-3.8.2.6.2.2.2.2.2.2">forward</dd>
<dt pn="section-5.7-3.8.2.6.2.2.2.2.2.3">Number of med
<t>Traffic timeline: each short TCP flow is modeled as a ia sources:</dt>
<dd pn="section-5.7-3.8.2.6.2.2.2.2.2.4">two (2)</dd>
<dt pn="section-5.7-3.8.2.6.2.2.2.2.2.5">Media timelin
e: </dt>
<dd pn="section-5.7-3.8.2.6.2.2.2.2.2.6">
<t indent="0" pn="section-5.7-3.8.2.6.2.2.2.2.2.6.1"
><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="
section-5.7-3.8.2.6.2.2.2.2.2.6.2">
<dt pn="section-5.7-3.8.2.6.2.2.2.2.2.6.2.1">Start
time:</dt>
<dd pn="section-5.7-3.8.2.6.2.2.2.2.2.6.2.2">5 s</
dd>
<dt pn="section-5.7-3.8.2.6.2.2.2.2.2.6.2.3">End t
ime:</dt>
<dd pn="section-5.7-3.8.2.6.2.2.2.2.2.6.2.4">299 s
</dd>
</dl>
</dd>
</dl>
</dd>
<dt pn="section-5.7-3.8.2.6.2.2.2.3">Media type:</dt>
<dd pn="section-5.7-3.8.2.6.2.2.2.4">
<t indent="0" pn="section-5.7-3.8.2.6.2.2.2.4.1">Audio</
t>
<dl spacing="normal" indent="3" newline="false" pn="sect
ion-5.7-3.8.2.6.2.2.2.4.2">
<dt pn="section-5.7-3.8.2.6.2.2.2.4.2.1">Media directi
on:</dt>
<dd pn="section-5.7-3.8.2.6.2.2.2.4.2.2">forward</dd>
<dt pn="section-5.7-3.8.2.6.2.2.2.4.2.3">Number of med
ia sources:</dt>
<dd pn="section-5.7-3.8.2.6.2.2.2.4.2.4"> two (2)</dd>
<dt pn="section-5.7-3.8.2.6.2.2.2.4.2.5">Media timelin
e: </dt>
<dd pn="section-5.7-3.8.2.6.2.2.2.4.2.6">
<t indent="0" pn="section-5.7-3.8.2.6.2.2.2.4.2.6.1"
><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="
section-5.7-3.8.2.6.2.2.2.4.2.6.2">
<dt pn="section-5.7-3.8.2.6.2.2.2.4.2.6.2.1">Start
time:</dt>
<dd pn="section-5.7-3.8.2.6.2.2.2.4.2.6.2.2"> 5 s<
/dd>
<dt pn="section-5.7-3.8.2.6.2.2.2.4.2.6.2.3">End t
ime: </dt>
<dd pn="section-5.7-3.8.2.6.2.2.2.4.2.6.2.4">299 s
</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</dd>
<dt pn="section-5.7-3.8.2.6.2.3">Competing traffic: </dt>
<dd pn="section-5.7-3.8.2.6.2.4">
<t indent="0" pn="section-5.7-3.8.2.6.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
5.7-3.8.2.6.2.4.2">
<dt pn="section-5.7-3.8.2.6.2.4.2.1">Number and types of s
ources:</dt>
<dd pn="section-5.7-3.8.2.6.2.4.2.2"> ten (10), short-live
d TCP flows.</dd>
<dt pn="section-5.7-3.8.2.6.2.4.2.3">Traffic direction: </
dt>
<dd pn="section-5.7-3.8.2.6.2.4.2.4">forward</dd>
<dt pn="section-5.7-3.8.2.6.2.4.2.5">Congestion algorithm:
</dt>
<dd pn="section-5.7-3.8.2.6.2.4.2.6"> default TCP congesti
on control
<xref target="RFC5681" format="default" sectionFormat="of" d
erivedContent="RFC5681"/>. Implementers are also encouraged
to run the experiment with an alternative TCP congestion
control algorithm.</dd>
<dt pn="section-5.7-3.8.2.6.2.4.2.7">Traffic timeline: </d
t>
<dd pn="section-5.7-3.8.2.6.2.4.2.8">Each short TCP flow i
s modeled as a
sequence of file downloads interleaved with idle periods. sequence of file downloads interleaved with idle periods.
Not all short TCP flows start at the same time, 2 of them Not all short TCP flows start at the same time, two of them
start in the ON state while rest of the 8 flows start in start in the ON state, while rest of the eight flows start i
an OFF state. For description of short TCP flow model see n
test specific information below.</t> an OFF state. For a description of the short TCP flow model,
</list></t> see
</list></t> test-specific information below.</dd>
</dl>
<t>Test Specific Information: <list style="symbols"> </dd>
<t>Short-TCP traffic model: The short TCP model to be used in </dl>
this test is described in <xref </dd>
target="I-D.ietf-rmcat-eval-criteria"/>.</t> </dl>
</list></t> </dd>
</list></t> <dt pn="section-5.7-3.9">Test-specific information: </dt>
<dd pn="section-5.7-3.10">
<t indent="0" pn="section-5.7-3.10.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.7-3.10
.2">
<dt pn="section-5.7-3.10.2.1">Short TCP traffic model:</dt>
<dd pn="section-5.7-3.10.2.2">The short TCP model to be used in
this test is described in <xref target="RFC8868" format="default" se
ctionFormat="of" derivedContent="RFC8868"/>.</dd>
</dl>
</dd>
</dl>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5.8
<section title="Media Pause and Resume"> ">
<t>In this test case, more than one real-time interactive media flows <name slugifiedName="name-media-pause-and-resume">Media Pause and Resume
share the link bandwidth and all flows reach to a steady state by </name>
utilizing the link capacity in an optimum way. At this stage one of <t indent="0" pn="section-5.8-1">In this test case, more than one real-t
ime interactive media flow
share the link bandwidth, and all flows reach to a steady state by
utilizing the link capacity in an optimum way. At this stage, one of
the media flows is paused for a moment. This event will result in more the media flows is paused for a moment. This event will result in more
available bandwidth for the rest of the flows as they are on a shared available bandwidth for the rest of the flows as they are on a shared
link. When the paused media flow resumes it would no longer have the link. When the paused media flow resumes, it no longer has the
same bandwidth share on the link. It has to make its way through the same bandwidth share on the link. It has to make its way through the
other existing flows in the link to achieve a fair share of the link other existing flows in the link to achieve a fair share of the link
capacity. This test case is important specially for real-time capacity. This test case is important specially for real-time
interactive media which consists of more than one media flows and can interactive media, which consists of more than one media flows and can
pause/resume media flows at any point of time during the session. This pause/resume media flows at any point of time during the session. This
test case directly addresses the requirement number 5 in <xref test case directly addresses requirement 5 in
target="I-D.ietf-rmcat-cc-requirements"/>. One can think it as a <xref target="RFC8836" section="2" sectionFormat="of" format="default" d
variation of test case defined in <xref erivedLink="https://rfc-editor.org/rfc/rfc8836#section-2" derivedContent="RFC883
target="competing-rmcat-flow"/>. However, it is different as the 6"/>. One can think of it as a
candidate algorithms can use different strategies to increase its variation of the test case defined in
efficiency, for example in terms of fairness, convergence time, reduce <xref target="competing-rmcat-flow" format="default" sectionFormat="of"
oscillation etc, by capitalizing the fact that they have previous derivedContent="Section 5.4"/>.
However, it is different as the
candidate algorithms can use different strategies to increase
efficiency, for example, in terms of fairness, convergence time,
oscillation reduction, etc., by capitalizing on the fact that they have
previous
information of the link.</t> information of the link.</t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.8-2">
<t>Expected behavior: During the period where the third stream is <dt pn="section-5.8-2.1">Expected behavior:</dt>
<dd pn="section-5.8-2.2">During the period where the third stream is
paused, the two remaining flows are expected to increase their rates paused, the two remaining flows are expected to increase their rates
and reach the maximum media bit rate. When the third stream resumes, and reach the maximum media bit rate. When the third stream resumes,
all three flows are expected to converge to the same original fair all three flows are expected to converge to the same original fair
share of rates prior to the media pause/resume event.</t> share of rates prior to the media pause/resume event.</dd>
<dt pn="section-5.8-2.3">Evaluation metrics:</dt>
<t>Evaluation metrics : following metrics in addition to as described <dd pn="section-5.8-2.4">
in <xref target="EM"/>.<list style="numbers"> <t indent="0" pn="section-5.8-2.4.1">Includes the following metrics
<t>Flow level: <list style="letters"> in addition to those described
<t>Variation in sending bit rate and throughput. Mainly in <xref target="EM" format="default" sectionFormat="of" derivedContent=
observing the frequency and magnitude of oscillations.</t> "Section 4.1"/>:</t>
</list></t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="sectio
</list></t> n-5.8-2.4.2">
<li pn="section-5.8-2.4.2.1" derivedCounter="1.">
<t>Testbed Topology: Same as test case defined in <xref <t indent="0" pn="section-5.8-2.4.2.1.1">Flow level: </t>
target="competing-rmcat-flow"/></t> <ol spacing="normal" type="A" indent="adaptive" start="1" pn="se
ction-5.8-2.4.2.1.2">
<t>Testbed attributes: The general description of the testbed <li pn="section-5.8-2.4.2.1.2.1" derivedCounter="A.">Variation in
parameters are same as <xref target="competing-rmcat-flow"/> with sending bit rate and throughput. Mainly
changes in the test specific setup as below-</t> observing the frequency and magnitude of oscillations.</li>
</ol>
<t><list style="symbols"> </li>
<t>Other test specific setup: <list style="symbols"> </ol>
<t>Media flow timeline: <list style="symbols"> </dd>
<t>Flow ID: one (1)</t> <dt pn="section-5.8-2.5">Testbed topology:</dt>
<dd pn="section-5.8-2.6">Same as the test case defined in <xref target
<t>Start time: 0s</t> ="competing-rmcat-flow" format="default" sectionFormat="of" derivedContent="Sect
ion 5.4"/>.</dd>
<t>Flow duration: 119s</t> <dt pn="section-5.8-2.7">Testbed attributes:</dt>
<dd pn="section-5.8-2.8">
<t>Pause time: not required</t> <t indent="0" pn="section-5.8-2.8.1">The general description of the
testbed parameters are
<t>Resume time: not required</t> the same as <xref target="competing-rmcat-flow" format="default" section
</list></t> Format="of" derivedContent="Section 5.4"/>
with changes in the test-specific setup as below:</t>
<t>Media flow timeline: <list style="symbols"> <t indent="0" pn="section-5.8-2.8.2">Other test-specific setup: </t>
<t>Flow ID: two (2)</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.8-2.8.
3">
<t>Start time: 0s</t> <dt pn="section-5.8-2.8.3.1">Media flow timeline: </dt>
<dd pn="section-5.8-2.8.3.2">
<t>Flow duration: 119s</t> <t indent="0" pn="section-5.8-2.8.3.2.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.8-
<t>Pause time: at 40s</t> 2.8.3.2.2">
<dt pn="section-5.8-2.8.3.2.2.1">Flow ID: </dt>
<t>Resume time: at 60s</t> <dd pn="section-5.8-2.8.3.2.2.2">one (1)</dd>
</list></t> <dt pn="section-5.8-2.8.3.2.2.3">Start time: </dt>
<dd pn="section-5.8-2.8.3.2.2.4">0 s</dd>
<t>Media flow timeline: <list style="symbols"> <dt pn="section-5.8-2.8.3.2.2.5">Flow duration: </dt>
<t>Flow ID: three (3)</t> <dd pn="section-5.8-2.8.3.2.2.6">119 s</dd>
<dt pn="section-5.8-2.8.3.2.2.7">Pause time: </dt>
<t>Start time: 0s</t> <dd pn="section-5.8-2.8.3.2.2.8">not required</dd>
<dt pn="section-5.8-2.8.3.2.2.9">Resume time: </dt>
<t>Flow duration:119s</t> <dd pn="section-5.8-2.8.3.2.2.10">not required</dd>
</dl>
<t>Pause time: not required</t> </dd>
<dt pn="section-5.8-2.8.3.3">Media flow timeline: </dt>
<t>Resume time: not required</t> <dd pn="section-5.8-2.8.3.4">
</list></t> <t indent="0" pn="section-5.8-2.8.3.4.1"><br/></t>
</list></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.8-
</list></t> 2.8.3.4.2">
<dt pn="section-5.8-2.8.3.4.2.1">Flow ID: </dt>
<dd pn="section-5.8-2.8.3.4.2.2">two (2)</dd>
<dt pn="section-5.8-2.8.3.4.2.3">Start time: </dt>
<dd pn="section-5.8-2.8.3.4.2.4">0 s</dd>
<dt pn="section-5.8-2.8.3.4.2.5">Flow duration: </dt>
<dd pn="section-5.8-2.8.3.4.2.6">119 s</dd>
<dt pn="section-5.8-2.8.3.4.2.7">Pause time: </dt>
<dd pn="section-5.8-2.8.3.4.2.8">at 40 s</dd>
<dt pn="section-5.8-2.8.3.4.2.9">Resume time: </dt>
<dd pn="section-5.8-2.8.3.4.2.10">at 60 s</dd>
</dl>
</dd>
<dt pn="section-5.8-2.8.3.5">Media flow timeline: </dt>
<dd pn="section-5.8-2.8.3.6">
<t indent="0" pn="section-5.8-2.8.3.6.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-5.8-
2.8.3.6.2">
<dt pn="section-5.8-2.8.3.6.2.1">Flow ID:</dt>
<dd pn="section-5.8-2.8.3.6.2.2">three (3)</dd>
<dt pn="section-5.8-2.8.3.6.2.3">Start time:</dt>
<dd pn="section-5.8-2.8.3.6.2.4">0 s</dd>
<dt pn="section-5.8-2.8.3.6.2.5">Flow duration:</dt>
<dd pn="section-5.8-2.8.3.6.2.6">119 s</dd>
<dt pn="section-5.8-2.8.3.6.2.7">Pause time:</dt>
<dd pn="section-5.8-2.8.3.6.2.8">not required</dd>
<dt pn="section-5.8-2.8.3.6.2.9">Resume time:</dt>
<dd pn="section-5.8-2.8.3.6.2.10">not required</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6">
<section title="Other potential test cases"> <name slugifiedName="name-other-potential-test-cases">Other Potential Test
<t>It has been noticed that there are other interesting test cases Cases</name>
<t indent="0" pn="section-6-1">It has been noticed that there are other in
teresting test cases
besides the basic test cases listed above. In many aspects, these besides the basic test cases listed above. In many aspects, these
additional test cases can help further evaluation of the candidate additional test cases can help further evaluation of the candidate
algorithm. They are listed as below.</t> algorithm. They are listed below.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6.1
<section title="Media Flows with Priority"> ">
<t>In this test case media flows will have different priority levels. <name slugifiedName="name-media-flows-with-priority">Media Flows with Pr
This will be an extension of <xref target="competing-rmcat-flow"/> iority</name>
where the same test will be run with different priority levels imposed <t indent="0" pn="section-6.1-1">In this test case, media flows will hav
e different priority levels.
This is an extension of <xref target="competing-rmcat-flow" format="defa
ult" sectionFormat="of" derivedContent="Section 5.4"/>
where the same test is run with different priority levels imposed
on each of the media flows. For example, the first flow (S1) is on each of the media flows. For example, the first flow (S1) is
assigned a priority of 2 whereas the remaining two flows (S2 and S3) assigned a priority of 2, whereas the remaining two flows (S2 and S3)
are assigned a priority of 1. The candidate algorithm must reflect the are assigned a priority of 1. The candidate algorithm must reflect the
relative priorities assigned to each media flow. In this case, the relative priorities assigned to each media flow. In this case, the
first flow (S1) must arrive at a steady-state rate approximately twice first flow (S1) must arrive at a steady-state rate approximately twice
of that of the other two flows (S2 and S3).</t> that of the other two flows (S2 and S3).</t>
<t indent="0" pn="section-6.1-2">The candidate algorithm can use a coupl
<t>The candidate algorithm can use a coupled congestion control ed congestion control
mechanism <xref target="I-D.ietf-rmcat-coupled-cc"/> or use a weighted mechanism <xref target="RFC8699" format="default" sectionFormat="of" der
ivedContent="RFC8699"/> or use a weighted
priority scheduler for the bandwidth distribution according to the priority scheduler for the bandwidth distribution according to the
respective media flow priority or use.</t> respective media flow priority or use.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6.2
<section title="Explicit Congestion Notification Usage"> ">
<t>This test case requires to run all the basic test cases with the <name slugifiedName="name-explicit-congestion-notific">Explicit Congesti
availability of Explicit Congestion Notification (ECN) <xref on Notification Usage</name>
target="RFC6679"/> feature enabled. The goal of this test is to <t indent="0" pn="section-6.2-1">This test case requires running all the
basic test cases with the
availability of Explicit Congestion Notification (ECN)
<xref target="RFC6679" format="default" sectionFormat="of" derivedConten
t="RFC6679"/> feature enabled. The goal of this test is to
exhibit that the candidate algorithms do not fail when ECN signals are exhibit that the candidate algorithms do not fail when ECN signals are
available. With ECN signals enabled the algorithms are expected to available. With ECN signals enabled, the algorithms are expected to
perform better than their delay-based variants.</t> perform better than their delay-based variants.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6.3
<section title="Multiple Bottlenecks"> ">
<t>In this test case one congestion controlled media flow, S1-&gt;R1, <name slugifiedName="name-multiple-bottlenecks">Multiple Bottlenecks</na
traverses a path with multiple bottlenecks. As illustrated in <xref me>
target="fig-eval-topo-6-2"/>, the first flow (S1-&gt;R1) competes with <t indent="0" pn="section-6.3-1">In this test case, one congestion-contr
the second congestion controlled media flow (S2-&gt;R2) over the link olled media flow, S1-&gt;R1,
between A and B which is close to the sender side; again, that flow traverses a path with multiple bottlenecks. As illustrated in
(S1-&gt;R1) competes with the third congestion controlled media flow <xref target="fig-eval-topo-6-2" format="default" sectionFormat="of" der
(S3-&gt;R3) over the link between C and D which is close to the ivedContent="Figure 7"/>, the first flow (S1-&gt;R1) competes with
the second congestion-controlled media flow (S2-&gt;R2) over the link
between A and B, which is close to the sender side. Again, that flow
(S1-&gt;R1) competes with the third congestion-controlled media flow
(S3-&gt;R3) over the link between C and D, which is close to the
receiver side. The goal of this test is to ensure that the candidate receiver side. The goal of this test is to ensure that the candidate
algorithms work properly in the presence of multiple bottleneck links algorithms work properly in the presence of multiple bottleneck links
on the end to end path.</t> on the end-to-end path.</t>
<dl spacing="normal" indent="3" newline="false" pn="section-6.3-2">
<t>Expected behavior: The candidate algorithm is expected to achieve <dt pn="section-6.3-2.1">Expected behavior:</dt>
<dd pn="section-6.3-2.2"> The candidate algorithm is expected to achie
ve
full utilization at both bottleneck links without starving any of the full utilization at both bottleneck links without starving any of the
three congestion controlled media flows and ensuring fair share of the three congestion-controlled media flows and ensuring fair share of the
available bandwidth at each bottlenecks.</t> available bandwidth at each bottleneck.</dd>
</dl>
<t><figure anchor="fig-eval-topo-6-2" <figure anchor="fig-eval-topo-6-2" align="left" suppress-title="false" p
title="Testbed Topology for Multiple Bottlenecks"> n="figure-7">
<artwork><![CDATA[ <name slugifiedName="name-testbed-topology-for-multipl">Testbed Topolo
gy for Multiple Bottlenecks</name>
Forward ----> <artwork name="" type="" align="left" alt="" pn="section-6.3-3.1">
Forward ----&gt;
+---+ +---+ +---+ +---+
|S2 | |R2 | |S3 | |R3 |
+---+ +---+ +---+ +---+
| | | |
| | | |
+---+ +-----+ +-----+ +-----+ +-----+ +---+
|S1 |=======| A |------>| B |----->| C |---->| D |=======|R1 |
+---+ | |<------| |<-----| |<----| | +---+
+-----+ +-----+ +-----+ +-----+
1st 2nd
Bottleneck (A->B) Bottleneck (C->D)
<------ Backward
]]></artwork>
</figure></t>
<t>Testbed topology: Three media sources S1, S2, and S3 are connected
to respective destinations R1, R2, and R3. For all three flows the
media traffic is transported over the forward path and corresponding
feedback/control traffic is transported over the backward path.</t>
<t>Testbed attributes:</t>
<t><list style="symbols">
<t>Test duration: 300s</t>
<t>Path characteristics: <list style="symbols">
<t>Reference bottleneck capacity: 2Mbps.</t>
<t>Path capacity ratio between A and B: 1.0</t>
<t>Path capacity ratio between B and C: 4.0.</t>
<t>Path capacity ratio between C and D: 0.75.</t>
<t>One-Way propagation delay: <list style="numbers">
<t>Between S1 and R1: 100ms</t>
<t>Between S2 and R2: 40ms</t>
<t>Between S3 and R3: 40ms</t>
</list></t>
</list></t>
<t>Application-related: <list style="symbols">
<t>Media Source: <list style="symbols">
<t>Media type: Video <list style="symbols">
<t>Media direction: Forward</t>
<t>Number of media sources: Three (3)</t>
<t>Media timeline: <list style="symbols">
<t>Start time: 0s.</t>
<t>End time: 299s.</t>
</list></t>
</list></t>
<t>Media type: Audio <list style="symbols">
<t>Media direction: Forward</t>
<t>Number of media sources: Three (3)</t>
<t>Media timeline: <list style="symbols"> +---+ +---+ +---+ +---+
<t>Start time: 0s.</t> |S2 | |R2 | |S3 | |R3 |
+---+ +---+ +---+ +---+
| | | |
| | | |
+---+ +-----+ +-----+ +-----+ +-----+ +---+
|S1 |======| A |------&gt;| B |-----&gt;| C |----&gt;| D |======|R1 |
+---+ | |&lt;------| |&lt;-----| |&lt;----| | +---+
+-----+ +-----+ +-----+ +-----+
<t>End time: 299s.</t> 1st 2nd
</list></t> Bottleneck (A-&gt;B) Bottleneck (C-&gt;D)
</list></t>
</list></t>
<t>Competing traffic: <list style="symbols"> &lt;------ Backward
<t>Number of sources : Zero (0)</t> </artwork>
</list></t> </figure>
</list></t> <dl spacing="normal" indent="3" newline="false" pn="section-6.3-4">
</list></t> <dt pn="section-6.3-4.1">Testbed topology:</dt>
<dd pn="section-6.3-4.2">Three media sources S1, S2, and S3 are connec
ted
to respective destinations R1, R2, and R3. For all three flows, the
media traffic is transported over the forward path, and the corresponding
feedback/control traffic is transported over the backward path.</dd>
<dt pn="section-6.3-4.3">Testbed attributes:</dt>
<dd pn="section-6.3-4.4">
<t indent="0" pn="section-6.3-4.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-6.3-4.4.
2">
<dt pn="section-6.3-4.4.2.1">Test duration:</dt>
<dd pn="section-6.3-4.4.2.2"> 300 s</dd>
<dt pn="section-6.3-4.4.2.3">Path characteristics: </dt>
<dd pn="section-6.3-4.4.2.4">
<t indent="0" pn="section-6.3-4.4.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-6.3-
4.4.2.4.2">
<dt pn="section-6.3-4.4.2.4.2.1">Reference bottleneck capacity
:</dt>
<dd pn="section-6.3-4.4.2.4.2.2">2 Mbps</dd>
<dt pn="section-6.3-4.4.2.4.2.3">Path capacity ratio between A
and B:</dt>
<dd pn="section-6.3-4.4.2.4.2.4">1.0</dd>
<dt pn="section-6.3-4.4.2.4.2.5">Path capacity ratio between B
and C:</dt>
<dd pn="section-6.3-4.4.2.4.2.6">4.0</dd>
<dt pn="section-6.3-4.4.2.4.2.7">Path capacity ratio between C
and D:</dt>
<dd pn="section-6.3-4.4.2.4.2.8">0.75</dd>
<dt pn="section-6.3-4.4.2.4.2.9">One-way propagation delay: </
dt>
<dd pn="section-6.3-4.4.2.4.2.10">
<t indent="0" pn="section-6.3-4.4.2.4.2.10.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
6.3-4.4.2.4.2.10.2">
<dt pn="section-6.3-4.4.2.4.2.10.2.1">Between S1 and R1:</
dt>
<dd pn="section-6.3-4.4.2.4.2.10.2.2">100 ms</dd>
<dt pn="section-6.3-4.4.2.4.2.10.2.3">Between S2 and R2:</
dt>
<dd pn="section-6.3-4.4.2.4.2.10.2.4">40 ms</dd>
<dt pn="section-6.3-4.4.2.4.2.10.2.5">Between S3 and R3:</
dt>
<dd pn="section-6.3-4.4.2.4.2.10.2.6">40 ms</dd>
</dl>
</dd>
</dl>
</dd>
<dt pn="section-6.3-4.4.2.5">Application-related: </dt>
<dd pn="section-6.3-4.4.2.6">
<t indent="0" pn="section-6.3-4.4.2.6.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-6.3-
4.4.2.6.2">
<dt pn="section-6.3-4.4.2.6.2.1">Media source:</dt>
<dd pn="section-6.3-4.4.2.6.2.2">
<t indent="0" pn="section-6.3-4.4.2.6.2.2.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
6.3-4.4.2.6.2.2.2">
<dt pn="section-6.3-4.4.2.6.2.2.2.1">Media type:</dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.2">
<t indent="0" pn="section-6.3-4.4.2.6.2.2.2.2.1">Video <
/t>
<dl spacing="normal" indent="3" newline="false" pn="sect
ion-6.3-4.4.2.6.2.2.2.2.2">
<dt pn="section-6.3-4.4.2.6.2.2.2.2.2.1">Media directi
on:</dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.2.2.2">Forward</dd>
<dt pn="section-6.3-4.4.2.6.2.2.2.2.2.3">Number of med
ia sources:</dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.2.2.4">Three (3)</dd
>
<dt pn="section-6.3-4.4.2.6.2.2.2.2.2.5">Media timelin
e: </dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.2.2.6">
<t indent="0" pn="section-6.3-4.4.2.6.2.2.2.2.2.6.1"
><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="
section-6.3-4.4.2.6.2.2.2.2.2.6.2">
<dt pn="section-6.3-4.4.2.6.2.2.2.2.2.6.2.1">Start
time:</dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.2.2.6.2.2"> 0 s<
/dd>
<dt pn="section-6.3-4.4.2.6.2.2.2.2.2.6.2.3">End t
ime: </dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.2.2.6.2.4">299 s
</dd>
</dl>
</dd>
</dl>
</dd>
<dt pn="section-6.3-4.4.2.6.2.2.2.3">Media type:</dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.4">
<t indent="0" pn="section-6.3-4.4.2.6.2.2.2.4.1">Audio</
t>
<dl spacing="normal" indent="3" newline="false" pn="sect
ion-6.3-4.4.2.6.2.2.2.4.2">
<dt pn="section-6.3-4.4.2.6.2.2.2.4.2.1">Media directi
on:</dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.4.2.2">Forward</dd>
<dt pn="section-6.3-4.4.2.6.2.2.2.4.2.3">Number of med
ia sources:</dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.4.2.4">Three (3)</dd
>
<dt pn="section-6.3-4.4.2.6.2.2.2.4.2.5">Media timelin
e: </dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.4.2.6">
<t indent="0" pn="section-6.3-4.4.2.6.2.2.2.4.2.6.1"
><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="
section-6.3-4.4.2.6.2.2.2.4.2.6.2">
<dt pn="section-6.3-4.4.2.6.2.2.2.4.2.6.2.1">Start
time:</dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.4.2.6.2.2">0 s</
dd>
<dt pn="section-6.3-4.4.2.6.2.2.2.4.2.6.2.3">End t
ime:</dt>
<dd pn="section-6.3-4.4.2.6.2.2.2.4.2.6.2.4">299 s
</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</dd>
<dt pn="section-6.3-4.4.2.6.2.3">Competing traffic: </dt>
<dd pn="section-6.3-4.4.2.6.2.4">
<t indent="0" pn="section-6.3-4.4.2.6.2.4.1"><br/></t>
<dl spacing="normal" indent="3" newline="false" pn="section-
6.3-4.4.2.6.2.4.2">
<dt pn="section-6.3-4.4.2.6.2.4.2.1">Number of sources:</d
t>
<dd pn="section-6.3-4.4.2.6.2.4.2.2">Zero (0)</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
<section title="Wireless Access Links"> <name slugifiedName="name-wireless-access-links">Wireless Access Links</na
<!-- --> me>
<t indent="0" pn="section-7-1">Additional wireless network (both cellular
<t>Additional wireless network (both cellular network and WiFi network) network and Wi-Fi network)
specific test cases are defined in <xref specific test cases are defined in <xref target="RFC8869" format="default"
target="I-D.ietf-rmcat-wireless-tests"/>.</t> sectionFormat="of" derivedContent="RFC8869"/>.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-8">
<section title="Security Considerations"> <name slugifiedName="name-security-considerations">Security Considerations
<t>The security considerations in <xref </name>
target="I-D.ietf-rmcat-eval-criteria"/> and the relevant congestion <t indent="0" pn="section-8-1">The security considerations in <xref target
="RFC8868" section="6" sectionFormat="of" format="default" derivedLink="https://
rfc-editor.org/rfc/rfc8868#section-6" derivedContent="RFC8868"/> and the relevan
t congestion
control algorithms apply. The principles for congestion control are control algorithms apply. The principles for congestion control are
described in <xref target="RFC2914"/>, and in particular any new method described in <xref target="RFC2914" format="default" sectionFormat="of" de rivedContent="RFC2914"/>, and in particular any new method
must implement safeguards to avoid congestion collapse of the must implement safeguards to avoid congestion collapse of the
Internet.</t> Internet.</t>
<t indent="0" pn="section-8-2">The evaluation of the test cases are intend
<t>The evaluation of the test cases are intended to be run in a ed to be run in a
controlled lab environment. Hence, the applications, simulators and controlled lab environment. Hence, the applications, simulators, and
network nodes ought to be well-behaved and should not impact the desired network nodes ought to be well-behaved and should not impact the desired
results. Moreover, proper measures must be taken to avoid leaking results. Moreover, proper measures must be taken to avoid leaking
non-responsive traffic from unproven congestion avoidance techniques nonresponsive traffic from unproven congestion avoidance techniques
onto the open Internet.</t> onto the open Internet.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-9">
<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-9-1">This document has no IANA actions.</t>
</section>
<section title="Acknowledgements">
<t>Much of this document is derived from previous work on congestion
control at the IETF.</t>
<t>The content and concepts within this document are a product of the
discussion carried out in the Design Team.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-10">
<?rfc include='reference.RFC.6679.xml'?> <name slugifiedName="name-references">References</name>
<references pn="section-10.1">
<!-- RTP related --> <name slugifiedName="name-normative-references">Normative References</na
me>
&rfc3550; <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3
550" quoteTitle="true" derivedAnchor="RFC3550">
&rfc3551; <front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
&rfc3611; <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
&rfc4585; <organization showOnFrontPage="true"/>
</author>
&rfc5506; <author initials="S." surname="Casner" fullname="S. Casner">
<organization showOnFrontPage="true"/>
<!--RMCAT related --> </author>
<author initials="R." surname="Frederick" fullname="R. Frederick">
&I-D.ietf-rmcat-eval-criteria; <organization showOnFrontPage="true"/>
</author>
&I-D.ietf-rmcat-wireless-tests; <author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
&I-D.ietf-rmcat-video-traffic-model; </author>
<date year="2003" month="July"/>
&I-D.ietf-rmcat-cc-requirements; <abstract>
<t indent="0">This memorandum describes RTP, the real-time transpo
<?rfc include='reference.RFC.5681.xml'?> 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
<!--&rfc5681; --> , 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
<!-- Standard TCP --> data transport is augmented by a control protocol (RTCP) to allow monitoring of
</references> 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
<references title="Informative References"> 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
&I-D.ietf-rtcweb-use-cases-and-requirements; --> 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
<?rfc include='reference.RFC.2914.xml'?> 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
<?rfc include='reference.RFC.8290.xml'?> e transmission in excess of the intended rate when many participants join a sess
ion simultaneously. [STANDARDS-TRACK]</t>
<?rfc include='reference.RFC.8033.xml'?> </abstract>
</front>
<?rfc include='reference.RFC.7567.xml'?> <seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<!-- &rfc5033; --> <seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<!-- CC Evaluation --> <reference anchor="RFC3551" target="https://www.rfc-editor.org/info/rfc3
551" quoteTitle="true" derivedAnchor="RFC3551">
<!-- &rfc5166; --> <front>
<title>RTP Profile for Audio and Video Conferences with Minimal Cont
<!-- CC Metrics --> 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>
<reference anchor="xiph-seq"> <date year="2003" month="July"/>
<front> <abstract>
<title>Video Test Media</title> <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
<author fullname="" initials="" surname="Xiph.org"/> ted control protocol, RTCP, within audio and video multiparticipant conferences
with minimal control. It provides interpretations of generic fields within the
<date month="" year=""/> RTP specification suitable for audio and video conferences. In particular, this
</front> 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
<seriesInfo name="http://media.xiph.org/video/derf/" value=""/> RTP. It defines a set of standard encodings and their names when used within RT
</reference> 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
<reference anchor="HEVC-seq"> o and other real-time multimedia applications. This memorandum obsoletes RFC 189
<front> 0. It is mostly backwards-compatible except for functions removed because two i
<title>Test Sequences</title> 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
<author fullname="" initials="" surname="HEVC"/> w payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]</t>
</abstract>
<date month="" year=""/> </front>
</front> <seriesInfo name="STD" value="65"/>
<seriesInfo name="RFC" value="3551"/>
<seriesInfo name="http://www.netlab.tkk.fi/~varun/test_sequences/" <seriesInfo name="DOI" value="10.17487/RFC3551"/>
value=""/> </reference>
</reference> <reference anchor="RFC3611" target="https://www.rfc-editor.org/info/rfc3
611" quoteTitle="true" derivedAnchor="RFC3611">
<?rfc include='reference.I-D.ietf-rmcat-coupled-cc'?> <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="RFC5681" target="https://www.rfc-editor.org/info/rfc5
681" quoteTitle="true" derivedAnchor="RFC5681">
<front>
<title>TCP Congestion Control</title>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Paxson" fullname="V. Paxson">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Blanton" fullname="E. Blanton">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="September"/>
<abstract>
<t indent="0">This document defines TCP's four intertwined congest
ion control algorithms: slow start, congestion avoidance, fast retransmit, and f
ast recovery. In addition, the document specifies how TCP should begin transmis
sion after a relatively long idle period, as well as discussing various acknowle
dgment generation methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5681"/>
<seriesInfo name="DOI" value="10.17487/RFC5681"/>
</reference>
<reference anchor="RFC6679" target="https://www.rfc-editor.org/info/rfc6
679" quoteTitle="true" derivedAnchor="RFC6679">
<front>
<title>Explicit Congestion Notification (ECN) for RTP over UDP</titl
e>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization showOnFrontPage="true"/>
</author>
<author initials="I." surname="Johansson" fullname="I. Johansson">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="O'Hanlon" fullname="P. O'Hanlon">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Carlberg" fullname="K. Carlberg">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="August"/>
<abstract>
<t indent="0">This memo specifies how Explicit Congestion Notifica
tion (ECN) can be used with the Real-time Transport Protocol (RTP) running over
UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines
a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP tran
sport feedback message for timely reporting of congestion events, and a Session
Traversal Utilities for NAT (STUN) extension used in the optional initialisation
method using Interactive Connectivity Establishment (ICE). Signalling and proc
edures for negotiation of capabilities and initialisation methods are also defin
ed. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6679"/>
<seriesInfo name="DOI" value="10.17487/RFC6679"/>
</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>
<reference anchor="RFC8868" target="https://www.rfc-editor.org/info/rfc8
868" quoteTitle="true" derivedAnchor="RFC8868">
<front>
<title>Evaluating Congestion Control for Interactive Real-Time Media
</title>
<author initials="V" surname="Singh" fullname="Varun Singh">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Ott" fullname="Jörg Ott">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Holmer" fullname="Stefan Holmer">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8868"/>
<seriesInfo name="DOI" value="10.17487/RFC8868"/>
</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>
</references>
<references pn="section-10.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="HEVC-seq" target="http://www.netlab.tkk.fi/~varun/tes
t_sequences/" quoteTitle="true" derivedAnchor="HEVC-seq">
<front>
<title>Test Sequences</title>
<author>
<organization showOnFrontPage="true">HEVC</organization>
</author>
</front>
</reference>
<reference anchor="RFC2914" target="https://www.rfc-editor.org/info/rfc2
914" quoteTitle="true" derivedAnchor="RFC2914">
<front>
<title>Congestion Control Principles</title>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization showOnFrontPage="true"/>
</author>
<date year="2000" month="September"/>
<abstract>
<t indent="0">The goal of this document is to explain the need for
congestion control in the Internet, and to discuss what constitutes correct con
gestion control. This document specifies an Internet Best Current Practices for
the Internet Community, and requests discussion and suggestions for improvement
s.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="41"/>
<seriesInfo name="RFC" value="2914"/>
<seriesInfo name="DOI" value="10.17487/RFC2914"/>
</reference>
<reference anchor="RFC7567" target="https://www.rfc-editor.org/info/rfc7
567" quoteTitle="true" derivedAnchor="RFC7567">
<front>
<title>IETF Recommendations Regarding Active Queue Management</title
>
<author initials="F." surname="Baker" fullname="F. Baker" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="July"/>
<abstract>
<t indent="0">This memo presents recommendations to the Internet c
ommunity concerning measures to improve and preserve Internet performance. It p
resents a strong recommendation for testing, standardization, and widespread dep
loyment of active queue management (AQM) in network devices to improve the perfo
rmance of today's Internet. It also urges a concerted effort of research, measu
rement, and ultimate deployment of AQM mechanisms to protect the Internet from f
lows that are not sufficiently responsive to congestion notification.</t>
<t indent="0">Based on 15 years of experience and new research, th
is document replaces the recommendations of RFC 2309.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="197"/>
<seriesInfo name="RFC" value="7567"/>
<seriesInfo name="DOI" value="10.17487/RFC7567"/>
</reference>
<reference anchor="RFC8033" target="https://www.rfc-editor.org/info/rfc8
033" quoteTitle="true" derivedAnchor="RFC8033">
<front>
<title>Proportional Integral Controller Enhanced (PIE): A Lightweigh
t Control Scheme to Address the Bufferbloat Problem</title>
<author initials="R." surname="Pan" fullname="R. Pan">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Natarajan" fullname="P. Natarajan">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Baker" fullname="F. Baker">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="White" fullname="G. White">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="February"/>
<abstract>
<t indent="0">Bufferbloat is a phenomenon in which excess buffers
in the network cause high latency and latency variation. As more and more inter
active applications (e.g., voice over IP, real-time video streaming, and financi
al transactions) run in the Internet, high latency and latency variation degrade
application performance. There is a pressing need to design intelligent queue
management schemes that can control latency and latency variation, and hence pro
vide desirable quality of service to users.</t>
<t indent="0">This document presents a lightweight active queue ma
nagement design called "PIE" (Proportional Integral controller Enhanced) that ca
n effectively control the average queuing latency to a target value. Simulation
results, theoretical analysis, and Linux testbed results have shown that PIE can
ensure low latency and achieve high link utilization under various congestion s
ituations. The design does not require per-packet timestamps, so it incurs very
little overhead and is simple enough to implement in both hardware and software
.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8033"/>
<seriesInfo name="DOI" value="10.17487/RFC8033"/>
</reference>
<reference anchor="RFC8290" target="https://www.rfc-editor.org/info/rfc8
290" quoteTitle="true" derivedAnchor="RFC8290">
<front>
<title>The Flow Queue CoDel Packet Scheduler and Active Queue Manage
ment Algorithm</title>
<author initials="T." surname="Hoeiland-Joergensen" fullname="T. Hoe
iland-Joergensen">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="McKenney" fullname="P. McKenney">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Taht" fullname="D. Taht">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Gettys" fullname="J. Gettys">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Dumazet" fullname="E. Dumazet">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="January"/>
<abstract>
<t indent="0">This memo presents the FQ-CoDel hybrid packet schedu
ler and Active Queue Management (AQM) algorithm, a powerful tool for fighting bu
fferbloat and reducing latency.</t>
<t indent="0">FQ-CoDel mixes packets from multiple flows and reduc
es the impact of head-of-line blocking from bursty traffic. It provides isolati
on for low-rate traffic such as DNS, web, and videoconferencing traffic. It imp
roves utilisation across the networking fabric, especially for bidirectional tra
ffic, by keeping queue lengths short, and it can be implemented in a memory- and
CPU-efficient fashion across a wide range of hardware.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8290"/>
<seriesInfo name="DOI" value="10.17487/RFC8290"/>
</reference>
<reference anchor="RFC8699" target="https://www.rfc-editor.org/info/rfc8
699" quoteTitle="true" derivedAnchor="RFC8699">
<front>
<title>Coupled Congestion Control for RTP Media</title>
<author initials="S." surname="Islam" fullname="S. Islam">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Welzl" fullname="M. Welzl">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Gjessing" fullname="S. Gjessing">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="January"/>
<abstract>
<t indent="0">When multiple congestion-controlled Real-time Transp
ort Protocol (RTP) sessions traverse the same network bottleneck, combining thei
r controls can improve the total on-the-wire behavior in terms of delay, loss, a
nd fairness. This document describes such a method for flows that have the same
sender, in a way that is as flexible and simple as possible while minimizing the
number of changes needed to existing RTP applications. This document also speci
fies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA)
congestion control algorithm and provides suggestions on how to apply it to othe
r congestion control algorithms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8699"/>
<seriesInfo name="DOI" value="10.17487/RFC8699"/>
</reference>
<reference anchor="xiph-seq" target="http://media.xiph.org/video/derf/"
quoteTitle="true" derivedAnchor="xiph-seq">
<front>
<title>Video Test Media</title>
<author>
<organization showOnFrontPage="true">Xiph.org</organization>
</author>
</front>
</reference>
</references>
</references> </references>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.a">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.a-1">Much of this document is derived f
rom previous work on congestion
control at the IETF.</t>
<t indent="0" pn="section-appendix.a-2">The content and concepts within th
is document are a product of the
discussion carried out within the Design Team.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Zaheduzzaman Sarker" initials="Z" surname="Sarker">
<organization showOnFrontPage="true">Ericsson AB</organization>
<address>
<postal>
<street>Torshamnsgatan 23</street>
<city>Stockholm</city>
<code>164 83</code>
<country>Sweden</country>
</postal>
<phone>+46 10 717 37 43</phone>
<email>zaheduzzaman.sarker@ericsson.com</email>
</address>
</author>
<author fullname="Varun Singh" initials="V" surname="Singh">
<organization abbrev="callstats.io" showOnFrontPage="true">CALLSTATS I/O
Oy</organization>
<address>
<postal>
<street>Rauhankatu 11 C</street>
<city>Helsinki</city>
<code>00100</code>
<country>Finland</country>
</postal>
<email>varun.singh@iki.fi</email>
<uri>http://www.callstats.io/</uri>
</address>
</author>
<author fullname="Xiaoqing Zhu" initials="X" surname="Zhu">
<organization showOnFrontPage="true">Cisco Systems</organization>
<address>
<postal>
<street>12515 Research Blvd</street>
<city>Austin</city>
<region>TX</region>
<code>78759</code>
<country>United States of America</country>
</postal>
<email>xiaoqzhu@cisco.com</email>
</address>
</author>
<author fullname="Michael A. Ramalho" initials="M." surname="Ramalho">
<organization abbrev="AcousticComms" showOnFrontPage="true">AcousticComm
s Consulting</organization>
<address>
<postal>
<street>6310 Watercrest Way Unit 203</street>
<city>Lakewood Ranch</city>
<region>FL</region>
<code>34202-5211</code>
<country>USA</country>
</postal>
<phone>+1 732 832 9723</phone>
<email>mar42@cornell.edu</email>
<uri>http://ramalho.webhop.info/</uri>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 169 change blocks. 
1600 lines changed or deleted 2955 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/