<?xmlversion="1.0"?>version="1.0" encoding="UTF-8"?> <!-- updated by Chris 04/23/20 --> <!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" ?>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-rmcat-eval-criteria-14"category="info"> <!-- What is the category field value-->number="8868" submissionType="IETF" category="info" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 2.43.0 --> <front> <title abbrev="Evaluating Congestion Control forRMCAT">Interactive Real-Time Media"> Evaluating Congestion Control for InteractiveReal-timeReal-Time Media<!--Evaluation Criteria for RTP Congestion Avoidance Techniques --></title> <seriesInfo name="RFC" value="8868"/> <author initials="V." surname="Singh" fullname="Varun Singh"> <organization abbrev="callstats.io"> CALLSTATS I/O 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/abouthttps://www.callstats.io/ </uri> </address> </author> <author initials="J." surname="Ott"fullname="Joergfullname="Jörg Ott"> <organization>Technical University of Munich</organization> <address> <postal> <street>Faculty of Informatics</street> <street>Boltzmannstrasse 3</street> <city>Garching bei München</city><region>DE</region><code>85748</code> <country>Germany</country> </postal> <email>ott@in.tum.de</email> </address> </author> <author fullname="Stefan Holmer" initials="S." surname="Holmer"> <organization abbrev="Google">Google</organization> <address> <postal> <street>Kungsbron 2</street> <code>11122</code> <city>Stockholm</city> <country>Sweden</country> </postal> <email>holmer@google.com</email> </address> </author> <date year="2020"month="3"/>month="August" /> <area>TSV</area><workgroup>RMCAT WG</workgroup><workgroup>RMCAT</workgroup> <keyword>RTP</keyword> <keyword>RTCP</keyword> <keyword>Congestion Control</keyword> <abstract> <t>TheReal-timeReal-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> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>This memo describes the guidelines to help with evaluating new congestion control algorithms for interactive point-to-pointreal timereal-time media. The requirements for the congestion control algorithm are outlined in <xreftarget="I-D.ietf-rmcat-cc-requirements" />).target="RFC8836" format="default"/>. This document builds upon previous work at the IETF: <xreftarget="RFC5033">Specifyingtarget="RFC5033" format="default">Specifying New Congestion Control Algorithms</xref> and <xreftarget="RFC5166">Metricstarget="RFC5166" format="default">Metrics for the Evaluation of Congestion Control Algorithms</xref>.</t> <t>The guidelines proposed in the document are intended to help prevent a congestion collapse, to promote fair capacityusageusage, 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 <xreftarget="RFC8083">RFC8083</xref>.</t>target="RFC8083" format="default">RFC8083</xref>.</t> <t>This document only provides the broad set of network parameters andandtraffic models for evaluating a new congestion control algorithm. The minimalrequirementsrequirement for congestion control proposals is to produce or present results for the test scenarios described in <xreftarget="I-D.ietf-rmcat-eval-test" />target="RFC8867" format="default"/> (Basic Test Cases), which also defines the specifics for the test cases. Additionally, proponents may produce evaluation results for the <xreftarget="I-D.ietf-rmcat-wireless-tests">target="RFC8869" format="default"> wireless test scenarios</xref>. </t> <t> 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 ofexperienceexperience, 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 usingareal codecs and video sequences and state-of-the-art quality metrics. </t> <t> Beyond optimizing individual metrics, real-time applications may have further options to trade off performance, e.g., across multiple media; refer to the <xreftarget="I-D.ietf-rmcat-cc-requirements">RMCATtarget="RFC8836" format="default">RMCAT requirements</xref> document. Such trade-offs may be defined in the future. </t> </section> <sectiontitle="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> -->anchor="sec-terminology" numbered="true" toc="default"> <name>Terminology</name> <t> The terminology defined in <xreftarget="RFC3550">RTP</xref>,target="RFC3550" format="default">RTP</xref>, <xreftarget="RFC3551">RTPtarget="RFC3551" format="default">RTP Profile for Audio and Video Conferences with Minimal Control</xref>, <xreftarget="RFC3611">RTCPtarget="RFC3611" format="default">RTCP Extended Report (XR)</xref>, <xreftarget="RFC4585">Extendedtarget="RFC4585" format="default">Extended RTP Profile forRTCP-basedRTCP-Based Feedback (RTP/AVPF)</xref> and <xreftarget="RFC5506">Supporttarget="RFC5506" format="default">Support for Reduced-Size RTCP</xref>apply.</t>applies.</t> </section> <sectiontitle="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> -->anchor="cc-metrics" numbered="true" toc="default"> <name>Metrics</name> <t> 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 experiment is expected to log every incoming and outgoing packet (the RTP logging format is described in <xref target="rtp-logging"/>).format="default"/>). The logging can be done inside the application or at the endpoints using PCAP (packet capture, e.g., tcpdump <xreftarget="tcpdump"/>, wiresharktarget="tcpdump" format="default"/>, Wireshark <xreftarget="wireshark"/>).target="wireshark" format="default"/>). The following metrics are calculated based on the information in the packet logs:<list style="numbers"> <t>Sending</t> <ol spacing="normal" type="1"> <li>Sending rate,Receiverreceiver rate,Goodputgoodput (measured at 200msintervals)</t> <t>Packetsintervals)</li> <li>Packets sent,Packets received</t> <t>Bytespackets received</li> <li>Bytes sent, bytesreceived</t> <t>Packet delay</t> <t>Packetsreceived</li> <li>Packet delay</li> <li>Packets lost,Packetspackets discarded (from the playout or de-jitterbuffer)</t> <t>If using,buffer)</li> <li>If using retransmission or FEC: post-repairloss</t> <!-- <t>[Editor's note: How 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-Fairnessloss</li> <li> <t>Self-fairness andFairnessfairness with respect to 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> During static periods of a test (i.e., when bottleneck bandwidth is constant and no arrival/departure of streams), thesereportreports on relative ratios serve as an indicator of howfairfairly 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, at1s, 5s,1 s, 5 s, and20s)20 s) in order to measure fairness across differenttime scales. <vspace/>timescales. </t> <t> As a general guideline, the relative ratio betweencongestion controlledcongestion-controlled RTP flows with the same priority level and similar path RTT should be bounded between(0.3330.333 and3.)3. For example, see the test scenarios described in <xreftarget="I-D.ietf-rmcat-eval-test" />.</t> <t>Convergencetarget="RFC8867" format="default"/>.</t> </li> <li>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 bottlenecklink.</t> <t>Instabilitylink.</li> <li>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 of500ms.</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>Bandwidth utilization, defined as the ratio of the instantaneous sending rate to the instantaneous bottleneckcapacity.capacity: This metric is useful only when acongestion controlledcongestion-controlled RTP flow is by itself or is competing with similarcross-traffic.</t> </list></t>cross-traffic.</li> </ol> <t> Note that the above metrics are all objective application-independent metrics. Refer toSection 3, in<xref target="I-D.ietf-netvc-testing"/>section="3" sectionFormat="of" format="default"/> for objective metrics for evaluating codecs. </t> <t>From thelogslogs, the statistical measures (min, max, mean, standarddeviationdeviation, 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 overtime,time; the measurements in the plot are at1 secondone-second intervals. Additionally, from thelogslogs, it is possible to plot the histogram orCDFcumulative 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="default"> <name>RTP Log Format</name> <t> Having atime series? Additionally: Use JFI forcommon log format simplifies running analyses across different measurement setups and comparingfairness between 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 of time when the endpoint's encoding rate is lower than the end-to-end capacity, i.e., the bandwidth utilization is less than 1.</t> <t>Overuse: is the period of time when the endpoint's encoding rate is higher than the end-to-end capacity, i.e., the bandwidth utilization is greater than 1.</t> <t>Steady-state: is the period of time when the endpoint's encoding rate is relatively stable, i.e., the bandwidth utilization is constant.</t> </list></t> <t></t> <t>(ii) Packet Loss and Discard Rate.</t> <t></t> <t>(iii) Fair Share. </t> <t></t> <t>[Editor's Note: This metric should match the ones defined in the <xref target="I-D.ietf-rmcat-cc-requirements">RMCAT requirements</xref> document.]</t> <t></t> <t>(iv) Quality: There are many different types of quality metrics for audio and video. Audio quality is often expressed by a MOS ("Mean Opinion Score") and can be calculated using an objective algorithm (E-model/R-model). Section 4.7 of <xref target="RFC3611" /> can also be used for VoIP metrics. Similarly, there exist several metrics to measure video quality, for example Peak Signal to Noise Ratio (PSNR). </t> <t>[Editor's Note: Should the algorithm compare average PSNR of test video sequences or what other video quality metric can be used? If Quality 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> </t> --> <section title="RTP Log Format" anchor="rtp-logging"> <t> Having a common log format simplifies running analyses across and comparing different measurements. The log file should be tab or comma separated containing the following details:their results. </t><figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![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>]]></artwork> <t>Each line of the log file should be terminated with CRLF, CR, or LF characters. Empty lines are disregarded.</t> <t>If the congestion control implements retransmissions orFEC,Forward Error Correction (FEC), the evaluation should report both packet loss (before applyingerror-resilience)error resilience) and residual packet loss (after applyingerror-resilience).</t>error resilience).</t> <t>These data should suffice to compute 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 in a separate file, as the repair streams have different payload type and/or SSRC.</t> --></section> </section><!-- <section title="Congestion control requirements" anchor="cc-require"> <t> </t> </section> --> <!--<sectiontitle="Guidelines" anchor="cc-guidelines"> <t>A congestion control algorithm should be tested in simulation or a testbed environment, and the experiments should be repeated multiple timesanchor="add-params" numbered="true" toc="default"> <name>List of Network Parameters</name> <t>The implementors are encouraged toinfer statistical significance. Thechoose evaluation settings from the followingguidelines are considered for evaluation:</t>values initially:</t> <sectiontitle="Avoiding Congestion Collapse"> <t>The congestion control algorithm isanchor="scen-delay" numbered="true" toc="default"> <name>One-Way Propagation Delay</name> <t>Experiments are expected totake an action, such as reducing the sending rate, when it detects congestion. Typically, it should intervene before the circuit breaker <xref target="I-D.ietf-avtcore-rtp-circuit-breakers" /> is engaged. </t> <t>Doesverify that the congestion controlpropose any changesis able to(or diverge from) the circuit breaker conditions defined in <xref target="I-D.ietf-avtcore-rtp-circuit-breakers" />.</t> </section> <section title="Stability"> <t>The congestion control should be assessed for its stability when thework across a broad range of pathcharacteristics do not changecharacteristics, including challenging situations, for example, overtime. Changing the media encoding rate estimate too often or by too much may adversely affecttranscontinental and/or satellite links. Tests thus account for theapplication layer performance.</t>following different latencies: </t> <ol spacing="normal" type="1"> <li>Very low latency: 0-1 ms</li> <li>Low latency: 50 ms</li> <li>High latency: 150 ms</li> <li>Extreme latency: 300 ms</li> </ol> </section> <sectiontitle ="Media Traffic"> <t>The congestion control algorithm should be assessed with different types of media behavior, i.e.,anchor="scen-loss" numbered="true" toc="default"> <name>End-to-End Loss</name> <t> Many paths in themedia should contain idleInternet today are largely lossless; however, in scenarios featuring interference in wireless networks, sending to anddata-limited periods. For example, periods of silence for audio, varying amount of motion for video,receiving from remote regions, orbursty nature of I-frames. </t> <t>The evaluationhigh/fast mobility, media flows may exhibit substantial packet loss. This variety needs to bedone in two stages. Inreflected appropriately by thefirst stage,tests.</t> <t>To model a wide range of lossy links, theendpoint generates traffic atexperiments can choose one of therate calculated byfollowing loss rates; thecongestion controller. Infractional loss is thesecond stage, real codecs or modelsratio ofvideo codecs are used to mimic application-limited data periodspackets lost andvarying video frame sizes.</t>packets sent: </t> <ol spacing="normal" type="1"> <li>no loss: 0%</li> <li>1%</li> <li>5%</li> <li>10%</li> <li>20%</li> </ol> </section> <sectiontitle="Start-up Behavior"> <t>The congestion control algorithmanchor="scen-queue" numbered="true" toc="default"> <name>Drop-Tail Router Queue Length</name> <t>Routers should beassessedconfigured to use drop-tail queues in the experiments due to their (still) prevalent nature. Experimentation withdifferent start-rates. The main reasonActive Queue Management (AQM) schemes is encouraged but not mandatory. </t> <t>The router queue length is measured as the time taken toobservedrain thebehavior ofFIFO queue. It has been noted in various discussions that thecongestion control in different test scenarios, such as when competing with varying amount of cross-traffic or how quickly does the congestion control algorithm achieve a stable sending rate.</t> </section> <section title="Diverse Environments"> <t>The congestion control algorithm should be assessed in heterogeneous environments, containing both wired and wireless paths. Examples of wireless access technologies are: 802.11, GPRS, HSPA, or LTE. One of the main challenges of the wireless environments for the congestion control algorithm is to distinguish between congestion induced loss and transmission (bit-error) loss. Congestion control algorithms may incorrectly identify transmission loss as congestion loss and reduce the media encoding rate by too much, which may cause oscillatory behavior and deteriorate the users' quality of experience. Furthermore, packet loss may induce additional delay in networks with wireless paths due to link-layer retransmissions.</t> </section> <section title="Varying Path Characteristics"> <t>The congestion control algorithm should be evaluated for a range of path characteristics such as, different end-to-end capacity and latency, varying amount of cross traffic on a bottleneck link and a router's queue length. For the moment, only Drop Tail queues are used. However, if new Active Queue Management (AQM) schemes become available, the performance of the congestion control algorithm should be again evaluated.</t> <t>In an experiment, if the media only flows in a single direction, the feedback path should also be tested with varying amounts of impairment.</t> <t>The main motivation for the previous and current criteria is to identify situations in which the proposed congestion control is less performant.</t> </section> <section title="Reacting to Transient Events or Interruptions"> <t>The congestion control algorithm should be able to handle changes in end-to-end capacity and latency. Latency may change due to route updates, link failures, hand-overs etc. In mobile environment the end-to-end capacity may vary due to the interference, fading, hand-overs, etc. In wired networks the end-to-end capacity may vary due to changes in resource reservation.</t> </section> <section title="Fairness With Similar Cross-Traffic"> <t>The congestion control algorithm should be evaluated when competing with other RTP flows using the same or another candidate congestion control algorithm. The proposal should highlight the bottleneck capacity share of each RTP flow.</t> </section> <section title="Impact on Cross-Traffic"> <t>The congestion control algorithm should be evaluated when competing with standard TCP. Short TCP flows may be considered as transient events and the RTP flow may give way to the short TCP flow to complete quickly. However, long-lived TCP flows may starve out the RTP flow depending on router queue length. </t> <t>The proposal should also measure the impact on varied number of cross-traffic sources, i.e., few and many competing flows, or mixing various amounts of TCP and similar cross-traffic.</t> </section> <section title="Extensions to RTP/RTCP"> <t>The congestion control algorithm should indicate if any protocol extensions are required to implement it and should carefully describe the impact of the extension.</t> </section> </section> --> <section anchor="add-params" title="List of Network Parameters"> <t>The implementors initially are encouraged to choose evaluation settings from the following values:</t> <section anchor="scen-delay" title="One-way Propagation Delay"> <!-- --> <t>Experiments are expected to verify that the congestion control is able to work across a broad range of path characteristics, also 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 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 the tests.</t> <t>To model a wide range of lossy links, the experiments can choose one of the following loss rates, the fractional loss is the ratio of packets lost 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 is measured as the time taken to drain the FIFO queue. It has been noted in various discussions that the queue lengthqueue length in thecurrentcurrently deployed Internet varies significantly. While the core backbone network has very short queue length, the home gateways usually have larger queue length. Those various queue lengths can be categorized in the following way:<list style="numbers"> <t>QoS-aware</t> <ol spacing="normal" type="1"> <li>QoS-aware (or short):70ms</t> <t>Nominal: 300-500ms</t> <t>Buffer-bloated: 1000-2000ms</t> </list>70 ms</li> <li>Nominal: 300-500 ms</li> <li>Buffer-bloated: 1000-2000 ms</li> </ol> <t> Here the size of the queue is measured in bytes orpackets and topackets. To convert 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 the above values, do we need to define parameters for other types of queues?]</t> --></section> <sectiontitle="Loss generation model">numbered="true" toc="default"> <name>Loss Generation Model</name> <t> Many models for generating packet loss areavailable,available: someyield correlated,generate correlated packet losses, others generate independentlosses;packet losses. In addition, packet losses can also be extracted from packet traces. As a (simple) minimum loss model with minimal parameterization (i.e., the loss rate), independent random losses must be used in the evaluation. </t> <t> It is known that independent loss models may reflect realitypoorlypoorly, and hence more sophisticated loss models could be considered. Suitable models for correlated lossesincludesinclude the Gilbert-Elliot model <xreftarget="gilbert-elliott"/>target="gilbert-elliott" format="default"/> and models that generate lossesgeneratedby modeling a queueincludingwith its (different) drop behaviors. </t> </section> <section anchor="JM"title="Jitter models">numbered="true" toc="default"> <name>Jitter Models</name> <t>This section defines jitter models for the purposes of this document. When jitter is to be applied to both thecongestion controlledcongestion-controlled RTP flow and any competing flow (such as a TCP competing flow), the competing flow will use the jitter definition below that does not allow forre-orderingreordering of packets on the competing flow (seeNR-RBPDVNR-BPDV definition below).</t> <t>Jitter is an overloaded term in communications. It is typically used to refer to the variation of a metric (e.g., delay) with respect to some reference metric (e.g., average delay or minimum delay). Forexample,example in RFC35503550, jitter is computed as the smoothed difference in packet arrival times relative to their respective expected arrival times, which is particularly meaningful if the underlying packet delay variation was caused by a Gaussian random process.</t> <t>Because jitter is an overloaded term, we use the term Packet Delay Variation (PDV) instead to describe the variation of delay of individual packets in the same sense as the IETFIPPM WGIP Performance Metrics (IPPM) working group has defined PDV in their documents (e.g., RFC 3393) 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, the measurement of which with a finite number of measurement samples results in one-sided histograms. In the usual packet network transport case, there is typically one packet that transited the network with the minimum delay; a (large) number of 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 are outliers). Although infrequent, outliers can cause significant deleterious operation in adaptive systems and should be considered in rate adaptation designs for RTP congestion control.</t> <t>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>The former, 1) Random BoundedPDVPDV, is presented for information only, while the latter, 2) Approximately Random Subject to No-Reordering Bounded PDV, must be used in the evaluation.</t> <sectiontitle="Randomnumbered="true" toc="default"> <name>Random Bounded PDV(RBPDV)">(RBPDV)</name> <t>The RBPDV probability distribution function (PDF) is specified to be of some mathematically describable functionwhichthat includes some practical minimum and maximum discrete values suitable for testing. For example, the minimum value, x_min, might be specified as the minimum transit timepacketpacket, and the maximum value, x_max, might be defined to be two standard deviations higher than the mean.</t> <t>Since we are typically interested in the distribution relative to the mean delay packet, we define the zero mean PDV sample, z(n), to be z(n) = x(n) - x_mean, where x(n) is a sample of the RBPDV random variable x and x_mean is the mean of x.</t> <t>We assume here that s(n) is the original source time of packet n and 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 of packets n and n+1 is {[s(n+1)-s(n)] - [z(n)-z(n+1)]}. Since the first term is always a positive quantity, we note that 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 of any two sent packets, we have the possibility of packetre-ordering.</t>reordering.</t> <t>There are important use cases in real networks where packets can becomere-orderedreordered, such as inload balancingload-balancing topologies and during route changes. However, for the vast majority ofcasescases, there is no packetre-orderingreordering because most of the time packets follow the same path. Due to this, if a packet becomes overly delayed, the packets after it on that flow are also delayed. This is especially true for 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 forre-orderingreordering within a flow.</t> </section> <sectiontitle="Approximatelynumbered="true" toc="default"> <name>Approximately Random Subject to No-Reordering Bounded PDV(NR-RPVD)">(NR-BPDV)</name> <t>No ReorderingRPDV, NR-RPVD,BPDV, NR-BPDV, is defined similarly to the above with one important exception. Let serial(n) be defined as the serialization delay of packet n at the lowest bottleneck link rate (or other appropriate rate) in a given test. Then we produce all the post-jitter values for j(n) for n = 1, 2, ... N, where N is the length of the source sequence s to beoffset-ed.offset. The exception can be stated as follows: We revisit all j(n) beginning from index n=2, and if j(n) is determined to be less than [j(n-1)+serial(n-1)], we redefine j(n) to be equal to [j(n-1)+serial(n-1)] and continue for all remaining n (i.e., n = 3, 4, .. N). This models the case where the packet n is sent immediately after packet (n-1) at the bottleneck link rate. Although this is generally the theoretical minimum in that it assumes that no other packets from other flows arein-betweenin between packet n and n+1 at the bottleneck link, it is a reasonable assumption forper flowper-flow queuing.</t> <t>We note that this assumption holds for some important exception cases, such as packets immediately following outliers. There are a multitude ofsoftware controlledsoftware-controlled elements common on end-to-end Internet paths (such as firewalls,ALGsapplication-layer gateways, and other middleboxes)whichthat 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 outliers. ThusNR-RPVDNR-BPDV models this particular use case (assuming serial(n+1) is defined appropriately for the device causing the outlier) andthusis believed to be important for adaptation development forcongestion controlledcongestion-controlled RTP streams.</t> </section> <sectiontitle="Recommended distribution">numbered="true" toc="default"> <name>Recommended Distribution</name> <t>Whether Random Bounded PDV or Approximately Random Subject to No-Reordering Bounded PDV, it is recommended that z(n) is distributed according to a truncated Gaussian for the above jitter models:</t> <t>z(n) ~ |max(min(N(0,std^2),std<sup>2</sup>), N_STD * std), -N_STD * std)|</t> <t>where N(0,std^2)std<sup>2</sup>) is the Gaussian distribution with zero mean and std is standarddeviation std.deviation. Recommended values:</t><t><list style="symbols"> <t>std<ul empty="true"> <li>std = 5ms</t> <t>N_STDms</li> <li>N_STD =3</t> </list></t> </section>3</li> </ul> </section> </section><!-- <section title="WiFi or Cellular Links"> <t> <xref target="I-D.ietf-rmcat-wireless-tests" /> describes the test cases to simulate networks with wireless links. 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">numbered="true" toc="default"> <name>Traffic Models</name> <section numbered="true" toc="default"> <name>TCP Traffic Model</name> <t>Long-lived TCP flows will download data throughout the session and are expected to have infinite amount of data to send or receive. This roughly applies, for example, when downloading software distributions.</t> <t>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>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>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><t>[These<aside><t>These values were picked based on the data available athttp://httparchive.org/interesting.php<eref target="https://httparchive.org/reports/state-of-the-web?start=2015_10_01&end=2015_11_01&view=list" brackets="angle"/> as of October2015].</t>2015.</t></aside> <t> Many different TCP congestion control schemes are deployed today. Therefore, experimentation with a range of different schemes, especially includingCUBIC,CUBIC <xref target="RFC8312"/>, is encouraged. Experiments must document in detail which congestion control schemes they tested against and which parameters were used. </t> </section> <sectiontitle="RTPnumbered="true" toc="default"> <name>RTP Videomodel">Model</name> <t> <xreftarget="RFC8593"/>target="RFC8593" format="default"/> 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> Sample video test sequences are available at <xreftarget="xiph-seq"></xref>.target="xiph-seq" format="default"/>. 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,respectively), they shall be stitched together repeatedly until the desired length is reached. </t> </section> <sectiontitle="Background UDP">numbered="true" toc="default"> <name>Background UDP</name> <t>Background UDP flow is modeled as a constant bit rate (CBR) flow. It will download data at a particular CBRratefor the complete session, or will change to particular CBRrateat predefined intervals. Theinter packetinter-packet interval is calculated based on the CBR and the packet size(is typically(typically set to the path MTU size, the default value can be 1500 bytes). </t> <t>Note that new transport protocols such as QUIC may useUDP but,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 intoshort-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> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> 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> 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> This specification focuses on assessing the regular operation of the protocols and algorithms underconsiderations.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 arecheckedchecked, and the appropriate actions (or non-actions) are taken. </t> </section> <sectiontitle="IANA Considerations"> <t>There arenumbered="true" toc="default"> <name>IANA Considerations</name> <t>This document has no IANAimpacts in this memo.</t> </section> <section anchor="contrib" title="Contributors"> <t>The content and concepts within this document are a product of the discussion carried out in the Design Team.</t> <t>Michael Ramalho provided the text for the Jitter model.</t> </section> <section title="Acknowledgments"> <t> Much of this document is derived from previous work on congestion control at the IETF.</t> <t> The authors would like 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 of this draft. Additionally, also thank the participants of the design team for their comments and discussion related to the evaluation criteria.</t>actions.</t> </section> </middle> <back><references title="Normative References"> <!--&rfc2119;--><displayreference target="I-D.ietf-netvc-testing" to="netvc-testing"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3611.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5506.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8083.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8593.xml"/> <!--RTP related --> &rfc3550; &rfc3551; &rfc3611; &rfc4585; &rfc5506; <!--RMCAT relateddraft-ietf-rmcat-cc-requirements-09: 8836 -->&rfc8083; &rfc8593; &I-D.ietf-rmcat-cc-requirements;<reference anchor="RFC8836" target="https://www.rfc-editor.org/info/rfc8836"> <front> <title>Congestion Control Requirements for Interactive Real-Time Media</title> <author initials="R" surname="Jesup" fullname="Randell Jesup"> <organization/> </author> <author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker" role="editor"> <organization/> </author> <date month="July" year="2020"/> </front> <seriesInfo name="RFC" value="8836" /> <seriesInfo name="DOI" value="10.17487/RFC8836"/> </reference> </references><references title="Informative References"> &rfc5033;<references> <name>Informative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5033.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5166.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8312.xml"/> <!--CC Evaluationdraft-ietf-rmcat-eval-test (8867) part of C238 -->&rfc5166;<reference anchor="RFC8867" target="https://www.rfc-editor.org/info/rfc8867"> <front> <title>Test Cases for Evaluating RMCAT Proposals</title> <author initials='Z' surname='Sarker' fullname='Zaheduzzaman Sarker'> <organization /> </author> <author initials='V' surname='Singh' fullname='Varun Singh'> <organization /> </author> <author initials='X' surname='Zhu' fullname='Xiaoqing Zhu'> <organization /> </author> <author initials='M' surname='Ramalho' fullname='Michael Ramalho'> <organization /> </author> <date month='July' year='2020' /> </front> <seriesInfo name="RFC" value="8867"/> <seriesInfo name="DOI" value="10.17487/RFC8867"/> </reference> <!--CC Metricsdraft-ietf-rmcat-wireless-tests-11 (8869) part of C238 --> <reference anchor="RFC8869" target="https://www.rfc-editor.org/info/rfc8869"> <front> <title>Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks</title> <author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker"> <organization/> </author> <author initials="X" surname="Zhu" fullname="Xiaoqing Zhu"> <organization/> </author> <author initials="J" surname="Fu" fullname="Jian Fu"> <organization/> </author> <date month='July' year='2020' /> </front> <seriesInfo name="RFC" value="8869"/> <seriesInfo name="DOI" value="10.17487/RFC8869"/> </reference> <!--&rfc5681; Standard TCP[I-D.ietf-netvc-testing] IESG state I-D Exists (IESG: Dead) as of 2020 May 18. -->&I-D.ietf-rmcat-eval-test; &I-D.ietf-rmcat-wireless-tests; &I-D.ietf-netvc-testing;<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netvc-testing-09.xml"/> <referenceanchor="gilbert-elliott">anchor="gilbert-elliott" target="https://ieeexplore.ieee.org/document/5755057"> <front> <title>The Gilbert-Elliott Model for Packet Loss in Real Time Services on the Internet</title> <author surname="Hasslinger" fullname="Gerhard Hasslinger"> <organization/> </author> <author surname="Hohlfeld" fullname="Oliver Hohlfeld"><organization /><organization/> </author> <date month="3"year="2008" />year="2008"/> <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 is derived over arbitrary time scales and used to fit packet loss processes of traffic traces measured in the IP back- bone of Deutsche Telekom. The results show that simple Markov models are appropriate to capture the observed loss pattern.</t></abstract></t> </abstract> </front><seriesInfo name="14th<refcontent>14th GI/ITG Conference- Measurement, Modelling and Evalutation of Computer and Communication Systems" value=""/> </reference> <reference anchor="tcpdump"> <front> <title>Homepage of tcpdump and libpcap</title> <author> <organization/> </author> <date month="" year="" /> </front> <seriesInfo name="https://www.tcpdump.org/index.html" value=""/> </reference> <reference anchor="wireshark"> <front> <title>Homepage of Wireshark</title> <author> <organization/> </author> <date month="" year="" /> </front> <seriesInfo name="https://www.wireshark.org" value=""/> </reference> <!-- <?rfc include="reference.3GPP.R1.081955"?> <reference anchor="SA4-EVAL"> <front> <title>LTE Link Level Throughput Data for SA4 Evaluation Framework</title> <author initials="3GPP" surname="R1-081955" fullname="3GPP R1-081955"> <organization /> </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> </front> <seriesInfo name="3GPP" value="R1-081955" /> <format type='ZIP' octets='3459875' target='http://www.3gpp.net/ftp/tsg_ran/WG1_RL1/TSGR1_53/Docs/R1-081955.zip' /> </reference> --> <!-- <reference anchor="SA4-LR"> <front> <title>Error Patterns for MBMS Streaming over UTRAN and GERAN</title> <author initials="3GPP" surname="S4-050560" fullname="3GPP S4-050560"> <organization /> </author> <date month="5" year="2008" /> </front> <seriesInfo name="3GPP" value="S4-050560" /> <format type='ZIP' octets='335322' target='http://www.3gpp.org/FTP/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050560.zip' /> </reference> --> <!-- <reference anchor="TCP-eval-suite"> <front> <title>Towards a Common TCP Evaluation Suite</title> <author initials="A." surname="Lachlan" fullname="Andrew 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"/> </front> <seriesInfo name="Proc. PFLDnet." value="2008"/> </reference> --> <reference anchor="xiph-seq"> <front> <title>Video Test Media Set</title> <author fullname="Daede, T." initials="T." surname="Daede"></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="" /> </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- Measurement, Modelling andvideo sequences. </t> </section> </section>Evalutation [sic] of Computer and Communication Systems</refcontent> </reference> <reference anchor="tcpdump" target="https://www.tcpdump.org/index.html"> <front> <title>Homepage of tcpdump and libpcap</title> <author> <organization/> </author> </front> </reference> <reference anchor="wireshark" target="https://www.wireshark.org"> <front> <title>Homepage of Wireshark</title> <author> <organization/> </author> </front> </reference> <!--[xiph-seq] The URL below is correct --> <reference anchor="xiph-seq" target="https://media.xiph.org/video/derf/"> <front> <title>Video Test Media Set</title> <author fullname="Daede, T." initials="T." surname="Daede"/> </front> </reference> </references> </references> <sectionanchor="App-cl" title="Change Log"> <t>Note to the RFC-Editor: please removeanchor="contrib" numbered="false" toc="default"> <name>Contributors</name> <t>The content and concepts within thissection prior to publication as an RFC.</t> <section title="Changes in draft-ietf-rmcat-eval-criteria-07"> <t>Updated the draft according todocument are a product of the discussionat IETF-101.</t> <t><list style="symbols"> <t>Updatedcarried out in thediscussion on fairness. Thanks to Xiaoqing Zhu for providing text.</t> <t>Fixed a simple loss model andDesign Team.</t> <t><contact fullname="Michael Ramalho"/> providedpointers to more sophisticated ones.</t> <t>Fixedthechoice oftext for the jittermodel.</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>models (<xref target="JM" format="default"/>).</t> </section> <sectiontitle="Changes in draft-ietf-rmcat-eval-criteria-04"> <t><list style="symbols"> <t>Removed the guidelines section, as mostnumbered="false" toc="default"> <name>Acknowledgments</name> <t> Much ofthe sections are now covered: wireless tests, video model, etc.</t> <t>Improved Short TCP model basedthis document is derived from previous work on congestion control at thesuggestionIETF.</t> <t> The authors would like touse 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>Incorporatethank <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 feedbackfrom 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 issueon draft versions ofmeasuring video qualitythis document. Additionally, thanks toappendix.</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>Incorporatethediscussion within the design team.</t> <t>Added a section on evaluation parameters, it describesparticipants of theflow 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 guidelineDesign Team foridletheir comments anddata-limited periods.</t> <t>Added referencediscussion related toTCP evaluation suite in examplethe evaluationscenarios.</t> </list></t> </section>criteria.</t> </section> </back> </rfc>