<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3550 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3551 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY rfc3611 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc4585 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc5506 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5506.xml">
<!ENTITY rfc5166 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5166.xml">
<!ENTITY rfc5033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5033.xml">
<!ENTITY rfc8593 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8593.xml">
<!-- <!ENTITY rfc5681 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5681.xml"> -->
<!ENTITY rfc8083 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8083.xml">
<!ENTITY I-D.ietf-rmcat-cc-requirements PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-cc-requirements.xml">
<!ENTITY I-D.ietf-avtcore-rtp-circuit-breakers PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circuit-breakers.xml">
<!ENTITY I-D.ietf-netvc-testing PUBLIC ""
"https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netvc-testing.xml">
<!ENTITY I-D.ietf-rmcat-eval-test PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-eval-test.xml">
<!ENTITY I-D.ietf-rmcat-wireless-tests PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-wireless-tests.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 ipr="trust200902" xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-rmcat-eval-criteria-14" category="info">
    <!-- What is the category field value--> indexInclude="true" ipr="trust200902" number="8868" prepTime="2021-01-19T00:08:29" 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-criteria-14" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8868" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Evaluating Congestion Control for RMCAT">
            Evaluating Interactive Real-Time Media">Evaluating Congestion Control for Interactive Real-time Media
            <!--Evaluation Criteria for RTP Congestion Avoidance Techniques -->
        </title> Real-Time Media</title>
    <seriesInfo name="RFC" value="8868" stream="IETF"/>
    <author initials="V." surname="Singh" fullname="Varun Singh">
      <organization abbrev="callstats.io">
            CALLSTATS abbrev="callstats.io" showOnFrontPage="true">CALLSTATS I/O Oy
          </organization> Oy</organization>
      <address>
        <postal>
              <street>Runeberginkatu 4c A 4</street>
          <street>Rauhankatu 11 C</street>
          <code>00100</code>
          <city>Helsinki</city>
          <country>Finland</country>
        </postal>
        <email>varun.singh@iki.fi</email>
            <uri>
              https://www.callstats.io/about
            </uri>
        <uri>https://www.callstats.io/</uri>
      </address>
    </author>
    <author initials="J." surname="Ott" fullname="Joerg fullname="Jörg Ott">
          <organization>Technical
      <organization showOnFrontPage="true">Technical University of Munich</organization>
      <address>
        <postal>
              <street>Faculty
          <extaddr>Department of Informatics</street> Informatics</extaddr>
          <extaddr>Chair of Connected Mobility</extaddr>
          <street>Boltzmannstrasse 3</street>
              <city>Garching bei München</city>
              <region>DE</region>
          <city>Garching</city>
          <code>85748</code>
          <country>Germany</country>
        </postal>
        <email>ott@in.tum.de</email>
      </address>
    </author>
    <author fullname="Stefan Holmer" initials="S." surname="Holmer">
      <organization abbrev="Google">Google</organization> abbrev="Google" showOnFrontPage="true">Google</organization>
      <address>
        <postal>
          <street>Kungsbron 2</street>
          <code>11122</code>
          <city>Stockholm</city>
          <country>Sweden</country>
        </postal>
        <email>holmer@google.com</email>
      </address>
    </author>
    <date year="2020" month="3"/> month="01" year="2021"/>
    <area>TSV</area>
        <workgroup>RMCAT WG</workgroup>
    <workgroup>RMCAT</workgroup>
    <keyword>RTP</keyword>
    <keyword>RTCP</keyword>
    <keyword>Congestion Control</keyword>
        <abstract>
            <t>The Real-time
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The Real-Time Transport Protocol (RTP) is used to transmit
            media in telephony and video conferencing applications. This
            document describes the guidelines to evaluate new congestion
            control algorithms for interactive point-to-point real-time
            media.</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/rfc8868" 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" 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-metrics">Metrics</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rtp-log-format">RTP Log Format</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-list-of-network-parameters">List of Network Parameters</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-one-way-propagation-delay">One-Way Propagation Delay</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-end-to-end-loss">End-to-End Loss</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-drop-tail-router-queue-leng">Drop-Tail Router Queue Length</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-loss-generation-model">Loss Generation Model</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-jitter-models">Jitter Models</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.5.2">
                  <li pn="section-toc.1-1.4.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.1.1"><xref derivedContent="4.5.1" format="counter" sectionFormat="of" target="section-4.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-random-bounded-pdv-rbpdv">Random Bounded PDV (RBPDV)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.2.1"><xref derivedContent="4.5.2" format="counter" sectionFormat="of" target="section-4.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-approximately-random-subjec">Approximately Random Subject to No-Reordering Bounded PDV (NR-BPDV)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.5.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.3.1"><xref derivedContent="4.5.3" format="counter" sectionFormat="of" target="section-4.5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recommended-distribution">Recommended Distribution</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-traffic-models">Traffic Models</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-tcp-traffic-model">TCP Traffic Model</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rtp-video-model">RTP Video Model</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-background-udp">Background UDP</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</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-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </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.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section title="Introduction">

            <t>This numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This memo describes the guidelines to help with evaluating
            new congestion control algorithms for interactive
            point-to-point real time real-time media. The requirements for the
            congestion control algorithm are outlined in <xref
            target="I-D.ietf-rmcat-cc-requirements" />). target="RFC8836" format="default" sectionFormat="of" derivedContent="RFC8836"/>. This document
            builds upon previous work at the IETF: <xref
            target="RFC5033">Specifying target="RFC5033" format="default" sectionFormat="of" derivedContent="RFC5033">Specifying New Congestion Control
            Algorithms</xref> and <xref target="RFC5166">Metrics target="RFC5166" format="default" sectionFormat="of" derivedContent="RFC5166">Metrics for the
            Evaluation of Congestion Control Algorithms</xref>.</t>

            <t>The
      <t indent="0" pn="section-1-2">The guidelines proposed in the document are intended to help
            prevent a congestion collapse, to promote fair capacity usage usage, and
            to optimize the media flow's throughput.  Furthermore, the proposed
            congestion control algorithms are expected to operate within the envelope of the
            circuit breakers defined in RFC 8083 <xref target="RFC8083">RFC8083</xref>.</t>

            <t>This target="RFC8083" format="default" sectionFormat="of" derivedContent="RFC8083"/>.</t>
      <t indent="0" pn="section-1-3">This document only provides the broad set of network
            parameters and and traffic models for evaluating a new
            congestion control algorithm.  The minimal requirements requirement
            for congestion control proposals is to produce or present
            results for the test scenarios described in <xref
            target="I-D.ietf-rmcat-eval-test" /> target="RFC8867" format="default" sectionFormat="of" derivedContent="RFC8867"/> (Basic Test Cases),
            which also defines the specifics for the test cases.
            Additionally, proponents may produce evaluation results
            for the <xref target="I-D.ietf-rmcat-wireless-tests"> target="RFC8869" format="default" sectionFormat="of" derivedContent="RFC8869">
            wireless test scenarios</xref>.
      </t>

            <t>
      <t indent="0" pn="section-1-4">
	      This document does not cover application-specific
	      implications of congestion control algorithms and how
	      those could be evaluated.  Therefore, no quality metrics
	      are defined for performance evaluation; quality metrics
	      and the algorithms to infer those vary between media types.
	      Metrics and algorithms to assess, e.g., the quality of
	      experience
	      experience, evolve continuously so that determining
	      suitable choices is left for future work. However, there
	      is consensus that each congestion control algorithm
	      should be able to show that it is useful for interactive
	      video by performing analysis using a real codecs and
	      video sequences and state-of-the-art quality metrics.
      </t>
	    <t>
      <t indent="0" pn="section-1-5">
	      Beyond optimizing individual metrics, real-time
	      applications may have further options to trade off
	      performance, e.g., across multiple media; refer to the
	      <xref target="I-D.ietf-rmcat-cc-requirements">RMCAT target="RFC8836" format="default" sectionFormat="of" derivedContent="RFC8836">RMCAT
	      requirements</xref> document.  Such trade-offs may be
	      defined in the future.
      </t>
    </section>
    <section title="Terminology" anchor="sec-terminology">
            <!--<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
            "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
            "OPTIONAL" in this document are to be interpreted as described
            in BCP 14, <xref target="RFC2119" /> and indicate requirement
            levels for compliant implementations. </t> -->

            <t> anchor="sec-terminology" numbered="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 <xref target="RFC3550">RTP</xref>, target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTP</xref>,
            <xref target="RFC3551">RTP target="RFC3551" format="default" sectionFormat="of" derivedContent="RFC3551">RTP Profile for Audio and Video Conferences
            with Minimal Control</xref>, <xref target="RFC3611">RTCP target="RFC3611" format="default" sectionFormat="of" derivedContent="RFC3611">RTCP Extended
            Report (XR)</xref>, <xref target="RFC4585">Extended target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">Extended RTP Profile
            for RTCP-based RTCP-Based Feedback (RTP/AVPF)</xref> and <xref
            target="RFC5506">Support target="RFC5506" format="default" sectionFormat="of" derivedContent="RFC5506">Support for Reduced-Size RTCP</xref> apply.</t> applies.</t>
    </section>
    <section title="Metrics" anchor="cc-metrics">

        <!-- <t><xref target="RFC5166" /> describes the basic metrics for
        congestion control. Metrics that are of interest for interactive
        multimedia are:
        <list style="symbols">
            <t>Throughput.</t>
            <t>Minimizing oscillations in the transmission rate (stability)
            when the end-to-end capacity varies slowly.</t>
            <t>Delay.</t>
            <t>Reactivity to transient events.</t>
            <t>Packet losses and discards.</t>
            <t>Users' quality of experience</t>
            <t>Section 2.1 of <xref target="RFC5166" /> discusses the tradeoff
            between throughput, delay and loss.</t>
        </list></t> -->

	<t> anchor="cc-metrics" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-metrics">Metrics</name>
      <t indent="0" pn="section-3-1"> This document specifies testing criteria for evaluating
	congestion control algorithms for RTP media flows.  Proposed
	algorithms are to prove their performance by means of
	simulation and/or emulation experiments for all the cases
	described.</t>

         <t>Each
      <t indent="0" pn="section-3-2">Each experiment is expected to log every incoming and outgoing
         packet (the RTP logging format is described in <xref target="rtp-logging" />). format="default" sectionFormat="of" derivedContent="Section 3.1"/>). The logging can be done inside the
         application or at the endpoints using PCAP (packet capture, e.g.,
         tcpdump <xref target="tcpdump"/>, wireshark target="tcpdump" format="default" sectionFormat="of" derivedContent="tcpdump"/>, Wireshark <xref target="wireshark"/>). target="wireshark" format="default" sectionFormat="of" derivedContent="wireshark"/>).
	 The following metrics are calculated based on the
         information in the packet logs:
         <list style="numbers">
            <t>Sending
      </t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3-3">
        <li pn="section-3-3.1" derivedCounter="1.">Sending rate, Receiver receiver rate, Goodput goodput (measured at 200ms intervals)</t>
            <t>Packets intervals)</li>
        <li pn="section-3-3.2" derivedCounter="2.">Packets sent, Packets received</t>
            <t>Bytes packets received</li>
        <li pn="section-3-3.3" derivedCounter="3.">Bytes sent, bytes received</t>
            <t>Packet delay</t>
            <t>Packets received</li>
        <li pn="section-3-3.4" derivedCounter="4.">Packet delay</li>
        <li pn="section-3-3.5" derivedCounter="5.">Packets lost, Packets packets discarded (from the playout or de-jitter buffer)</t>
            <t>If using, buffer)</li>
        <li pn="section-3-3.6" derivedCounter="6.">If using retransmission or FEC: post-repair loss</t>

        <!-- <t>[Editor's note: How loss</li>
        <li pn="section-3-3.7" derivedCounter="7.">
          <t indent="0" pn="section-3-3.7.1">Self-fairness and fairness with respect to handle packet re-transmissions? loss before
        retransmission, after retransmission?]</t> -->
            <!-- t>Fairness or Unfairness: Experiments testing the performance
            of an RMCAT proposal against any cross-traffic must define its
            expected criteria for fairness. The "unfairness" test guideline
            (measured at 1s intervals) is:<vspace />
                1. Does not trigger the circuit breaker.<vspace />
                2. No RMCAT stream achieves more than 3 times the average throughput
                of the RMCAT stream with the lowest average throughput, for a case
                when the competing streams have similar RTTs.<vspace />
                3. RTT should not grow by a factor of 3 for the existing flows when a
                new flow is added.
                <vspace />
	    -->
	    <t>Self-Fairness and Fairness with respect to cross
	    traffic: cross
	    traffic: Experiments testing a given congestion control proposal must
	    report on relative ratios of the average throughput
	    (measured at coarser time intervals) obtained by each
	    RTP media stream. In the presence of background cross-traffic
	    such as TCP, the report must also include the relative
	    ratio between average throughput of RTP media streams and
	    cross-traffic streams.
	    <vspace/>
          </t>
          <t indent="0" pn="section-3-3.7.2">
	    During static periods of a test (i.e., when bottleneck
	    bandwidth is constant and no arrival/departure of
	    streams), these report reports on relative ratios serve as an
	    indicator of how fair fairly the RTP streams share bandwidth
	    amongst themselves and against cross-traffic streams. The
	    throughput measurement interval should be set at a few
	    values (for example, at 1s, 5s, 1 s, 5 s, and 20s) 20 s) in order to
	    measure fairness across different time scales.
	    <vspace/> timescales.
          </t>
          <t indent="0" pn="section-3-3.7.3">
	    As a general guideline, the relative ratio between congestion controlled congestion-controlled RTP
	    flows with the same priority level and similar path RTT
	    should be bounded between (0.333 0.333 and 3.) 3.  For example, see
	    the test scenarios described in <xref
	    target="I-D.ietf-rmcat-eval-test" />.</t>

            <t>Convergence target="RFC8867" format="default" sectionFormat="of" derivedContent="RFC8867"/>.</t>
        </li>
        <li pn="section-3-3.8" derivedCounter="8.">Convergence time: The time taken to reach a stable rate at startup,
            after the available link capacity changes, or when new flows get added
            to the bottleneck link.</t>

            <t>Instability link.</li>
        <li pn="section-3-3.9" derivedCounter="9.">Instability or oscillation in the sending rate: The frequency or
            number of instances when the sending rate oscillates between an
            high watermark level and a low watermark level, or vice-versa in
            a defined time window. For example, the watermarks can be set at 4x
            interval: 500 Kbps, 2 Mbps, and a time window of 500ms.</t>

        <!--
        <t>[Open issue (2): Convergence time was discussed briefly in the
        design meetings. It is defined as: the time it takes the congestion
        control to reach a stable rate (at startup or after new RMCAT flows
        are added). What is a stable rate?]</t>
                 -->
            <t>Bandwidth Utilization, 500 ms.</li>
        <li pn="section-3-3.10" derivedCounter="10.">Bandwidth utilization, defined as the ratio of the instantaneous
            sending rate to the instantaneous bottleneck capacity. capacity: This metric is
            useful only when a congestion controlled congestion-controlled RTP flow is by itself or is competing with similar
            cross-traffic.</t>
        </list></t>

	<t>
            cross-traffic.</li>
      </ol>
      <t indent="0" pn="section-3-4">
	  Note that the above metrics are all objective
	  application-independent metrics.  Refer to Section 3, in
	  <xref target="I-D.ietf-netvc-testing" /> section="3" sectionFormat="of" format="default" derivedLink="https://tools.ietf.org/html/draft-ietf-netvc-testing-09#section-3" derivedContent="netvc-testing"/>
          for objective metrics for evaluating codecs.
      </t>

        <t>From
      <t indent="0" pn="section-3-5">From the logs logs, the statistical measures (min, max, mean, standard
        deviation
        deviation, and variance) for the whole duration or any specific part of
        the session can be calculated. Also the metrics (sending rate,
        receiver rate, goodput, latency) can be visualized in graphs as
        variation over time, time; the measurements in the plot are at 1 second one-second
        intervals. Additionally, from the logs logs, it is possible to plot the
        histogram or CDF cumulative distribution function (CDF) of packet delay.</t>

        <!-- t>[Open issue (1): Using Jain-fairness index (JFI) for measuring
            self-fairness between RTP flows? measured at what intervals?
            visualized as a CDF or
      <section anchor="rtp-logging" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-rtp-log-format">RTP Log Format</name>
        <t indent="0" pn="section-3.1-1">
		Having a time series? Additionally: Use JFI
            for common log format simplifies running analyses across
		different measurement setups and comparing fairness between their results.
        </t>
        <artwork name="" type="" align="left" alt="" pn="section-3.1-2">
Send or receive timestamp (Unix): &lt;int&gt;.&lt;int&gt;  -- sec.usec decimal
RTP and long TCP flows?
           ]</t -->

         <!-- <t> <list style="empty">
         <t>(i) Bandwidth Utilization: is the
        ratio of the encoding rate to the (available) end-to-end path
        capacity.

        <list style="symbols">

            <t>Under-utilization: is the period payload type                  &lt;int&gt;        -- decimal
SSRC                              &lt;int&gt;        -- hexadecimal
RTP sequence no                   &lt;int&gt;        -- decimal
RTP timestamp                     &lt;int&gt;        -- decimal
marker bit                        0|1          -- character
Payload size                      &lt;int&gt;        -- # bytes, decimal
	</artwork>
        <t indent="0" pn="section-3.1-3">Each line of time when the endpoint's
            encoding rate is lower than log file should be terminated with CRLF,
          CR, or LF characters. Empty lines are disregarded.</t>
        <t indent="0" pn="section-3.1-4">If the end-to-end capacity, i.e., congestion control implements retransmissions or Forward Error Correction (FEC), the
            bandwidth utilization is less than 1.</t>

             <t>Overuse: is
          evaluation should report both packet loss (before applying
          error resilience) and residual packet loss (after applying
          error resilience).</t>
        <t indent="0" pn="section-3.1-5">These data should suffice to compute the period media-encoding independent
	  metrics described above.  Use of time when the endpoint's encoding
             rate is higher than a common log will allow simplified
	  post-processing and analysis across different implementations.
        </t>
      </section>
    </section>
    <section anchor="add-params" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-list-of-network-parameters">List of Network Parameters</name>
      <t indent="0" pn="section-4-1">The implementors are encouraged to choose evaluation settings
      from the end-to-end capacity, i.e., following values initially:</t>
      <section anchor="scen-delay" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-one-way-propagation-delay">One-Way Propagation Delay</name>
        <t indent="0" pn="section-4.1-1">Experiments are expected to verify that the bandwidth
             utilization is greater than 1.</t>

             <t>Steady-state: congestion control is the period
        able to work across a broad range of time when the endpoint's
             encoding rate is relatively stable, i.e., path characteristics, including challenging situations, for example, over
        transcontinental and/or satellite links.  Tests thus account for the bandwidth
             utilization is constant.</t>

        </list></t>

        <t></t>

        <t>(ii) Packet Loss and Discard Rate.</t> <t></t>

        <t>(iii) Fair Share. following different latencies:

        </t> <t></t>

        <t>[Editor's Note: This metric should match the ones defined
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.1-2">
          <li pn="section-4.1-2.1" derivedCounter="1.">Very low latency: 0-1 ms</li>
          <li pn="section-4.1-2.2" derivedCounter="2.">Low latency: 50 ms</li>
          <li pn="section-4.1-2.3" derivedCounter="3.">High latency: 150 ms</li>
          <li pn="section-4.1-2.4" derivedCounter="4.">Extreme latency: 300 ms</li>
        </ol>
      </section>
      <section anchor="scen-loss" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-end-to-end-loss">End-to-End Loss</name>
        <t indent="0" pn="section-4.2-1">   Many paths in the
        <xref target="I-D.ietf-rmcat-cc-requirements">RMCAT requirements</xref>
        document.]</t>
        <t></t>

        <t>(iv) Quality: There Internet today are many different types of quality metrics for
        audio largely lossless;
   however, in scenarios featuring interference in wireless
   networks, sending to and video. Audio quality is often expressed receiving from remote regions,
   or high/fast mobility, media flows may exhibit substantial
   packet loss. This variety needs
	to be reflected appropriately by the tests.</t>
        <t indent="0" pn="section-4.2-2">To model a MOS ("Mean
        Opinion Score") and can be calculated using an objective algorithm
        (E-model/R-model). Section 4.7 wide range of <xref target="RFC3611" /> can also
        be used for VoIP metrics. Similarly, there exist several metrics to
        measure video quality, for example Peak Signal to Noise Ratio (PSNR).
        </t>

        <t>[Editor's Note: Should lossy links, the algorithm compare average PSNR of test
        video sequences or what other video quality metric experiments can be used? If
        Quality choose one of the
        following loss rates; the fractional loss is used as a metric, it should not be the only metric used to
        compare rate-control schemes. Also, algorithms using different codecs
        cannot be compared]. </t>

            </list> ratio of packets lost
        and packets sent: </t>
            -->
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.2-3">
          <li pn="section-4.2-3.1" derivedCounter="1.">no loss: 0%</li>
          <li pn="section-4.2-3.2" derivedCounter="2.">1%</li>
          <li pn="section-4.2-3.3" derivedCounter="3.">5%</li>
          <li pn="section-4.2-3.4" derivedCounter="4.">10%</li>
          <li pn="section-4.2-3.5" derivedCounter="5.">20%</li>
        </ol>
      </section>
      <section title="RTP Log Format" anchor="rtp-logging">
	  <t>
	    Having a common log format simplifies running analyses
	    across and comparing different measurements.  The log file anchor="scen-queue" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-drop-tail-router-queue-leng">Drop-Tail Router Queue Length</name>
        <t indent="0" pn="section-4.3-1">Routers should be tab or comma separated containing configured to use drop-tail queues in
	the following
	    details:
	  </t>

	  <figure><artwork><![CDATA[
Send or receive timestamp (Unix): <int>.<int>  -- sec.usec decimal
RTP payload type                  <int>        -- decimal
SSRC                              <int>        -- hexadecimal
RTP sequence no                   <int>        -- decimal
RTP timestamp                     <int>        -- decimal
marker bit                        0|1          -- character
Payload size                      <int>        -- # bytes, decimal
	]]></artwork></figure>

	  <t>Each line of the log file should be terminated experiments due to their (still) prevalent nature.
	Experimentation with CRLF,
          CR, or LF characters. Empty lines are disregarded.</t>
          <t>If the congestion control implements retransmissions or FEC, Active Queue Management (AQM) schemes is encouraged but not mandatory.
        </t>
        <t indent="0" pn="section-4.3-2">The router queue length is measured as the
          evaluation should report both packet loss (before applying
          error-resilience) and residual packet loss (after applying
          error-resilience).</t>

	  <t>These data should suffice time taken to compute drain the media-encoding independent
	  metrics described above.  Use of a common log will allow simplified
	  post-processing and analysis across different implementations.
	  </t>
          <!-- <t>The retransmissions for post-repair loss metric be logged
        FIFO queue. It has been noted in a
            separate file, as various discussions that the repair streams queue
        length in the currently deployed Internet varies significantly. While
        the core backbone network has very short queue length, the home
        gateways usually have different payload type
            and/or SSRC.</t> -->
        </section>
        </section>

        <!--
        <section title="Congestion control requirements" anchor="cc-require">
            <t> </t>
        </section>
        -->
<!--
        <section title="Guidelines" anchor="cc-guidelines">
            <t>A congestion control algorithm should larger queue length. Those various queue lengths
        can be tested categorized in
            simulation or a testbed environment, and the experiments should
            be repeated multiple times to infer statistical significance.
            The following guidelines are considered for evaluation:</t>

            <section title="Avoiding Congestion Collapse">
            <t>The congestion control algorithm is expected to take an action,
            such as reducing way: </t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.3-3">
          <li pn="section-4.3-3.1" derivedCounter="1.">QoS-aware (or short): 70 ms</li>
          <li pn="section-4.3-3.2" derivedCounter="2.">Nominal: 300-500 ms</li>
          <li pn="section-4.3-3.3" derivedCounter="3.">Buffer-bloated: 1000-2000 ms</li>
        </ol>
        <t indent="0" pn="section-4.3-4"> Here the sending rate, when it detects congestion.
            Typically, it should intervene before size of the circuit breaker <xref
            target="I-D.ietf-avtcore-rtp-circuit-breakers" /> queue is engaged. </t>

            <t>Does measured in bytes or packets.
        To convert the congestion control propose any changes queue length measured in seconds to (or diverge
            from) the circuit breaker conditions defined queue length in <xref
            target="I-D.ietf-avtcore-rtp-circuit-breakers" />.</t>
        bytes:</t>
        <t indent="0" pn="section-4.3-5">QueueSize (in bytes) = QueueSize (in sec) x Throughput (in
        bps)/8</t>
      </section>
      <section title="Stability">
            <t>The congestion control should be assessed numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-loss-generation-model">Loss Generation Model</name>
        <t indent="0" pn="section-4.4-1">
	Many models for its stability
            when the path characteristics do not change over time. Changing
            the media encoding rate estimate too often or by too much may
            adversely affect the application layer performance.</t>
            </section>

            <section title ="Media Traffic">
            <t>The congestion control algorithm should generating packet loss are available: some
   generate correlated packet losses, others generate independent packet losses. In addition,
 packet losses can also be assessed extracted from packet traces.
	   As a (simple) minimum loss
	  model with
            different types of media behavior, i.e., minimal parameterization (i.e., the media should contain
            idle and data-limited periods. For example, periods of silence for
            audio, varying amount of motion for video, or bursty nature of
            I-frames. </t>

            <t>The evaluation may loss rate),
	  independent random losses must be done used in two stages. In the first stage, the endpoint generates traffic at evaluation.
        </t>
        <t indent="0" pn="section-4.4-2">
	  It is known that independent loss models may reflect reality poorly,
	  and hence more sophisticated loss models could be
	  considered.
   Suitable models for correlated losses include the rate calculated Gilbert-Elliot
   model <xref target="gilbert-elliott" format="default" sectionFormat="of" derivedContent="gilbert-elliott"/> and models that generate losses by the
            congestion controller. In the second stage, real codecs or
   modeling a queue with its (different) drop behaviors.
        </t>
      </section>
      <section anchor="JM" numbered="true" toc="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-jitter-models">Jitter Models</name>
        <t indent="0" pn="section-4.5-1">This section defines jitter models for the purposes of video codecs are used this
        document. When jitter is to mimic application-limited data periods
            and varying video frame sizes.</t>
            </section>

            <section title="Start-up Behavior">
            <t>The congestion control algorithm should be assessed with
            different start-rates. The main reason is applied to observe the behavior
            of both the congestion control in different test scenarios, such congestion-controlled RTP flow and any
        competing flow (such as when a TCP competing with varying amount of cross-traffic or how
            quickly flow), the competing flow will
        use the jitter definition below that does not allow for reordering of
        packets on the congestion control algorithm achieve a stable
            sending rate.</t>
            </section>

            <section title="Diverse Environments">
            <t>The congestion control algorithm should be assessed competing flow (see NR-BPDV definition below).</t>
        <t indent="0" pn="section-4.5-2">Jitter is an overloaded term in
            heterogeneous environments, containing both wired and wireless
            paths. Examples of wireless access technologies are: 802.11, GPRS,
            HSPA, or LTE. One of communications. It is
        typically used to refer to the main challenges variation of the wireless
            environments for the congestion control algorithm is a metric (e.g.,
        delay) with respect to
            distinguish between congestion induced loss and transmission
            (bit-error) loss. Congestion control algorithms may
            incorrectly identify transmission loss some reference metric (e.g., average
        delay or minimum delay). For example in RFC 3550, jitter is
        computed as congestion loss and
            reduce the media encoding rate by too much, smoothed difference in packet arrival times
        relative to their respective expected arrival times, which may cause
            oscillatory behavior and deteriorate is
        particularly meaningful if the users' quality of
            experience. Furthermore, underlying packet loss may induce additional delay
            in networks with wireless paths due to link-layer
            retransmissions.</t>
            </section>

            <section title="Varying Path Characteristics">
            <t>The congestion control algorithm should be evaluated for a
            range of path characteristics such as, different end-to-end
            capacity and latency, varying amount of cross traffic on a
            bottleneck link and
        variation was caused by a router's queue length. For Gaussian random process.</t>
        <t indent="0" pn="section-4.5-3">Because jitter is an overloaded term, we use the moment, only
            Drop Tail queues are used. However, if new Active Queue Management
            (AQM) schemes become available, term
        Packet Delay Variation (PDV) instead to describe the performance variation
        of delay of individual packets in the congestion
            control algorithm should be again evaluated.</t>

            <t>In an experiment, if same sense as the media only flows IETF
        IP Performance Metrics (IPPM) working group has defined PDV in a single
            direction, their documents (e.g., RFC 3393)
        and as the feedback path should also be tested ITU-T SG16 has defined IP Packet Delay Variation
        (IPDV) in their documents (e.g., Y.1540).</t>
        <t indent="0" pn="section-4.5-4">Most PDV distributions in packet network systems are
        one-sided distributions, the measurement of which with varying
            amounts a
        finite number of impairment.</t>

            <t>The main motivation for the previous and current criteria is to
            identify situations measurement samples results in which one-sided
        histograms. In the proposed congestion control usual packet network transport case, there
        is
            less performant.</t>
            </section>

            <section title="Reacting to Transient Events or Interruptions">
            <t>The congestion control algorithm should be able to handle
            changes in end-to-end capacity and latency. Latency may change
            due to route updates, link failures, hand-overs etc. In mobile
            environment typically one packet that transited the end-to-end capacity may vary due to network with the
            interference, fading, hand-overs, etc. In wired networks
        minimum delay; a (large) number of packets transit the
            end-to-end capacity may vary due to changes in resource
            reservation.</t>
            </section>

            <section title="Fairness With Similar Cross-Traffic">
            <t>The congestion control algorithm should be evaluated when
            competing network
        within some (smaller) positive variation from this minimum
        delay, and a (small) number of the packets transit the network
        with other RTP flows using delays higher than the same median or another candidate
            congestion control algorithm. The proposal should highlight the
            bottleneck capacity share of each RTP flow.</t>
            </section>

            <section title="Impact on Cross-Traffic">

            <t>The congestion control algorithm average transit time
        (these are outliers). Although infrequent, outliers can cause
        significant deleterious operation in adaptive systems and
        should be evaluated when
            competing with standard TCP. Short TCP flows may be considered
            as transient events and the in rate adaptation designs for RTP flow may give way
        congestion control.</t>
        <t indent="0" pn="section-4.5-5">In this section we define two different bounded PDV
        characteristics, 1) Random Bounded PDV and 2) Approximately Random
        Subject to No-Reordering Bounded PDV.</t>
        <t indent="0" pn="section-4.5-6">The former, 1) Random Bounded PDV, is presented for
        information only, while the short
            TCP flow latter, 2) Approximately Random
        Subject to complete quickly. However, long-lived TCP flows may
            starve out the RTP flow depending on router queue length. </t>

            <t>The proposal should also measure No-Reordering Bounded PDV, must be used in the impact on varied number
            of cross-traffic sources, i.e., few and many competing flows,
            or mixing various amounts of TCP and similar cross-traffic.</t>
            </section>
        evaluation.</t>
        <section title="Extensions to RTP/RTCP">
            <t>The congestion control algorithm should indicate if any
            protocol extensions are required numbered="true" toc="include" removeInRFC="false" pn="section-4.5.1">
          <name slugifiedName="name-random-bounded-pdv-rbpdv">Random Bounded PDV (RBPDV)</name>
          <t indent="0" pn="section-4.5.1-1">The RBPDV probability distribution function (PDF) is specified to implement it
        be of some mathematically describable function that includes some
        practical minimum and should
            carefully describe maximum discrete values suitable for testing.
        For example, the impact of minimum value, x_min, might be specified as the extension.</t>
            </section>

        </section> -->

    <section anchor="add-params" title="List of Network Parameters">

      <t>The implementors initially are encouraged
        minimum transit time packet, and the maximum value, x_max, might be
        defined to choose evaluation settings
      from be two standard deviations higher than the following values:</t>

      <section anchor="scen-delay" title="One-way Propagation Delay">
        <!-- -->

        <t>Experiments mean.</t>
          <t indent="0" pn="section-4.5.1-2">Since we are expected typically interested in the distribution relative to verify that
        the congestion control is
        able mean delay packet, we define the zero mean PDV sample, z(n), to work across be
        z(n) = x(n) - x_mean, where x(n) is a broad range sample of path characteristics, also including challenging situations, for example over
        trans-continental and/or satellite links.  Tests thus account for the following different latencies:

	<list style="numbers">
            <t>Very low latency: 0-1ms</t>

            <t>Low latency: 50ms</t>

            <t>High latency: 150ms</t>

            <t>Extreme latency: 300ms</t>
          </list></t>
      </section>

      <section anchor="scen-loss" title="End-to-end Loss">
	<t>Many paths in the Internet today are largely lossless but,
	with wireless networks RBPDV random
        variable x and interference, towards remote
	regions, or in scenarios featuring high/fast mobility, media
	flows may exhibit substantial packet loss.  This variety needs
	to be reflected appropriately by x_mean is the tests.</t>

        <t>To model a wide range mean of lossy links, x.</t>
          <t indent="0" pn="section-4.5.1-3">We assume here that s(n) is the experiments can choose one original source time of packet n
        and the
        following loss rates, post-jitter induced emission time, j(n), for packet n is:
          </t>
          <t indent="0" pn="section-4.5.1-4">j(n) = {[z(n) + x_mean] + s(n)}.</t>
          <t indent="0" pn="section-4.5.1-5">
	  It follows that the fractional loss is separation in the ratio post-jitter time of
	  packets lost n and packets sent. <list style="numbers">
            <t>no loss: 0%</t>

            <t>1%</t>

            <t>5%</t>

            <t>10%</t>

            <t>20%</t>
          </list></t>
      </section>

      <section anchor="scen-queue" title="Drop Tail Router Queue Length">
	<t>Routers should be configured to use Drop Trail queues in
	the experiments due to their (still) prevalent nature.
	Experimentation with AQM schemes is encouraged but not mandatory.
	</t>

        <t>The router queue length n+1 is measured as the time taken to drain {[s(n+1)-s(n)] - [z(n)-z(n+1)]}. Since
	  the
        FIFO queue. It has been noted in various discussions first term is always a positive quantity, we note that
	  packet reordering at the queue
        length in receiver is possible whenever the current deployed Internet varies significantly. While
	  second term is greater than the core backbone network has very short queue length, first. Said another way,
	  whenever the home
        gateways usually have larger queue length. Those various queue lengths
        can be categorized difference in possible zero mean PDV sample
	  delays (i.e., [x_max-x_min]) exceeds the following way: <list style="numbers">
            <t>QoS-aware (or short): 70ms</t>

            <t>Nominal: 300-500ms</t>

            <t>Buffer-bloated: 1000-2000ms</t>
          </list> Here the size inter-departure
	  time of any two sent packets, we have the queue is measured possibility of
	  packet reordering.</t>
          <t indent="0" pn="section-4.5.1-6">There are important use cases in bytes or real networks where packets can
        become reordered, such as in load-balancing topologies and to convert during
        route changes. However, for the queue length measured in seconds to queue length in
        bytes:</t>

        <t>QueueSize (in bytes) = QueueSize (in sec) x Throughput (in
        bps)/8</t>

        <!-- <t>and 2) queue length in packets:</t>
        <t>QueueSize (in pkts) = QueueSize (in bytes)/MTU,
        MTU=1500</t> -->

        <!-- <t>[Open issue (11): Confirm vast majority of cases, there is no
        packet reordering because most of the above values, do we need time packets follow the same
        path. Due to
                        define parameters for other types of queues?]</t> -->
      </section>

      <section title="Loss generation model">
        <t>
	  Many models for generating this, if a packet loss becomes overly delayed, the packets
        after it on that flow are available, some
	  yield correlated, others independent losses; losses can also
	  be extracted from packet traces.  As a (simple) minimum loss
	  model with minimal parameterization (i.e., the loss rate),
	  independent random losses must be used in the evaluation.
	</t>
	<t>
	  It delayed. This is known that independent loss models may reflect reality
	  poorly and hence more sophisticated loss models could be
	  considered.  Suitable models for correlated losses includes
	  the Gilbert-Elliot model <xref target="gilbert-elliott"/> and
	  losses generated by modeling a queue including its
	  (different) drop behaviors.
	</t>
      </section>

      <section anchor="JM" title="Jitter models">
        <t>This section defines jitter models especially true for the purposes of this
        document. When jitter is
        mobile wireless links where there are per-flow queues prior to be applied base
        station scheduling. Owing to both the congestion controlled RTP flow and any
        competing flow (such as a TCP competing flow), the competing flow will this important use case, we define
        another PDV profile similar to the jitter definition below above, but one that does not allow
        for re-ordering of
        packets on the competing flow (see NR-RBPDV definition below).</t>

        <t>Jitter is an overloaded term in communications. It is
        typically used reordering within a flow.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.5.2">
          <name slugifiedName="name-approximately-random-subjec">Approximately Random Subject to refer No-Reordering Bounded PDV (NR-BPDV)</name>
          <t indent="0" pn="section-4.5.2-1">No Reordering BPDV, NR-BPDV, is defined similarly to the variation of a metric (e.g.,
        delay) above with respect to some reference metric (e.g., average
        delay or minimum delay). For example, RFC 3550 jitter is
        computed
          one important exception. Let serial(n) be defined as the smoothed difference in serialization
          delay of packet arrival times
        relative to their respective expected arrival times, which is
        particularly meaningful if n at the underlying packet delay
        variation was caused by lowest bottleneck link rate (or other
          appropriate rate) in a Gaussian random process.</t>

        <t>Because jitter is an overloaded term, given test. Then we use the term
        Packet Delay Variation (PDV) instead to describe produce all the variation
        of delay post-jitter
          values for j(n) for n = 1, 2, ... N, where N is the length of individual packets in the same sense
          source sequence s to be offset. The exception can be stated as the IETF
        IPPM WG has defined PDV in their documents (e.g., RFC 3393)
          follows: We revisit all j(n) beginning from index n=2, and as the ITU-T SG16 has defined IP Packet Delay Variation
        (IPDV) in their documents (e.g., Y.1540).</t>

        <t>Most PDV distributions in packet network systems are
        one-sided distributions, if j(n) is
          determined to be less than [j(n-1)+serial(n-1)], we redefine j(n) to
          be equal to [j(n-1)+serial(n-1)] and continue for all remaining n
          (i.e., n = 3, 4, .. N). This models the measurement of which with a
        finite number of measurement samples results in one-sided
        histograms. In case where the usual packet network transport case, there n is typically one
          sent immediately after packet that transited (n-1) at the network with bottleneck link rate.
          Although this is generally the theoretical minimum delay; a (large) number of in that it assumes
          that no other packets transit the network
        within some (smaller) positive variation from this minimum
        delay, and a (small) number of the packets transit the network
        with delays higher than the median or average transit time
        (these other flows are outliers). Although infrequent, outliers can cause
        significant deleterious operation in adaptive systems between packet n and
        should be considered in rate adaptation designs n+1
          at the bottleneck link, it is a reasonable assumption for RTP
        congestion control.</t>

        <t>In per-flow
          queuing.</t>
          <t indent="0" pn="section-4.5.2-2">We note that this section we define two different bounded PDV
        characteristics, 1) Random Bounded PDV and 2) Approximately Random
        Subject to No-Reordering Bounded PDV.</t>

        <t>The former, 1) Random Bounded PDV is presented assumption holds for
        information only, some important exception
          cases, such as packets immediately following outliers. There are a
          multitude of software-controlled elements common on end-to-end
          Internet paths (such as firewalls, application-layer gateways, and other middleboxes) that
          stop processing packets while servicing other functions (e.g., garbage
          collection). Often these devices do not drop packets, but rather queue
          them for later processing and cause many of the latter, 2) outliers. Thus NR-BPDV
          models this particular use case (assuming serial(n+1) is defined
          appropriately for the device causing the outlier) and is believed
          to be important for adaptation development for congestion-controlled RTP streams.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.5.3">
          <name slugifiedName="name-recommended-distribution">Recommended Distribution</name>
          <t indent="0" pn="section-4.5.3-1">Whether Random Bounded PDV or Approximately Random
          Subject to No-Reordering Bounded PDV, must be used in the
        evaluation.</t>

        <section title="Random Bounded PDV (RBPDV)">

        <t>The RBPDV probability distribution function (PDF) it is specified recommended that
          z(n) is distributed according to
        be of some mathematically describable function which includes some
        practical minimum and maximum discrete values suitable a truncated Gaussian for testing.
        For example,
          the minimum value, x_min, might be specified as above jitter models:</t>
          <t indent="0" pn="section-4.5.3-2">z(n) ~ |max(min(N(0, std<sup>2</sup>), N_STD * std), -N_STD * std)|</t>
          <t indent="0" pn="section-4.5.3-3">where N(0, std<sup>2</sup>) is the
        minimum transit time packet Gaussian distribution with zero mean and the maximum value, x_max, might be
        defined to be two
          std is standard deviations higher than deviation. Recommended values:</t>
          <ul empty="true" bare="false" indent="3" spacing="normal" pn="section-4.5.3-4">
            <li pn="section-4.5.3-4.1">std = 5 ms</li>
            <li pn="section-4.5.3-4.2">N_STD = 3</li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="app-additional" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-traffic-models">Traffic Models</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-tcp-traffic-model">TCP Traffic Model</name>
        <t indent="0" pn="section-5.1-1">Long-lived TCP flows will download data throughout the mean.</t>

        <t>Since we
        session and are typically interested in the distribution relative expected to
        the mean delay packet, we define the zero mean PDV sample, z(n), have infinite amount of data to be
        z(n) = x(n) - x_mean, where x(n) is a sample
        send or receive.  This roughly applies, for example, when
        downloading software distributions.</t>
        <t indent="0" pn="section-5.1-2">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, i.e., some start in the ON state while others start in the OFF
        state.</t>
        <t indent="0" pn="section-5.1-3">The short TCP flows can be modeled as follows: 30
        connections start simultaneously fetching small (30-50 KB)
        amounts of data, evenly distributed.  This covers the case
        where the short TCP flows are fetching web page resources rather
        than video files.</t>
        <t indent="0" pn="section-5.1-4">The idle period between bursts of starting a group of TCP flows is
        typically derived from an exponential distribution with the mean value of
        10 seconds.</t>
        <aside pn="section-5.1-5">
          <t indent="0" pn="section-5.1-5.1">These values were picked based on the data available at
	<eref target="https://httparchive.org/reports/state-of-the-web?start=2015_10_01&amp;end=2015_11_01&amp;view=list" brackets="angle"/>
         as of October 2015.</t>
        </aside>
        <t indent="0" pn="section-5.1-6">
	  Many different TCP congestion control schemes are deployed
	  today.  Therefore, experimentation with a range of different
	  schemes, especially including CUBIC <xref target="RFC8312" format="default" sectionFormat="of" derivedContent="RFC8312"/>, is encouraged.
	  Experiments must document in detail which congestion control
	  schemes they tested against and which parameters were used.
        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-rtp-video-model">RTP Video Model</name>
        <t indent="0" pn="section-5.2-1">
          <xref target="RFC8593" format="default" sectionFormat="of" derivedContent="RFC8593"/>
	  describes two
          types of video traffic models for evaluating candidate algorithms for RTP congestion control.
          The first model statistically characterizes the behavior of a video
          encoder, whereas the second model uses video traces.
        </t>
        <t indent="0" pn="section-5.2-2">
	  Sample video test sequences are available at <xref target="xiph-seq" format="default" sectionFormat="of" derivedContent="xiph-seq"/>.  The following two video streams
	  are the recommended minimum for testing: Foreman (CIF
	  sequence) and FourPeople (720p); both come as raw video data
	  to be encoded dynamically.  As these video sequences are
	  short (300 and 600 frames, respectively), they shall be
	  stitched together repeatedly until the desired length is
	  reached.
        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-background-udp">Background UDP</name>
        <t indent="0" pn="section-5.3-1">Background UDP flow is modeled as a constant
            bit rate (CBR) flow. It will download data at a particular CBR
            for the complete session, or will change to particular
            CBR at predefined intervals. The inter-packet interval is
            calculated based on the CBR and the packet size (typically
            set to the path MTU size, the default value can be 1500 bytes).
        </t>
        <t indent="0" pn="section-5.3-2">Note that new transport protocols such as QUIC may use UDP;
       however, due to their congestion control algorithms, they will exhibit
       behavior conceptually similar in nature to TCP flows above and
       can thus be subsumed by the above, including the division into
       short-lived and long-lived flows.  As QUIC evolves independently of
       TCP congestion control algorithms, its future congestion
       control should be considered as competing traffic as appropriate.
        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">
	    This document specifies evaluation criteria and parameters
	    for assessing and comparing the performance of congestion
	    control protocols and algorithms for real-time
	    communication.  This memo itself is thus not subject to
	    security considerations but the protocols and algorithms
	    evaluated may be.  In particular, successful operation
	    under all tests defined in this document may suffice for a
	    comparative evaluation but must not be interpreted that
	    the protocol is free of risks when deployed on the
	    Internet as briefly described in the following by example.
      </t>
      <t indent="0" pn="section-6-2">
	    Such evaluations are expected to be
	    carried out in controlled environments for limited numbers
	    of parallel flows.  As such, these evaluations are by
	    definition limited and will not be able to systematically
	    consider possible interactions or very large groups of
	    communicating nodes under all possible circumstances, so
	    that careful protocol design is advised to avoid
	    incidentally contributing traffic that could lead to
	    unstable networks, e.g., (local) congestion collapse.
      </t>
      <t indent="0" pn="section-6-3">
	   This specification focuses on assessing the regular
	   operation of the protocols and algorithms under
	   consideration.  It does not suggest checks against
	   malicious use of the protocols -- by the sender, the
	   receiver, or intermediate parties, e.g., through faked,
	   dropped, replicated, or modified congestion signals.  It is
	   up to the protocol specifications themselves to ensure that
	   authenticity, integrity, and/or plausibility of received
	   signals are checked, and the appropriate actions (or
	   non-actions) are taken.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-netvc-testing" to="netvc-testing"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3550" quoteTitle="true" derivedAnchor="RFC3550">
          <front>
            <title>RTP: A Transport Protocol for Real-Time Applications</title>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Casner" fullname="S. Casner">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Frederick" fullname="R. Frederick">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Jacobson" fullname="V. Jacobson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="July"/>
            <abstract>
              <t indent="0">This memorandum describes RTP, the real-time 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 RBPDV random
        variable x data delivery in a manner scalable to large multicast networks, and x_mean is the mean to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of x.</t>

        <t>We assume here that s(n) is the original source time of packet n underlying transport and network layers.  The protocol supports the post-jitter induced emission time, j(n), for packet n is:
	</t>
	<t>j(n) = {[z(n) + x_mean] + s(n)}.</t>
	<t>
	  It follows that the separation in the post-jitter time use of
	  packets n RTP-level translators and n+1 is {[s(n+1)-s(n)] - [z(n)-z(n+1)]}. Since
	  the first term is always a positive quantity, we note that
	  packet reordering at the receiver is possible whenever the
	  second term is greater than the first. Said another way,
	  whenever the difference in possible zero mean PDV sample
	  delays (i.e., [x_max-x_min]) exceeds the inter-departure
	  time mixers. Most of any two sent packets, we have the possibility of
	  packet re-ordering.</t>

        <t>There are important use cases in real networks where packets can
        become re-ordered such as text in load balancing topologies and during
        route changes. However, for the vast majority of cases there this memorandum is identical to RFC 1889 which it obsoletes.  There are no
        packet re-ordering because most of the time packets follow changes in the same
        path. Due to this, if a packet becomes overly delayed, the packets
        after it formats on that flow are also delayed. This is especially true for
        mobile wireless links where there are per-flow queues prior to base
        station scheduling. Owing to this important use case, we define
        another PDV profile similar to the above, but one that does not allow
        for re-ordering within a flow.</t>
        </section>

        <section title="Approximately Random Subject wire, only changes to No-Reordering Bounded PDV
        (NR-RPVD)">

          <t>No Reordering RPDV, NR-RPVD, the rules and algorithms governing how the protocol is used. The biggest change is defined similarly an enhancement to the above with
          one important exception. Let serial(n) be defined as the serialization
          delay scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of packet n at the lowest bottleneck link intended rate (or other
          appropriate rate) in when many participants join a given test. Then we produce all the post-jitter
          values 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 j(n) 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 n = 1, the use of the real-time transport protocol (RTP), version 2, ... N, where N is and the length associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control.  It provides interpretations of generic fields within the
          source sequence s to be offset-ed. The exception can be stated as
          follows: We revisit all j(n) beginning from index n=2, RTP specification suitable for audio and if j(n) is
          determined to be less than [j(n-1)+serial(n-1)], we redefine j(n) 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 equal carried within RTP.  It defines a set of standard encodings and their names when used within RTP.  The descriptions provide pointers to [j(n-1)+serial(n-1)] reference implementations and continue the detailed standards.  This document is meant as an aid for all remaining n
          (i.e., n = 3, 4, .. N). implementors of audio, video and other real-time multimedia applications. This models 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 case where 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 n is
          sent immediately after packet (n-1) at type for the bottleneck link rate.
          Although this is generally RTP Control Protocol (RTCP), and defines how the theoretical minimum in that use of XR packets can be signaled by an application if it assumes
          that no other employs the Session Description Protocol (SDP).  XR packets from other flows are in-between packet n composed of report blocks, and n+1
          at seven block types are defined here.  The purpose of the bottleneck link, it extended reporting format is a reasonable assumption for per flow
          queuing.</t>

          <t>We note to convey information that this assumption holds for some important exception
          cases, 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 packets immediately following outliers. There are a
          multitude multicast inference of software controlled elements common on end-to-end
          Internet paths (such as firewalls, ALGs and other middleboxes) which
          stop processing packets while servicing network characteristics (MINC) or voice over IP (VoIP) monitoring, require other functions (e.g., garbage
          collection). Often these devices do not drop packets, but rather queue
          them for later processing and cause many of more detailed statistics.  In addition to the outliers. Thus NR-RPVD
          models block types defined here, additional block types may be defined in the future by adhering to the framework that this particular 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 case (assuming serial(n+1) 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 defined
          appropriately the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms).  This document defines an extension to the device causing Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the outlier) senders and thus is believed
          to be important allows for short-term adaptation development for congestion controlled RTP streams.</t>
        </section>
        <section title="Recommended distribution">
          <t>Whether Random Bounded PDV or Approximately Random
          Subject and efficient feedback-based repair mechanisms to No-Reordering Bounded PDV, it is recommended that
          z(n) is distributed according be implemented.  This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to a truncated Gaussian 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
          the above jitter models:</t>
            <t>z(n) ~ |max(min(N(0, std^2), N_STD * std), -N_STD * std)|</t>
          <t>where N(0, std^2) is the Gaussian distribution with zero mean Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and
          standard deviation std. Recommended values:</t>
          <t><list style="symbols">
            <t>std = 5 ms</t>
            <t>N_STD = 3</t>
          </list></t>
        </section>
      </section>
    </section>

    <!--
    <section title="WiFi or Cellular Links">
        <t>
          <xref target="I-D.ietf-rmcat-wireless-tests" /> describes the test
          cases 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 simulate networks be transmitted with wireless links. reduced size.  The document
          describes mechanism to simulate both cellular and WiFi networks.
        </t>
	</section>
    -->

    <section anchor="app-additional" title="Traffic Models">

      <section title="TCP traffic model">
        <t>Long-lived TCP flows will download data throughout size can be reduced if the
        session and rules on how to create compound packets outlined in RFC 3550 are expected removed or changed.  Based on that analysis, this memo defines certain changes to have infinite amount of data the rules to
        send or receive. 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 roughly applies, document updates RFC 3550, RFC 3711, and RFC 4585.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5506"/>
          <seriesInfo name="DOI" value="10.17487/RFC5506"/>
        </reference>
        <reference anchor="RFC8083" target="https://www.rfc-editor.org/info/rfc8083" quoteTitle="true" derivedAnchor="RFC8083">
          <front>
            <title>Multimedia Congestion Control: Circuit Breakers for example, when
        downloading software distributions.</t>

        <t>Each short TCP flow Unicast RTP Sessions</title>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Singh" fullname="V. Singh">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="March"/>
            <abstract>
              <t indent="0">The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications.  Such applications are often run on best-effort UDP/IP networks.  If congestion control is modeled as not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a sequence resulting deterioration of file downloads
        interleaved with idle periods.  Not all short TCP flows start at the same
        time, i.e., some start in the ON state while others start in the OFF
        state.</t>

        <t>The short TCP flows can be modeled user's multimedia experience.  The congestion control algorithm acts as follows: 30
        connections start simultaneously fetching small (30-50 KB)
        amounts of data, evenly distributed.  This covers a safety measure by stopping RTP flows from using excessive resources and protecting the case
        where network from overload.  At the short TCP flows time of this writing, however, while there are fetching web page resources rather
        than video files.</t>

        <t>The idle period between bursts several proprietary solutions, there is no standard algorithm for congestion control of starting interactive RTP flows.</t>
              <t indent="0">This document does not propose a group congestion control algorithm.  It instead defines a minimal set of TCP flows is
        typically derived from RTP circuit breakers: conditions under which an exponential distribution with RTP sender needs to stop transmitting media data to protect the mean value network from excessive congestion.  It is expected that, in the absence of
        10 seconds.</t>

        <t>[These values were picked based long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers.  To avoid triggering the data available at
        http://httparchive.org/interesting.php as of October 2015].</t>

	<t>
	  Many different TCP RTP circuit breaker, any Standards Track congestion control schemes are deployed
	  today.  Therefore, experimentation with a range of different
	  schemes, especially including CUBIC, is encouraged.
	  Experiments must algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8083"/>
          <seriesInfo name="DOI" value="10.17487/RFC8083"/>
        </reference>
        <reference anchor="RFC8593" target="https://www.rfc-editor.org/info/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 in detail which congestion control
	  schemes they tested against and which parameters were used.
	</t>
      </section>

      <section title="RTP Video model">
        <t>
          <xref target="RFC8593"/> describes two
          types of reference video traffic models for evaluating candidate algorithms for RTP congestion control. control algorithms.  The first model statistically characterizes the behavior of a live video
          encoder, whereas encoder in response to changing requests on the second model uses video traces.
        </t>
        <t>
	  Sample target video test sequences are available at <xref
	  target="xiph-seq"></xref>. rate.  The following two video streams
	  are the recommended minimum for testing: Foreman (CIF
	  sequence) second model is trace-driven and FourPeople (720p); both come as raw video data
	  to be emulates the output of actual encoded dynamically.  As these video sequences frame sizes from a high-resolution test sequence.  Both models are
	  short (300 designed to strike a balance between simplicity, repeatability, and 600 frames, respectively, they shall be
	  stitched together repeatedly until authenticity in modeling the desired length is
	  reached.
	</t>
      </section>

      <section title="Background UDP">
       <t>Background UDP flow is modeled as interactions between a constant
            bit rate (CBR) flow. It will download data at live video traffic source and the congestion control module.  Finally, the document describes how both approaches can be combined into a particular CBR
            rate 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 the complete session, or will change to particular
            CBR rate at predefined intervals. The inter packet interval is
            calculated based 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>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="gilbert-elliott" target="https://ieeexplore.ieee.org/document/5755057" quoteTitle="true" derivedAnchor="gilbert-elliott">
          <front>
            <title>The Gilbert-Elliott Model for Packet Loss in Real Time Services on the CBR Internet</title>
            <author surname="Hasslinger" fullname="Gerhard Hasslinger">
              <organization showOnFrontPage="true"/>
            </author>
            <author surname="Hohlfeld" fullname="Oliver Hohlfeld">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="3" year="2008"/>
            <abstract>
              <t indent="0">The estimation of quality for real-time services over telecommunication networks requires realistic models for impairments and failures during transmission. We focus on the packet size (is typically
            set classical Gilbert-Elliott model whose second order statistics is derived over arbitrary time scales and used to fit packet loss processes of traffic traces measured in the path MTU size, the default value can be 1500 bytes).
       </t>

       <t>Note IP back- bone of Deutsche Telekom. The results show that new transport protocols such as QUIC may use UDP
       but, due simple Markov models are appropriate to their capture the observed loss pattern.
              </t>
            </abstract>
          </front>
          <refcontent>14th GI/ITG Conference - Measurement, Modelling and Evalutation [sic] of Computer and Communication Systems</refcontent>
        </reference>
        <reference anchor="I-D.ietf-netvc-testing" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-netvc-testing-09" derivedAnchor="netvc-testing">
          <front>
            <title>Video Codec Testing and Quality Measurement</title>
            <author initials="T" surname="Daede" fullname="Thomas Daede">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A" surname="Norkin" fullname="Andrey Norkin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I" surname="Brailovskiy" fullname="Ilya Brailovskiy">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" day="31" year="2020"/>
            <abstract>
              <t indent="0">This document describes guidelines and procedures for evaluating a video codec.  This covers subjective and objective tests, test conditions, and materials used for the test.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netvc-testing-09"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netvc-testing-09.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC5033" target="https://www.rfc-editor.org/info/rfc5033" quoteTitle="true" derivedAnchor="RFC5033">
          <front>
            <title>Specifying New Congestion Control Algorithms</title>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Allman" fullname="M. Allman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="August"/>
            <abstract>
              <t indent="0">The IETF's standard congestion control algorithms, will exhibit
       behavior conceptually similar in nature schemes have been widely shown to TCP flows above and
       can thus be subsumed by the above, including inadequate for various environments (e.g., high-speed networks).  Recent research has yielded many alternate congestion control schemes that significantly differ from the division into
       short- and long-lived flows.  As QUIC evolves independently of
       TCP IETF's congestion control algorithms, its future principles.  Using these new congestion control should be considered as competing schemes in the global Internet has possible ramifications to both the traffic as appropriate.
       </t>
        </section>

    </section>

        <section title="Security Considerations">
          <t>
	    This document specifies evaluation criteria and parameters
	    for assessing and comparing using the performance of new congestion control protocols and algorithms for real-time
	    communication.  This memo itself is thus not subject to
	    security considerations but traffic using the protocols and algorithms
	    evaluated may be.  In particular, successful operation
	    under all tests defined in currently standardized congestion control.  Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals.  The goal of this document may suffice is to provide guidance for a
	    comparative evaluation but must not be interpreted that considering alternate congestion control algorithms within the protocol is free of risks when deployed on IETF.  This document specifies an Internet Best Current Practices for the Internet as briefly described in Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="133"/>
          <seriesInfo name="RFC" value="5033"/>
          <seriesInfo name="DOI" value="10.17487/RFC5033"/>
        </reference>
        <reference anchor="RFC5166" target="https://www.rfc-editor.org/info/rfc5166" quoteTitle="true" derivedAnchor="RFC5166">
          <front>
            <title>Metrics for the following by example.
	  </t>
	  <t>
	    Such evaluations are expected Evaluation of Congestion Control Mechanisms</title>
            <author initials="S." surname="Floyd" fullname="S. Floyd" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="March"/>
            <abstract>
              <t indent="0">This document discusses the metrics to be
	    carried out considered in controlled environments for limited numbers an evaluation of parallel flows.  As such, these evaluations are by
	    definition limited and will not be able to systematically
	    consider possible interactions new or very large groups modified congestion control mechanisms for the Internet.  These include metrics for the evaluation of
	    communicating nodes under all possible circumstances, so
	    that careful protocol design is advised to avoid
	    incidentally contributing traffic that could lead new transport protocols, of proposed modifications to
	    unstable networks, e.g., (local) TCP, of application-level congestion collapse.
	  </t>
	  <t> control, and of Active Queue Management (AQM) mechanisms in the router.  This specification focuses on assessing document is the regular
	   operation first in a series of documents aimed at improving the protocols and algorithms under
	   considerations.  It does not suggest checks against
	   malicious models that we use of the protocols -- by the sender, in the
	   receiver, or intermediate parties, e.g., through faked,
	   dropped, replicated, or modified congestion signals.  It evaluation of transport protocols.</t>
              <t indent="0">This document is
	   up to the protocol specifications themselves to ensure that
	   authenticity, integrity, and/or plausibility a product of received
	   signals are checked and the appropriate actions (or
	   non-actions) are taken.
	  </t>
        </section>

        <section title="IANA Considerations">
            <t>There are no IANA impacts in this memo.</t>
        </section>

        <section anchor="contrib" title="Contributors">
            <t>The content Transport Modeling Research Group (TMRG), and concepts within this has received detailed feedback from many members of the Research Group (RG).  As the document are tries to make clear, there is not necessarily a product of consensus within the discussion carried out in research community (or the Design Team.</t>

            <t>Michael Ramalho provided IETF community, the text for vendor community, the Jitter model.</t>
        </section>

        <section title="Acknowledgments">
          <t> Much of this document is derived from previous work on operations community, or any other community) about the metrics that congestion control at the IETF.</t>
          <t> The authors would like mechanisms should be designed to thank
          Harald Alvestrand,
          Anna Brunstrom,
          Luca De Cicco,
          Wesley Eddy,
          Lars Eggert,
          Kevin Gross,
          Vinayak Hegde,
          Randell Jesup,
          Mirja Kuehlewind,
          Karen Nielsen,
          Piers O'Hanlon,
          Colin Perkins,
          Michael Ramalho,
          Zaheduzzaman Sarker,
          Timothy B. Terriberry,
          Michael Welzl,
          Mo Zanaty, and
	  Xiaoqing Zhu
          for providing valuable feedback on earlier versions optimize, in terms of this draft.
          Additionally, also thank trade-offs between throughput and delay, fairness between competing flows, and the participants like.  However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of the design team trade-offs between a range of metrics, rather than in terms of optimizing for a single metric.  This memo provides information for
          their comments and discussion related to the evaluation
          criteria.</t>
        </section>
    </middle>
    <back>
        <references title="Normative References">
            <!--&rfc2119;-->
            <!-- RTP related -->
            &rfc3550;
            &rfc3551;
            &rfc3611;
            &rfc4585;
            &rfc5506;
            <!--RMCAT related -->
	    &rfc8083;
            &rfc8593;
            &I-D.ietf-rmcat-cc-requirements;
            </references>

            <references title="Informative References">
            &rfc5033; <!-- CC Evaluation -->
            &rfc5166; <!-- CC Metrics -->
            <!-- &rfc5681; Standard TCP -->
            &I-D.ietf-rmcat-eval-test;
            &I-D.ietf-rmcat-wireless-tests;
            &I-D.ietf-netvc-testing; Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5166"/>
          <seriesInfo name="DOI" value="10.17487/RFC5166"/>
        </reference>
        <reference anchor="gilbert-elliott"> anchor="RFC8312" target="https://www.rfc-editor.org/info/rfc8312" quoteTitle="true" derivedAnchor="RFC8312">
          <front>
                    <title>The Gilbert-Elliott Model
            <title>CUBIC for Packet Loss in Real Time Services on the Internet</title> Fast Long-Distance Networks</title>
            <author surname="Hasslinger" fullname="Gerhard Hasslinger">
		      <organization/> initials="I." surname="Rhee" fullname="I. Rhee">
              <organization showOnFrontPage="true"/>
            </author>
            <author surname="Hohlfeld" fullname="Oliver Hohlfeld"> initials="L." surname="Xu" fullname="L. Xu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Ha" fullname="S. Ha">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Zimmermann" fullname="A. Zimmermann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Eggert" fullname="L. Eggert">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Scheffenegger" fullname="R. Scheffenegger">
              <organization /> showOnFrontPage="true"/>
            </author>
            <date month="3" year="2008" /> year="2018" month="February"/>
            <abstract>
                    <t>The estimation of quality for real-time services over telecommunication networks requires realistic models for impairments and failures during transmission. We focus on the classical Gilbert-Elliott model whose second order statistics
              <t indent="0">CUBIC is derived over arbitrary time scales and used an extension to fit packet loss processes of traffic traces measured the current TCP standards.  It differs from the current TCP standards only in the IP back- bone of Deutsche Telekom. The results show that simple Markov models are appropriate to capture congestion control algorithm on the sender side.  In particular, it uses a cubic function instead of a linear window increase function of the observed loss pattern.
                    </t></abstract>
                </front>
                <seriesInfo name="14th GI/ITG Conference - Measurement, Modelling current TCP standards to improve scalability and Evalutation of Computer stability under fast and Communication Systems" value=""/>
            </reference>
            <reference anchor="tcpdump">
                <front>
                  <title>Homepage long-distance networks.  CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years.  This document provides a specification of tcpdump CUBIC to enable third-party implementations and libpcap</title>
		  <author>
		    <organization/>
		  </author>
                  <date month="" year="" /> to solicit community feedback through experimentation on the performance of CUBIC.</t>
            </abstract>
          </front>
          <seriesInfo name="https://www.tcpdump.org/index.html" value=""/> name="RFC" value="8312"/>
          <seriesInfo name="DOI" value="10.17487/RFC8312"/>
        </reference>
        <reference anchor="wireshark"> anchor="RFC8867" target="https://www.rfc-editor.org/info/rfc8867" quoteTitle="true" derivedAnchor="RFC8867">
          <front>
                  <title>Homepage of Wireshark</title>
		  <author>
		    <organization/>
            <title>Test Cases for Evaluating Congestion Control for Interactive Real-Time Media</title>
            <author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V" surname="Singh" fullname="Varun Singh">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="X" surname="Zhu" fullname="Xiaoqing Zhu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Ramalho" fullname="Michael A. Ramalho">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="" year="" /> month="January" year="2021"/>
          </front>
          <seriesInfo name="https://www.wireshark.org" value=""/> name="RFC" value="8867"/>
          <seriesInfo name="DOI" value="10.17487/RFC8867"/>
        </reference>
            <!-- <?rfc include="reference.3GPP.R1.081955"?>
        <reference anchor="SA4-EVAL"> anchor="RFC8869" target="https://www.rfc-editor.org/info/rfc8869" quoteTitle="true" derivedAnchor="RFC8869">
          <front>
                    <title>LTE Link Level Throughput Data
            <title>Evaluation Test Cases for SA4 Evaluation Framework</title> 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="3GPP" surname="R1-081955" fullname="3GPP R1-081955"> initials="J" surname="Fu" fullname="Jiantao Fu">
              <organization /> showOnFrontPage="true"/>
            </author>
            <date month="5" year="2008" />
                    <abstract>
                    <t>In R1-081720, 3GPP SA4 has requested RAN1 and RAN2 for link
                    level throughput traces to be used in an evaluation framework
                    they are developing for dynamic video rate adaptation.
                    </t></abstract> month="January" year="2021"/>
          </front>
          <seriesInfo name="3GPP" value="R1-081955" />
                <format type='ZIP' octets='3459875' target='http://www.3gpp.net/ftp/tsg_ran/WG1_RL1/TSGR1_53/Docs/R1-081955.zip' /> name="RFC" value="8869"/>
          <seriesInfo name="DOI" value="10.17487/RFC8869"/>
        </reference>
            -->

<!--
        <reference anchor="SA4-LR"> anchor="tcpdump" target="https://www.tcpdump.org/index.html" quoteTitle="true" derivedAnchor="tcpdump">
          <front>
                    <title>Error Patterns for MBMS Streaming over UTRAN
            <title>Homepage of tcpdump and GERAN</title>
                    <author initials="3GPP" surname="S4-050560" fullname="3GPP S4-050560"> libpcap</title>
            <author>
              <organization /> showOnFrontPage="true"/>
            </author>
                    <date month="5" year="2008" />
          </front>
                <seriesInfo name="3GPP" value="S4-050560" />
                <format type='ZIP' octets='335322' target='http://www.3gpp.org/FTP/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050560.zip' />
        </reference>
-->

<!--
        <reference anchor="TCP-eval-suite"> anchor="wireshark" target="https://www.wireshark.org" quoteTitle="true" derivedAnchor="wireshark">
          <front>
                <title>Towards a Common TCP Evaluation Suite</title>
                <author initials="A." surname="Lachlan"   fullname="Andrew Lachlan"/>
                <author initials="C." surname="Marcondes" fullname="Cesar Marcondes"/>
                <author initials="S." surname="Floyd"  fullname="Sally Floyd"/>
                <author initials="L." surname="Dunn"  fullname="Lawrence Dunn"/>
                <author initials="R." surname="Guillier"  fullname="Romeric Guillier"/>
                <author initials="W." surname="Gang"  fullname="Wang Gang"/>
                <author initials="L." surname="Eggert"  fullname="Lars Eggert"/>
                <author initials="S." surname="Ha"  fullname="Sangtae Ha"/>
                <author initials="I." surname="Rhee"  fullname="Injong Rhee"/>
                <date month="August" year="2008"/>
            <title>Homepage of Wireshark</title>
            <author>
              <organization showOnFrontPage="true"/>
            </author>
          </front>
              <seriesInfo name="Proc. PFLDnet." value="2008"/>
        </reference>
-->
        <reference anchor="xiph-seq"> anchor="xiph-seq" target="https://media.xiph.org/video/derf/" quoteTitle="true" derivedAnchor="xiph-seq">
          <front>
            <title>Video Test Media Set</title>
            <author fullname="Daede, T." initials="T." surname="Daede"></author>

                  <date month="" year="" />
                </front>
                <seriesInfo name="https://media.xiph.org/video/derf/" value="" />
            </reference>

<!--            <reference anchor="HEVC-seq">
                <front>
                  <title>Test Sequences</title>

                  <author fullname="" initials="" surname="HEVC"></author>

                  <date month="" year="" /> surname="Daede"/>
          </front>
                <seriesInfo name="http://www.netlab.tkk.fi/~varun/test_sequences/"
                        value="" />
        </reference>
-->
      </references>

<!--
        <section anchor="misc"  title="Application Trade-off">
          <t>Application trade-off is yet to be defined. see <xref
          target="I-D.ietf-rmcat-cc-requirements">RMCAT requirements</xref>
          document. Perhaps each experiment should define the application's
          expectation or trade-off.</t>
          <section anchor="misc-2"  title="Measuring Quality">
            <t>No quality metric is defined for performance evaluation, it is
            currently an open issue. However, there is consensus that
            congestion control algorithm should be able to show that it is
            useful for interactive video by performing analysis using a real
            codec and video sequences. </t>
          </section>
        </section>
-->

        <section anchor="App-cl" title="Change Log">
        <t>Note to the RFC-Editor: please remove this section prior to
        publication as an RFC.</t>
        <section title="Changes in draft-ietf-rmcat-eval-criteria-07">
	  <t>Updated the draft according to
    </references>
    <section anchor="contrib" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.a-1">The content and concepts within this document are a product of
            the discussion at IETF-101.</t>
            <t><list style="symbols">
              <t>Updated carried out in the discussion on fairness.  Thanks to Xiaoqing Zhu for providing text.</t>
	      <t>Fixed a simple loss model and Design Team.</t>
      <t indent="0" pn="section-appendix.a-2"><contact fullname="Michael Ramalho"/> provided pointers to more sophisticated ones.</t>
	      <t>Fixed the choice of the jitter model.</t>
              </list></t>
            </section>
            <section title="Changes in draft-ietf-rmcat-eval-criteria-06">
            <t><list style="symbols">
                <t>Updated Jitter.</t>
              </list></t>
            </section>
            <section title="Changes in draft-ietf-rmcat-eval-criteria-05">
            <t><list style="symbols">
                <t>Improved text surrounding wireless tests, video sequences,
                and short-TCP model.</t>
              </list></t>
            </section>
            <section title="Changes in draft-ietf-rmcat-eval-criteria-04">
            <t><list style="symbols">
                <t>Removed for the guidelines section, as most jitter models (<xref target="JM" format="default" sectionFormat="of" derivedContent="Section 4.5"/>).</t>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.b-1"> Much of the sections
                  are now covered: wireless tests, video model, etc.</t>
                <t>Improved Short TCP model based this document is derived from previous work on
          congestion control at the suggestion IETF.</t>
      <t indent="0" pn="section-appendix.b-2"> The authors would like to use
                  httparchive.org.</t>
              </list></t>
            </section>
            <section title="Changes in draft-ietf-rmcat-eval-criteria-03">
            <t><list style="symbols">
                <t>Keep-alive version.</t>
                <t>Moved link parameters and traffic models from eval-test</t>
              </list></t>
            </section>
            <section title="Changes in draft-ietf-rmcat-eval-criteria-02">
            <t><list style="symbols">
                <t>Incorporated fairness test as a working test.</t>
                <t>Updated text on mimimum evaluation requirements.</t>
            </list></t>
            </section>
            <section title="Changes in draft-ietf-rmcat-eval-criteria-01">
            <t><list style="symbols">
                <t>Removed Appendix B.</t>
                <t>Removed Section on Evaluation Parameters.</t>
            </list></t>
            </section>
            <section title="Changes in draft-ietf-rmcat-eval-criteria-00">
            <t><list style="symbols">
                <t>Updated references.</t>
                <t>Resubmitted as WG draft.</t>
            </list></t>
            </section>
            <section title="Changes in draft-singh-rmcat-cc-eval-04">
            <t><list style="symbols">
                <t>Incorporate thank
          <contact fullname="Harald Alvestrand"/>,
          <contact fullname="Anna Brunstrom"/>,
          <contact fullname="Luca De Cicco"/>,
          <contact fullname="Wesley Eddy"/>,
          <contact fullname="Lars Eggert"/>,
          <contact fullname="Kevin Gross"/>,
          <contact fullname="Vinayak Hegde"/>,
          <contact fullname="Randell Jesup"/>,
          <contact fullname="Mirja Kühlewind"/>,
          <contact fullname="Karen Nielsen"/>,
          <contact fullname="Piers O'Hanlon"/>,
          <contact fullname="Colin Perkins"/>,
          <contact fullname="Michael Ramalho"/>,
          <contact fullname="Zaheduzzaman Sarker"/>,
          <contact fullname="Timothy B. Terriberry"/>,
          <contact fullname="Michael Welzl"/>,
          <contact fullname="Mo Zanaty"/>, and
	  <contact fullname="Xiaoqing Zhu"/>
          for providing valuable feedback from IETF 87, Berlin.</t>
                <t>Clarified metrics: convergence time, bandwidth
                utilization.</t>
                <t>Changed fairness criteria to fairness test.</t>
                <t>Added measuring pre- and post-repair loss.</t>
                <t>Added open issue on draft versions of measuring video quality this document.
          Additionally, thanks to
                appendix.</t>
                <t>clarified use of DropTail and AQM.</t>
                <t>Updated text in "Minimum Requirements for Evaluation"</t>

            </list></t>
            </section>
            <section title="Changes in draft-singh-rmcat-cc-eval-03">
            <t><list style="symbols">
                <t>Incorporate the discussion within the design team.</t>
                <t>Added a section on evaluation parameters, it describes participants of the
                flow and network characteristics.</t>
                <t>Added Appendix with self-fairness experiment.</t>
                <t>Changed bottleneck parameters from a proposal to an example
                set.</t>
                <t></t>
            </list></t>
            </section>

            <section title="Changes in draft-singh-rmcat-cc-eval-02">
            <t><list style="symbols">
                <t>Added scenario descriptions.</t>
            </list></t>
            </section>

            <section title="Changes in draft-singh-rmcat-cc-eval-01">
            <t><list style="symbols">
                <t>Removed QoE metrics.</t>
                <t>Changed stability to steady-state.</t>
                <t>Added measuring impact against few and many
                flows.</t>
                <t>Added guideline Design Team for idle
          their comments and data-limited periods.</t>
                <t>Added reference discussion related to TCP evaluation suite in example the evaluation scenarios.</t>
            </list></t>
          criteria.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="V." surname="Singh" fullname="Varun Singh">
        <organization abbrev="callstats.io" showOnFrontPage="true">CALLSTATS I/O Oy</organization>
        <address>
          <postal>
            <street>Rauhankatu 11 C</street>
            <code>00100</code>
            <city>Helsinki</city>
            <country>Finland</country>
          </postal>
          <email>varun.singh@iki.fi</email>
          <uri>https://www.callstats.io/</uri>
        </address>
      </author>
      <author initials="J." surname="Ott" fullname="Jörg Ott">
        <organization showOnFrontPage="true">Technical University of Munich</organization>
        <address>
          <postal>
            <extaddr>Department of Informatics</extaddr>
            <extaddr>Chair of Connected Mobility</extaddr>
            <street>Boltzmannstrasse 3</street>
            <city>Garching</city>
            <code>85748</code>
            <country>Germany</country>
          </postal>
          <email>ott@in.tum.de</email>
        </address>
      </author>
      <author fullname="Stefan Holmer" initials="S." surname="Holmer">
        <organization abbrev="Google" showOnFrontPage="true">Google</organization>
        <address>
          <postal>
            <street>Kungsbron 2</street>
            <code>11122</code>
            <city>Stockholm</city>
            <country>Sweden</country>
          </postal>
          <email>holmer@google.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>