<?xmlversion="1.0" encoding="US-ASCII"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY rfc3550 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"> <!ENTITY rfc3551 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml"> <!ENTITY rfc3611 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3611.xml"> <!ENTITY rfc4585 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"> <!ENTITY rfc5506 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5506.xml"> <!ENTITY rfc5166 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5166.xml"> <!ENTITY rfc5033 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5033.xml"> <!ENTITY rfc5681 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.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.ietf.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/public/rfc/bibxml3/reference.I-D.ietf-rmcat-eval-criteria.xml"> <!ENTITY I-D.ietf-rtcweb-use-cases-and-requirements PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-use-cases-and-requirements.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" ?>version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-rmcat-eval-test-10"ipr="trust200902"> <!---->indexInclude="true" ipr="trust200902" number="8867" prepTime="2021-01-18T23:57:30" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-test-10" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8867" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="Test Scenarios for RMCAT">Test Cases for EvaluatingRMCAT Proposals</title>Congestion Control for Interactive Real-Time Media</title> <seriesInfo name="RFC" value="8867" stream="IETF"/> <author fullname="Zaheduzzaman Sarker" initials="Z" surname="Sarker"><organization>Ericsson<organization showOnFrontPage="true">Ericsson AB</organization> <address> <postal> <street>Torshamnsgatan 23</street> <city>Stockholm</city><region>SE</region><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"> <organizationabbrev="callstats.io">Nemu Dialogue Systemsabbrev="callstats.io" showOnFrontPage="true">CALLSTATS I/O Oy</organization> <address> <postal><street>Runeberginkatu 4c A 4</street><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>Cisco<organization showOnFrontPage="true">Cisco Systems</organization> <address> <postal> <street>12515 Research Blvd</street><city>Austing</city><city>Austin</city> <region>TX</region> <code>78759</code><country>USA</country><country>United States of America</country> </postal> <email>xiaoqzhu@cisco.com</email> </address> </author> <author fullname="Michael A. Ramalho"initials="M. A."initials="M." surname="Ramalho"> <organizationabbrev="Cisco Systems">Cisco Systems, Inc.</organization>abbrev="AcousticComms" showOnFrontPage="true">AcousticComms 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>+1919 476 2038</phone> <email>mramalho@cisco.com</email>732 832 9723</phone> <email>mar42@cornell.edu</email> <uri>http://ramalho.webhop.info/</uri> </address> </author> <dateday="23" month="May" year="2019"/>month="01" year="2021"/> <area>TSV</area> <keyword>Multimedia</keyword> <keyword>Test cases</keyword> <keyword>Congestion Control</keyword><abstract> <t>The<abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1">The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications. These applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms in a controlled environment.</t> </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 is 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="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="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 derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t> </li> <li pn="section-toc.1-1.3"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-structure-of-test-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" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-recommended-evaluation-sett">Recommended Evaluation Settings</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-evaluation-metrics">Evaluation 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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-media-source">Media Source</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" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-basic-test-cases">Basic Test Cases</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-variable-available-capacity">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 derivedContent="" format="title" sectionFormat="of" target="name-variable-available-capacity-">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 derivedContent="" format="title" sectionFormat="of" target="name-congested-feedback-link-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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-round-trip-time-fairness">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 derivedContent="" format="title" sectionFormat="of" target="name-media-flow-competing-with-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 derivedContent="" format="title" sectionFormat="of" target="name-media-flow-competing-with-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 derivedContent="" 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" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-media-flows-with-priority">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 derivedContent="" format="title" sectionFormat="of" target="name-explicit-congestion-notific">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 derivedContent="" 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" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-wireless-access-links">Wireless Access Links</xref></t> </li> <li pn="section-toc.1-1.8"> <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="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" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> </li> <li pn="section-toc.1-1.10"> <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-normative-references">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 derivedContent="" format="title" sectionFormat="of" target="name-informative-references">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="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t> </li> <li pn="section-toc.1-1.12"> <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <sectiontitle="Introduction"> <t>Thisnumbered="true" toc="include" removeInRFC="false" pn="section-1"> <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 interactive media. It is based on the guidelines enumerated in <xreftarget="I-D.ietf-rmcat-eval-criteria"/>target="RFC8868" format="default" sectionFormat="of" derivedContent="RFC8868"/> and the requirements discussed in <xreftarget="I-D.ietf-rmcat-cc-requirements"/>.target="RFC8836" format="default" sectionFormat="of" derivedContent="RFC8836"/>. The test cases cover basic usage scenarios and are described using a common structure, which allows for additional test cases to be added to those described herein to accommodate other topologies and/or themodellingmodeling of different path characteristics. The described test cases in this memo should be used to evaluate any proposed congestion control algorithm for real-time interactive media.</t> </section> <section anchor="sec-terminology"title="Terminology"> <!--The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, <xref target="RFC2119" /> and indicate requirement levels for compliant implementations.--> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-terminology">Terminology</name> <t indent="0" pn="section-2-1">The terminology defined in <xreftarget="RFC3550">RTP</xref>, <xref target="RFC3551">RTPtarget="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTP</xref>, <xref target="RFC3551" format="default" sectionFormat="of" derivedContent="RFC3551">RTP Profile for Audio and Video Conferences with Minimal Control</xref>, <xreftarget="RFC3611">RTCPtarget="RFC3611" format="default" sectionFormat="of" derivedContent="RFC3611">RTCP Extended Report (XR)</xref>, <xreftarget="RFC4585">Extendedtarget="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)</xref>, and <xreftarget="RFC5506">Supporttarget="RFC5506" format="default" sectionFormat="of" derivedContent="RFC5506">Support for Reduced-Size RTCP</xref>apply.</t>applies.</t> </section> <section anchor="TS"title="Structurenumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-structure-of-test-cases">Structure of Testcases"> <t>AllCases</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 explaining common attributes. The structure includes a general description section that describes the test case and its motivation. Additionally the test case defines a set of attributes that characterize the testbed, for example, the network path between communicating peers and the diverse traffic sources.</t><t><list style="symbols"> <t>Define the test case: <list style="symbols"> <t>General description: describes<dl spacing="normal" indent="3" newline="false" pn="section-3-2"> <dt pn="section-3-2.1">Define the test case:</dt> <dd pn="section-3-2.2"> <t indent="0" pn="section-3-2.2.1"><br/></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> <dd pn="section-3-2.2.2.2">describes the motivation and the goals of the testcase.</t> <t>Expected behavior: describescase.</dd> <dt pn="section-3-2.2.2.3">Expected behavior:</dt> <dd pn="section-3-2.2.2.4">describes the desired rate adaptationbehavior.</t> <t>Define a listbehavior.</dd> <dt pn="section-3-2.2.2.5">List of metrics to evaluate the desiredbehavior:behavior:</dt> <dd pn="section-3-2.2.2.6"> this indicates the minimum set of metrics (e.g., link utilization, media sending rate) that a proposed algorithm needs to measure to validate the expected rate adaptation behavior. It should also indicate the time granularity (e.g., averaged over10ms, 100ms,10 ms, 100 ms, or1s)1 s) for measuring certain metrics. Typical measurement interval is200ms.</t> <!-- we agreed this should be 200ms or was it based on some IPPM doc? --> </list></t> <t>Define200 ms.</dd> </dl> </dd> <dt pn="section-3-2.3">Define testbedtopology: everytopology:</dt> <dd pn="section-3-2.4"> <t indent="0" pn="section-3-2.4.1"><br/></t> <t indent="0" pn="section-3-2.4.2">Every test case needs to define an evaluation testbed topology. <xreftarget="fig-eval-topo"/>target="fig-eval-topo" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows such an evaluation topology. In this evaluation topology, S1..Sn are traffic sources. These sources generate media traffic and use the congestion control algorithm(s) under investigation. R1..Rn are the corresponding receivers. A test case can have one or more such traffic sources (S) and their corresponding receivers (R). The path from the source to destination is denoted as"forward""forward", and the path from a destination to a source is denoted as "backward". The following basic structure of the test case has been described from the perspective ofmedia generatingmedia-generating endpoints attached on the left-hand side of <xreftarget="fig-eval-topo"/>.target="fig-eval-topo" format="default" sectionFormat="of" derivedContent="Figure 1"/>. In this setup, the media flows are transported in the forwarddirectiondirection, and the corresponding feedback/control messages are transported in the backward direction. However, it is also possible to set up the test with media in both forward and backward directions. In that case, unless otherwise specified by the test case, it is expected that the backward path does not introduce anycongestion relatedcongestion-related impairments and has enough capacity to accommodate both media and feedback/control messages. It should be notedthatthat, depending on the testcasescases, it is possible to have different path characteristics in either of thedirections.<figuredirections.</t> <figure anchor="fig-eval-topo"title="Examplealign="left" suppress-title="false" pn="figure-1"> <name slugifiedName="name-example-of-a-testbed-topolo">Example ofAa TestbedTopology"> <artwork><![CDATA[Topology</name> <artwork name="" type="" align="left" alt="" pn="section-3-2.4.3.1"> +---+ +---+ |S1 |====== \ Forward-->--> / =======|R1 | +---+ \\ // +---+ \\ // +---+ +-----+ +-----+ +---+ |S2 |=======| A|------------------------------>||--------------------------->| B |=======|R2 | +---+ ||<------------------------------||<---------------------------| | +---+ +-----+ +-----+ (...) // \\ (...) //<--<-- Backward \\ +---+ // \\ +---+ |Sn |====== / \ ======|Rn | +---+ +---+]]></artwork> </figure>In</artwork> </figure> <t indent="0" pn="section-3-2.4.4">In a testbed environment with realequipments,equipment, there may exist a significant amount of unwanted traffic on the portions of the network path between the endpoints. Some of this traffic may be generated by other processes on the endpoints themselves (e.g., discovery protocols) or by other endpoints not presently under test. Such unwanted traffic should be removed or avoided to the greatest extent possible.</t><t>Define</dd> <dt pn="section-3-2.5">Define testbedattributes: <list style="symbols"> <t>Duration: definesattributes:</dt> <dd pn="section-3-2.6"> <t indent="0" pn="section-3-2.6.1"><br/></t> <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 inseconds.</t> <t>Path characteristics: definesseconds.</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 transport level path characteristics of the testbed for a particular test case. Two sets of attributes describe the path characteristics, one for the forward path and the other for the backward path. The path characteristics for a particular path directionisare applicable to all theSourcessources "S" sending traffic on that path. If only one attribute is specified, it is used for both pathdirections,directions; however, unless specified the reverse path has no capacity restrictions and no pathloss.<list style="symbols"> <t>Path direction: forwardloss.</t> <dl spacing="normal" indent="3" newline="false" pn="section-3-2.6.2.4.2"> <dt pn="section-3-2.6.2.4.2.1">Path direction:</dt> <dd pn="section-3-2.6.2.4.2.2">forward orbackward.</t> <t>Minimumbackward.</dd> <dt pn="section-3-2.6.2.4.2.3">Minimum bottleneck-linkcapacity: definescapacity:</dt> <dd pn="section-3-2.6.2.4.2.4">defines the minimum capacity of the end-to-endpath</t> <t>Referencepath.</dd> <dt pn="section-3-2.6.2.4.2.5">Reference bottleneckcapacity: definescapacity:</dt> <dd pn="section-3-2.6.2.4.2.6">defines a reference value for the bottleneck capacity for test cases with time-varying bottleneck capacities. All bottleneck capacities will be specified as a ratio with respect to the reference capacityvalue.</t> <t>One-wayvalue.</dd> <dt pn="section-3-2.6.2.4.2.7">One-way propagationdelay: describesdelay:</dt> <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., the time it takes for a packet to go from the sender to the receiver without encountering any queuingdelay.</t> <t>Maximumdelay.</dd> <dt pn="section-3-2.6.2.4.2.9">Maximum end-to-endjitter: definesjitter:</dt> <dd pn="section-3-2.6.2.4.2.10">defines the maximum jitter that can be observed along thepath.</t> <t>Bottleneckpath.</dd> <dt pn="section-3-2.6.2.4.2.11">Bottleneck queuetype: fortype:</dt> <dd pn="section-3-2.6.2.4.2.12">for example, "tail drop" <xreftarget="RFC7567"/>,target="RFC7567" format="default" sectionFormat="of" derivedContent="RFC7567"/>, Flow Queue-CoDel (FQ-CoDel)<xref target="RFC8290"/>,Controlled Delay (FQ-CoDel) <xref target="RFC8290" format="default" sectionFormat="of" derivedContent="RFC8290"/>, or Proportional Integral controller Enhanced(PIE)<xref target="RFC8033"/>.</t> <t>Bottleneck(PIE) <xref target="RFC8033" format="default" sectionFormat="of" derivedContent="RFC8033"/>.</dd> <dt pn="section-3-2.6.2.4.2.13">Bottleneck queuesize: definessize:</dt> <dd pn="section-3-2.6.2.4.2.14">defines the size of queue in terms of queuing time when the queue is full (inmilliseconds).</t> <t>Pathmilliseconds).</dd> <dt pn="section-3-2.6.2.4.2.15">Path lossratio: characterizesratio:</dt> <dd pn="section-3-2.6.2.4.2.16">characterizes the non-congested,additive,additive losses to be generated on the end-to-end path. This must describe the loss pattern or loss model used to generate thelosses.</t> </list></t> <t>Application-related: defineslosses.</dd> </dl> </dd> <dt pn="section-3-2.6.2.5">Application-related:</dt> <dd pn="section-3-2.6.2.6"> <t indent="0" pn="section-3-2.6.2.6.1">defines the traffic source behavior for implementing the testcase <list style="symbols"> <t>Media traffic Source: definescase:</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 characteristics of the media sources. When using more than one media source, the different attributes are enumerated separately for each different media source.<list style="symbols"> <t>Media type: Video/Voice</t> <t>Media</t> <dl spacing="normal" indent="3" newline="false" pn="section-3-2.6.2.6.2.2.2"> <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> <dt pn="section-3-2.6.2.6.2.2.2.3">Media flowdirection: forward, backwarddirection:</dt> <dd pn="section-3-2.6.2.6.2.2.2.4">forward, backward, orboth.</t> <t>Numberboth.</dd> <dt pn="section-3-2.6.2.6.2.2.2.5">Number of mediasources: definessources:</dt> <dd pn="section-3-2.6.2.6.2.2.2.6">defines the total number of mediasources</t> <t>Media codec: Constantsources.</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) or Variable Bit Rate(VBR)</t> <t>Media(VBR).</dd> <dt pn="section-3-2.6.2.6.2.2.2.9">Media sourcebehavior: describesbehavior:</dt> <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 adaptation behavior. This may include but is not limitedto: <list style="symbols"> <t>Adaptability: describesto the following: </t> <dl spacing="normal" indent="3" newline="false" pn="section-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:</dt> <dd pn="section-3-2.6.2.6.2.2.2.10.2.2">describes the adaptation options. For example, in the case ofvideovideo, it defines the following ranges of adaptation: bit rate, frame rate, and video resolution. Similarly, in the case of voice, it defines the range of bit rate adaptation, the sampling rate variation, and the variation in packetizationinterval.</t> <t>Output variation : forinterval.</dd> <dt pn="section-3-2.6.2.6.2.2.2.10.2.3">Output variation:</dt> <dd pn="section-3-2.6.2.6.2.2.2.10.2.4">for a VBRencoderencoder, it defines the encoder output variation from the average target rate over a particular measurement interval. For example, on average the encoder output may vary between 5% to 15% above or below the average target bit rate when measured over a 100 ms time window. The time interval over which the variation is specified must beprovided.</t> <!-- --> <t>Responsivenessprovided.</dd> <dt pn="section-3-2.6.2.6.2.2.2.10.2.5">Responsiveness to a new bit raterequest: therequest:</dt> <dd pn="section-3-2.6.2.6.2.2.2.10.2.6">the lag in time between a new bit rate request from the congestion control algorithm and actual rate changes in encoder output. Depending on the encoder, this value may be specified in absolute time(e.g. 10ms(e.g., 10 ms to1000ms)1000 ms) or other appropriate metric(e.g.(e.g., next frame intervaltime).</t> </list>time).</dd> </dl> <t indent="0" pn="section-3-2.6.2.6.2.2.2.10.3"> More detailed discussions on expected media source behavior, including those from synthetic video traffic sources,is atcan be found in <xreftarget="I-D.ietf-rmcat-video-traffic-model"/>.</t> <t>Media content: describestarget="RFC8593" format="default" sectionFormat="of" derivedContent="RFC8593"/>.</t> </dd> <dt pn="section-3-2.6.2.6.2.2.2.11">Media content:</dt> <dd pn="section-3-2.6.2.6.2.2.2.12">describes the chosen video scenario. For example, video test sequences are availableat:at <xreftarget="xiph-seq"/>target="xiph-seq" format="default" sectionFormat="of" derivedContent="xiph-seq"/> and <xreftarget="HEVC-seq"/>.target="HEVC-seq" format="default" sectionFormat="of" derivedContent="HEVC-seq"/>. Different video scenarios give differentdistributiondistributions of video frames produced by the video encoder. Hence, it is important to specify the media content used in a particular test. If a synthetic video trafficsoucesource <xreftarget="I-D.ietf-rmcat-video-traffic-model"/>target="RFC8593" format="default" sectionFormat="of" derivedContent="RFC8593"/> is used, then the synthetic video traffic source needs toconfigurebe configured according to the characteristics of the media contentspecified.</t> <t>Media timeline: describesspecified.</dd> <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 example, the media source may start transmitting immediately when the test case begins, or after a fewseconds.</t> <t>Startup behavior: theseconds.</dd> <dt pn="section-3-2.6.2.6.2.2.2.15">Startup behavior:</dt> <dd pn="section-3-2.6.2.6.2.2.2.16">the media starts at a defined bit rate, which may be the minimum, maximum bit rate, or a value in between (inKbps).</t> </list></t> <t>Competing traffic source: describesKbps).</dd> </dl> </dd> <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 characteristics of the competing traffic source, the different types of competing flows are enumerated in <xreftarget="I-D.ietf-rmcat-eval-criteria"/>. <list style="symbols"> <t>Traffic direction: forward, backwardtarget="RFC8868" format="default" sectionFormat="of" derivedContent="RFC8868"/>. </t> <dl spacing="normal" indent="3" newline="false" pn="section-3-2.6.2.6.2.4.2"> <dt pn="section-3-2.6.2.6.2.4.2.1">Traffic direction:</dt> <dd pn="section-3-2.6.2.6.2.4.2.2">forward, backward, orboth.</t> <t>Type of sources: definesboth.</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 competing traffic sources. Types of competing traffic flows are listed in <xreftarget="I-D.ietf-rmcat-eval-criteria"/>.target="RFC8868" format="default" sectionFormat="of" derivedContent="RFC8868"/>. For example, the number of TCP flows connected to a web browser, the mean size and distribution of the contentdownloaded.</t> <t>Number of sources: definesdownloaded.</dd> <dt pn="section-3-2.6.2.6.2.4.2.5">Number of sources:</dt> <dd pn="section-3-2.6.2.6.2.4.2.6">defines the total number of competing sources of each media type per trafficdirection.</t> <t>Congestion control: enumeratesdirection.</dd> <dt pn="section-3-2.6.2.6.2.4.2.7">Congestion control:</dt> <dd pn="section-3-2.6.2.6.2.4.2.8">enumerates the congestion control used by each type of competingtraffic.</t> <t>Traffic timeline: describestraffic.</dd> <dt pn="section-3-2.6.2.6.2.4.2.9">Traffic timeline:</dt> <dd pn="section-3-2.6.2.6.2.4.2.10">describes when the competing traffic starts and ends in the testcase.</t> </list></t> </list></t> <t>Additional attributes: describescase.</dd> </dl> </dd> </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 casewhichthat are not included in the above structure. These attributes must be well defined, so that the other implementers of that particular test case are able to implement iteasily.</t> </list></t> </list></t> <t>Anyeasily.</dd> </dl> </dd> </dl> <t indent="0" pn="section-3-3">Any attribute can have a set of values (enclosed within "[]"). Each 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 attribute value.</t><t>The<t indent="0" pn="section-3-4">The test cases described in this document follow the above structure.</t> </section> <section anchor="sec-rec-eval"title="Recommendednumbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-recommended-evaluation-sett">Recommended EvaluationSettings"> <t>ThisSettings</name> <t indent="0" pn="section-4-1">This section describes recommended test case settings and could be overwritten by the respective test cases.</t> <section anchor="EM"title="Evaluation metrics"> <t>Tonumbered="true" toc="include" removeInRFC="false" pn="section-4.1"> <name slugifiedName="name-evaluation-metrics">Evaluation Metrics</name> <t indent="0" pn="section-4.1-1">To evaluate the performance of the candidatealgorithmsalgorithms, the implementers must log enough information to visualize the following metrics at a fine enough time granularity:<list style="numbers"> <t>Flow</t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.1-2"> <li pn="section-4.1-2.1" derivedCounter="1."> <t indent="0" pn="section-4.1-2.1.1">Flow level:<list style="letters"> <t>End-to-end</t> <ol spacing="normal" type="A" indent="adaptive" start="1" pn="section-4.1-2.1.2"> <li pn="section-4.1-2.1.2.1" derivedCounter="A.">End-to-end delay for thecongestion controlledcongestion-controlled media flow(s). Forexample -example, end-to-end delay observed on the IP packetlevel,level and the video framelevel.</t> <t>Variationlevel.</li> <li pn="section-4.1-2.1.2.2" derivedCounter="B.">Variation in sending bit rate and throughput. Mainly observing the frequency and magnitude ofoscillations.</t> <t>Packetoscillations.</li> <li pn="section-4.1-2.1.2.3" derivedCounter="C.">Packet losses observed at the receivingendpoint.</t> <t>Feedbackendpoint.</li> <li pn="section-4.1-2.1.2.4" derivedCounter="D.">Feedback messageoverhead.</t> <t>Convergence time - timeoverhead.</li> <li pn="section-4.1-2.1.2.5" derivedCounter="E.">Convergence time. Time to reach steady state for thecongestion controlledcongestion-controlled media flow(s). Each occurrence of convergence during the test periodneedneeds to bepresented.</t> </list></t> <t>Transportpresented.</li> </ol> </li> <li pn="section-4.1-2.2" derivedCounter="2."> <t indent="0" pn="section-4.1-2.2.1">Transport level:<list style="letters"> <t>Bandwidth utilization.</t> <t>Queue</t> <ol spacing="normal" type="A" indent="adaptive" start="1" pn="section-4.1-2.2.2"> <li pn="section-4.1-2.2.2.1" derivedCounter="A.">Bandwidth utilization.</li> <li pn="section-4.1-2.2.2.2" derivedCounter="B.">Queue length (milliseconds at specified pathcapacity).</t> </list></t> </list></t>capacity).</li> </ol> </li> </ol> </section> <section anchor="PC"title="Path characteristics"> <t>Eachnumbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-path-characteristics">Path Characteristics</name> <t indent="0" pn="section-4.2-1">Each path between a sender and receiver as described in <xreftarget="fig-eval-topo"/> havetarget="fig-eval-topo" format="default" sectionFormat="of" derivedContent="Figure 1"/> has the following characteristics unless otherwise specified in the testcase. <list style="symbols"> <t>Pathcase: </t> <dl newline="false" spacing="normal" indent="3" pn="section-4.2-2"> <dt pn="section-4.2-2.1">Path direction:forward and backward.</t> <t>Reference</dt> <dd pn="section-4.2-2.2">forward and backward.</dd> <dt pn="section-4.2-2.3">Reference bottleneck capacity:1Mbps.</t> <t>One-Way</dt> <dd pn="section-4.2-2.4">1 Mbps.</dd> <dt pn="section-4.2-2.5">One-way propagation delay:50ms.</dt> <dd pn="section-4.2-2.6">50 ms. Implementers are encouraged to run the experiment with additional propagation delays mentioned in <xreftarget="I-D.ietf-rmcat-eval-criteria"/></t> <t>Maximumtarget="RFC8868" format="default" sectionFormat="of" derivedContent="RFC8868"/>.</dd> <dt pn="section-4.2-2.7">Maximum end-to-end jitter:30ms.</dt> <dd pn="section-4.2-2.8">30 ms. Jitter models are described in <xreftarget="I-D.ietf-rmcat-eval-criteria"/></t> <t>Bottlenecktarget="RFC8868" format="default" sectionFormat="of" derivedContent="RFC8868"/>.</dd> <dt pn="section-4.2-2.9">Bottleneck queue type:"tail</dt> <dd pn="section-4.2-2.10">"tail drop". Implementers are encouraged to run the experiment with otherAQMActive Queue Management (AQM) schemes, such as FQ-CoDel andPIE.</t> <t>BottleneckPIE.</dd> <dt pn="section-4.2-2.11">Bottleneck queue size:300ms.</t> <t>Path</dt> <dd pn="section-4.2-2.12">300 ms.</dd> <dt pn="section-4.2-2.13">Path loss ratio:0%.</t> </list></t> <t>Examples</dt> <dd pn="section-4.2-2.14">0%.</dd> </dl> <t indent="0" pn="section-4.2-3">Examples of additional network parameters are discussed in <xreftarget="I-D.ietf-rmcat-eval-criteria"/>.</t> <t>Fortarget="RFC8868" format="default" sectionFormat="of" derivedContent="RFC8868"/>.</t> <t indent="0" pn="section-4.2-4">For test cases involving time-varying bottleneck capacity, all capacity values are specified as a ratio with respect to a reference capacity value, so as to allow flexible scaling of capacity values along with media source rate range. There exist two different mechanisms for inducing path capacity variation: a) by explicitly modifying the value of physical linkcapacity;capacity, or b) by introducing background non-adaptive UDP traffic with time-varying traffic rate. Implementers are encouraged to run the experiments with both mechanisms for test cases specified in <xreftarget="VACS"/>, <xref target="VACM"/>, and <xref target="CFL"/>.</t>target="VACS" format="default" sectionFormat="of" derivedContent="Section 5.1"/>, <xref target="VACM" format="default" sectionFormat="of" derivedContent="Section 5.2"/>, and <xref target="CFL" format="default" sectionFormat="of" derivedContent="Section 5.3"/>.</t> </section> <section anchor="MS"title="Media source"> <t>Unlessnumbered="true" toc="include" removeInRFC="false" pn="section-4.3"> <name slugifiedName="name-media-source">Media Source</name> <t indent="0" pn="section-4.3-1">Unless otherwise specified, each test case will include one or more media sources as describedbelow. <list style="symbols"> <t>Media type: Video <list style="symbols"> <t>Media codec: VBR</t> <t>Mediabelow: </t> <dl newline="false" spacing="normal" indent="3" pn="section-4.3-2"> <dt pn="section-4.3-2.1">Media type:</dt> <dd pn="section-4.3-2.2"> <t indent="0" pn="section-4.3-2.2.1">Video</t> <dl newline="false" spacing="normal" indent="3" pn="section-4.3-2.2.2"> <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 sourcebehavior: <list style="symbols"> <t>Adaptability: <list style="symbols"> <t>Bitbehavior:</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 raterange:range:</dt> <dd pn="section-4.3-2.2.2.4.2.2.2.2"> 150 Kbps - 1.5 Mbps. In real-lifeapplicationsapplications, the bit rate range can vary a lot depending on the providedservice,service; for example, the maximum bit rate can be up to4Mbps.4 Mbps. However, for running tests to evaluate the congestion controlalgorithmsalgorithms, it is more important to have a look at how theyare reactingreact to a certain amount of bandwidth change. Also it is possible that the media traffic generator used in a particular simulator or testbed is not capable of generating a higher bit rate.HenceHence, we have selected a suitable bit rate range typical of consumer-grade video conferencing applications in designing the test case. If a different bit rate range is used in the test cases, then the end-to-end path capacity values will also need to be scaledaccordingly.</t> <t>Frameaccordingly.</dd> <dt pn="section-4.3-2.2.2.4.2.2.2.3">Frame resolution:144p</dt> <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 range. If a different bit rate range is used in the testcasescases, thenthea suitable frame resolution range alsoneedneeds to beselected suitably.</t> <t>Frameselected.</dd> <dt pn="section-4.3-2.2.2.4.2.2.2.5">Frame rate:10fps</dt> <dd pn="section-4.3-2.2.2.4.2.2.2.6">10 fps -30fps.30 fps. This frame rate range is selected based on the bit rate range. If a different bit rate range is used in the testcasescases, then the frame rate range alsoneedneeds to beadjusted suitably.</t> </list></t> <t>Variationsuitably adjusted.</dd> </dl> </dd> <dt pn="section-4.3-2.2.2.4.2.3">Variation from target bit rate:+/-5%.</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 be calculated over a one (1) second period oftime.</t> <t>Responsivenesstime.</dd> <dt pn="section-4.3-2.2.2.4.2.5">Responsiveness to new bit rate request:100ms</t> </list></t> <t>Media content: The</dt> <dd pn="section-4.3-2.2.2.4.2.6">100 ms</dd> </dl> </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. We recommendto useusing the Foreman videosequence<xref target="xiph-seq"/>.</t> <t>Mediasequence <xref target="xiph-seq" format="default" sectionFormat="of" derivedContent="xiph-seq"/>.</dd> <dt pn="section-4.3-2.2.2.7">Media startupbehavior: 150Kbps.behavior:</dt> <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 bit rate value for a certain network condition. In suchcasescases, the candidate proposals may show the effectiveness of such a smart approach asanadditional information for the evaluationprocess.</t> </list></t> </list><list style="symbols"> <t>Media type: Audio<list style="symbols"> <t>Mediaprocess.</dd> </dl> </dd> <dt pn="section-4.3-2.3">Media type:</dt> <dd pn="section-4.3-2.4"> <t indent="0" pn="section-4.3-2.4.1">Audio</t> <dl spacing="normal" indent="3" newline="false" pn="section-4.3-2.4.2"> <dt pn="section-4.3-2.4.2.1">Media codec:CBR</t> <t>Media</dt> <dd pn="section-4.3-2.4.2.2">CBR</dd> <dt pn="section-4.3-2.4.2.3">Media bitrate: 20Kbps</t> </list></t> </list></t>rate:</dt> <dd pn="section-4.3-2.4.2.4">20 Kbps</dd> </dl> </dd> </dl> </section> </section> <section anchor="TC"title="Basicnumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-basic-test-cases">Basic TestCases">Cases</name> <section anchor="VACS"title="Variablenumbered="true" toc="include" removeInRFC="false" pn="section-5.1"> <name slugifiedName="name-variable-available-capacity">Variable Available Capacity with a SingleFlow"> <t>InFlow</name> <t indent="0" pn="section-5.1-1">In this testcasecase, the minimum bottleneck-link capacity between the two endpoints varies over time. This test is designed to measure the responsiveness of the candidate algorithm. This test tries to address the requirements in <xreftarget="I-D.ietf-rmcat-cc-requirements"/>,target="RFC8836" format="default" sectionFormat="of" derivedContent="RFC8836"/>, which requires the algorithm to adapt the flow(s) and provide lower end-to-end latency when there exists:<list style="symbols"> <t>an</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-2"> <li pn="section-5.1-2.1">an intermediatebottleneck</t> <t>changebottleneck</li> <li pn="section-5.1-2.2">change in available capacity (e.g., due to interface change, routing change, abrupt arrival/departure of background non-adaptivetraffic).</t> <t>maximumtraffic)</li> <li pn="section-5.1-2.3">maximum media bit rate is greater than link capacity. In this case, when the application tries to ramp up to its maximum bit rate, since the link capacity is limited to avalue lower,lower value, the congestion control scheme is expected to stabilize the sending bit rate close to the available bottleneckcapacity.</t> <!-- --> </list>Itcapacity.</li> </ul> <t indent="0" pn="section-5.1-3">It should be noted that the exact variation in available capacity due to any of the above depends on the underlying technologies. Hence, we describe a set of known factors, which may be extended to devise a more specific test case targeting certain behaviors in a certain network environment.</t><t>Expected behavior: the<dl spacing="normal" indent="3" newline="false" pn="section-5.1-4"> <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'scapacitycapacity, and adapt the flow to avoid unwanted media rate oscillation when the sending bit rate is approaching the bottleneck link's capacity. Such oscillations might occur when the media flow(s) attempts to reach its maximum bit rate but overshoots the usage of the available bottleneckcapacitycapacity, then to rectify, it reduces the bit rate and starts to ramp upagain.</t> <t>Evaluation metrics : asagain.</dd> <dt pn="section-5.1-4.3">Evaluation metrics:</dt> <dd pn="section-5.1-4.4">As described in <xreftarget="EM"/>.</t> <t>Testbed topology: Onetarget="EM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>.</dd> <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 path and corresponding feedback/control traffic is transported over the backward path. </dd> </dl> <figure anchor="fig-eval-topo-4-2"title="Testbedalign="left" suppress-title="false" pn="figure-2"> <name slugifiedName="name-testbed-topology-for-limite">Testbed Topology for Limited LinkCapacity"> <artwork><![CDATA[Capacity</name> <artwork name="" type="" align="left" alt="" pn="section-5.1-5.1"> Forward-->--> +---+ +-----+ +-----+ +---+ |S1 |=======| A|------------------------------>||------------------------------>| B |=======|R1 | +---+ ||<------------------------------||<------------------------------| | +---+ +-----+ +-----+<--<-- Backward]]></artwork> </figure></t> <t>Testbed attributes:</t> <t><list style="symbols"> <t>Test duration: 100s</t> <t>Path characteristics: as</artwork> </figure> <dl spacing="normal" indent="3" newline="false" pn="section-5.1-6"> <dt pn="section-5.1-6.1">Testbed attributes:</dt> <dd pn="section-5.1-6.2"> <t indent="0" pn="section-5.1-6.2.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.1-6.2.2"> <dt pn="section-5.1-6.2.2.1">Test duration:</dt> <dd pn="section-5.1-6.2.2.2">100 s</dd> <dt pn="section-5.1-6.2.2.3">Path characteristics:</dt> <dd pn="section-5.1-6.2.2.4">as described in <xreftarget="PC"/></t> <t>Application-related: <list style="symbols"> <t>Media Traffic:<list style="symbols"> <t>Media type: Video<list style="symbols"> <t>Media direction: forward.</t> <t>Number of media sources: one (1)</t> <t>Media timeline: <list style="symbols"> <t>Start time: 0s.</t> <t>End time: 99s.</t> </list></t> </list></t> <t>Media type: Audio<list style="symbols"> <t>Media direction: forward.</t> <t>Number of media sources: one (1)</t> <t>Media timeline: <list style="symbols"> <t>Start time: 0s.</t> <t>End time: 99s.</t> </list></t> </list></t> </list></t> <t>Competing traffic: <list style="symbols"> <t>Number of sources : zero (0)</t> </list></t> </list></t> <t>Test Specific Information: <list style="symbols"> <t>One-waytarget="PC" format="default" sectionFormat="of" derivedContent="Section 4.2"/></dd> <dt pn="section-5.1-6.2.2.5">Application-related:</dt> <dd pn="section-5.1-6.2.2.6"> <t indent="0" pn="section-5.1-6.2.2.6.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.1-6.2.2.6.2"> <dt pn="section-5.1-6.2.2.6.2.1">Media Traffic:</dt> <dd pn="section-5.1-6.2.2.6.2.2"> <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-5.1-6.2.2.6.2.2.2"> <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 indent="0" pn="section-5.1-6.2.2.6.2.2.2.2.1">Video</t> <dl spacing="normal" indent="3" newline="false" pn="section-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 direction:</dt> <dd pn="section-5.1-6.2.2.6.2.2.2.2.2.2">forward</dd> <dt pn="section-5.1-6.2.2.6.2.2.2.2.2.3">Number of media sources:</dt> <dd pn="section-5.1-6.2.2.6.2.2.2.2.2.4">one (1)</dd> <dt pn="section-5.1-6.2.2.6.2.2.2.2.2.5">Media timeline:</dt> <dd pn="section-5.1-6.2.2.6.2.2.2.2.2.6"> <t indent="0" pn="section-5.1-6.2.2.6.2.2.2.2.2.6.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.1-6.2.2.6.2.2.2.2.2.6.2"> <dt pn="section-5.1-6.2.2.6.2.2.2.2.2.6.2.1">Start time:</dt> <dd pn="section-5.1-6.2.2.6.2.2.2.2.2.6.2.2">0 s</dd> <dt pn="section-5.1-6.2.2.6.2.2.2.2.2.6.2.3">End time:</dt> <dd pn="section-5.1-6.2.2.6.2.2.2.2.2.6.2.4">99 s</dd> </dl> </dd> </dl> </dd> <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"> <t indent="0" pn="section-5.1-6.2.2.6.2.2.2.4.1">Audio</t> <dl spacing="normal" indent="3" newline="false" pn="section-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 direction:</dt> <dd pn="section-5.1-6.2.2.6.2.2.2.4.2.2">forward</dd> <dt pn="section-5.1-6.2.2.6.2.2.2.4.2.3">Number of media sources:</dt> <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 timeline:</dt> <dd pn="section-5.1-6.2.2.6.2.2.2.4.2.6"> <t indent="0" pn="section-5.1-6.2.2.6.2.2.2.4.2.6.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.1-6.2.2.6.2.2.2.4.2.6.2"> <dt pn="section-5.1-6.2.2.6.2.2.2.4.2.6.2.1">Start time:</dt> <dd pn="section-5.1-6.2.2.6.2.2.2.4.2.6.2.2">0 s</dd> <dt pn="section-5.1-6.2.2.6.2.2.2.4.2.6.2.3">End time:</dt> <dd pn="section-5.1-6.2.2.6.2.2.2.4.2.6.2.4">99 s</dd> </dl> </dd> </dl> </dd> </dl> </dd> <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"> <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-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:</dt> <dd pn="section-5.1-6.2.2.6.2.4.2.2">zero (0)</dd> </dl> </dd> </dl> </dd> </dl> </dd> <dt pn="section-5.1-6.3">Test-specific information:</dt> <dd pn="section-5.1-6.4"> <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 propagationdelay: [ 50delay:</dt> <dd pn="section-5.1-6.4.2.2">[50 ms, 100 ms].onOn the forward pathdirection</t> <t>Thisdirection.</dd> </dl> <t indent="0" pn="section-5.1-6.4.3">This test uses bottleneck path capacity variation as listed in <xreftarget="VACS_US"/></t> <t>Whentarget="VACS_US" format="default" sectionFormat="of" derivedContent="Table 1"/>.</t> <t indent="0" pn="section-5.1-6.4.4">When using background non-adaptive UDP traffic to induce a time-varyingbottleneck ,bottleneck, the physical path capacity remains at4Mbps4 Mbps, and the UDP traffic source rate changes over time as (4 - (Y x r)), where r is the Reference bottleneck capacity inMbpsMbps, and Y is the path capacity ratio specified in <xreftarget="VACS_US"/></t> </list></t> </list></t> <texttabletarget="VACS_US" format="default" sectionFormat="of" derivedContent="Table 1"/>.</t> </dd> </dl> <table anchor="VACS_US"title="Path capacity variation patternalign="center" pn="table-1"> <name slugifiedName="name-path-capacity-variation-pat">Path Capacity Variation Pattern forforward direction"> <ttcol>Variation pattern index</ttcol> <ttcol>Path direction</ttcol> <ttcol>Start time</ttcol> <ttcol>Path capacity ratio</ttcol> <c>One</c> <c>Forward</c> <c>0s</c> <c>1.0</c> <c>Two</c> <c>Forward</c> <c>40s</c> <c>2.5</c> <c>Three</c> <c>Forward</c> <c>60s</c> <c>0.6</c> <c>Four</c> <c>Forward</c> <c>80s</c> <c>1.0</c> <!-- <postamble>Table 1: Path capacity variationthe Forward Direction</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Variation patternfor forward direction</postamble> --> </texttable> <t/>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 anchor="VACM"title="Variablenumbered="true" toc="include" removeInRFC="false" pn="section-5.2"> <name slugifiedName="name-variable-available-capacity-">Variable Available Capacity with MultipleFlows"> <t>ThisFlows</name> <t indent="0" pn="section-5.2-1">This test case is similar to <xreftarget="VACS"/>. However in additiontarget="VACS" format="default" sectionFormat="of" derivedContent="Section 5.1"/>. However, this test will also consider persistent network load due to competing traffic.</t><t>Expected behavior: the<dl spacing="normal" indent="3" newline="false" pn="section-5.2-2"> <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) accordingly. The flows stabilize around their maximum bit rate as the maximum link capacity is large enough to accommodate the flows. When the available capacity drops, the flows adapt by decreasing their sending bit rate, and when congestion disappears, the flows are again expected to rampup.</t> <t>Evaluation metrics : asup.</dd> <dt pn="section-5.2-2.3">Evaluation metrics:</dt> <dd pn="section-5.2-2.4">As described in <xreftarget="EM"/>.</t> <t>Testbed Topology: Twotarget="EM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>.</dd> <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 transported over the forward path and corresponding feedback/control traffic is transported over the backward path. </dd> </dl> <figure anchor="fig-eval-topo-4-1"title="Testbedalign="left" suppress-title="false" pn="figure-3"> <name slugifiedName="name-testbed-topology-for-variab">Testbed Topology for Variable AvailableCapacity"> <artwork><![CDATA[Capacity</name> <artwork name="" type="" align="left" alt="" pn="section-5.2-3.1"> +---+ +---+ |S1 |===== \ / =======|R1 | +---+ \\ Forward-->--> // +---+ \\ // +-----+ +-----+ | A|------------------------------>||------------------------------>| B | ||<------------------------------||<------------------------------| | +-----+ +-----+ // \\ //<--<-- Backward \\ +---+ // \\ +---+ |S2 |====== / \ ======|R2 | +---+ +---+]]></artwork> </figure></t> <t>Testbed attributes:</t> <t>Testbed</artwork> </figure> <dl spacing="normal" indent="3" newline="false" pn="section-5.2-4"> <dt pn="section-5.2-4.1">Testbed attributes:</dt> <dd pn="section-5.2-4.2">Testbed attributes are similarasto those described in <xreftarget="VACS"/>target="VACS" format="default" sectionFormat="of" derivedContent="Section 5.1"/>, except for thetest specifictest-specific capacity variationsetup.</t> <t>Test Specific Information: Thissetup.</dd> <dt pn="section-5.2-4.3">Test-specific information:</dt> <dd pn="section-5.2-4.4">This test uses path capacity variation as listed in <xreftarget="VACM_US"/>target="VACM_US" format="default" sectionFormat="of" derivedContent="Table 2"/> with a corresponding end time of 125 seconds. The reference bottleneck capacity is2Mbps.2 Mbps. When using background non-adaptive UDP traffic to induce time-varying bottleneck forcongestion controlledcongestion-controlled media flows, the physical path capacity is4Mbps4 Mbps, and the UDP traffic source rate changes over time as (4 - (Y x r)), where r is the Reference bottleneck capacity inMbpsMbps, and Y is the path capacity ratio specified in <xreftarget="VACM_US"/>.</t> <texttabletarget="VACM_US" format="default" sectionFormat="of" derivedContent="Table 2"/>.</dd> </dl> <table anchor="VACM_US"title="Path capacity variation patternalign="center" pn="table-2"> <name slugifiedName="name-path-capacity-variation-patt">Path Capacity Variation Pattern forforward direction"> <ttcol>Variation pattern index</ttcol> <ttcol>Path direction</ttcol> <ttcol>Start time</ttcol> <ttcol>Path capacity ratio</ttcol> <c>One</c> <c>Forward</c> <c>0s</c> <c>2.0</c> <c>Two</c> <c>Forward</c> <c>25s</c> <c>1.0</c> <c>Three</c> <c>Forward</c> <c>50s</c> <c>1.75</c> <c>Four</c> <c>Forward</c> <c>75s</c> <c>0.5</c> <c>Five</c> <c>Forward</c> <c>100s</c> <c>1.0</c> <!-- <postamble>Table 2: Path capacity variationthe Forward Direction</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Variation patternfor forward direction</postamble> --> </texttable>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">2.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">25 s</td> <td align="left" colspan="1" rowspan="1">1.0</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">50 s</td> <td align="left" colspan="1" rowspan="1">1.75</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">75 s</td> <td align="left" colspan="1" rowspan="1">0.5</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">Five</td> <td align="left" colspan="1" rowspan="1">Forward</td> <td align="left" colspan="1" rowspan="1">100 s</td> <td align="left" colspan="1" rowspan="1">1.0</td> </tr> </tbody> </table> </section> <section anchor="CFL"title="Congestednumbered="true" toc="include" removeInRFC="false" pn="section-5.3"> <name slugifiedName="name-congested-feedback-link-wit">Congested Feedback Link with Bi-directional MediaFlows"> <t>Real-timeFlows</name> <t indent="0" pn="section-5.3-1">Real-time interactive media usesRTPRTP; hence it is assumed that RTCP, RTP headerextensionextension, or such would be used by the congestion control algorithm in thebackchannel.back channel. Due to the asymmetric nature of the link between communicatingpeerspeers, it is possible for a participating peer to not receive such feedback information due to an impaired or congestedbackchannelback channel (even when the forward channel might not be impaired). This test case is designed to observe the candidate congestion control behavior in such an event.</t><t>Expected behavior: It<dl spacing="normal" indent="3" newline="false" pn="section-5.3-2"> <dt pn="section-5.3-2.1">Expected behavior:</dt> <dd pn="section-5.3-2.2"> <t indent="0" pn="section-5.3-2.2.1">It is expected that the candidate 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 channel.</t><t>It<t indent="0" pn="section-5.3-2.2.2">It should be noted that for this testcase:case, logs are compared with the reference case,i.e,i.e., when the backward channel has no impairments.</t><t>Evaluation metrics : as</dd> <dt pn="section-5.3-2.3">Evaluation metrics:</dt> <dd pn="section-5.3-2.4">As described in <xreftarget="EM"/>.</t> <t>Testbed topology: Onetarget="EM" format="default" 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 sending data, respectively. The media traffic (S1->R1) is transported over the forwardpathpath, and the corresponding feedback/control traffic is transported over the backward path.LikewiseLikewise, media traffic (S2->R2) is transported over the backwardpathpath, and the corresponding feedback/control traffic is transported over the forwardpath.</t> <t><figurepath.</dd> </dl> <figure anchor="fig-eval-topo-4-6"title="Testbedalign="left" suppress-title="false" pn="figure-4"> <name slugifiedName="name-testbed-topology-for-conges">Testbed Topology for Congested FeedbackLink"> <artwork><![CDATA[Link</name> <artwork name="" type="" align="left" alt="" pn="section-5.3-3.1"> +---+ +---+ |S1|=====|====== \ Forward-->--> / =======|R1 | +---+ \\ // +---+ \\ // +-----+ +-----+ | A|------------------------------>||------------------------------>| B | ||<------------------------------||<------------------------------| | +-----+ +-----+ // \\ //<--<-- Backward \\ +---+ // \\ +---+ |R2 |===== / \ ======|S2 | +---+ +---+]]></artwork> </figure></t> <t>Testbed attributes:</t> <t><list style="symbols"> <t>Test duration: 100s</t> <t>Path characteristics: <list style="symbols"> <t>Reference</artwork> </figure> <dl spacing="normal" indent="3" newline="false" pn="section-5.3-4"> <dt pn="section-5.3-4.1">Testbed attributes:</dt> <dd pn="section-5.3-4.2"> <t indent="0" pn="section-5.3-4.2.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.3-4.2.2"> <dt pn="section-5.3-4.2.2.1">Test duration:</dt> <dd pn="section-5.3-4.2.2.2">100 s</dd> <dt pn="section-5.3-4.2.2.3">Path characteristics:</dt> <dd pn="section-5.3-4.2.2.4"> <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-4.2.2.4.2"> <dt pn="section-5.3-4.2.2.4.2.1">Reference bottleneckcapacity: 1Mbps.</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 and backward</t> <t>Number of media sources: two (2)</t> <t>Media timeline: <list style="symbols"> <t>Start time: 0s.</t> <t>End time: 99s.</t> </list></t> </list></t> <t>Media type: Audio<list style="symbols"> <t>Media direction: forward and backward</t> <t>Number of media sources: two (2)</t> <t>Mediacapacity:</dt> <dd pn="section-5.3-4.2.2.4.2.2">1 Mbps</dd> </dl> </dd> <dt pn="section-5.3-4.2.2.5">Application-related:</dt> <dd pn="section-5.3-4.2.2.6"> <t indent="0" pn="section-5.3-4.2.2.6.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.3-4.2.2.6.2"> <dt pn="section-5.3-4.2.2.6.2.1">Media source:</dt> <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> <dl spacing="normal" indent="3" newline="false" pn="section-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> <dd pn="section-5.3-4.2.2.6.2.2.2.2"> <t indent="0" pn="section-5.3-4.2.2.6.2.2.2.2.1">Video</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.3-4.2.2.6.2.2.2.2.2"> <dt pn="section-5.3-4.2.2.6.2.2.2.2.2.1">Media direction:</dt> <dd pn="section-5.3-4.2.2.6.2.2.2.2.2.2">forward and backward</dd> <dt pn="section-5.3-4.2.2.6.2.2.2.2.2.3">Number of media sources:</dt> <dd pn="section-5.3-4.2.2.6.2.2.2.2.2.4">two (2)</dd> <dt pn="section-5.3-4.2.2.6.2.2.2.2.2.5">Media timeline:</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 time:</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="section-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 direction:</dt> <dd pn="section-5.3-4.2.2.6.2.2.2.4.2.2">forward and backward</dd> <dt pn="section-5.3-4.2.2.6.2.2.2.4.2.3">Number of media 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 timeline:<list style="symbols"> <t>Start time: 0s.</t> <t>End time: 99s.</t> </list></t> </list></t> </list></t> <t>Competing</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 time:</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:<list style="symbols"> <t>Number of sources : zero (0)</t> </list></t> </list></t> <t>Test Specific Information: this</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:</dt> <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. <xreftarget="CFL_US"> </xref>target="CFL_US" format="default" sectionFormat="of" derivedContent="Table 3"/> lists the variation patterns applied to the forwardpathpath, and <xreftarget="CFL_DS"/>target="CFL_DS" format="default" sectionFormat="of" derivedContent="Table 4"/> lists the variation patterns applied to the backward path. When using background non-adaptive UDP traffic to induce a time-varying bottleneck forcongestion controlledcongestion-controlled media flows, the physical path capacity is4Mbps4 Mbps for bothdirectionsdirections, and the UDP traffic source rate changes over time as(4-x)Mbps(4-x) Mbps in each direction, where x is the bottleneck capacity specified in <xreftarget="CFL_DS"/>.</t> </list></t> <texttabletarget="CFL_DS" format="default" sectionFormat="of" derivedContent="Table 4"/>.</dd> </dl> <table anchor="CFL_US"title="Path capacity variation patternalign="center" pn="table-3"> <name slugifiedName="name-path-capacity-variation-patte">Path Capacity Variation Pattern forforward direction"> <ttcol>Variation pattern index</ttcol> <ttcol>Path direction</ttcol> <ttcol>Start time</ttcol> <ttcol>Path capacity ratio</ttcol> <c>One</c> <c>Forward</c> <c>0s</c> <c>2.0</c> <c>Two</c> <c>Forward</c> <c>20s</c> <c>1.0</c> <c>Three</c> <c>Forward</c> <c>40s</c> <c>0.5</c> <c>Four</c> <c>Forward</c> <c>60s</c> <c>2.0</c> <!-- <postamble>Table 3: Path capacity variationthe Forward Direction</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Variation patternfor forward direction</postamble> --> </texttable> <t/> <texttableindex</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">2.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">20 s</td> <td align="left" colspan="1" rowspan="1">1.0</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">40 s</td> <td align="left" colspan="1" rowspan="1">0.5</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">60 s</td> <td align="left" colspan="1" rowspan="1">2.0</td> </tr> </tbody> </table> <t indent="0" pn="section-5.3-6"/> <table anchor="CFL_DS"title="Path capacity variation patternalign="center" pn="table-4"> <name slugifiedName="name-path-capacity-variation-patter">Path Capacity Variation Pattern forbackward direction"> <ttcol>Variation pattern index</ttcol> <ttcol>Path direction</ttcol> <ttcol>Start time</ttcol> <ttcol>Path capacity ratio</ttcol> <c>One</c> <c>Backward</c> <c>0s</c> <c>2.0</c> <c>Two</c> <c>Backward</c> <c>35s</c> <c>0.8</c> <c>Three</c> <c>Backward</c> <c>70s</c> <c>2.0</c> <!-- <postamble>Table 4: Path capacity variationthe Backward Direction</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Variation patternfor backward direction</postamble> --> </texttable>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">Backward</td> <td align="left" colspan="1" rowspan="1">0 s</td> <td align="left" colspan="1" rowspan="1">2.0</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">Two</td> <td align="left" colspan="1" rowspan="1">Backward</td> <td align="left" colspan="1" rowspan="1">35 s</td> <td align="left" colspan="1" rowspan="1">0.8</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">Three</td> <td align="left" colspan="1" rowspan="1">Backward</td> <td align="left" colspan="1" rowspan="1">70 s</td> <td align="left" colspan="1" rowspan="1">2.0</td> </tr> </tbody> </table> </section> <section anchor="competing-rmcat-flow"title="Competingnumbered="true" toc="include" removeInRFC="false" pn="section-5.4"> <name slugifiedName="name-competing-media-flows-with-">Competing Media Flows withsamethe Same Congestion ControlAlgorithm"> <t>InAlgorithm</name> <t indent="0" pn="section-5.4-1">In this test case, more than one media flow share the bottlenecklinklink, and each of them uses the same congestion control algorithm. This is a typical scenario where a real-time interactive application sends more than one media flow to the samedestinationdestination, and these flows are multiplexed over the same port. In such ascenarioscenario, it is likely that the flows will be routed via the same path and need to share the available bandwidth amongst themselves. For the sake ofsimplicitysimplicity, it is assumed that there are no other competing traffic sources in the bottleneck link and that there is sufficient capacity to accommodate all the flows individually. While this appears to be a variant of the test case defined in <xreftarget="VACM"/>,target="VACM" format="default" sectionFormat="of" derivedContent="Section 5.2"/>, it focuses on thecapacity sharingcapacity-sharing aspect of the candidate algorithm. The previous test case, on the other hand, measures adaptability, stability, and responsiveness of the candidate algorithm.</t><t>Expected behavior: It<dl spacing="normal" indent="3" newline="false" pn="section-5.4-2"> <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 minimum possible latency and loss. Specifically, the test introduces three media flows at different timeinstances, wheninstances. When the second flowappearsappears, there should still be room to accommodate another flow on the bottleneck link. Lastly, when the third flowappearsappears, the bottleneck link should besaturated.</t> <t>Evaluation metrics : assaturated.</dd> <dt pn="section-5.4-2.3">Evaluation metrics:</dt> <dd pn="section-5.4-2.4">As described in <xreftarget="EM"/>.</t> <t>Testbedtarget="EM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>.</dd> <dt pn="section-5.4-2.5">Testbed topology:Three</dt> <dd pn="section-5.4-2.6">Three media sources S1, S2, and S3 are connected to R1, R2,R3and R3, respectively. The media traffic is transported over the forwardpathpath, and the corresponding feedback/control traffic is transported over the backward path. </dd> </dl> <figure anchor="fig-eval-topo-4-3"title="Testbedalign="left" suppress-title="false" pn="figure-5"> <name slugifiedName="name-testbed-topology-for-multip">Testbed Topology for Multiplecongestion controlled media Flows"> <artwork><![CDATA[Congestion-Controlled Media Flows</name> <artwork name="" type="" align="left" alt="" pn="section-5.4-3.1"> +---+ +---+ |S1 |===== \ Forward-->--> / =======|R1 | +---+ \\ // +---+ \\ // +---+ +-----+ +-----+ +---+ |S2 |=======| A|------------------------------>||------------------------------>| B |=======|R2 | +---+ ||<------------------------------||<------------------------------| | +---+ +-----+ +-----+ //<--<-- Backward \\ +---+ // \\ +---+ |S3 |===== / \ ======|R3 | +---+ +---+]]></artwork> </figure></t> <t>Testbed attributes:</t> <t><list style="symbols"> <t>Test duration: 120s</t> <t>Path characteristics: <list style="symbols"> <t>Reference</artwork> </figure> <dl spacing="normal" indent="3" newline="false" pn="section-5.4-4"> <dt pn="section-5.4-4.1">Testbed attributes:</dt> <dd pn="section-5.4-4.2"> <t indent="0" pn="section-5.4-4.2.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.4-4.2.2"> <dt pn="section-5.4-4.2.2.1">Test duration:</dt> <dd pn="section-5.4-4.2.2.2">120 s</dd> <dt pn="section-5.4-4.2.2.3">Path characteristics:</dt> <dd pn="section-5.4-4.2.2.4"> <t indent="0" pn="section-5.4-4.2.2.4.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.4-4.2.2.4.2"> <dt pn="section-5.4-4.2.2.4.2.1">Reference bottleneckcapacity: 3.5Mbps</t> <t>Path capacity ratio: 1.0</t> <!-- <t>One-Way propagation delay: [10ms, 50ms]</t> --> </list></t> <t>Application-related: <list style="symbols"> <t>Mediacapacity:</dt> <dd pn="section-5.4-4.2.2.4.2.2">3.5 Mbps</dd> <dt pn="section-5.4-4.2.2.4.2.3">Path capacity ratio:</dt> <dd pn="section-5.4-4.2.2.4.2.4">1.0</dd> </dl> </dd> <dt pn="section-5.4-4.2.2.5">Application-related: </dt> <dd pn="section-5.4-4.2.2.6"> <t indent="0" pn="section-5.4-4.2.2.6.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.4-4.2.2.6.2"> <dt pn="section-5.4-4.2.2.6.2.1">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: new</dt> <dd pn="section-5.4-4.2.2.6.2.2"> <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-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> <dd pn="section-5.4-4.2.2.6.2.2.2.2"> <t indent="0" pn="section-5.4-4.2.2.6.2.2.2.2.1">Video</t> <dl spacing="normal" indent="3" newline="false" pn="section-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 direction:</dt> <dd pn="section-5.4-4.2.2.6.2.2.2.2.2.2">forward</dd> <dt pn="section-5.4-4.2.2.6.2.2.2.2.2.3">Number of media sources:</dt> <dd pn="section-5.4-4.2.2.6.2.2.2.2.2.4">three (3)</dd> <dt pn="section-5.4-4.2.2.6.2.2.2.2.2.5">Media timeline:</dt> <dd pn="section-5.4-4.2.2.6.2.2.2.2.2.6">New media flows are added sequentially, at short time intervals. Seetest specificthe test-specific setupbelow.</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: newbelow.</dd> </dl> </dd> <dt pn="section-5.4-4.2.2.6.2.2.2.3">Media type:</dt> <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</t> <dl spacing="normal" indent="3" newline="false" pn="section-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 direction:</dt> <dd pn="section-5.4-4.2.2.6.2.2.2.4.2.2">forward</dd> <dt pn="section-5.4-4.2.2.6.2.2.2.4.2.3">Number of media sources:</dt> <dd pn="section-5.4-4.2.2.6.2.2.2.4.2.4">three (3)</dd> <dt pn="section-5.4-4.2.2.6.2.2.2.4.2.5">Media timeline:</dt> <dd pn="section-5.4-4.2.2.6.2.2.2.4.2.6">New media flows are added sequentially, at short time intervals. Seetest specificthe test-specific setupbelow.</t> </list></t> </list></t> <t>Competingbelow.</dd> </dl> </dd> </dl> </dd> <dt pn="section-5.4-4.2.2.6.2.3">Competing traffic:<list style="symbols"> <t>Number of sources : zero (0)</t> </list></t> </list></t> <t>Test Specific Information: <xref target="MTL_CF"/></dt> <dd pn="section-5.4-4.2.2.6.2.4"> <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-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:</dt> <dd pn="section-5.4-4.2.2.6.2.4.2.2">zero (0)</dd> </dl> </dd> </dl> </dd> </dl> </dd> <dt pn="section-5.4-4.3">Test-specific information:</dt> <dd pn="section-5.4-4.4"> <xref target="MTL_CF" format="default" sectionFormat="of" derivedContent="Table 5"/> defines the media timeline for both mediatype.</t> </list></t> <texttabletypes.</dd> </dl> <table anchor="MTL_CF"title="Media Timelinealign="center" pn="table-5"> <name slugifiedName="name-media-timelines-for-video-a">Media Timelines for Video and Audiomedia sources"> <ttcol>Flow ID</ttcol> <ttcol>Media type</ttcol> <ttcol>Start time</ttcol> <ttcol>End time</ttcol> <c>1</c> <c>Video</c> <c>0s</c> <c>119s</c> <c>2</c> <c>Video</c> <c>20s</c> <c>119s</c> <c>3</c> <c>Video</c> <c>40s</c> <c>119s</c> <c>4</c> <c>Audio</c> <c>0s</c> <c>119s</c> <c>5</c> <c>Audio</c> <c>20s</c> <c>119s</c> <c>6</c> <c>Audio</c> <c>40s</c> <c>119s</c> </texttable>Media Sources</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Flow ID</th> <th align="left" colspan="1" rowspan="1">Media type</th> <th align="left" colspan="1" rowspan="1">Start time</th> <th align="left" colspan="1" rowspan="1">End time</th> </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> <sectiontitle="Roundnumbered="true" toc="include" removeInRFC="false" pn="section-5.5"> <name slugifiedName="name-round-trip-time-fairness">Round Trip TimeFairness"> <t>InFairness</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 sake ofsimplicitysimplicity, it is assumed that there are no other competing traffic sources in the bottleneck link and that there is sufficient capacity to accommodate all the flows. While this appears to be a variant of test case5.2,5.2 (<xref target="VACM" format="default" sectionFormat="of" derivedContent="Section 5.2"/>), it focuses on thecapacity sharingcapacity-sharing aspect of the candidate algorithm under different RTTs.</t><t>Expected behavior: It<dl spacing="normal" indent="3" newline="false" pn="section-5.5-2"> <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 possible latency and loss. The effectiveness of the algorithm depends on how fast and fairly the competing flows converge to their steady states irrespective of the RTTobserved.</t> <t>Evaluation metrics : asobserved.</dd> <dt pn="section-5.5-2.3">Evaluation metrics:</dt> <dd pn="section-5.5-2.4">As described in <xreftarget="EM"/>.</t> <t>Testbed Topology: Fivetarget="EM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>.</dd> <dt pn="section-5.5-2.5">Testbed topology: </dt> <dd pn="section-5.5-2.6">Five (5) media sourcesS1,S2,..,S5S1..S5 are connected to their corresponding media sinksR1,R2,..,R5.R1..R5. The media traffic is transported over the forwardpathpath, and the corresponding feedback/control traffic is transported over the backward path. The topology is the same as in <xreftarget="competing-rmcat-flow"/>.</t> <t>Testbed attributes:</t> <t><list style="symbols"> <t>Test duration: 300s</t> <t>Pathtarget="competing-rmcat-flow" format="default" sectionFormat="of" derivedContent="Section 5.4"/>.</dd> <dt pn="section-5.5-2.7">Testbed attributes: </dt> <dd pn="section-5.5-2.8"> <t indent="0" pn="section-5.5-2.8.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.5-2.8.2"> <dt pn="section-5.5-2.8.2.1">Test duration:</dt> <dd pn="section-5.5-2.8.2.2">300 s</dd> <dt pn="section-5.5-2.8.2.3">Path characteristics:<list style="symbols"> <t>Reference</dt> <dd pn="section-5.5-2.8.2.4"> <t indent="0" pn="section-5.5-2.8.2.4.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.5-2.8.2.4.2"> <dt pn="section-5.5-2.8.2.4.2.1">Reference bottleneckcapacity: 4Mbps</t> <t>Path capacity ratio: 1.0</t> <t>One-Waycapacity:</dt> <dd pn="section-5.5-2.8.2.4.2.2">4 Mbps</dd> <dt pn="section-5.5-2.8.2.4.2.3">Path capacity ratio:</dt> <dd pn="section-5.5-2.8.2.4.2.4">1.0</dd> <dt pn="section-5.5-2.8.2.4.2.5">One-way propagation delay for eachflow: 10msflow:</dt> <dd pn="section-5.5-2.8.2.4.2.6">10 ms for S1-R1,25ms25 ms for S2-R2,50ms50 ms for S3-R3,100ms100 ms for S4-R4, and150ms S5-R5.</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: five (5)</t> <t>Media timeline: new150 ms S5-R5.</dd> </dl> </dd> <dt pn="section-5.5-2.8.2.5">Application-related: </dt> <dd pn="section-5.5-2.8.2.6"> <t indent="0" pn="section-5.5-2.8.2.6.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.5-2.8.2.6.2"> <dt pn="section-5.5-2.8.2.6.2.1">Media source: </dt> <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> <dl spacing="normal" indent="3" newline="false" pn="section-5.5-2.8.2.6.2.2.2"> <dt pn="section-5.5-2.8.2.6.2.2.2.1">Media type:</dt> <dd pn="section-5.5-2.8.2.6.2.2.2.2"> <t indent="0" pn="section-5.5-2.8.2.6.2.2.2.2.1">Video</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.5-2.8.2.6.2.2.2.2.2"> <dt pn="section-5.5-2.8.2.6.2.2.2.2.2.1">Media direction:</dt> <dd pn="section-5.5-2.8.2.6.2.2.2.2.2.2">forward</dd> <dt pn="section-5.5-2.8.2.6.2.2.2.2.2.3">Number of media sources:</dt> <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 timeline:</dt> <dd pn="section-5.5-2.8.2.6.2.2.2.2.2.6">New media flows are added sequentially, at short time intervals. Seetest specificthe test-specific setupbelow.</t> </list></t> <t>Media type: Audio<list style="symbols"> <t>Media direction: forward.</t> <t>Number of media sources:below.</dd> </dl> </dd> <dt pn="section-5.5-2.8.2.6.2.2.2.3">Media type:</dt> <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</t> <dl spacing="normal" indent="3" newline="false" pn="section-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 direction:</dt> <dd pn="section-5.5-2.8.2.6.2.2.2.4.2.2">forward</dd> <dt pn="section-5.5-2.8.2.6.2.2.2.4.2.3">Number of media sources:</dt> <dd pn="section-5.5-2.8.2.6.2.2.2.4.2.4"> five(5)</t> <t>Media timeline: new(5)</dd> <dt pn="section-5.5-2.8.2.6.2.2.2.4.2.5">Media timeline:</dt> <dd pn="section-5.5-2.8.2.6.2.2.2.4.2.6">New media flows are added sequentially, at short time intervals. Seetest specificthe test-specific setupbelow.</t> </list></t> </list></t> <t>Competingbelow.</dd> </dl> </dd> </dl> </dd> <dt pn="section-5.5-2.8.2.6.2.3">Competing traffic:<list style="symbols"> <t>Number of sources : zero (0)</t> </list></t> </list></t> <t>Test Specific Information: <xref target="MTL_RTT"/></dt> <dd pn="section-5.5-2.8.2.6.2.4"> <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-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:</dt> <dd pn="section-5.5-2.8.2.6.2.4.2.2">zero (0)</dd> </dl> </dd> </dl> </dd> </dl> </dd> <dt pn="section-5.5-2.9">Test-specific information: </dt> <dd pn="section-5.5-2.10"> <xref target="MTL_RTT" format="default" sectionFormat="of" derivedContent="Table 6"/> defines the media timeline for both mediatype.</t> </list></t> <texttabletypes.</dd> </dl> <table anchor="MTL_RTT"title="Mediaalign="center" pn="table-6"> <name slugifiedName="name-media-timeline-for-video-an">Media Timeline for Video and Audiomedia sources"> <ttcol>Flow IF</ttcol> <ttcol>Media type</ttcol> <ttcol>Start time</ttcol> <ttcol>End time</ttcol> <c>1</c> <c>Video</c> <c>0s</c> <c>299s</c> <c>2</c> <c>Video</c> <c>10s</c> <c>299s</c> <c>3</c> <c>Video</c> <c>20s</c> <c>299s</c> <c>4</c> <c>Video</c> <c>30s</c> <c>299s</c> <c>5</c> <c>Video</c> <c>40s</c> <c>299s</c> <c>6</c> <c>Audio</c> <c>0</c> <c>299s</c> <c>7</c> <c>Audio</c> <c>10s</c> <c>299s</c> <c>8</c> <c>Audio</c> <c>20s</c> <c>299s</c> <c>9</c> <c>Audio</c> <c>30s</c> <c>299s</c> <c>10</c> <c>Audio</c> <c>40s</c> <c>299s</c> </texttable>Media Sources</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Flow ID</th> <th align="left" colspan="1" rowspan="1">Media type</th> <th align="left" colspan="1" rowspan="1">Start time</th> <th align="left" colspan="1" rowspan="1">End time</th> </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">299 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">10 s</td> <td align="left" colspan="1" rowspan="1">299 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">20 s</td> <td align="left" colspan="1" rowspan="1">299 s</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">4</td> <td align="left" colspan="1" rowspan="1">Video</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">5</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">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> <sectiontitle="Medianumbered="true" toc="include" removeInRFC="false" pn="section-5.6"> <name slugifiedName="name-media-flow-competing-with-a">Media Flow Competing with a Long TCPFlow"> <t>InFlow</name> <t indent="0" pn="section-5.6-1">In this test case, one or more media flows share the bottleneck link with at least onelong livedlong-lived TCP flow.Long livedLong-lived TCP flows download data throughout the session and are expected to have infinite amount of data to send and receive. This is a scenario where a multimedia applicationco-existscoexists with a large file download. The test case measures the adaptivity of the candidate algorithm to competing traffic. It addressestherequirement 3 in <xreftarget="I-D.ietf-rmcat-cc-requirements"/>.</t> <t>Expected behavior: dependingtarget="RFC8836" section="2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8836#section-2" derivedContent="RFC8836"/>.</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.6-2"> <dt pn="section-5.6-2.1">Expected behavior:</dt> <dd pn="section-5.6-2.2">Depending on the convergence observed in testcasecases 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 the minimum media bitrate.</t> <t>Evaluation metrics :rate.</dd> <dt pn="section-5.6-2.3">Evaluation metrics:</dt> <dd pn="section-5.6-2.4"> <t indent="0" pn="section-5.6-2.4.1">Includes the following metrics in addition toasthose described in <xreftarget="EM"/>. <list style="numbers"> <t>Flowtarget="EM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>: </t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.6-2.4.2"> <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:<list style="letters"> <t>TCP throughput.</t> <t>Loss</t> <ol spacing="normal" type="a" indent="adaptive" start="1" pn="section-5.6-2.4.2.1.2"> <li pn="section-5.6-2.4.2.1.2.1" derivedCounter="a.">TCP throughput</li> <li pn="section-5.6-2.4.2.1.2.2" derivedCounter="b.">Loss for the TCPflow</t> </list></t> </list></t> <t>Testbed topology: Oneflow</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 along-livelong-lived TCP flow sharing the same bottleneck link. The media traffic is transported over the forwardpathpath, and the corresponding feedback/control traffic is transported over the backward path. The TCP traffic goes over the forward pathfrom,from S_tcp with acknowledgment packetsgogoing over the backward pathfrom, R_tcp.</t> <t><figurefrom R_tcp.</dd> </dl> <figure anchor="fig-eval-topo-4-4"title="Testbedalign="left" suppress-title="false" pn="figure-6"> <name slugifiedName="name-testbed-topology-for-tcp-vs">Testbed Topology for TCP vscongestion controlled media Flows"> <artwork><![CDATA[Congestion-Controlled Media Flows</name> <artwork name="" type="" align="left" alt="" pn="section-5.6-3.1"> +--+ +--+ |S1|===== \ Forward-->--> / =====|R1| +--+ \\ // +--+ \\ // +-----+ +-----+ | A|---------------------------->||---------------------------->| B | ||<----------------------------||<----------------------------| | +-----+ +-----+ //<--<-- Backward \\ +-----+ // \\ +-----+ |S_tcp|=== / \ ===|R_tcp| +-----+ +-----+]]></artwork> </figure></t> <t>Testbed attributes:</t> <t><list style="symbols"> <t>Test duration: 120s</t> <t>Path characteristics: <list style="symbols"> <t>Reference</artwork> </figure> <dl spacing="normal" indent="3" newline="false" pn="section-5.6-4"> <dt pn="section-5.6-4.1">Testbed attributes:</dt> <dd pn="section-5.6-4.2"> <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.2"> <dt pn="section-5.6-4.2.2.1">Test duration:</dt> <dd pn="section-5.6-4.2.2.2">120 s</dd> <dt pn="section-5.6-4.2.2.3">Path characteristics:</dt> <dd pn="section-5.6-4.2.2.4"> <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-4.2.2.4.2"> <dt pn="section-5.6-4.2.2.4.2.1">Reference bottleneckcapacity: 2Mbps</t> <t>Path capacity ratio: 1.0</t> <!-- <t>One-Way propagation delay: [10ms, 150ms]</t> --> <t>Bottleneckcapacity:</dt> <dd pn="section-5.6-4.2.2.4.2.2">2 Mbps</dd> <dt pn="section-5.6-4.2.2.4.2.3">Path capacity ratio:</dt> <dd pn="section-5.6-4.2.2.4.2.4">1.0</dd> <dt pn="section-5.6-4.2.2.4.2.5">Bottleneck queuesize: [300ms, 1000ms]</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: one (1)</t> <t>Media timeline: <list style="symbols"> <t>Start time: 5s.</t> <t>End time: 119s.</t> </list></t> </list></t> <t>Media type: Audio<list style="symbols"> <t>Media direction: forward</t> <t>Number of media sources: one (1)</t> <t>Media timeline: <list style="symbols"> <t>Start time: 5s.</t> <t>End time: 119s.</t> </list></t> </list></t> </list></t> <t>Additionally,size:</dt> <dd pn="section-5.6-4.2.2.4.2.6">[300 ms, 1000 ms]</dd> </dl> </dd> <dt pn="section-5.6-4.2.2.5">Application-related:</dt> <dd pn="section-5.6-4.2.2.6"> <t indent="0" pn="section-5.6-4.2.2.6.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.6-4.2.2.6.2"> <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 indent="0" pn="section-5.6-4.2.2.6.2.2.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.6-4.2.2.6.2.2.2"> <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 indent="0" pn="section-5.6-4.2.2.6.2.2.2.2.1">Video</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.6-4.2.2.6.2.2.2.2.2"> <dt pn="section-5.6-4.2.2.6.2.2.2.2.2.1">Media direction:</dt> <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 media 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 timeline:</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 time:</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="section-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 direction:</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 media 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 timeline:</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 time:</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, implementers are encouraged to run the experiment with multiple media sources.</t><t>Competing traffic: <list style="symbols"> <t>Number</dd> <dt pn="section-5.6-4.2.2.6.2.3">Competing traffic:</dt> <dd pn="section-5.6-4.2.2.6.2.4"> <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-5.6-4.2.2.6.2.4.2"> <dt pn="section-5.6-4.2.2.6.2.4.2.1">Number andTypestypes ofsources : onesources:</dt> <dd pn="section-5.6-4.2.2.6.2.4.2.2">one (1) and long-livedTCP</t> <t>Traffic direction : forward</t> <t>Congestion control: defaultTCP</dd> <dt pn="section-5.6-4.2.2.6.2.4.2.3">Traffic direction:</dt> <dd pn="section-5.6-4.2.2.6.2.4.2.4">forward</dd> <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 congestioncontrol<xref target="RFC5681"/>.control <xref target="RFC5681" format="default" sectionFormat="of" derivedContent="RFC5681"/>. Implementers are also encouraged to run the experiment with alternative TCP congestion controlalgorithm.<!----></t> <t>Trafficalgorithms.</dd> <dt pn="section-5.6-4.2.2.6.2.4.2.7">Traffic timeline:<list style="symbols"> <t>Start time: 0s.</t> <!----> <t>End time: 119s.</t> </list></t> </list></t> </list></t> <t>Test Specific Information: none</t> </list></t></dt> <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="section-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> <sectiontitle="Medianumbered="true" toc="include" removeInRFC="false" pn="section-5.7"> <name slugifiedName="name-media-flow-competing-with-s">Media Flow Competing with Short TCPFlows"> <t>InFlows</name> <t indent="0" pn="section-5.7-1">In this test case, one or morecongestion controlledcongestion-controlled mediaflow sharesflows share the bottleneck link with multiple short-lived TCP flows. Short-lived TCP flows resemble the on/off pattern observed intheweb traffic, wherein clients (for example, browsers) connect to a server and download a resource (typically a web page, few images, text files, etc.) using several TCP connections. This scenario shows the performance of a multimedia application when several browser windows are active. The test case measures the adaptivity of the candidate algorithm to competing web traffic, and it addressesthe requirementsrequirement 1.E in <xreftarget="I-D.ietf-rmcat-cc-requirements"/>.</t> <t>Dependingtarget="RFC8836" section="2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8836#section-2" derivedContent="RFC8836"/>.</t> <t indent="0" pn="section-5.7-2">Depending on the number of short TCP flows, thecross-trafficcross traffic either appears as a short burst flow or resembles alonglong-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><t>Expected behavior:<dl spacing="normal" indent="3" newline="false" pn="section-5.7-3"> <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 flows, streaming at least at the minimum media bit rate. After competing TCP flows terminate, the media streams are expected to be robust enough to eventually recover to previous steady state behavior, and at the very least, avoid persistentstarvation.</t> <t>Evaluation metrics :starvation.</dd> <dt pn="section-5.7-3.3">Evaluation metrics:</dt> <dd pn="section-5.7-3.4"> <t indent="0" pn="section-5.7-3.4.1">Includes the following metrics in addition toasthose described in <xreftarget="EM"/>.<list style="numbers"> <t>Flowtarget="EM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>:</t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.7-3.4.2"> <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:<list style="letters"> <t>Variation</t> <ol spacing="normal" type="A" indent="adaptive" start="1" pn="section-5.7-3.4.2.1.2"> <li pn="section-5.7-3.4.2.1.2.1" derivedCounter="A.">Variation in the sending rate of the TCPflow.</t> <t>TCP throughput.</t> </list></t> </list></t> <t>Testbed topology: Theflow</li> <li pn="section-5.7-3.4.2.1.2.2" derivedCounter="B.">TCP throughput</li> </ol> </li> </ol> </dd> <dt pn="section-5.7-3.5">Testbed topology:</dt> <dd pn="section-5.7-3.6">The topology described here is the same as the one described in <xreftarget="fig-eval-topo-4-4"/>.</t> <t>Testbed attributes:</t> <t><list style="symbols"> <t>Test duration: 300s</t> <t>Path characteristics: <list style="symbols"> <t>Referencetarget="fig-eval-topo-4-4" format="default" sectionFormat="of" derivedContent="Figure 6"/>.</dd> <dt pn="section-5.7-3.7">Testbed attributes:</dt> <dd pn="section-5.7-3.8"> <t indent="0" pn="section-5.7-3.8.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.7-3.8.2"> <dt pn="section-5.7-3.8.2.1">Test duration:</dt> <dd pn="section-5.7-3.8.2.2">300 s</dd> <dt pn="section-5.7-3.8.2.3">Path characteristics:</dt> <dd pn="section-5.7-3.8.2.4"> <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-3.8.2.4.2"> <dt pn="section-5.7-3.8.2.4.2.1">Reference bottleneckcapacity: 2.0Mbps</t> <t>Path capacity ratio: 1.0</t> <!-- <t>One-Way propagation delay: [10ms, 150ms]</t> --> </list></t> <t>Application-related: <list style="symbols"> <t>Mediacapacity:</dt> <dd pn="section-5.7-3.8.2.4.2.2">2.0 Mbps</dd> <dt pn="section-5.7-3.8.2.4.2.3">Path capacity ratio:</dt> <dd pn="section-5.7-3.8.2.4.2.4">1.0</dd> </dl> </dd> <dt pn="section-5.7-3.8.2.5">Application-related: </dt> <dd pn="section-5.7-3.8.2.6"> <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-3.8.2.6.2"> <dt pn="section-5.7-3.8.2.6.2.1">Media source:<list style="symbols"> <t>Media type: Video<list style="symbols"> <t>Media direction: forward</t> <t>Number of media sources: two (2)</t> <t>Media</dt> <dd pn="section-5.7-3.8.2.6.2.2"> <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-5.7-3.8.2.6.2.2.2"> <dt pn="section-5.7-3.8.2.6.2.2.2.1">Media type:</dt> <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> <dl spacing="normal" indent="3" newline="false" pn="section-5.7-3.8.2.6.2.2.2.2.2"> <dt pn="section-5.7-3.8.2.6.2.2.2.2.2.1">Media direction:</dt> <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 media 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 timeline:<list style="symbols"> <t>Start time: 5s.</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:</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 time:</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="section-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 direction:</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 media sources:</dt> <dd pn="section-5.7-3.8.2.6.2.2.2.4.2.4"> two(2)</t> <t>Media(2)</dd> <dt pn="section-5.7-3.8.2.6.2.2.2.4.2.5">Media timeline:<list style="symbols"> <t>Start time: 5s.</t> <t>End</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 time:299s.</t> </list></t> </list></t> </list></t> <t>Competing</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:<list style="symbols"> <t>Number</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 andTypestypes ofsources :sources:</dt> <dd pn="section-5.7-3.8.2.6.2.4.2.2"> ten (10), short-lived TCPflows.</t> <t>Traffic direction : forward</t> <t>Congestion algorithm: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 TCPCongestioncongestion control <xreftarget="RFC5681"/>.target="RFC5681" format="default" sectionFormat="of" derivedContent="RFC5681"/>. Implementers are also encouraged to run the experiment with an alternative TCP congestion controlalgorithm.</t> <t>Trafficalgorithm.</dd> <dt pn="section-5.7-3.8.2.6.2.4.2.7">Traffic timeline:each</dt> <dd pn="section-5.7-3.8.2.6.2.4.2.8">Each short TCP flow is modeled as a sequence of file downloads interleaved with idle periods. Not all short TCP flows start at the same time,2two of them start in the ONstatestate, while rest of the8eight flows start in an OFF state. For a description of the short TCP flowmodelmodel, seetest specifictest-specific informationbelow.</t> </list></t> </list></t> <t>Test Specific Information: <list style="symbols"> <t>Short-TCPbelow.</dd> </dl> </dd> </dl> </dd> </dl> </dd> <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 trafficmodel: Themodel:</dt> <dd pn="section-5.7-3.10.2.2">The short TCP model to be used in this test is described in <xreftarget="I-D.ietf-rmcat-eval-criteria"/>.</t> </list></t> </list></t>target="RFC8868" format="default" sectionFormat="of" derivedContent="RFC8868"/>.</dd> </dl> </dd> </dl> </section> <sectiontitle="Medianumbered="true" toc="include" removeInRFC="false" pn="section-5.8"> <name slugifiedName="name-media-pause-and-resume">Media Pause andResume"> <t>InResume</name> <t indent="0" pn="section-5.8-1">In this test case, more than one real-time interactive mediaflowsflow share the linkbandwidthbandwidth, and all flows reach to a steady state by utilizing the link capacity in an optimum way. At thisstagestage, one of 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 link. When the paused media flowresumesresumes, itwouldno longerhavehas 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 capacity. This test case is important specially for real-time interactivemediamedia, which consists of more than one media flows and can pause/resume media flows at any point of time during the session. This test case directly addressestherequirementnumber5 in <xreftarget="I-D.ietf-rmcat-cc-requirements"/>.target="RFC8836" section="2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8836#section-2" derivedContent="RFC8836"/>. One can think of it as a variation of the test case defined in <xreftarget="competing-rmcat-flow"/>.target="competing-rmcat-flow" format="default" sectionFormat="of" derivedContent="Section 5.4"/>. However, it is different as the candidate algorithms can use different strategies to increaseitsefficiency, forexampleexample, in terms of fairness, convergence time,reduceoscillationetc,reduction, etc., by capitalizing on the fact that they have previous information of the link.</t><t>Expected behavior: During<dl spacing="normal" indent="3" newline="false" pn="section-5.8-2"> <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 and reach the maximum media bit rate. When the third stream resumes, all three flows are expected to converge to the same original fair share of rates prior to the media pause/resumeevent.</t> <t>Evaluation metrics :event.</dd> <dt pn="section-5.8-2.3">Evaluation metrics:</dt> <dd pn="section-5.8-2.4"> <t indent="0" pn="section-5.8-2.4.1">Includes the following metrics in addition toasthose described in <xreftarget="EM"/>.<list style="numbers"> <t>Flowtarget="EM" format="default" sectionFormat="of" derivedContent="Section 4.1"/>:</t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.8-2.4.2"> <li pn="section-5.8-2.4.2.1" derivedCounter="1."> <t indent="0" pn="section-5.8-2.4.2.1.1">Flow level:<list style="letters"> <t>Variation</t> <ol spacing="normal" type="A" indent="adaptive" start="1" pn="section-5.8-2.4.2.1.2"> <li pn="section-5.8-2.4.2.1.2.1" derivedCounter="A.">Variation in sending bit rate and throughput. Mainly observing the frequency and magnitude ofoscillations.</t> </list></t> </list></t> <t>Testbed Topology: Sameoscillations.</li> </ol> </li> </ol> </dd> <dt pn="section-5.8-2.5">Testbed topology:</dt> <dd pn="section-5.8-2.6">Same as the test case defined in <xreftarget="competing-rmcat-flow"/></t> <t>Testbed attributes: Thetarget="competing-rmcat-flow" format="default" sectionFormat="of" derivedContent="Section 5.4"/>.</dd> <dt pn="section-5.8-2.7">Testbed attributes:</dt> <dd pn="section-5.8-2.8"> <t indent="0" pn="section-5.8-2.8.1">The general description of the testbed parameters are the same as <xreftarget="competing-rmcat-flow"/>target="competing-rmcat-flow" format="default" sectionFormat="of" derivedContent="Section 5.4"/> with changes in thetest specifictest-specific setup asbelow-</t> <t><list style="symbols"> <t>Other test specificbelow:</t> <t indent="0" pn="section-5.8-2.8.2">Other test-specific setup:<list style="symbols"> <t>Media</t> <dl spacing="normal" indent="3" newline="false" pn="section-5.8-2.8.3"> <dt pn="section-5.8-2.8.3.1">Media flow timeline:<list style="symbols"> <t>Flow</dt> <dd pn="section-5.8-2.8.3.2"> <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-2.8.3.2.2"> <dt pn="section-5.8-2.8.3.2.2.1">Flow ID:one (1)</t> <t>Start</dt> <dd pn="section-5.8-2.8.3.2.2.2">one (1)</dd> <dt pn="section-5.8-2.8.3.2.2.3">Start time:0s</t> <t>Flow</dt> <dd pn="section-5.8-2.8.3.2.2.4">0 s</dd> <dt pn="section-5.8-2.8.3.2.2.5">Flow duration:119s</t> <t>Pause</dt> <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:not required</t> <t>Resume</dt> <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:not required</t> </list></t> <t>Media</dt> <dd pn="section-5.8-2.8.3.2.2.10">not required</dd> </dl> </dd> <dt pn="section-5.8-2.8.3.3">Media flow timeline:<list style="symbols"> <t>Flow</dt> <dd pn="section-5.8-2.8.3.4"> <t indent="0" pn="section-5.8-2.8.3.4.1"><br/></t> <dl spacing="normal" indent="3" newline="false" pn="section-5.8-2.8.3.4.2"> <dt pn="section-5.8-2.8.3.4.2.1">Flow ID:two (2)</t> <t>Start</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:0s</t> <t>Flow</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:119s</t> <t>Pause</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:at 40s</t> <t>Resume</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:at 60s</t> </list></t> <t>Media</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:<list style="symbols"> <t>Flow ID: three (3)</t> <t>Start time: 0s</t> <t>Flow duration:119s</t> <t>Pause time: not required</t> <t>Resume time: not required</t> </list></t> </list></t> </list></t></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> <sectiontitle="Other potential test cases"> <t>Itnumbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-other-potential-test-cases">Other Potential Test Cases</name> <t indent="0" pn="section-6-1">It has been noticed that there are other interesting test cases besides the basic test cases listed above. In many aspects, these additional test cases can help further evaluation of the candidate algorithm. They are listedasbelow.</t> <sectiontitle="Medianumbered="true" toc="include" removeInRFC="false" pn="section-6.1"> <name slugifiedName="name-media-flows-with-priority">Media Flows withPriority"> <t>InPriority</name> <t indent="0" pn="section-6.1-1">In this testcasecase, media flows will have different priority levels. Thiswill beis an extension of <xreftarget="competing-rmcat-flow"/>target="competing-rmcat-flow" format="default" sectionFormat="of" derivedContent="Section 5.4"/> where the same testwill beis run with different priority levels imposed on each of the media flows. For example, the first flow (S1) is assigned a priority of22, whereas the remaining two flows (S2 and S3) are assigned a priority of 1. The candidate algorithm must reflect the relative priorities assigned to each media flow. In this case, the first flow (S1) must arrive at a steady-state rate approximately twiceofthat of the other two flows (S2 and S3).</t><t>The<t indent="0" pn="section-6.1-2">The candidate algorithm can use a coupled congestion control mechanism <xreftarget="I-D.ietf-rmcat-coupled-cc"/>target="RFC8699" format="default" sectionFormat="of" derivedContent="RFC8699"/> or use a weighted priority scheduler for the bandwidth distribution according to the respective media flow priority or use.</t> </section> <sectiontitle="Explicitnumbered="true" toc="include" removeInRFC="false" pn="section-6.2"> <name slugifiedName="name-explicit-congestion-notific">Explicit Congestion NotificationUsage"> <t>ThisUsage</name> <t indent="0" pn="section-6.2-1">This test case requiresto runrunning all the basic test cases with the availability of Explicit Congestion Notification (ECN) <xreftarget="RFC6679"/>target="RFC6679" format="default" sectionFormat="of" derivedContent="RFC6679"/> feature enabled. The goal of this test is to exhibit that the candidate algorithms do not fail when ECN signals are available. With ECN signalsenabledenabled, the algorithms are expected to perform better than their delay-based variants.</t> </section> <sectiontitle="Multiple Bottlenecks"> <t>Innumbered="true" toc="include" removeInRFC="false" pn="section-6.3"> <name slugifiedName="name-multiple-bottlenecks">Multiple Bottlenecks</name> <t indent="0" pn="section-6.3-1">In this testcasecase, onecongestion controlledcongestion-controlled media flow, S1->R1, traverses a path with multiple bottlenecks. As illustrated in <xreftarget="fig-eval-topo-6-2"/>,target="fig-eval-topo-6-2" format="default" sectionFormat="of" derivedContent="Figure 7"/>, the first flow (S1->R1) competes with the secondcongestion controlledcongestion-controlled media flow (S2->R2) over the link between A andBB, which is close to the senderside; again,side. Again, that flow (S1->R1) competes with the thirdcongestion controlledcongestion-controlled media flow (S3->R3) over the link between C andDD, which is close to the receiver side. The goal of this test is to ensure that the candidate algorithms work properly in the presence of multiple bottleneck links on theend to endend-to-end path.</t><t>Expected behavior:<dl spacing="normal" indent="3" newline="false" pn="section-6.3-2"> <dt pn="section-6.3-2.1">Expected behavior:</dt> <dd pn="section-6.3-2.2"> The candidate algorithm is expected to achieve full utilization at both bottleneck links without starving any of the threecongestion controlledcongestion-controlled media flows and ensuring fair share of the available bandwidth at eachbottlenecks.</t> <t><figurebottleneck.</dd> </dl> <figure anchor="fig-eval-topo-6-2"title="Testbedalign="left" suppress-title="false" pn="figure-7"> <name slugifiedName="name-testbed-topology-for-multipl">Testbed Topology for MultipleBottlenecks"> <artwork><![CDATA[Bottlenecks</name> <artwork name="" type="" align="left" alt="" pn="section-6.3-3.1"> Forward---->----> +---+ +---+ +---+ +---+ |S2 | |R2 | |S3 | |R3 | +---+ +---+ +---+ +---+ | | | | | | | | +---+ +-----+ +-----+ +-----+ +-----+ +---+ |S1|=======||======| A|------>||------>| B|----->||----->| C|---->||---->| D|=======|R1|======|R1 | +---+ ||<------| |<-----| |<----||<------| |<-----| |<----| | +---+ +-----+ +-----+ +-----+ +-----+ 1st 2nd Bottleneck(A->B)(A->B) Bottleneck(C->D) <------(C->D) <------ Backward]]></artwork> </figure></t> <t>Testbed topology: Three</artwork> </figure> <dl spacing="normal" indent="3" newline="false" pn="section-6.3-4"> <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 connected to respective destinations R1, R2, and R3. For all threeflowsflows, the media traffic is transported over the forwardpathpath, and the corresponding feedback/control traffic is transported over the backwardpath.</t> <t>Testbed attributes:</t> <t><list style="symbols"> <t>Test duration: 300s</t> <t>Pathpath.</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:<list style="symbols"> <t>Reference</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 bottleneckcapacity: 2Mbps.</t> <t>Pathcapacity:</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 andB: 1.0</t> <t>PathB:</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 andC: 4.0.</t> <t>PathC:</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 andD: 0.75.</t> <t>One-WayD:</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:<list style="numbers"> <t>Between</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 andR1: 100ms</t> <t>BetweenR1:</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 andR2: 40ms</t> <t>BetweenR2:</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 andR3: 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>MediaR3:</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="section-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 direction:</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 media 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 timeline:<list style="symbols"> <t>Start time: 0s.</t> <t>End</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 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</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="section-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 direction:</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 media 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 timeline:<list style="symbols"> <t>Start time: 0s.</t> <t>End time: 299s.</t> </list></t> </list></t> </list></t> <t>Competing</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 time:</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:<list style="symbols"> <t>Number of sources : Zero (0)</t> </list></t> </list></t> </list></t></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:</dt> <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> <sectiontitle="Wirelessnumbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-wireless-access-links">Wireless AccessLinks"> <!-- --> <t>AdditionalLinks</name> <t indent="0" pn="section-7-1">Additional wireless network (both cellular network andWiFiWi-Fi network) specific test cases are defined in <xreftarget="I-D.ietf-rmcat-wireless-tests"/>.</t>target="RFC8869" format="default" sectionFormat="of" derivedContent="RFC8869"/>.</t> </section> <sectiontitle="Security Considerations"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-8"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t indent="0" pn="section-8-1">The security considerations in <xreftarget="I-D.ietf-rmcat-eval-criteria"/>target="RFC8868" section="6" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8868#section-6" derivedContent="RFC8868"/> and the relevant congestion control algorithms apply. The principles for congestion control are described in <xreftarget="RFC2914"/>,target="RFC2914" format="default" sectionFormat="of" derivedContent="RFC2914"/>, and in particular any new method must implement safeguards to avoid congestion collapse of the Internet.</t><t>The<t indent="0" pn="section-8-2">The evaluation of the test cases are intended to be run in a controlled lab environment. Hence, the applications,simulatorssimulators, and network nodes ought to be well-behaved and should not impact the desired results. Moreover, proper measures must be taken to avoid leakingnon-responsivenonresponsive traffic from unproven congestion avoidance techniques onto the open Internet.</t> </section> <sectiontitle="IANA Considerations"> <t>There arenumbered="true" toc="include" removeInRFC="false" pn="section-9"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t indent="0" pn="section-9-1">This document has no IANAimpacts in this memo.</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>actions.</t> </section> </middle> <back> <referencestitle="Normative References"> <?rfc include='reference.RFC.6679.xml'?> <!-- RTP related --> &rfc3550; &rfc3551; &rfc3611; &rfc4585; &rfc5506; <!--RMCAT related --> &I-D.ietf-rmcat-eval-criteria; &I-D.ietf-rmcat-wireless-tests; &I-D.ietf-rmcat-video-traffic-model; &I-D.ietf-rmcat-cc-requirements; <?rfc include='reference.RFC.5681.xml'?> <!--&rfc5681; --> <!-- Standard TCP --> </references>pn="section-10"> <name slugifiedName="name-references">References</name> <referencestitle="Informative References"> <!-- &I-D.ietf-rtcweb-use-cases-and-requirements; --> <?rfc include='reference.RFC.2914.xml'?> <?rfc include='reference.RFC.8290.xml'?> <?rfc include='reference.RFC.8033.xml'?> <?rfc include='reference.RFC.7567.xml'?> <!-- &rfc5033; --> <!-- CC Evaluation --> <!-- &rfc5166; --> <!-- CC Metrics --> <!----> <!-- --> <!---->pn="section-10.1"> <name slugifiedName="name-normative-references">Normative References</name> <referenceanchor="xiph-seq">anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3550" quoteTitle="true" derivedAnchor="RFC3550"> <front><title>Video Test Media</title><title>RTP: A Transport Protocol for Real-Time Applications</title> <authorfullname="" initials="" surname="Xiph.org"/> <date month="" year=""/> </front> <seriesInfo name="http://media.xiph.org/video/derf/" value=""/> </reference> <reference anchor="HEVC-seq"> <front> <title>Test Sequences</title>initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Casner" fullname="S. Casner"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Frederick" fullname="R. Frederick"> <organization showOnFrontPage="true"/> </author> <authorfullname="" initials="" surname="HEVC"/>initials="V." surname="Jacobson" fullname="V. Jacobson"> <organization showOnFrontPage="true"/> </author> <datemonth="" year=""/> </front> <seriesInfo name="http://www.netlab.tkk.fi/~varun/test_sequences/" value=""/> </reference> <?rfc include='reference.I-D.ietf-rmcat-coupled-cc'?> <!-- --> </references>year="2003" month="July"/> <abstract> <t indent="0">This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="64"/> <seriesInfo name="RFC" value="3550"/> <seriesInfo name="DOI" value="10.17487/RFC3550"/> </reference> <reference anchor="RFC3551" target="https://www.rfc-editor.org/info/rfc3551" quoteTitle="true" derivedAnchor="RFC3551"> <front> <title>RTP Profile for Audio and Video Conferences with Minimal Control</title> <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Casner" fullname="S. Casner"> <organization showOnFrontPage="true"/> </author> <date year="2003" month="July"/> <abstract> <t indent="0">This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="65"/> <seriesInfo name="RFC" value="3551"/> <seriesInfo name="DOI" value="10.17487/RFC3551"/> </reference> <reference anchor="RFC3611" target="https://www.rfc-editor.org/info/rfc3611" quoteTitle="true" derivedAnchor="RFC3611"> <front> <title>RTP Control Protocol Extended Reports (RTCP XR)</title> <author initials="T." surname="Friedman" fullname="T. Friedman" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Caceres" fullname="R. Caceres" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Clark" fullname="A. Clark" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2003" month="November"/> <abstract> <t indent="0">This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.</t> </abstract> </front> <seriesInfo name="RFC" value="3611"/> <seriesInfo name="DOI" value="10.17487/RFC3611"/> </reference> <reference anchor="RFC4585" target="https://www.rfc-editor.org/info/rfc4585" 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 degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. 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 Audio-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 feedback 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/rfc5506" 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 when 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 packets 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/rfc5681" 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 congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment 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/rfc6679" quoteTitle="true" derivedAnchor="RFC6679"> <front> <title>Explicit Congestion Notification (ECN) for RTP over UDP</title> <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 Notification (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 transport 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 procedures for negotiation of capabilities and initialisation methods are also defined. [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/rfc8593" 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 statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate. The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic 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/rfc8836" quoteTitle="true" derivedAnchor="RFC8836"> <front> <title>Congestion Control Requirements for Interactive Real-Time Media</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/rfc8868" 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/rfc8869" quoteTitle="true" derivedAnchor="RFC8869"> <front> <title>Evaluation Test Cases for Interactive Real-Time Media over Wireless 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/test_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/rfc2914" 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 congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</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/rfc7567" quoteTitle="true" derivedAnchor="RFC7567"> <front> <title>IETF Recommendations Regarding Active Queue Management</title> <author initials="F." surname="Baker" fullname="F. Baker" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="G." surname="Fairhurst" fullname="G. Fairhurst" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2015" month="July"/> <abstract> <t indent="0">This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.</t> <t indent="0">Based on 15 years of experience and new research, this 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/rfc8033" quoteTitle="true" derivedAnchor="RFC8033"> <front> <title>Proportional Integral Controller Enhanced (PIE): A Lightweight 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 interactive applications (e.g., voice over IP, real-time video streaming, and financial 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 provide desirable quality of service to users.</t> <t indent="0">This document presents a lightweight active queue management design called "PIE" (Proportional Integral controller Enhanced) that can 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 situations. 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/rfc8290" quoteTitle="true" derivedAnchor="RFC8290"> <front> <title>The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm</title> <author initials="T." surname="Hoeiland-Joergensen" fullname="T. Hoeiland-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 scheduler and Active Queue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency.</t> <t indent="0">FQ-CoDel mixes packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, 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/rfc8699" 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 Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and 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 specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other 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> <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-acknowledgments">Acknowledgments</name> <t indent="0" pn="section-appendix.a-1">Much of this document is derived from previous work on congestion control at the IETF.</t> <t indent="0" pn="section-appendix.a-2">The content and concepts within this 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">AcousticComms 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> </rfc>