Diff: rfc8868xml2.original.xml

	rfc8868xml2.original.xml	rfc8868.xml

	<?xml version="1.0"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!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/refer
	ence.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-requirem
	ents.xml">
	<!ENTITY I-D.ietf-avtcore-rtp-circuit-breakers PUBLIC ""
	"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circu
	it-breakers.xml">
	<!ENTITY I-D.ietf-netvc-testing PUBLIC ""
	"https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netvc-test
	ing.xml">
	<!ENTITY I-D.ietf-rmcat-eval-test PUBLIC ""
	"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-eval-test.x
	ml">
	<!ENTITY I-D.ietf-rmcat-wireless-tests PUBLIC ""
	"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rmcat-wireless-te
	sts.xml">
	]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc toc="yes" ?>
	<?rfc compact="yes" ?>
	<?rfc symrefs="yes" ?>
	<rfc ipr="trust200902" docName="draft-ietf-rmcat-eval-criteria-14" category="inf
	o">
	<!-- What is the category field value-->
	<front>
	<title abbrev="Evaluating Congestion Control for RMCAT">
	Evaluating Congestion Control for Interactive Real-time Media
	<!--Evaluation Criteria for RTP Congestion Avoidance Techniques -->
	</title>


	<author initials="V." surname="Singh" fullname="Varun Singh">	<!-- updated by Chris 04/23/20 -->
	<organization abbrev="callstats.io">
	CALLSTATS I/O Oy
	</organization>
	<address>
	<postal>
	<street>Runeberginkatu 4c A 4</street>
	<code>00100</code> <city>Helsinki</city>
	<country>Finland</country>
	</postal>
	<email>varun.singh@iki.fi</email>
	<uri>
	https://www.callstats.io/about
	</uri>
	</address>
	</author>


	<author initials="J." surname="Ott" fullname="Joerg Ott">	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<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">	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	<organization abbrev="Google">Google</organization>	ipr="trust200902"
	<address>	docName="draft-ietf-rmcat-eval-criteria-14"
	<postal>	number="8868"
	<street>Kungsbron 2</street>	submissionType="IETF"
	<code>11122</code>	category="info"
	<city>Stockholm</city>	consensus="true"
	<country>Sweden</country>	obsoletes=""
	</postal>	updates=""
	<email>holmer@google.com</email>	xml:lang="en"
	</address>	tocInclude="true"
	</author>	symRefs="true"
		sortRefs="true"
		version="3">


	<date year="2020" month="3"/>	<!-- xml2rfc v2v3 conversion 2.43.0 -->
	<area>TSV</area>	<front>
	<workgroup>RMCAT WG</workgroup>	<title abbrev="Evaluating Congestion Control for Interactive Real-Time Media
	<keyword>RTP</keyword>	">
	<keyword>RTCP</keyword>	Evaluating Congestion Control for Interactive Real-Time Media
	<keyword>Congestion Control</keyword>	</title>
	<abstract>	<seriesInfo name="RFC" value="8868"/>
	<t>The Real-time Transport Protocol (RTP) is used to transmit	<author initials="V." surname="Singh" fullname="Varun Singh">
		<organization abbrev="callstats.io">
		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>Technical University of Munich</organization>
		<address>
		<postal>
		<street>Faculty of Informatics</street>
		<street>Boltzmannstrasse 3</street>
		<city>Garching bei München</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>
		<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="August" />
		<area>TSV</area>
		<workgroup>RMCAT</workgroup>
		<keyword>RTP</keyword>
		<keyword>RTCP</keyword>
		<keyword>Congestion Control</keyword>
		<abstract>
		<t>The Real-Time Transport Protocol (RTP) is used to transmit
	media in telephony and video conferencing applications. This	media in telephony and video conferencing applications. This
	document describes the guidelines to evaluate new congestion	document describes the guidelines to evaluate new congestion
	control algorithms for interactive point-to-point real-time	control algorithms for interactive point-to-point real-time
	media.</t>	media.</t>

	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>
	<section title="Introduction">	<section numbered="true" toc="default">
		<name>Introduction</name>
	<t>This memo describes the guidelines to help with evaluating	<t>This memo describes the guidelines to help with evaluating
	new congestion control algorithms for interactive	new congestion control algorithms for interactive

	point-to-point real time media. The requirements for the	point-to-point real-time media. The requirements for the
	congestion control algorithm are outlined in <xref	congestion control algorithm are outlined in <xref target="RFC8836"
	target="I-D.ietf-rmcat-cc-requirements" />). This document	format="default"/>. This document
	builds upon previous work at the IETF: <xref	builds upon previous work at the IETF: <xref target="RFC5033" format
	target="RFC5033">Specifying New Congestion Control	="default">Specifying New Congestion Control
	Algorithms</xref> and <xref target="RFC5166">Metrics for the	Algorithms</xref> and <xref target="RFC5166" format="default">Metric
		s for the
	Evaluation of Congestion Control Algorithms</xref>.</t>	Evaluation of Congestion Control Algorithms</xref>.</t>

		<t>The guidelines proposed in the document are intended to help
	<t>The guidelines proposed in the document are intended to help	prevent a congestion collapse, to promote fair capacity usage, and
	prevent a congestion collapse, promote fair capacity usage and	to optimize the media flow's throughput. Furthermore, the proposed
	optimize the media flow's throughput. Furthermore, the proposed
	congestion control algorithms are expected to operate within the env elope of the	congestion control algorithms are expected to operate within the env elope of the

	circuit breakers defined in <xref target="RFC8083">RFC8083</xref>.</	circuit breakers defined in RFC 8083 <xref target="RFC8083" format="
	t>	default">RFC8083</xref>.</t>
		<t>This document only provides the broad set of network
	<t>This document only provides the broad set of network	parameters and traffic models for evaluating a new
	parameters and and traffic models for evaluating a new	congestion control algorithm. The minimal requirement
	congestion control algorithm. The minimal requirements
	for congestion control proposals is to produce or present	for congestion control proposals is to produce or present

	results for the test scenarios described in <xref	results for the test scenarios described in <xref target="RFC8867" f
	target="I-D.ietf-rmcat-eval-test" /> (Basic Test Cases),	ormat="default"/> (Basic Test Cases),
	which also defines the specifics for the test cases.	which also defines the specifics for the test cases.
	Additionally, proponents may produce evaluation results	Additionally, proponents may produce evaluation results

	for the <xref target="I-D.ietf-rmcat-wireless-tests">	for the <xref target="RFC8869" format="default">
	wireless test scenarios</xref>.	wireless test scenarios</xref>.

	</t>	</t>
		<t>
	<t>
	This document does not cover application-specific	This document does not cover application-specific
	implications of congestion control algorithms and how	implications of congestion control algorithms and how
	those could be evaluated. Therefore, no quality metrics	those could be evaluated. Therefore, no quality metrics
	are defined for performance evaluation; quality metrics	are defined for performance evaluation; quality metrics

	and algorithms to infer those vary between media types.	and the algorithms to infer those vary between media types.
	Metrics and algorithms to assess, e.g., quality of	Metrics and algorithms to assess, e.g., the quality of
	experience evolve continuously so that determining	experience, evolve continuously so that determining
	suitable choices is left for future work. However, there	suitable choices is left for future work. However, there
	is consensus that each congestion control algorithm	is consensus that each congestion control algorithm
	should be able to show that it is useful for interactive	should be able to show that it is useful for interactive

	video by performing analysis using a real codecs and	video by performing analysis using real codecs and
	video sequences and state-of-the-art quality metrics.	video sequences and state-of-the-art quality metrics.

	</t>	</t>
	<t>	<t>
	Beyond optimizing individual metrics, real-time	Beyond optimizing individual metrics, real-time
	applications may have further options to trade off	applications may have further options to trade off
	performance, e.g., across multiple media; refer to the	performance, e.g., across multiple media; refer to the

	<xref target="I-D.ietf-rmcat-cc-requirements">RMCAT	<xref target="RFC8836" format="default">RMCAT
	requirements</xref> document. Such trade-offs may be	requirements</xref> document. Such trade-offs may be
	defined in the future.	defined in the future.

	</t>	</t>
		</section>
	</section>	<section anchor="sec-terminology" numbered="true" toc="default">
		<name>Terminology</name>
	<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> The terminology defined in <xref target="RFC3550">RTP</xref>,
	<xref target="RFC3551">RTP Profile for Audio and Video Conferences
	with Minimal Control</xref>, <xref target="RFC3611">RTCP Extended
	Report (XR)</xref>, <xref target="RFC4585">Extended RTP Profile
	for RTCP-based Feedback (RTP/AVPF)</xref> and <xref
	target="RFC5506">Support for Reduced-Size RTCP</xref> apply.</t>
	</section>

	<section title="Metrics" anchor="cc-metrics">


	<!-- <t><xref target="RFC5166" /> describes the basic metrics for	<t> The terminology defined in <xref target="RFC3550" format="defaul
	congestion control. Metrics that are of interest for interactive	t">RTP</xref>,
	multimedia are:	<xref target="RFC3551" format="default">RTP Profile for Audio and Vi
	<list style="symbols">	deo Conferences
	<t>Throughput.</t>	with Minimal Control</xref>, <xref target="RFC3611" format="default"
	<t>Minimizing oscillations in the transmission rate (stability)	>RTCP Extended
	when the end-to-end capacity varies slowly.</t>	Report (XR)</xref>, <xref target="RFC4585" format="default">Extended
	<t>Delay.</t>	RTP Profile
	<t>Reactivity to transient events.</t>	for RTCP-Based Feedback (RTP/AVPF)</xref> and <xref target="RFC5506"
	<t>Packet losses and discards.</t>	format="default">Support for Reduced-Size RTCP</xref> applies.</t>
	<t>Users' quality of experience</t>	</section>
	<t>Section 2.1 of <xref target="RFC5166" /> discusses the tradeoff	<section anchor="cc-metrics" numbered="true" toc="default">
	between throughput, delay and loss.</t>	<name>Metrics</name>
	</list></t> -->

	<t> This document specifies testing criteria for evaluating	<t> This document specifies testing criteria for evaluating
	congestion control algorithms for RTP media flows. Proposed	congestion control algorithms for RTP media flows. Proposed
	algorithms are to prove their performance by means of	algorithms are to prove their performance by means of
	simulation and/or emulation experiments for all the cases	simulation and/or emulation experiments for all the cases
	described.</t>	described.</t>

		<t>Each experiment is expected to log every incoming and outgoing
	<t>Each experiment is expected to log every incoming and outgoing	packet (the RTP logging format is described in <xref target="rtp-loggin
	packet (the RTP logging format is described in <xref	g" format="default"/>). The logging can be done inside the
	target="rtp-logging" />). The logging can be done inside the
	application or at the endpoints using PCAP (packet capture, e.g.,	application or at the endpoints using PCAP (packet capture, e.g.,

	tcpdump <xref target="tcpdump"/>, wireshark <xref target="wireshark"/>) .	tcpdump <xref target="tcpdump" format="default"/>, Wireshark <xref targ et="wireshark" format="default"/>).
	The following metrics are calculated based on the	The following metrics are calculated based on the
	information in the packet logs:	information in the packet logs:

	<list style="numbers">	</t>
	<t>Sending rate, Receiver rate, Goodput (measured at 200ms intervals	<ol spacing="normal" type="1">
	)</t>	<li>Sending rate, receiver rate, goodput (measured at 200ms intervals)</
	<t>Packets sent, Packets received</t>	li>
	<t>Bytes sent, bytes received</t>	<li>Packets sent, packets received</li>
	<t>Packet delay</t>	<li>Bytes sent, bytes received</li>
	<t>Packets lost, Packets discarded (from the playout or de-jitter bu	<li>Packet delay</li>
	ffer)</t>	<li>Packets lost, packets discarded (from the playout or de-jitter buffe
	<t>If using, retransmission or FEC: post-repair loss</t>	r)</li>
		<li>If using retransmission or FEC: post-repair loss</li>
	<!-- <t>[Editor's note: How to handle packet re-transmissions? loss befo	<li>
	re	<t>Self-fairness and fairness with respect to cross
	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 throug
	hput
	of the RMCAT stream with the lowest average throughput, for a ca
	se
	when the competing streams have similar RTTs.<vspace />
	3. RTT should not grow by a factor of 3 for the existing flows w
	hen a
	new flow is added.
	<vspace />
	-->
	<t>Self-Fairness and Fairness with respect to cross
	traffic: Experiments testing a given congestion control proposal must	traffic: Experiments testing a given congestion control proposal must
	report on relative ratios of the average throughput	report on relative ratios of the average throughput
	(measured at coarser time intervals) obtained by each	(measured at coarser time intervals) obtained by each
	RTP media stream. In the presence of background cross-traffic	RTP media stream. In the presence of background cross-traffic
	such as TCP, the report must also include the relative	such as TCP, the report must also include the relative
	ratio between average throughput of RTP media streams and	ratio between average throughput of RTP media streams and
	cross-traffic streams.	cross-traffic streams.

	<vspace/>	</t>
		<t>
	During static periods of a test (i.e., when bottleneck	During static periods of a test (i.e., when bottleneck
	bandwidth is constant and no arrival/departure of	bandwidth is constant and no arrival/departure of

	streams), these report on relative ratios serve as an	streams), these reports on relative ratios serve as an
	indicator of how fair the RTP streams share bandwidth	indicator of how fairly the RTP streams share bandwidth
	amongst themselves and against cross-traffic streams. The	amongst themselves and against cross-traffic streams. The
	throughput measurement interval should be set at a few	throughput measurement interval should be set at a few

	values (for example, at 1s, 5s, and 20s) in order to	values (for example, at 1 s, 5 s, and 20 s) in order to
	measure fairness across different time scales.	measure fairness across different timescales.
	<vspace/>	</t>
	As a general guideline, the relative ratio between congestion control	<t>
	led RTP	As a general guideline, the relative ratio between congestion-control
		led RTP
	flows with the same priority level and similar path RTT	flows with the same priority level and similar path RTT

	should be bounded between (0.333 and 3.) For example, see	should be bounded between 0.333 and 3. For example, see
	the test scenarios described in <xref	the test scenarios described in <xref target="RFC8867" format="defaul
	target="I-D.ietf-rmcat-eval-test" />.</t>	t"/>.</t>
		</li>
	<t>Convergence time: The time taken to reach a stable rate at startu	<li>Convergence time: The time taken to reach a stable rate at startup,
	p,
	after the available link capacity changes, or when new flows get add ed	after the available link capacity changes, or when new flows get add ed

	to the bottleneck link.</t>	to the bottleneck link.</li>
		<li>Instability or oscillation in the sending rate: The frequency or
	<t>Instability or oscillation in the sending rate: The frequency or
	number of instances when the sending rate oscillates between an	number of instances when the sending rate oscillates between an
	high watermark level and a low watermark level, or vice-versa in	high watermark level and a low watermark level, or vice-versa in
	a defined time window. For example, the watermarks can be set at 4x	a defined time window. For example, the watermarks can be set at 4x

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

	<t>
	Note that the above metrics are all objective	Note that the above metrics are all objective

	application-independent metrics. Refer to Section 3, in	application-independent metrics. Refer to
	<xref target="I-D.ietf-netvc-testing" /> for objective	<xref target="I-D.ietf-netvc-testing" section="3" sectionFormat="of" fo
	metrics for evaluating codecs.	rmat="default"/>
	</t>	for objective metrics for evaluating codecs.
		</t>
	<t>From the logs the statistical measures (min, max, mean, standard	<t>From the logs, the statistical measures (min, max, mean, standard
	deviation and variance) for the whole duration or any specific part of	deviation, and variance) for the whole duration or any specific part of
	the session can be calculated. Also the metrics (sending rate,	the session can be calculated. Also the metrics (sending rate,
	receiver rate, goodput, latency) can be visualized in graphs as	receiver rate, goodput, latency) can be visualized in graphs as

	variation over time, the measurements in the plot are at 1 second	variation over time; the measurements in the plot are at one-second
	intervals. Additionally, from the logs it is possible to plot the	intervals. Additionally, from the logs, it is possible to plot the
	histogram or CDF of packet delay.</t>	histogram or cumulative distribution function (CDF) of packet delay.</t>

	<!-- 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 a time series? Additionally: Use JFI
	for comparing fairness 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	<section anchor="rtp-logging" numbered="true" toc="default">
	audio and video. Audio quality is often expressed by a MOS ("Mean	<name>RTP Log Format</name>
	Opinion Score") and can be calculated using an objective algorithm	<t>
	(E-model/R-model). Section 4.7 of <xref target="RFC3611" /> can also	Having a common log format simplifies running analyses across
	be used for VoIP metrics. Similarly, there exist several metrics to	different measurement setups and comparing their results.
	measure video quality, for example Peak Signal to Noise Ratio (PSNR).
	</t>	</t>


	<t>[Editor's Note: Should the algorithm compare average PSNR of test	<artwork name="" type="" align="left" alt=""><![CDATA[
	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:
	</t>

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

	]]></artwork></figure>	]]></artwork>
		<t>Each line of the log file should be terminated with CRLF,
	<t>Each line of the log file should be terminated with CRLF,
	CR, or LF characters. Empty lines are disregarded.</t>	CR, or LF characters. Empty lines are disregarded.</t>

	<t>If the congestion control implements retransmissions or FEC, the	<t>If the congestion control implements retransmissions or Forward Error Correction (FEC), the
	evaluation should report both packet loss (before applying	evaluation should report both packet loss (before applying

	error-resilience) and residual packet loss (after applying	error resilience) and residual packet loss (after applying
	error-resilience).</t>	error resilience).</t>
		<t>These data should suffice to compute the media-encoding independent
	<t>These data should suffice to compute the media-encoding independent
	metrics described above. Use of a common log will allow simplified	metrics described above. Use of a common log will allow simplified
	post-processing and analysis across different implementations.	post-processing and analysis across different implementations.

	</t>	</t>
	<!-- <t>The retransmissions for post-repair loss metric be logged in a
	separate file, as the repair streams have different payload type
	and/or SSRC.</t> -->
	</section>
	</section>

	<!--
	<section title="Congestion control requirements" anchor="cc-require">
	<t> </t>
	</section>	</section>

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

	<section title="Avoiding Congestion Collapse">
	<t>The congestion control algorithm is expected to take an action,
	such as reducing the sending rate, when it detects congestion.
	Typically, it should intervene before the circuit breaker <xref
	target="I-D.ietf-avtcore-rtp-circuit-breakers" /> is engaged. </t>

	<t>Does the congestion control propose any changes to (or diverge
	from) the circuit breaker conditions defined in <xref
	target="I-D.ietf-avtcore-rtp-circuit-breakers" />.</t> </section>

	<section title="Stability">
	<t>The congestion control should be assessed for its stability
	when the path characteristics do not change over time. Changing
	the media encoding rate estimate too often or by too much may
	adversely affect the application layer performance.</t>
	</section>

	<section title ="Media Traffic">
	<t>The congestion control algorithm should be assessed with
	different types of media behavior, i.e., the media should contain
	idle and data-limited periods. For example, periods of silence for
	audio, varying amount of motion for video, or bursty nature of
	I-frames. </t>

	<t>The evaluation may be done in two stages. In the first stage,
	the endpoint generates traffic at the rate calculated by the
	congestion controller. In the second stage, real codecs or models
	of video codecs are used to mimic application-limited data periods
	and varying video frame sizes.</t>
	</section>

	<section title="Start-up Behavior">
	<t>The congestion control algorithm should be assessed with
	different start-rates. The main reason is to observe the behavior
	of the congestion control in different test scenarios, such
	as when competing with varying amount of cross-traffic or how
	quickly does the congestion control algorithm achieve a stable
	sending rate.</t>
	</section>

	<section title="Diverse Environments">
	<t>The congestion control algorithm should be assessed in
	heterogeneous environments, containing both wired and wireless
	paths. Examples of wireless access technologies are: 802.11, GPRS,
	HSPA, or LTE. One of the main challenges of the wireless
	environments for the congestion control algorithm is to
	distinguish between congestion induced loss and transmission
	(bit-error) loss. Congestion control algorithms may
	incorrectly identify transmission loss as congestion loss and
	reduce the media encoding rate by too much, which may cause
	oscillatory behavior and deteriorate the users' quality of
	experience. Furthermore, packet loss may induce additional delay
	in networks with wireless paths due to link-layer
	retransmissions.</t>
	</section>

	<section title="Varying Path Characteristics">
	<t>The congestion control algorithm should be evaluated for a
	range of path characteristics such as, different end-to-end
	capacity and latency, varying amount of cross traffic on a
	bottleneck link and a router's queue length. For the moment, only
	Drop Tail queues are used. However, if new Active Queue Management
	(AQM) schemes become available, the performance of the congestion
	control algorithm should be again evaluated.</t>

	<t>In an experiment, if the media only flows in a single
	direction, the feedback path should also be tested with varying
	amounts of impairment.</t>

	<t>The main motivation for the previous and current criteria is to
	identify situations in which the proposed congestion control is
	less performant.</t>
	</section>

	<section title="Reacting to Transient Events or Interruptions">
	<t>The congestion control algorithm should be able to handle
	changes in end-to-end capacity and latency. Latency may change
	due to route updates, link failures, hand-overs etc. In mobile
	environment the end-to-end capacity may vary due to the
	interference, fading, hand-overs, etc. In wired networks the
	end-to-end capacity may vary due to changes in resource
	reservation.</t>
	</section>

	<section title="Fairness With Similar Cross-Traffic">
	<t>The congestion control algorithm should be evaluated when
	competing with other RTP flows using the same or another candidate
	congestion control algorithm. The proposal should highlight the
	bottleneck capacity share of each RTP flow.</t>
	</section>

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

	<t>The congestion control algorithm should be evaluated when
	competing with standard TCP. Short TCP flows may be considered
	as transient events and the RTP flow may give way to the short
	TCP flow to complete quickly. However, long-lived TCP flows may
	starve out the RTP flow depending on router queue length. </t>

	<t>The proposal should also measure the impact on varied number
	of cross-traffic sources, i.e., few and many competing flows,
	or mixing various amounts of TCP and similar cross-traffic.</t>
	</section>

	<section title="Extensions to RTP/RTCP">
	<t>The congestion control algorithm should indicate if any
	protocol extensions are required to implement it and should
	carefully describe the impact of the extension.</t>
	</section>

	</section> -->

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

	<t>The implementors initially are encouraged to choose evaluation settings
	from the following values:</t>


	<section anchor="scen-delay" title="One-way Propagation Delay">	<section anchor="add-params" numbered="true" toc="default">
	<!-- -->	<name>List of Network Parameters</name>
		<t>The implementors are encouraged to choose evaluation settings
		from the following values initially:</t>
		<section anchor="scen-delay" numbered="true" toc="default">
		<name>One-Way Propagation Delay</name>

	<t>Experiments are expected to verify that the congestion control is	<t>Experiments are expected to verify that the congestion control is

	able to work across a broad range of path characteristics, also includin	able to work across a broad range of path characteristics, including cha
	g challenging situations, for example over	llenging situations, for example, over
	trans-continental and/or satellite links. Tests thus account for the fo	transcontinental and/or satellite links. Tests thus account for the fol
	llowing different latencies:	lowing 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>	</t>
	</list></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>	</section>

		<section anchor="scen-loss" numbered="true" toc="default">
	<section anchor="scen-loss" title="End-to-end Loss">	<name>End-to-End Loss</name>
	<t>Many paths in the Internet today are largely lossless but,	<t> Many paths in the Internet today are largely lossless;
	with wireless networks and interference, towards remote	however, in scenarios featuring interference in wireless
	regions, or in scenarios featuring high/fast mobility, media	networks, sending to and receiving from remote regions,
	flows may exhibit substantial packet loss. This variety needs	or high/fast mobility, media flows may exhibit substantial
		packet loss. This variety needs
	to be reflected appropriately by the tests.</t>	to be reflected appropriately by the tests.</t>


	<t>To model a wide range of lossy links, the experiments can choose one of the	<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	following loss rates; the fractional loss is the ratio of packets lost
	and packets sent. <list style="numbers">	and packets sent: </t>
	<t>no loss: 0%</t>	<ol spacing="normal" type="1">
		<li>no loss: 0%</li>
	<t>1%</t>	<li>1%</li>
		<li>5%</li>
	<t>5%</t>	<li>10%</li>
		<li>20%</li>
	<t>10%</t>	</ol>

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

		<section anchor="scen-queue" numbered="true" toc="default">
	<section anchor="scen-queue" title="Drop Tail Router Queue Length">	<name>Drop-Tail Router Queue Length</name>
	<t>Routers should be configured to use Drop Trail queues in	<t>Routers should be configured to use drop-tail queues in
	the experiments due to their (still) prevalent nature.	the experiments due to their (still) prevalent nature.

	Experimentation with AQM schemes is encouraged but not mandatory.	Experimentation with Active Queue Management (AQM) schemes is encouraged
	</t>	but not mandatory.
		</t>
	<t>The router queue length is measured as the time taken to drain the	<t>The router queue length is measured as the time taken to drain the
	FIFO queue. It has been noted in various discussions that the queue	FIFO queue. It has been noted in various discussions that the queue

	length in the current deployed Internet varies significantly. While	length in the currently deployed Internet varies significantly. While
	the core backbone network has very short queue length, the home	the core backbone network has very short queue length, the home
	gateways usually have larger queue length. Those various queue lengths	gateways usually have larger queue length. Those various queue lengths

	can be categorized in the following way: <list style="numbers">	can be categorized in the following way: </t>
	<t>QoS-aware (or short): 70ms</t>	<ol spacing="normal" type="1">
		<li>QoS-aware (or short): 70 ms</li>
	<t>Nominal: 300-500ms</t>	<li>Nominal: 300-500 ms</li>
		<li>Buffer-bloated: 1000-2000 ms</li>
	<t>Buffer-bloated: 1000-2000ms</t>	</ol>
	</list> Here the size of the queue is measured in bytes or packets	<t> Here the size of the queue is measured in bytes or packets.
	and to convert the queue length measured in seconds to queue length in	To convert the queue length measured in seconds to queue length in
	bytes:</t>	bytes:</t>


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


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

	<!-- <t>[Open issue (11): Confirm the above values, do we need to
	define parameters for other types of queues?]</t> -->
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Loss generation model">	<name>Loss Generation Model</name>
	<t>	<t>
	Many models for generating packet loss are available, some	Many models for generating packet loss are available: some
	yield correlated, others independent losses; losses can also	generate correlated packet losses, others generate independent packet losses.
	be extracted from packet traces. As a (simple) minimum loss	In addition,
		packet losses can also be extracted from packet traces.
		As a (simple) minimum loss
	model with minimal parameterization (i.e., the loss rate),	model with minimal parameterization (i.e., the loss rate),
	independent random losses must be used in the evaluation.	independent random losses must be used in the evaluation.

	</t>	</t>
	<t>	<t>
	It is known that independent loss models may reflect reality	It is known that independent loss models may reflect reality poorly,
	poorly and hence more sophisticated loss models could be	and hence more sophisticated loss models could be
	considered. Suitable models for correlated losses includes	considered.
	the Gilbert-Elliot model <xref target="gilbert-elliott"/> and	Suitable models for correlated losses include the Gilbert-Elliot
	losses generated by modeling a queue including its	model <xref target="gilbert-elliott" format="default"/> and models that gener
	(different) drop behaviors.	ate losses by
	</t>	modeling a queue with its (different) drop behaviors.
		</t>
	</section>	</section>

		<section anchor="JM" numbered="true" toc="default">
	<section anchor="JM" title="Jitter models">	<name>Jitter Models</name>
	<t>This section defines jitter models for the purposes of this	<t>This section defines jitter models for the purposes of this

	document. When jitter is to be applied to both the congestion controlled RTP flow and any	document. When jitter is to be applied to both the congestion-controlled RTP flow and any
	competing flow (such as a TCP competing flow), the competing flow will	competing flow (such as a TCP competing flow), the competing flow will

	use the jitter definition below that does not allow for re-ordering of	use the jitter definition below that does not allow for reordering of
	packets on the competing flow (see NR-RBPDV definition below).</t>	packets on the competing flow (see NR-BPDV definition below).</t>

	<t>Jitter is an overloaded term in communications. It is	<t>Jitter is an overloaded term in communications. It is
	typically used to refer to the variation of a metric (e.g.,	typically used to refer to the variation of a metric (e.g.,
	delay) with respect to some reference metric (e.g., average	delay) with respect to some reference metric (e.g., average

	delay or minimum delay). For example, RFC 3550 jitter is	delay or minimum delay). For example in RFC 3550, jitter is
	computed as the smoothed difference in packet arrival times	computed as the smoothed difference in packet arrival times
	relative to their respective expected arrival times, which is	relative to their respective expected arrival times, which is
	particularly meaningful if the underlying packet delay	particularly meaningful if the underlying packet delay
	variation was caused by a Gaussian random process.</t>	variation was caused by a Gaussian random process.</t>


	<t>Because jitter is an overloaded term, we use the term	<t>Because jitter is an overloaded term, we use the term
	Packet Delay Variation (PDV) instead to describe the variation	Packet Delay Variation (PDV) instead to describe the variation
	of delay of individual packets in the same sense as the IETF	of delay of individual packets in the same sense as the IETF

	IPPM WG has defined PDV in their documents (e.g., RFC 3393)	IP Performance Metrics (IPPM) working group has defined PDV in their doc uments (e.g., RFC 3393)
	and as the ITU-T SG16 has defined IP Packet Delay Variation	and as the ITU-T SG16 has defined IP Packet Delay Variation
	(IPDV) in their documents (e.g., Y.1540).</t>	(IPDV) in their documents (e.g., Y.1540).</t>


	<t>Most PDV distributions in packet network systems are	<t>Most PDV distributions in packet network systems are
	one-sided distributions, the measurement of which with a	one-sided distributions, the measurement of which with a
	finite number of measurement samples results in one-sided	finite number of measurement samples results in one-sided
	histograms. In the usual packet network transport case, there	histograms. In the usual packet network transport case, there
	is typically one packet that transited the network with the	is typically one packet that transited the network with the
	minimum delay; a (large) number of packets transit the network	minimum delay; a (large) number of packets transit the network
	within some (smaller) positive variation from this minimum	within some (smaller) positive variation from this minimum
	delay, and a (small) number of the packets transit the network	delay, and a (small) number of the packets transit the network
	with delays higher than the median or average transit time	with delays higher than the median or average transit time
	(these are outliers). Although infrequent, outliers can cause	(these are outliers). Although infrequent, outliers can cause

	skipping to change at line 626 ¶	skipping to change at line 360 ¶
	histograms. In the usual packet network transport case, there	histograms. In the usual packet network transport case, there
	is typically one packet that transited the network with the	is typically one packet that transited the network with the
	minimum delay; a (large) number of packets transit the network	minimum delay; a (large) number of packets transit the network
	within some (smaller) positive variation from this minimum	within some (smaller) positive variation from this minimum
	delay, and a (small) number of the packets transit the network	delay, and a (small) number of the packets transit the network
	with delays higher than the median or average transit time	with delays higher than the median or average transit time
	(these are outliers). Although infrequent, outliers can cause	(these are outliers). Although infrequent, outliers can cause
	significant deleterious operation in adaptive systems and	significant deleterious operation in adaptive systems and
	should be considered in rate adaptation designs for RTP	should be considered in rate adaptation designs for RTP
	congestion control.</t>	congestion control.</t>


	<t>In this section we define two different bounded PDV	<t>In this section we define two different bounded PDV
	characteristics, 1) Random Bounded PDV and 2) Approximately Random	characteristics, 1) Random Bounded PDV and 2) Approximately Random
	Subject to No-Reordering Bounded PDV.</t>	Subject to No-Reordering Bounded PDV.</t>

		<t>The former, 1) Random Bounded PDV, is presented for
	<t>The former, 1) Random Bounded PDV is presented for
	information only, while the latter, 2) Approximately Random	information only, while the latter, 2) Approximately Random
	Subject to No-Reordering Bounded PDV, must be used in the	Subject to No-Reordering Bounded PDV, must be used in the
	evaluation.</t>	evaluation.</t>

		<section numbered="true" toc="default">
	<section title="Random Bounded PDV (RBPDV)">	<name>Random Bounded PDV (RBPDV)</name>
		<t>The RBPDV probability distribution function (PDF) is specified to
	<t>The RBPDV probability distribution function (PDF) is specified to	be of some mathematically describable function that includes some
	be of some mathematically describable function which includes some
	practical minimum and maximum discrete values suitable for testing.	practical minimum and maximum discrete values suitable for testing.
	For example, the minimum value, x_min, might be specified as the	For example, the minimum value, x_min, might be specified as the

	minimum transit time packet and the maximum value, x_max, might be	minimum transit time packet, and the maximum value, x_max, might be
	defined to be two standard deviations higher than the mean.</t>	defined to be two standard deviations higher than the mean.</t>

		<t>Since we are typically interested in the distribution relative to
	<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	the mean delay packet, we define the zero mean PDV sample, z(n), to be
	z(n) = x(n) - x_mean, where x(n) is a sample of the RBPDV random	z(n) = x(n) - x_mean, where x(n) is a sample of the RBPDV random
	variable x and x_mean is the mean of x.</t>	variable x and x_mean is the mean of x.</t>

		<t>We assume here that s(n) is the original source time of packet n
	<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:	and the post-jitter induced emission time, j(n), for packet n is:

	</t>	</t>
	<t>j(n) = {[z(n) + x_mean] + s(n)}.</t>	<t>j(n) = {[z(n) + x_mean] + s(n)}.</t>
	<t>	<t>
	It follows that the separation in the post-jitter time of	It follows that the separation in the post-jitter time of
	packets n and n+1 is {[s(n+1)-s(n)] - [z(n)-z(n+1)]}. Since	packets n and n+1 is {[s(n+1)-s(n)] - [z(n)-z(n+1)]}. Since
	the first term is always a positive quantity, we note that	the first term is always a positive quantity, we note that
	packet reordering at the receiver is possible whenever the	packet reordering at the receiver is possible whenever the
	second term is greater than the first. Said another way,	second term is greater than the first. Said another way,
	whenever the difference in possible zero mean PDV sample	whenever the difference in possible zero mean PDV sample
	delays (i.e., [x_max-x_min]) exceeds the inter-departure	delays (i.e., [x_max-x_min]) exceeds the inter-departure
	time of any two sent packets, we have the possibility of	time of any two sent packets, we have the possibility of

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

	for re-ordering within a flow.</t>	for reordering within a flow.</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Approximately Random Subject to No-Reordering Bounded PD	<name>Approximately Random Subject to No-Reordering Bounded PDV (NR-BP
	V	DV)</name>
	(NR-RPVD)">	<t>No Reordering BPDV, NR-BPDV, is defined similarly to the above with

	<t>No Reordering RPDV, NR-RPVD, is defined similarly to the above with
	one important exception. Let serial(n) be defined as the serialization	one important exception. Let serial(n) be defined as the serialization
	delay of packet n at the lowest bottleneck link rate (or other	delay of packet n at the lowest bottleneck link rate (or other
	appropriate rate) in a given test. Then we produce all the post-jitter	appropriate rate) in a given test. Then we produce all the post-jitter
	values for j(n) for n = 1, 2, ... N, where N is the length of the	values for j(n) for n = 1, 2, ... N, where N is the length of the

	source sequence s to be offset-ed. The exception can be stated as	source sequence s to be offset. The exception can be stated as
	follows: We revisit all j(n) beginning from index n=2, and if j(n) is	follows: We revisit all j(n) beginning from index n=2, and if j(n) is
	determined to be less than [j(n-1)+serial(n-1)], we redefine j(n) to	determined to be less than [j(n-1)+serial(n-1)], we redefine j(n) to
	be equal to [j(n-1)+serial(n-1)] and continue for all remaining n	be equal to [j(n-1)+serial(n-1)] and continue for all remaining n
	(i.e., n = 3, 4, .. N). This models the case where the packet n is	(i.e., n = 3, 4, .. N). This models the case where the packet n is
	sent immediately after packet (n-1) at the bottleneck link rate.	sent immediately after packet (n-1) at the bottleneck link rate.
	Although this is generally the theoretical minimum in that it assumes	Although this is generally the theoretical minimum in that it assumes

	that no other packets from other flows are in-between packet n and n+1	that no other packets from other flows are in between packet n and n+1
	at the bottleneck link, it is a reasonable assumption for per flow	at the bottleneck link, it is a reasonable assumption for per-flow
	queuing.</t>	queuing.</t>


	<t>We note that this assumption holds for some important exception	<t>We note that this assumption holds for some important exception
	cases, such as packets immediately following outliers. There are a	cases, such as packets immediately following outliers. There are a

	multitude of software controlled elements common on end-to-end	multitude of software-controlled elements common on end-to-end
	Internet paths (such as firewalls, ALGs and other middleboxes) which	Internet paths (such as firewalls, application-layer gateways, and oth
		er middleboxes) that
	stop processing packets while servicing other functions (e.g., garbage	stop processing packets while servicing other functions (e.g., garbage
	collection). Often these devices do not drop packets, but rather queue	collection). Often these devices do not drop packets, but rather queue

	them for later processing and cause many of the outliers. Thus NR-RPVD	them for later processing and cause many of the outliers. Thus NR-BPDV
	models this particular use case (assuming serial(n+1) is defined	models this particular use case (assuming serial(n+1) is defined

	appropriately for the device causing the outlier) and thus is believed	appropriately for the device causing the outlier) and is believed
	to be important for adaptation development for congestion controlled R	to be important for adaptation development for congestion-controlled R
	TP streams.</t>	TP streams.</t>
	</section>	</section>

	<section title="Recommended distribution">	<section numbered="true" toc="default">
		<name>Recommended Distribution</name>
	<t>Whether Random Bounded PDV or Approximately Random	<t>Whether Random Bounded PDV or Approximately Random
	Subject to No-Reordering Bounded PDV, it is recommended that	Subject to No-Reordering Bounded PDV, it is recommended that
	z(n) is distributed according to a truncated Gaussian for	z(n) is distributed according to a truncated Gaussian for
	the above jitter models:</t>	the above jitter models:</t>

	<t>z(n) ~ \|max(min(N(0, std^2), N_STD * std), -N_STD * std)\|</t>	<t>z(n) ~ \|max(min(N(0, std<sup>2</sup>), N_STD * std), -N_STD * std)\|<
	<t>where N(0, std^2) is the Gaussian distribution with zero mean and	/t>
	standard deviation std. Recommended values:</t>	<t>where N(0, std<sup>2</sup>) is the Gaussian distribution with zero m
	<t><list style="symbols">	ean and
	<t>std = 5 ms</t>	std is standard deviation. Recommended values:</t>
	<t>N_STD = 3</t>	<ul empty="true">
	</list></t>	<li>std = 5 ms</li>
		<li>N_STD = 3</li>
		</ul>
	</section>	</section>
	</section>	</section>
	</section>	</section>


	<!--	<section anchor="app-additional" numbered="true" toc="default">
	<section title="WiFi or Cellular Links">	<name>Traffic Models</name>
	<t>	<section numbered="true" toc="default">
	<xref target="I-D.ietf-rmcat-wireless-tests" /> describes the test	<name>TCP Traffic Model</name>
	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">
	<t>Long-lived TCP flows will download data throughout the	<t>Long-lived TCP flows will download data throughout the
	session and are expected to have infinite amount of data to	session and are expected to have infinite amount of data to
	send or receive. This roughly applies, for example, when	send or receive. This roughly applies, for example, when
	downloading software distributions.</t>	downloading software distributions.</t>


	<t>Each short TCP flow is modeled as a sequence of file downloads	<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 sam e	interleaved with idle periods. Not all short TCP flows start at the sam e
	time, i.e., some start in the ON state while others start in the OFF	time, i.e., some start in the ON state while others start in the OFF
	state.</t>	state.</t>


	<t>The short TCP flows can be modeled as follows: 30	<t>The short TCP flows can be modeled as follows: 30
	connections start simultaneously fetching small (30-50 KB)	connections start simultaneously fetching small (30-50 KB)
	amounts of data, evenly distributed. This covers the case	amounts of data, evenly distributed. This covers the case
	where the short TCP flows are fetching web page resources rather	where the short TCP flows are fetching web page resources rather
	than video files.</t>	than video files.</t>


	<t>The idle period between bursts of starting a group of TCP flows is	<t>The idle period between bursts of starting a group of TCP flows is
	typically derived from an exponential distribution with the mean value o f	typically derived from an exponential distribution with the mean value o f
	10 seconds.</t>	10 seconds.</t>

		<aside><t>These values were picked based on the data available at
	<t>[These values were picked based on the data available at	<eref target="https://httparchive.org/reports/state-of-the-web?start=2015
	http://httparchive.org/interesting.php as of October 2015].</t>	_10_01&end=2015_11_01&view=list" brackets="angle"/>
		as of October 2015.</t></aside>
	<t>	<t>
	Many different TCP congestion control schemes are deployed	Many different TCP congestion control schemes are deployed
	today. Therefore, experimentation with a range of different	today. Therefore, experimentation with a range of different

	schemes, especially including CUBIC, is encouraged.	schemes, especially including CUBIC <xref target="RFC8312"/>, is encour aged.
	Experiments must document in detail which congestion control	Experiments must document in detail which congestion control
	schemes they tested against and which parameters were used.	schemes they tested against and which parameters were used.

	</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="RTP Video model">	<name>RTP Video Model</name>
	<t>	<t>

	<xref target="RFC8593"/>	<xref target="RFC8593" format="default"/>
	describes two	describes two
	types of video traffic models for evaluating candidate algorithms for RTP congestion control.	types of video traffic models for evaluating candidate algorithms for RTP congestion control.
	The first model statistically characterizes the behavior of a video	The first model statistically characterizes the behavior of a video
	encoder, whereas the second model uses video traces.	encoder, whereas the second model uses video traces.
	</t>	</t>
	<t>	<t>

	Sample video test sequences are available at <xref	Sample video test sequences are available at <xref target="xiph-seq" fo
	target="xiph-seq"></xref>. The following two video streams	rmat="default"/>. The following two video streams
	are the recommended minimum for testing: Foreman (CIF	are the recommended minimum for testing: Foreman (CIF
	sequence) and FourPeople (720p); both come as raw video data	sequence) and FourPeople (720p); both come as raw video data
	to be encoded dynamically. As these video sequences are	to be encoded dynamically. As these video sequences are

	short (300 and 600 frames, respectively, they shall be	short (300 and 600 frames, respectively), they shall be
	stitched together repeatedly until the desired length is	stitched together repeatedly until the desired length is
	reached.	reached.

	</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Background UDP">	<name>Background UDP</name>
	<t>Background UDP flow is modeled as a constant	<t>Background UDP flow is modeled as a constant
	bit rate (CBR) flow. It will download data at a particular CBR	bit rate (CBR) flow. It will download data at a particular CBR

	rate for the complete session, or will change to particular	for the complete session, or will change to particular
	CBR rate at predefined intervals. The inter packet interval is	CBR at predefined intervals. The inter-packet interval is
	calculated based on the CBR and the packet size (is typically	calculated based on the CBR and the packet size (typically
	set to the path MTU size, the default value can be 1500 bytes).	set to the path MTU size, the default value can be 1500 bytes).

	</t>	</t>
		<t>Note that new transport protocols such as QUIC may use UDP;
	<t>Note that new transport protocols such as QUIC may use UDP	however, due to their congestion control algorithms, they will exhibit
	but, due to their congestion control algorithms, will exhibit
	behavior conceptually similar in nature to TCP flows above and	behavior conceptually similar in nature to TCP flows above and
	can thus be subsumed by the above, including the division into	can thus be subsumed by the above, including the division into

	short- and long-lived flows. As QUIC evolves independently of	short-lived and long-lived flows. As QUIC evolves independently of
	TCP congestion control algorithms, its future congestion	TCP congestion control algorithms, its future congestion
	control should be considered as competing traffic as appropriate.	control should be considered as competing traffic as appropriate.

	</t>	</t>
	</section>	</section>

	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Security Considerations">	<name>Security Considerations</name>
	<t>	<t>
	This document specifies evaluation criteria and parameters	This document specifies evaluation criteria and parameters
	for assessing and comparing the performance of congestion	for assessing and comparing the performance of congestion
	control protocols and algorithms for real-time	control protocols and algorithms for real-time
	communication. This memo itself is thus not subject to	communication. This memo itself is thus not subject to
	security considerations but the protocols and algorithms	security considerations but the protocols and algorithms
	evaluated may be. In particular, successful operation	evaluated may be. In particular, successful operation
	under all tests defined in this document may suffice for a	under all tests defined in this document may suffice for a
	comparative evaluation but must not be interpreted that	comparative evaluation but must not be interpreted that
	the protocol is free of risks when deployed on the	the protocol is free of risks when deployed on the
	Internet as briefly described in the following by example.	Internet as briefly described in the following by example.

	</t>	</t>
	<t>	<t>
	Such evaluations are expected to be	Such evaluations are expected to be
	carried out in controlled environments for limited numbers	carried out in controlled environments for limited numbers
	of parallel flows. As such, these evaluations are by	of parallel flows. As such, these evaluations are by
	definition limited and will not be able to systematically	definition limited and will not be able to systematically
	consider possible interactions or very large groups of	consider possible interactions or very large groups of
	communicating nodes under all possible circumstances, so	communicating nodes under all possible circumstances, so
	that careful protocol design is advised to avoid	that careful protocol design is advised to avoid
	incidentally contributing traffic that could lead to	incidentally contributing traffic that could lead to
	unstable networks, e.g., (local) congestion collapse.	unstable networks, e.g., (local) congestion collapse.

	</t>	</t>
	<t>	<t>
	This specification focuses on assessing the regular	This specification focuses on assessing the regular
	operation of the protocols and algorithms under	operation of the protocols and algorithms under

	considerations. It does not suggest checks against	consideration. It does not suggest checks against
	malicious use of the protocols -- by the sender, the	malicious use of the protocols -- by the sender, the
	receiver, or intermediate parties, e.g., through faked,	receiver, or intermediate parties, e.g., through faked,
	dropped, replicated, or modified congestion signals. It is	dropped, replicated, or modified congestion signals. It is
	up to the protocol specifications themselves to ensure that	up to the protocol specifications themselves to ensure that
	authenticity, integrity, and/or plausibility of received	authenticity, integrity, and/or plausibility of received

	signals are checked and the appropriate actions (or	signals are checked, and the appropriate actions (or
	non-actions) are taken.	non-actions) are taken.

	</t>	</t>
	</section>	</section>


	<section title="IANA Considerations">	<section numbered="true" toc="default">
	<t>There are no IANA impacts in this memo.</t>	<name>IANA Considerations</name>
	</section>	<t>This document has no IANA actions.</t>
		</section>


	<section anchor="contrib" title="Contributors">	</middle>
	<t>The content and concepts within this document are a product of	<back>
	the discussion carried out in the Design Team.</t>


	<t>Michael Ramalho provided the text for the Jitter model.</t>	<displayreference target="I-D.ietf-netvc-testing" to="netvc-testing"/>
	</section>


	<section title="Acknowledgments">	<references>
	<t> Much of this document is derived from previous work on	<name>References</name>
	congestion control at the IETF.</t>	<references>
	<t> The authors would like to thank	<name>Normative References</name>
	Harald Alvestrand,	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	Anna Brunstrom,	ence.RFC.3550.xml"/>
	Luca De Cicco,	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	Wesley Eddy,	ence.RFC.3551.xml"/>
	Lars Eggert,	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	Kevin Gross,	ence.RFC.3611.xml"/>
	Vinayak Hegde,	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	Randell Jesup,	ence.RFC.4585.xml"/>
	Mirja Kuehlewind,	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	Karen Nielsen,	ence.RFC.5506.xml"/>
	Piers O'Hanlon,	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	Colin Perkins,	ence.RFC.8083.xml"/>
	Michael Ramalho,	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	Zaheduzzaman Sarker,	ence.RFC.8593.xml"/>
	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>
	</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">	<!-- draft-ietf-rmcat-cc-requirements-09: 8836 -->
	&rfc5033; <!-- CC Evaluation -->	<reference anchor="RFC8836" target="https://www.rfc-editor.org/info/rfc8836">
	&rfc5166; <!-- CC Metrics -->	<front>
	<!-- &rfc5681; Standard TCP -->	<title>Congestion Control Requirements for Interactive Real-Time Media</titl
	&I-D.ietf-rmcat-eval-test;	e>
	&I-D.ietf-rmcat-wireless-tests;	<author initials="R" surname="Jesup" fullname="Randell Jesup">
	&I-D.ietf-netvc-testing;	<organization/>
	<reference anchor="gilbert-elliott">	</author>
	<front>	<author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker" role="e
	<title>The Gilbert-Elliott Model for Packet Loss in Real Tim	ditor">
	e Services on the Internet</title>	<organization/>
	<author surname="Hasslinger" fullname="Gerhard Hasslinger">	</author>
	<organization/>	<date month="July" year="2020"/>
	</author>	</front>
	<author surname="Hohlfeld" fullname="Oliver Hohlfeld">	<seriesInfo name="RFC" value="8836" />
	<organization />	<seriesInfo name="DOI" value="10.17487/RFC8836"/>
	</author>	</reference>
	<date month="3" year="2008" />
	<abstract>
	<t>The estimation of quality for real-time services over tel
	ecommunication networks requires realistic models for impairments and failures d
	uring transmission. We focus on the classical Gilbert-Elliott model whose second
	order statistics is derived over arbitrary time scales and used to fit packet l
	oss processes of traffic traces measured in the IP back- bone of Deutsche Teleko
	m. The results show that simple Markov models are appropriate to capture the obs
	erved loss pattern.
	</t></abstract>
	</front>
	<seriesInfo name="14th GI/ITG Conference - Measurement, Modellin
	g 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 Fra
	mework</title>
	<author initials="3GPP" surname="R1-081955" fullname="3GPP R
	1-081955">
	<organization />
	</author>
	<date month="5" year="2008" />
	<abstract>
	<t>In R1-081720, 3GPP SA4 has requested RAN1 and RAN2 for li
	nk
	level throughput traces to be used in an evaluation framewor
	k
	they are developing for dynamic video rate adaptation.
	</t></abstract>
	</front>
	<seriesInfo name="3GPP" value="R1-081955" />
	<format type='ZIP' octets='3459875' target='http://www.3gpp.net/
	ftp/tsg_ran/WG1_RL1/TSGR1_53/Docs/R1-081955.zip' />
	</reference>
	-->


	<!--	</references>
	<reference anchor="SA4-LR">	<references>
	<front>	<name>Informative References</name>
	<title>Error Patterns for MBMS Streaming over UTRAN and GERA	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	N</title>	ence.RFC.5033.xml"/>
	<author initials="3GPP" surname="S4-050560" fullname="3GPP S	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	4-050560">	ence.RFC.5166.xml"/>
	<organization />	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	</author>	ence.RFC.8312.xml"/>
	<date month="5" year="2008" />
	</front>
	<seriesInfo name="3GPP" value="S4-050560" />
	<format type='ZIP' octets='335322' target='http://www.3gpp.org/F
	TP/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050560.zip' />
	</reference>


	<!--	<!-- draft-ietf-rmcat-eval-test (8867) part of C238 -->
	<reference anchor="TCP-eval-suite">	<reference anchor="RFC8867" target="https://www.rfc-editor.org/info/rfc8867">
	<front>	<front>
	<title>Towards a Common TCP Evaluation Suite</title>	<title>Test Cases for Evaluating RMCAT Proposals</title>
	<author initials="A." surname="Lachlan" fullname="Andrew Lachl
	an"/>
	<author initials="C." surname="Marcondes" fullname="Cesar Marcon
	des"/>
	<author initials="S." surname="Floyd" fullname="Sally Floyd"/>
	<author initials="L." surname="Dunn" fullname="Lawrence Dunn"/>
	<author initials="R." surname="Guillier" fullname="Romeric Guil
	lier"/>
	<author initials="W." surname="Gang" fullname="Wang Gang"/>
	<author initials="L." surname="Eggert" fullname="Lars Eggert"/>
	<author initials="S." surname="Ha" fullname="Sangtae Ha"/>
	<author initials="I." surname="Rhee" fullname="Injong Rhee"/>
	<date month="August" year="2008"/>
	</front>
	<seriesInfo name="Proc. PFLDnet." value="2008"/>
	</reference>


	<reference anchor="xiph-seq">	<author initials='Z' surname='Sarker' fullname='Zaheduzzaman Sarker'>
	<front>	<organization />
	<title>Video Test Media Set</title>	</author>


	<author fullname="Daede, T." initials="T." surname="Daede"></a	<author initials='V' surname='Singh' fullname='Varun Singh'>
	uthor>	<organization />
		</author>


	<date month="" year="" />	<author initials='X' surname='Zhu' fullname='Xiaoqing Zhu'>
	</front>	<organization />
	<seriesInfo name="https://media.xiph.org/video/derf/" value="" /	</author>
	>
	</reference>


	<!-- <reference anchor="HEVC-seq">	<author initials='M' surname='Ramalho' fullname='Michael Ramalho'>
	<front>	<organization />
	<title>Test Sequences</title>	</author>


	<author fullname="" initials="" surname="HEVC"></author>	<date month='July' year='2020' />
		</front>


	<date month="" year="" />	<seriesInfo name="RFC" value="8867"/>
	</front>	<seriesInfo name="DOI" value="10.17487/RFC8867"/>
	<seriesInfo name="http://www.netlab.tkk.fi/~varun/test_sequences
	/"
	value="" />
	</reference>


	</references>	</reference>


	<!--	<!-- draft-ietf-rmcat-wireless-tests-11 (8869) part of C238 -->
	<section anchor="misc" title="Application Trade-off">	<reference anchor="RFC8869" target="https://www.rfc-editor.org/info/rfc8869">
	<t>Application trade-off is yet to be defined. see <xref	<front>
	target="I-D.ietf-rmcat-cc-requirements">RMCAT requirements</xref>	<title>Evaluation Test Cases for Interactive Real-Time Media over Wireless Netwo
	document. Perhaps each experiment should define the application's	rks</title>
	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">	<author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker">
	<t>Note to the RFC-Editor: please remove this section prior to	<organization/>
	publication as an RFC.</t>	</author>
	<section title="Changes in draft-ietf-rmcat-eval-criteria-07">
	<t>Updated the draft according to the discussion at IETF-101.</t>
	<t><list style="symbols">
	<t>Updated the discussion on fairness. Thanks to Xiaoqing Zhu for
	providing text.</t>
	<t>Fixed a simple loss model and provided pointers to more sophisti
	cated ones.</t>
	<t>Fixed the choice of the jitter model.</t>
	</list></t>
	</section>
	<section title="Changes in draft-ietf-rmcat-eval-criteria-06">
	<t><list style="symbols">
	<t>Updated Jitter.</t>
	</list></t>
	</section>
	<section title="Changes in draft-ietf-rmcat-eval-criteria-05">
	<t><list style="symbols">
	<t>Improved text surrounding wireless tests, video sequences,
	and short-TCP model.</t>
	</list></t>
	</section>
	<section title="Changes in draft-ietf-rmcat-eval-criteria-04">
	<t><list style="symbols">
	<t>Removed the guidelines section, as most of the sections
	are now covered: wireless tests, video model, etc.</t>
	<t>Improved Short TCP model based on the suggestion to use
	httparchive.org.</t>
	</list></t>
	</section>
	<section title="Changes in draft-ietf-rmcat-eval-criteria-03">
	<t><list style="symbols">
	<t>Keep-alive version.</t>
	<t>Moved link parameters and traffic models from eval-test</t>
	</list></t>
	</section>
	<section title="Changes in draft-ietf-rmcat-eval-criteria-02">
	<t><list style="symbols">
	<t>Incorporated fairness test as a working test.</t>
	<t>Updated text on mimimum evaluation requirements.</t>
	</list></t>
	</section>
	<section title="Changes in draft-ietf-rmcat-eval-criteria-01">
	<t><list style="symbols">
	<t>Removed Appendix B.</t>
	<t>Removed Section on Evaluation Parameters.</t>
	</list></t>
	</section>
	<section title="Changes in draft-ietf-rmcat-eval-criteria-00">
	<t><list style="symbols">
	<t>Updated references.</t>
	<t>Resubmitted as WG draft.</t>
	</list></t>
	</section>
	<section title="Changes in draft-singh-rmcat-cc-eval-04">
	<t><list style="symbols">
	<t>Incorporate feedback from IETF 87, Berlin.</t>
	<t>Clarified metrics: convergence time, bandwidth
	utilization.</t>
	<t>Changed fairness criteria to fairness test.</t>
	<t>Added measuring pre- and post-repair loss.</t>
	<t>Added open issue of measuring video quality to
	appendix.</t>
	<t>clarified use of DropTail and AQM.</t>
	<t>Updated text in "Minimum Requirements for Evaluation"</t>


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


	<section title="Changes in draft-singh-rmcat-cc-eval-02">	<author initials="J" surname="Fu" fullname="Jian Fu">
	<t><list style="symbols">	<organization/>
	<t>Added scenario descriptions.</t>	</author>
	</list></t>
	</section>


	<section title="Changes in draft-singh-rmcat-cc-eval-01">	<date month='July' year='2020' />
	<t><list style="symbols">
	<t>Removed QoE metrics.</t>	</front>
	<t>Changed stability to steady-state.</t>	<seriesInfo name="RFC" value="8869"/>
	<t>Added measuring impact against few and many	<seriesInfo name="DOI" value="10.17487/RFC8869"/>
	flows.</t>	</reference>
	<t>Added guideline for idle and data-limited periods.</t>
	<t>Added reference to TCP evaluation suite in example	<!-- [I-D.ietf-netvc-testing] IESG state I-D Exists (IESG: Dead) as of 2020 May
	evaluation scenarios.</t>	18.
	</list></t>	-->
	</section>
	</section>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
	</back>	rence.I-D.draft-ietf-netvc-testing-09.xml"/>

		<reference anchor="gilbert-elliott" target="https://ieeexplore.ieee.org/
		document/5755057">
		<front>
		<title>The Gilbert-Elliott Model for Packet Loss in Real Time Servic
		es on the Internet</title>
		<author surname="Hasslinger" fullname="Gerhard Hasslinger">
		<organization/>
		</author>
		<author surname="Hohlfeld" fullname="Oliver Hohlfeld">
		<organization/>
		</author>
		<date month="3" year="2008"/>
		<abstract>
		<t>The estimation of quality for real-time services over telecommu
		nication 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 pr
		ocesses 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>
		</front>
		<refcontent>14th GI/ITG Conference - Measurement, Modelling and Eval
		utation [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/de
		rf/">
		<front>
		<title>Video Test Media Set</title>
		<author fullname="Daede, T." initials="T." surname="Daede"/>
		</front>
		</reference>
		</references>
		</references>
		<section anchor="contrib" numbered="false" toc="default">
		<name>Contributors</name>
		<t>The content and concepts within this document are a product of
		the discussion carried out in the Design Team.</t>
		<t><contact fullname="Michael Ramalho"/> provided the text for the jitter
		models (<xref target="JM" format="default"/>).</t>
		</section>
		<section numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t> Much of this document is derived from previous work on
		congestion control at the IETF.</t>

		<t> The authors would like to 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 on draft versions of this document.
		Additionally, thanks to the participants of the Design Team for
		their comments and discussion related to the evaluation
		criteria.</t>
		</section>

		</back>
	</rfc>	</rfc>

End of changes. 117 change blocks.
	929 lines changed or deleted	539 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/