Diff: rfc9743xml2.original.xml

	rfc9743xml2.original.xml	rfc9743.xml

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version='1.0' encoding='UTF-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 2.
	7.4) -->


	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">


	]>	]>


	<rfc ipr="trust200902" docName="draft-ietf-ccwg-rfc5033bis-08" category="bcp" co	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	nsensus="true" submissionType="IETF" obsoletes="5033" tocInclude="true" sortRefs	-ietf-ccwg-rfc5033bis-08" number="9743" category="bcp" consensus="true" submissi
	="true" symRefs="true">	onType="IETF" obsoletes="5033" updates="" tocInclude="true" sortRefs="true" symR
		efs="true" version="3" xml:lang="en">

	<front>	<front>
	<title abbrev="New CC Algorithms">Specifying New Congestion Control Algorith ms</title>	<title abbrev="New CC Algorithms">Specifying New Congestion Control Algorith ms</title>

		<seriesInfo name="RFC" value="9743"/>
		<seriesInfo name="BCP" value="133"/>

		<!--[rfced] *ADs - As this document obsoletes RFC 5033, should it be
		added to BCP 133? We have updated as such; please let us know
		any objections. -->

		<!--[rfced] While we understand RFC 5033 was published
		with some of the text we are questioning below, the questions and
		edits are aimed at making the text as correct and useful to the reader
		as possible. Please review carefully.

		In addition, this document is in the current RFC format (a major change
		was made in 2019), so various updates have been made in the source file.
		Details are here: https://www.rfc-editor.org/pubprocess/how-we-update.
		-->

	<author initials="M." surname="Duke" fullname="Martin Duke" role="editor">	<author initials="M." surname="Duke" fullname="Martin Duke" role="editor">
	<organization>Google LLC</organization>	<organization>Google LLC</organization>
	<address>	<address>
	<email>martin.h.duke@gmail.com</email>	<email>martin.h.duke@gmail.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="G." surname="Fairhurst" fullname="Godred Fairhurst" role=" editor">	<author initials="G." surname="Fairhurst" fullname="Godred Fairhurst" role=" editor">
	<organization>University of Aberdeen</organization>	<organization>University of Aberdeen</organization>
	<address>	<address>
	<email>gorry@erg.abdn.ac.uk</email>	<email>gorry@erg.abdn.ac.uk</email>
	</address>	</address>
	</author>	</author>

		<date year="2025" month="March"/>


	<date year="2024" month="August" day="21"/>	<area>WIT</area>
		<workgroup>ccwg</workgroup>


	<area>General</area>	<!-- [rfced] Please insert any keywords (beyond those that appear in
	<workgroup>CCWG</workgroup>	the title) for use on https://www.rfc-editor.org/search.
	<keyword>Internet-Draft</keyword>	-->


	<abstract>	<keyword>example</keyword>


	<?line 99?>	<!--[rfced] Might this update to the Abstract be of interest? It
		attempts to reduce redundancy and reorganize the sentences
		slightly.


	<t>This document replaces RFC 5033, which discusses the principles and	Original:
	guidelines for standardzing new congestion control algorithms. It seeks to
	ensure that proposed congestion control algorithms operate without harm and
	efficiently alongside other algorithms in the global Internet. It emphasizes the
	need for comprehensive testing and validation to prevent adverse interactions
	with existing flows. This document provides a framework for the development and
	assessment of congestion control mechanisms, promoting stability across diverse
	network environments. It obsoletes RFC5033 to reflect changes in the congestion
	control landscape.</t>


	</abstract>	This document replaces RFC 5033, which discusses the principles and
		guidelines for standardizing new congestion control algorithms. It
		seeks to ensure that proposed congestion control algorithms operate
		without harm and efficiently alongside other algorithms in the global
		Internet. It emphasizes the need for comprehensive testing and
		validation to prevent adverse interactions with existing flows. This
		document provides a framework for the development and assessment of
		congestion control mechanisms, promoting stability across diverse
		network environments. It obsoletes RFC5033 to reflect changes in
		the congestion control landscape.


	<note title="About This Document" removeInRFC="true">	Perhaps:
	<t>
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-ccwg-rfc5033bis/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	Congestion Control Working Group (ccwg) Working Group mailing list (<ere
	f target="mailto:ccwg@ietf.org"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/ccwg/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ccwg/"/
	>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/ietf-wg-ccwg/rfc5033bis"/>.</t>
	</note>


		RFC 5033 discusses the principles and guidelines for standardizing
		new congestion control algorithms. This document obsoletes RFC
		5033 to reflect changes in the congestion control landscape by
		providing a framework for the development and assessment of
		congestion control mechanisms, promoting stability across diverse
		work environments. This document aims to describe ways that
		proposed congestion control algorithms can operate both without
		harm and efficiently alongside other algorithms in the global
		Internet. It emphasizes the need for comprehensive testing and
		validation to prevent adverse interactions with existing flows.
		-->
		<abstract>
		<t>This document replaces RFC 5033, which discusses the principles and
		guidelines for standardizing new congestion control algorithms. It seeks
		to ensure that proposed congestion control algorithms operate without
		harm and efficiently alongside other algorithms in the global
		Internet. It emphasizes the need for comprehensive testing and
		validation to prevent adverse interactions with existing flows. This
		document provides a framework for the development and assessment of
		congestion control mechanisms, promoting stability across diverse
		network environments. It obsoletes RFC 5033 to reflect changes in the
		congestion control landscape.</t>
		</abstract>
	</front>	</front>

	<middle>	<middle>

		<section anchor="introduction">
		<name>Introduction</name>


	<?line 111?>	<t>This document provides guidelines for the IETF to use when evaluating
		a proposed congestion control algorithm that differs from the general
	<section anchor="introduction"><name>Introduction</name>	congestion control principles outlined in <xref target="RFC2914"/>. The
		guidance is intended to be useful to authors proposing congestion
		control algorithms and for the IETF community when evaluating whether a
		proposal is appropriate for publication in the RFC Series and for
		deployment in the Internet.</t>


	<t>This document provides guidelines for the IETF to use when evaluating a propo	<t>This document obsoletes <xref target="RFC5033"/>, which was published
	sed	in 2007 as a Best Current Practice for evaluating proposed congestion
	congestion control algorithm that differs from the general congestion control	control algorithms for publication in Experimental or Proposed Standard RF
	principles outlined in <xref target="RFC2914"/>. The guidance is intended to be	Cs.</t>
	useful to
	authors proposing congestion control algorithms and for the IETF community when
	evaluating whether a proposal is appropriate for publication in the RFC series
	and for deployment in the Internet.</t>


	<t>This document obsoletes <xref target="RFC5033"/>, which was published in 2007	<t>The IETF specifies standard Internet congestion control algorithms in
	as a Best	the RFC Series. These congestion control algorithms can suffer
	Current Practice for evaluating proposed congestion control algorithms as	performance challenges when used in differing environments (e.g.,
	Experimental or Proposed Standard RFCs.</t>	high-speed networks, cellular and Wi-Fi wireless technologies, and
		long-distance satellite links), and also when flows carry specific
		workloads (e.g., Voice over IP (VoIP), gaming, and videoconferencing).</t>


	<t>The IETF specifies standard Internet congestion control algorithms in the RFC	<t>When <xref target="RFC5033"/> was published, TCP <xref
	-series.	target="RFC9293"/> was the primary focus of IETF congestion control
	These congestion control algorithms can suffer performance challenges when used	efforts, with proposals typically discussed within the Internet
	in	Congestion Control Research Group (ICCRG). Concurrently, the Datagram
	differing environments (e.g., high-speed networks, cellular and WiFi wireless	Congestion Control Protocol (DCCP) <xref target="RFC4340"/> was
	technologies, and long distance satellite links), and also when flows carry	developed to define new congestion control algorithms for datagram
	specific workloads (Voice over IP (VoIP), gaming, and videoconferencing).</t>	traffic, while the Stream Control Transmission Protocol (SCTP) <xref
		target="RFC9260"/> reused TCP congestion control algorithms.</t>


	<t>When <xref target="RFC5033"></xref> was published in 2007, TCP [RFC9293] was	<t>Since then, several changes have occurred. The range of protocols
	the primary focus of	utilizing congestion control algorithms has expanded to include QUIC
	IETF congestion control efforts, with proposals typically discussed within the	<xref target="RFC9000"/> and RTP Media Congestion Avoidance Techniques
	Internet Congestion Control Research Group (ICCRG). Concurrently, the Datagram	(RMCAT) (e.g., <xref target="RFC8836"/>). Additionally, some alternative
	Congestion Control Protocol (DCCP) [RFC4340] was developed to define new	congestion control algorithms have been tested and deployed at scale
	congestion control algorithms for datagram traffic, while the Stream Control	without full IETF review. There is increased interest in specialized use
	Transmission Protocol (SCTP) [RFC9260] reused TCP congestion control algorithms.	cases, such as data centers (e.g., <xref target="RFC8257"/>), and in
	</t>	supporting a variety of upper-layer protocols and applications, such as
		real-time protocols. Moreover, the community has gained significant
		experience with congestion indications beyond packet loss.</t>


	<t>Since then, several changes have occurred. The range of protocols utilizing	<t>Multicast congestion control is a considerably less mature field of
	congestion control algorithms has expanded to include QUIC [RFC9000] and RTP	study and is not in the scope of this document. However, <xref
	Media Congestion Avoidance Techniques (RMCAT) (e.g., <xref target="RFC8836"></xr	section="4" sectionFormat="of" target="RFC8085"/> provides additional
	ef>. Additionally,	guidelines for multicast and broadcast usage of UDP.</t>
	some alternative congestion control algorithms have been tested and deployed
	at scale without full IETF review. There is increased interest in specialized
	use cases, such as data centers (e.g., [RFC8257], and in supporting a variety of
	upper layer protocols and applications, such as real-time protocols. Moreover,
	the community has gained significant experience with congestion indications
	beyond packet loss.</t>


	<t>Multicast congestion control is a considerably less mature field of study and	<t>Congestion control algorithms have been developed outside of the
	is not in the scope of this document. However, <xref section="4" sectionFormat="	IETF, including at least two that saw large scale deployment. These
	of" target="RFC8085"/> provides	include CUBIC <xref target="HRX08"/> and Bottleneck Bandwidth and
	additional guidelines for multicast and broadcast usage of UDP.</t>	Round-trip propagation time (BBR) <xref
		target="I-D.cardwell-iccrg-bbr-congestion-control"/>.</t>


	<t>Congestion control algorithms have been developed outside of the IETF, includ	<!-- [rfced] We note that [HRX08] states it was published in 2008. May
	ing	we update the text below accordingly?
	at least two that saw large scale deployment: CUBIC <xref target="HRX08"/> and B
	ottleneck
	Bandwidth and Round-trip propagation time (BBR) <xref target="BBR-draft"/>.</t>


	<t>CUBIC was documented in a research publication in 2007 <xref target="HRX08"/>	Original:
	, and was then	CUBIC was documented in a research publication in 2007 [HRX08], and
	adopted as the default congestion control algorithm for the TCP implementation	was then adopted as the default congestion control algorithm for
	in Linux. It was already used in a significant fraction of TCP connections over	the TCP implementation in Linux.
	the Internet before being documented in an Informational Internet-Draft in
	2015, published as an Informational RFC in 2017 as <xref target="RFC8312"/> and
	then as a
	Proposed Standard in 2023 <xref target="RFC9438"/>.</t>


	<t>At the time of writing, BBR is being developed as an internal research projec	Perhaps:
	t	CUBIC was documented in a research publication in 2008 [HRX08], and
	by Google, with the first implementation contributed to Linux kernel 4.19 in	was then adopted as the default congestion control algorithm for
	2016. It was described in an IRTF Internet-Draft in 2018, and that Internet-	the TCP implementation in Linux.
	Draft is regularly updated to document the evolving versions of the algorithm
	<xref target="BBR-draft"/>. BBR is currently widely used for Google services usi
	ng either
	TCP or QUIC, and is also widely deployed outside of Google.</t>


	<t>We cannot say now whether the original authors of <xref target="RFC5033"/> ex	-->
	pected that
	developers would be waiting for IETF review before widely deploying a
	new congestion control algorithm over the Internet, but the examples of CUBIC
	and BBR teach us that deployment of new algorithms is not, in fact, gated by the
	publication of the algorithm as an RFC.</t>


	<t>Nevertheless, a specification for a congestion control algorithm provides a n	<!--[rfced] Would one of the following suggestions be agreeable in
	umber of	order to clarify this document's journey?
	advantages:</t>


	<t><list style="symbols">	Original:
	<t>It can help implementers, operators, and other interested parties	It was already used in a significant fraction of TCP connections over
	develop a shared understanding of how the algorithm works and how it is	the Internet before being documented in an Informational
	expected to behave in various scenarios and configurations.</t>	Internet-Draft in 2015, published as an Informational RFC in 2017 as
	<t>It can help potential contributors understand the algorithm,	[RFC8312] and then as a Proposed Standard in 2023 [RFC9438].
	which can make it easier for them to suggest improvements and/or identify
	limitations. Furthermore, the specification can help multiple contributors
	align on a consensus change to the algorithm.</t>
	<t>A specification that is accessible to anyone can circumvent the issue that
	some implementers may be unable to read open source reference implementations
	due to the constraints of some open source licenses.</t>
	</list></t>


	<t>Beyond helping develop specific algorithm proposals, guidelines can also serv	Perhaps A:
	e	It was already used in a significant
	as a reminder to potential inventors and developers of the multiple facets of	fraction of TCP connections over the Internet before being published as an
	the congestion control problem.</t>	Informational RFC in 2017 as [RFC8312] and then as a Proposed
		Standard in 2023 [RFC9438].


	<t>The evaluation guidelines in this document are intended to be consistent with	Perhaps B:
	the congestion control principles from <xref target="RFC2914"/> of preventing co	It was already used in a significant fraction of TCP connections over
	ngestion	the Internet before being documented in an Internet-Draft with the
	collapse, considering fairness, and optimizing a flow's own performance in terms	intended status of Informational in 2015, published as an
	of throughput, delay, and loss. <xref target="RFC2914"/> also discusses the goal	Informational RFC in 2017 as [RFC8312], and then published as a
	of avoiding	Proposed Standard in 2023 [RFC9438].
	a congestion control "arms race" among competing transport protocols.</t>	-->


	<t>This document does not give hard-and-fast requirements for an appropriate	<t>CUBIC was documented in a research publication in 2007 <xref
	congestion control algorithm. Rather, the document provides a set of criteria	target="HRX08"/>, and was then adopted as the default congestion control
	that should be considered and weighed by the developers of alternative	algorithm for the TCP implementation in Linux. It was already used in a
	algorithms and by the IETF in the context of each proposal.</t>	significant fraction of TCP connections over the Internet before being
		documented in an Informational Internet-Draft in 2015, published as an
		Informational RFC in 2017 as <xref target="RFC8312"/> and then as a
		Proposed Standard in 2023 <xref target="RFC9438"/>.</t>


	<t>The high-order criterion for advancing any proposal within the IETF is a seri	<!--[rfced] Note that we have removed "IRTF" from the following text.
	ous	It doesn't appear to us that an IRTF RG adopted this draft (we
	scientific study of the pros and cons that occurs when the proposal is	see the first two versions as individual submissions and the last
	considered for publication by the IETF, or before it is deployed at large scale.	as an IETF document). Please review.
	</t>


	<t>After initial studies, authors are encouraged to write a specification of the	Original:
	ir	It was described in an IRTF Internet-Draft in 2018, and that
	proposal for publication in the RFC series. This allows others to understand and	Internet-Draft is regularly updated to document the
	investigate the wealth of proposals in this space.</t>	evolving versions of the algorithm [BBR-draft].


	<t>This document is intended to reduce the barriers to entry for new congestion	Current:
	control work to the IETF. As such, proponents of new congestion control	It was described in an Internet-Draft in 2018, which has been
	algorithms ought not to interpret these criteria as a checklist of requirements	regularly updated to document the evolving versions of the algorithm
	before approaching the IETF. Instead, proponents are encouraged to think about	[BBR].
	these issues beforehand, and have the willingness to do the work implied by the	-->
	remainder of this document.</t>


	</section>	<t>At the time of writing, BBR is being developed as an internal
	<section anchor="specification-of-requirements"><name>Specification of Requireme	research project by Google, with the first implementation contributed to
	nts</name>	Linux kernel 4.19 in 2016. It was described in an Internet-Draft in
		2018, which has been regularly updated to document the
		evolving versions of the algorithm <xref
		target="I-D.cardwell-iccrg-bbr-congestion-control"/>. BBR is currently
		widely used for Google services using either TCP or QUIC and is also
		widely deployed outside of Google.</t>


	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",	<t>We cannot say whether the original authors of <xref
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this	target="RFC5033"/> expected that developers would be waiting for IETF
	document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <	review before widely deploying a new congestion control algorithm over
	xref target="RFC8174"/>	the Internet, but the examples of CUBIC and BBR illustrate that deployment
	when, and only when, they appear in all capitals, as shown here.</t>	of new algorithms is not, in fact, gated by the publication of the
		algorithm as an RFC.</t>


	</section>	<!-- [rfced] May we update the third bullet below for consistency with
	<section anchor="guidelines-for-authors"><name>Guidelines for Authors</name>	the other bulleted items?


	<section anchor="guidelines-for-authors-about-evaluation"><name>Guidelines for A uthors about Evaluation</name>	Original:


	<t>This document does not specify specific evaluation methods, short of internet	Nevertheless, a specification for a congestion control algorithm
	-scale deployment and measurement, to test the criteria described below. There a	provides a number of advantages:
	re multiple possible approaches to evaluation. Each has a role, and the most app
	ropriate approach depends on the criteria being evaluated and the maturity of th
	e specification.</t>


	<t>For many algorithms, an initial evaluation will consider individual protocol	* It can help implementers, operators, and other interested parties
	mechanisms in a simulator to analyse their stability and safety across a wide ra	develop a shared understanding of how the algorithm works and how
	nge of conditions, including overload. For example, <xref target="RFC8869"/> de	it is expected to behave in various scenarios and configurations.
	scribes evaluation test cases for interactive real-time media over wireless netw
	orks. Such results could also be published or discussed in IRTF research groups,
	such as ICCRG and MAPRG.</t>


	<t>Before a proposed congestion control algorithm is published as an Experimenta	* It can help potential contributors understand the algorithm, which
	l	can make it easier for them to suggest improvements and/or
	or Standards Track RFC, the community SHOULD gain practical experience with	identify limitations. Furthermore, the specification can help
	implementation and experience using the algorithm. Where there is implementation	multiple contributors align on a consensus change to the
	by independent teams, this can help provide assurance that a specification has	algorithm.
	avoided assumptions or ambiguity. An independent evaluation by multiple teams
	helps provide assurance that the design meets the evaluation criteria, and can
	assess typical interactions with other traffic. This evaluation could use an
	emulated laboratory environment or a controlled experiment (within a limited
	domain or at Internet-scale). Evidence of results is normally considered by the
	working group in deciding if a specification is ready for publication and ought
	to be documented in any request for the working group to publish the
	specification.</t>


	<t>Publication might occur without multiple implementations if a single	* A specification that is accessible to anyone can circumvent the
	implementation is widely used, open source, and shown to have positive impact on	issue that some implementers may be unable to read open source
	the Internet, particularly if the target status is Experimental.</t>	reference implementations due to the constraints of some open
		source licenses.


	</section>	Perhaps:
	<section anchor="guidelines-for-authors-about-document-status"><name>Guidelines
	for Authors about Document Status</name>


	<t>This document applies to proposals for congestion control algorithms that	Nevertheless, a specification for a congestion control algorithm
	seek Experimental or Standards Track status. Evaluation of both cases involves	provides a number of advantages:
	the same questions, but with different expectations for both the answers and the
	degree of certainty of those answers.</t>


	<t>Congestion control algorithms without empirical evidence of Internet-scale	...
	deployment MUST seek Experimental status, unless they are not targeted at
	general use.</t>


	<t>Specifications published as Experimental ought to explain the reason for	* It can help (by being accessible to anyone) to circumvent the issue that
	the status and what further information would be required to progress to	some implementers may be unable to read open-source reference
	standards track. For example, section 12 of <xref target="RFC6928"/> provides	implementations due to the constraints of some open-source licenses.
	“Usage and Deployment Recommendations” that describe the experiments
	expected by the TCPM working group. Section 4 of <xref target="RFC4614"/> provid
	es other
	examples of extensions that were considered experimental
	when the specification was published.</t>


	<t>Experimental specifications SHOULD NOT be deployed as a default. They SHOULD	-->
	only be deployed in situations where they are being actively measured, and where
	it is possible to deactivate them if there are signs of pathological behavior.</
	t>


	<t>Congestion control algorithms with a	<t>Nevertheless, a specification for a congestion control algorithm
	record of measured Internet-scale deployment MAY directly seek the Standards	provides a number of advantages:</t>
	Track if there is solid data that reflects that it is safe, and the design is	<ul spacing="normal">
	stable, guided by the considerations in <xref target="general-use"/>. However, t	<li>
	he existence	<t>It can help implementers, operators, and other interested parties
	of this data does not waive the other considerations in this document.</t>	develop a shared understanding of how the algorithm works and how it
		is expected to behave in various scenarios and configurations.</t>
		</li>
		<li>
		<t>It can help potential contributors understand the algorithm,
		which can make it easier for them to suggest improvements and/or
		identify limitations. Furthermore, the specification can help
		multiple contributors align on a consensus change to the
		algorithm.</t>
		</li>
		<li>
		<t>A specification that is accessible to anyone can circumvent the
		issue that some implementers may be unable to read open-source
		reference implementations due to the constraints of some open-source
		licenses.</t>
		</li>
		</ul>
		<t>Beyond helping develop specific algorithm proposals, guidelines can
		also serve as a reminder to potential inventors and developers of the
		multiple facets of the congestion control problem.</t>


	<t>Each published congestion control algorithm is REQUIRED to include a statemen	<t>The evaluation guidelines in this document are intended to be
	t	consistent with the congestion control principles from <xref
	in the abstract indicating whether or not there is IETF consensus that the	target="RFC2914"/> related to preventing congestion collapse, considering
	proposed congestion control algorithm is considered safe for use on the	fairness, and optimizing a flow's own performance in terms of
	Internet. Each published algorithm is also REQUIRED to include a statement in	throughput, delay, and loss. <xref target="RFC2914"/> also discusses the
	the abstract describing environments where the protocol is not recommended for	goal of avoiding a congestion control "arms race" among competing
	deployment. There can be environments where the congestion control algorithm is	transport protocols.</t>
	deemed safe for use, but it is still is not recommended for use because it
	does not perform well for the user.</t>


	<t>As examples of such statements, <xref target="RFC3649"/> specifies HighSpeed	<t>This document does not give hard-and-fast requirements for an
	TCP and	appropriate congestion control algorithm. Rather, the document provides
	includes a statement in the abstract stating that the proposed congestion	a set of criteria that should be considered and weighed by the
	control algorithm is Experimental, but may be deployed in the Internet. In	developers of alternative algorithms and by the IETF in the context of
	contrast, the Quick-Start document <xref target="RFC4782"/> includes a paragraph	each proposal.</t>
	in the
	abstract stating that the mechanism is only being proposed for use in
	controlled environments. The abstract specifies environments where the
	Quick-Start request could give false positives (and therefore would be unsafe fo
	r
	incremental deployment where some routers forward, but do not process the
	option). The abstract also specifies environments where packets containing the
	Quick-Start request could be dropped in the network; in such an environment,
	Quick-Start would not be unsafe to deploy, but deployment is not recommended
	because it could lead to unnecessary delays for the connections attempting to
	use Quick-Start. The Quick-Start method is discussed as an example in
	<xref target="RFC9049"/>.</t>


	<t>Strictly speaking, Informational RFCs in the IETF stream need not meet all of	<t>The high-order criterion for advancing any proposal within the IETF
	the criteria in this document, as they do not carry a formal recommendation	is a serious scientific study of the pros and cons that occur when the
	from the community. Instead, the community judges the publication of	proposal is considered for publication by the IETF or before it is
	Informational RFCs based on the value of their addition to the RFC series.</t>	deployed at a large scale.</t>


	<t>Although out of the scope of this document, proponents of a new algorithm cou	<t>After initial studies, authors are encouraged to write a
	ld	specification of their proposal for publication in the RFC Series. This
	alternatively seek publication as an Informational or Experimental RFC via the	allows others to understand and investigate the wealth of proposals in
	Internet Research Task Force (IRTF). In general, these algorithms are expected	this space.</t>
	to be less mature than ones that follow the procedures in this document. Authors
	documenting deployed congestion control algorithms that cannot be changed by
	IETF or IRTF review are invited to seek publication as an Informational RFC via
	the Independent Stream Editor (ISE).</t>


	</section>	<t>This document is intended to reduce the barriers to entry for new
	</section>	congestion control work to the IETF. As such, proponents of new
	<section anchor="controlled-environments"><name>Specifying Algorithms for Use in	congestion control algorithms ought not to interpret these criteria as a
	Controlled Environments</name>	checklist of requirements before approaching the IETF. Instead,
		proponents are encouraged to think about these issues beforehand and
		have the willingness to do the work implied by the remainder of this
		document.</t>
		</section>


	<t>Algorithms can be designed for general Internet deployment or for use in	<section anchor="specification-of-requirements">
	controlled environments <xref target="RFC8799"/>. Within a controlled environmen	<name>Specification of Requirements</name>
	t,	<t>
	an operator can ensure that flows	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	are isolated from other Internet flows, or they might	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	allow these flows to share resources with other Internet flows.	",
	A data center is an example of a controlled environment, which often deploys	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	fabrics with rich signalling from switches to endpoints.</t>	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be
		interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
		target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
		</t>
		</section>


	<t>Algorithms that	<section anchor="guidelines-for-authors">
	rely on specific functions or configurations in the network need to provide a	<name>Guidelines for Authors</name>
	reference or specification for these functions (an RFC or another stable	<section anchor="guidelines-for-authors-about-evaluation">
	specification). For publication to proceed, the IETF will need to assess whether	<name>Evaluation Guidelines</name>
	a working group exists that can properly assess the network-layer aspects and	<t>This document does not provide specific evaluation methods, short
	their interaction with the congestion control.</t>	of Internet-scale deployment and measurement, to test the criteria
		described below. There are multiple possible approaches to
		evaluation. Each has a role, and the most appropriate approach depends
		on the criteria being evaluated and the maturity of the
		specification.</t>


	<t>In evaluating a new proposal for use in a controlled environment, the IETF ne	<t>For many algorithms, an initial evaluation will consider individual
	eds	protocol mechanisms in a simulator to analyze their stability and
	to understand the usage, e.g., how the usage is scoped to the controlled	safety across a wide range of conditions, including overload. For
	environment, whether the algorithm will share resources with Internet traffic,	example, <xref target="RFC8869"/> describes evaluation test cases for
	and consider what could happen if used in a protocol that is bridged across an	interactive real-time media over wireless networks. Such results could
	Internet path. Algorithms that are designed to be confined to a controlled	also be published or discussed in IRTF research groups, such as ICCRG
	environment and are not intended for use in the general Internet, might instead	and MAPRG.</t>
	seek real-world data for those environments. In such cases, the evaluation
	criteria in the remainder of this document might not apply.</t>


	</section>	<!--[rfced] Might this update reduce redundancy?
	<section anchor="evaluation-criteria"><name>Evaluation Criteria</name>


	<t>As previously noted, authors are expected to conduct a comprehensive evaluati	Original:
	on	Evidence of results is normally considered by the working group in
	of the advantages and disadvantages of congestion control algorithms presented	deciding if a specification is ready for publication and ought to be
	to the IETF. The following guidelines are intended to assist authors and the	documented in any request for the working group to publish the
	IETF community in this endeavor. While these guidelines provide a helpful	specification.
	framework, they should not be regarded as an exhaustive checklist, as concerns
	beyond the scope of these guidelines may also arise.</t>


	<t>When considering a proposed congestion control algorithm, the community MUST	Perhaps:
	consider the following criteria. These criteria will be evaluated in various	Any request for a working group to consider a specification for
	domains (see <xref target="general-use"/> and <xref target="special-cases"/>).</	publication ought to document evidence of results.
	t>


	<t>Some of the sections below will list criteria that SHOULD be met. It could	-->
	happen that these criteria are not in fact met by the proposal. In such cases,
	the community MUST document whether not meeting the criteria is acceptable, for
	example because there are practical limitations on carrying out an evaluation of
	the criteria.</t>


	<t>The requirement that the community consider a criterion does not imply that t	<t>Before a proposed congestion control algorithm is published as an
	he	Experimental or Standards Track RFC, the community
	result needs to be described in a resulting RFC. There is no formal requirement	<bcp14>SHOULD</bcp14> gain practical experience with implementations
	to document the results, although normal IETF policies for archiving proceedings	and experience using the algorithm. Implementations by independent
	will provide a record.</t>	teams can help provide assurance that a specification has avoided
		assumptions or ambiguity. An independent evaluation by multiple teams
		helps provide assurance that the design meets the evaluation criteria
		and can assess typical interactions with other traffic. This
		evaluation could use an emulated laboratory environment or a
		controlled experiment (within a limited domain or at the
		Internet scale). Evidence of results is normally considered by the
		working group in deciding if a specification is ready for publication
		and ought to be documented in any request for the working group to
		publish the specification.</t>


	<t>This document, except where otherwise noted, does not provide normative guida	<!--[rfced] May we make this update for accuracy/clarity?
	nce
	on the acceptable thresholds for any of these criteria. Instead, the community
	will use these evaluations as an input when considering whether to progress the
	proposed algorithm.</t>


	<section anchor="single-algorithm-behavior"><name>Single Algorithm Behavior</nam	Original:
	e>	Publication might occur without multiple implementations if a single
		implementation is widely used, open source, and shown to have
		positive impact on the Internet, particularly if the target status is
		Experimental.


	<t>The criteria in this section evaluate the congestion control algorithm when o	Perhaps:
	ne	A congestion control algorithm without multiple implementations
	or more flows using that algorithm share a bottleneck link (i.e., with no flows	might still be published as an RFC if a single implementation is
	using a differing congestion control algorithm).</t>	widely used, open source, and shown to have a positive impact on
		the Internet, particularly if the target status is Experimental.
		-->


	<section anchor="protection-against-congestion-collapse"><name>Protection Agains	<t>Publication might occur without multiple implementations if a
	t Congestion Collapse</name>	single implementation is widely used, open source, and shown to have
		a positive impact on the Internet, particularly if the target status is
		Experimental.</t>
		</section>


	<t>A congestion control algorithm should either stop sending when the packet dro	<!--[rfced] Please carefully review our updates to Section 3.2. As
	p	much of this section is about RFCs themselves and the publication
	rate exceeds some threshold <xref target="RFC3714"/>, or should include some not	process, we have made a number of changes to attempt to improve
	ion of "full	clarity and to align the style of terminology with past RFCs and
	backoff". For "full backoff", at some point the algorithm would reduce the	in-house guidance on such topics. Please let us know any
	sending rate to one packet per round-trip time and then exponentially backoff	objections or further updates to be made. -->
	the time between single packet transmissions if the congestion persists. Exactly
	when either "full backoff" or a pause in sending comes into play will be
	algorithm-specific. However, as discussed in <xref target="RFC2914"/> and <xref
	target="RFC8961"/>,
	this requirement is crucial to protect the network in times of extreme
	(persistent) congestion.</t>


	<t>If full backoff is used, this test does not require that the mechanism must b	<section anchor="guidelines-for-authors-about-document-status">
	e	<name>Document-Status Guidelines</name>
	identical to that of TCP (<xref target="RFC6298"/>, <xref target="RFC8961"/>). F
	or example, this does
	not preclude full backoff mechanisms that would give flows with different round-
	trip times comparable capacity during backoff.</t>


	</section>	<t>The guidelines in this document apply to specifications of congestion
	<section anchor="protection-against-bufferbloat"><name>Protection Against Buffer	control
	bloat</name>	algorithms that seek publication as an RFC via the IETF Stream with an E
		xperimental or Standards Track
		status. The evaluation of either status involves the same questions, but
		with
		different expectations for both the answers and the degree of
		certainty of those answers.</t>


	<t>A congestion control algorithm should try to avoid maintaining excessive queu	<!--[rfced] This text left us wondering what happens to algorithms
	es	that are not targeted at general use? What status can they seek?
	in the network. Exactly how the algorithm achieves this is algorithm-specific,	Perhaps further info would be helpful to the reader?
	but see <xref target="RFC8961"/> and <xref target="RFC8085"/> for requirements.<
	/t>


	<t>Bufferbloat <xref target="Bufferbloat"/> refers to the building of excessive	Original:
	queues in the	Congestion control algorithms without empirical evidence of
	network. Many network routers are configured with very large buffers. The	Internet-scale deployment MUST seek Experimental status, unless they
	standards-track Reno <xref target="RFC5681"/> and CUBIC <xref target="RFC9438"/>	are not targeted at general use.
	congestion control
	algorithms send at progressively higher rates until a First-In First-Out (FIFO)
	buffer completely fills, and packet losses then occur. Every connection passing
	through that bottleneck experiences increased latency due to the high buffer
	occupancy. This adds unwanted latency that negatively impacts highly interactive
	applications such as videoconferencing or games, but it also affects routine web
	browsing and video playing.</t>


	<t>This problem has been widely discussed since 2011 <xref target="Bufferbloat"/	-->
	>, but was not
	discussed in the Congestion Control Principles published in September 2002
	<xref target="RFC2914"/>. The Reno and CUBIC congestion control algorithms do no
	t address
	this problem, but a new congestion control algorithm has the opportunity to impr
	ove the
	state of the art.</t>


	</section>	<t>Specifications on congestion control algorithms without empirical evi
	<section anchor="protection-against-high-packet-loss"><name>Protection Against H	dence of
	igh Packet Loss</name>	Internet-scale deployment <bcp14>MUST</bcp14> seek Experimental
		status, unless they are not targeted for general use.</t>


	<t>A congestion control algorithm should try to avoid causing excessively high	<!--[rfced] In the following, we assume that RFC 4614 should remain as
	rates of packet loss. To accomplish this, it should avoid excessive increases in	the cited document even though it has been obsoleted.
	sending rate, and reduce its sending rate if experiencing high packet loss.</t>	Please note that we have added mention of the obsoleting document
		as well as an Informative References entry for the ease of the
		reader.


	<t>The first version of the BBR algorithm <xref target="BBRv1-draft"/> failed th	Original:
	is requirement.	Section 4 of [RFC4614] provides other examples of extensions that were
	Experimental evaluation <xref target="BBRv1-Evaluation"/> showed that it caused	considered experimental when the specification was
	a sustained	published.
	rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer
	size was less than roughly one and a half times the Bandwidth Delay Product
	(BDP). This was unsatisfactory, and indeed further versions provided a fix for t
	his
	aspect of BBR <xref target="BBR-draft"/>.</t>


	<t>This requirement does not imply that the algorithm should react to packet los	Current:
	ses	Section 4 of [RFC4614] provides other examples of extensions that were
	in exactly the same way as current standards-track congestion control algorithms	considered experimental when the specification was
	(e.g., <xref target="RFC5681"/>).</t>	published (note that [RFC4614] has since been obsoleted by
		[RFC7414]).
		-->


	</section>	<t>Specifications that seek to be published as Experimental IETF Stream
	<section anchor="fairness-within-the-proposed-congestion-control-algorithm"><nam	RFCs ought to explain the
	e>Fairness within the Proposed Congestion Control Algorithm</name>	reason for the status and what further information would be required
		to progress to a Standards Track RFC. For example, <xref target="RFC6928
		"
		section="12" sectionFormat="of"/> provides "Usage and Deployment
		Recommendations" that describe the experiments expected by the TCPM
		Working Group. <xref target="RFC4614" section="4" sectionFormat="of"/>
		provides other examples of extensions that were considered
		experimental when the specification was published (note that <xref targe
		t="RFC4614" format="default"/> has since been obsoleted by <xref target="RFC7414
		" format="default"/>).</t>


	<t>When multiple competing flows all use the same proposed congestion control	<t>Experimental specifications <bcp14>SHOULD NOT</bcp14> be deployed
	algorithm, the proposal should explore how the capacity is shared among the	as a default. They <bcp14>SHOULD</bcp14> only be deployed in
	competing flows. Capacity fairness can be important when a small number of	situations where they are being actively measured and where it is
	similar flows compete to fill a bottleneck. However, it can also not be useful,	possible to deactivate them if there are signs of pathological
	for example, when comparing flows that seek to send at different rates, or if	behavior.</t>
	some of the flows do not last sufficiently long to approach asymptotic behavior.
	</t>


	</section>	<t>Specifications on congestion control algorithms with a record of meas
	<section anchor="short-flows"><name>Short Flows</name>	ured
		Internet-scale deployment <bcp14>MAY</bcp14> directly seek
		Standards Track status if there is solid data that reflects that the alg
		orithm is safe
		and the design is stable, guided by the considerations in <xref
		target="general-use"/>. However, the existence of this data does not
		waive the other considerations in this document.</t>
		<t>Each specification submitted for publication as an RFC is
		<bcp14>REQUIRED</bcp14> to include a statement in the abstract
		indicating whether or not there is IETF consensus that the proposed
		congestion control algorithm is considered safe for use on the
		Internet. Each such specification is also <bcp14>REQUIRED</bcp14> to
		include a statement in the abstract describing environments where the
		protocol is not recommended for deployment. There can be environments
		where the congestion control algorithm is deemed safe for use, but it
		is still not recommended for use because it does not perform well
		for the user.</t>


	<t>A great deal of congestion control analysis concerns the steady-state behavio	<t>Examples of such statements exist in <xref target="RFC3649"/>, which
	r	specifies
	of long flows. However, many Internet flows are relatively short-lived.	HighSpeed TCP and includes a statement in the abstract stating that
	Many short-lived flows today remain in the "slow	the proposed congestion control algorithm is experimental but may be
	start" mode of operation <xref target="RFC5681"/> that commonly features exponen	deployed in the Internet. In contrast, the Quick-Start document <xref
	tial	target="RFC4782"/> includes a paragraph in the abstract stating that
	congestion window growth because the flow	the mechanism is only being proposed for use in controlled
	never experiences congestion (e.g., packet loss).</t>	environments. The abstract specifies environments where the
		Quick-Start request could give false positives (and therefore would be
		unsafe for incremental deployment where some routers forward but do
		not process the option). The abstract also specifies environments
		where packets containing the Quick-Start request could be dropped in
		the network; in such an environment, Quick-Start would not be unsafe
		to deploy, but deployment is not recommended because it could lead to
		unnecessary delays for the connections attempting to use
		Quick-Start. The Quick-Start method is discussed as an example in
		<xref target="RFC9049"/>.</t>


	<t>A proposed congestion control algorithm MUST consider how new and short-lived	<t>Strictly speaking, documents for publication as Informational RFCs fr
	flows affect long-lived flows, and vice versa.</t>	om the IETF Stream need not
		meet all of the criteria in this document, as they do not carry a
		formal recommendation from the IETF community. Instead, the community
		judges the publication of these Informational RFCs based on the value of
		their addition to the information captured by the RFC Series.</t>


	</section>	<t>Although it is out of scope for this document, proponents of a new
	</section>	algorithm could alternatively seek publication of their specification as
	<section anchor="mixed-algorithm-behavior"><name>Mixed Algorithm Behavior</name>	an Informational or
		Experimental RFC via the Internet Research Task Force (IRTF) Stream. In
		general, these algorithms are expected to be less mature than ones
		that follow the procedures in this document for publication via the IETF
		Stream. Authors documenting
		deployed congestion control algorithms that cannot be changed by IETF
		or IRTF review are invited to seek publication of their specification as
		an Informational RFC
		via the Independent Submission Stream.</t>
		</section>
		</section>


	<t>Mixed algorithm behavior criteria evaluate the interaction of the proposed	<section anchor="controlled-environments">
	congestion control algorithm with commonly deployed congestion control	<name>Specifying Algorithms for Use in Controlled Environments</name>
	algorithms.</t>	<t>Algorithms can be designed for general Internet deployment or for use
		in controlled environments <xref target="RFC8799"/>. Within a controlled
		environment, an operator can ensure that flows are isolated from other
		Internet flows or they might allow these flows to share resources with
		other Internet flows. A data center is an example of a controlled
		environment that often deploys fabrics with rich signaling from
		switches to endpoints.</t>


	<t>In contexts where differing congestion control algorithms are used, it is	<t>Algorithms that rely on specific functions or configurations in the
	important to understand whether the proposed congestion control algorithm could	network need to provide a reference or specification for these functions
	result in more harm than previous standards-track algorithms (e.g.,	(such as an RFC or another stable specification). For publication of a spe
	<xref target="RFC5681"/>, <xref target="RFC9002"/>, <xref target="RFC9438"/>) to	cification of one of these algorithms to proceed,
	flows sharing a common bottleneck.	the IETF will need to consider whether a working group exists that can
	The measure of harm is not restricted to unequal capacity, but ought also to	properly assess the network-layer aspects and their interaction with the
	consider metrics such as the introduced latency, or an increase in packet loss.	congestion control.</t>
	An evaluation MUST assess the potential to cause starvation, including
	assurance that a loss of all feedback (e.g., detected by expiry of a
	retransmission time out) results in backoff.</t>


	<section anchor="existing-general-purpose-congestion-control"><name>Existing Gen eral-Purpose Congestion Control</name>	<!-- [rfced] For readability, may we update this sentence as follows?


	<t>A proposed congestion control algorithm MUST be evaluated when competing agai	Original:
	nst	In evaluating a new proposal for use in a controlled environment,
	standard IETF congestion controls, e.g. <xref target="RFC5681"/>, <xref target="	the IETF needs to understand the usage, e.g., how the usage is
	RFC9002"/>,	scoped to the controlled environment, whether the algorithm will
	<xref target="RFC9438"/>. A proposed congestion control algorithm that has a sig	share resources with Internet traffic, and consider what could
	nificantly	happen if used in a protocol that is bridged across an Internet
	negative impact on flows using standard congestion control might be suspect, and	path.
	this aspect should be part of the community's decision making with regards to
	the suitability of the proposed congestion control algorithm. The community
	should also consider other non-standard congestion control algorithms that are
	known to be widely deployed.</t>


	<t>Note that this guideline is not a requirement for strict Reno- or CUBIC-	Perhaps:
	friendliness as a prerequisite for a proposed congestion control mechanism to	In evaluating a new proposal for use in a controlled environment,
	advance to Experimental or Standards Track status. As an example, HighSpeed TCP	the IETF community needs to understand the usage (e.g., how the usage is
	is a congestion control mechanism specified as Experimental, that is not TCP-	scoped to the controlled environment), whether the algorithm will
	friendly in all environments. When a new congestion control algorithm is	share resources with Internet traffic, and what could
	deployed, the existing major algorithm deployments need to be considered to	happen if used in a protocol that is bridged across an Internet
	avoid severe performance degradation. Note that this guideline does not	path.
	constrain the interaction with non-best-effort flows.</t>


	<t>As an example from an Experimental RFC, fairness with standard TCP is discuss	-->
	ed
	in Sections 4 and 6 of <xref target="RFC3649"/> (HighSpeed TCP) and using spare
	capacity is
	discussed in Sections 6, 11.1, and 12 of <xref target="RFC3649"/>.</t>


	</section>	<t>In evaluating a new proposal for use in a controlled environment, the
	<section anchor="real-time-congestion-control"><name>Real-Time Congestion Contro	IETF needs to understand the usage, e.g., how the usage is scoped to the
	l</name>	controlled environment, whether the algorithm will share resources with
		Internet traffic, and consider what could happen if used in a protocol
		that is bridged across an Internet path. Algorithms that are designed to
		be confined to a controlled environment and are not intended for use in
		the general Internet might instead seek real-world data for those
		environments. In such cases, the evaluation criteria in the remainder of
		this document might not apply.</t>
		</section>


	<t>General-purpose algorithms need to coexist in the Internet with real-time	<section anchor="evaluation-criteria">
	congestion control algorithms, which, in general, have finite throughput	<name>Evaluation Criteria</name>
	requirements (i.e., do not seek to utilize all available capacity) and more	<t>As previously noted, authors of a specification on a congestion control
	strict latency bounds. See <xref target="RFC8836"/> for a description of the cha	algorithm are expected to conduct a comprehensive
	racteristics	evaluation of the advantages and disadvantages of any congestion control
	of this use case and the resulting requirements.</t>	algorithms presented to the IETF community. The following guidelines are i
		ntended
		to assist authors and the community in this endeavor. While these
		guidelines provide a helpful framework, they should not be regarded as
		an exhaustive checklist as concerns beyond the scope of these
		guidelines may also arise.</t>


	<t><xref target="RFC8868"/> provides suggestions for real-time congestion contro	<t>When considering a proposed congestion control algorithm, the
	l design and	community <bcp14>MUST</bcp14> consider the criteria in the following secti
	<xref target="RFC8867"/> suggests test cases. <xref target="RFC9392"/> describes	ons. These
	some considerations	criteria will be evaluated in various domains (see Sections <xref
	for the RTP Control Protocol (RTCP). In particular, real-time flows	target="general-use" format="counter"/> and <xref target="special-cases"
	can use less frequent feedback (acknowledgement) than that provided by reliable	format="counter"/>).</t>
	transports.
	This document does not change the informational status of those RFCs.</t>


	<t>A proposed congestion control algorithm SHOULD consider coexistence with wide	<t>Some of the sections below will list criteria that
	ly	<bcp14>SHOULD</bcp14> be met. It could happen that these criteria are
	deployed real-time congestion control algorithms. Regrettably, at the time of	not, in fact, met by the proposal. In such cases, the community
	writing (2024), many algorithms with detailed public specifications are not	<bcp14>MUST</bcp14> document whether not meeting the criteria is
	widely deployed, while many widely deployed real-time congestion control	acceptable, for example, if there are practical limitations on
	algorithms have incomplete public specifications. It is hoped that this	carrying out an evaluation of the criteria.</t>
	situation will change.</t>


	<t>To the extent that behavior of widely deployed algorithms is understood,	<t>The requirement that the community consider a criterion does not
	proponents of a proposed congestion control algorithm can analyze and simulate	imply that the result needs to be described in an RFC: there is
	a proposal's interaction with those algorithms. To the extent they are not, expe	no formal requirement to document the results, although normal IETF
	riments	policies for archiving proceedings will provide a record.</t>
	can be conducted where possible.</t>


	<t>Real-time flows can be directed into distinct queues via Differentiated Servi	<!--[rfced] Does the suggested text capture your intended meaning?
	ces
	Code Points (DSCP) or other mechanisms, which can substantially reduce the
	interplay with other traffic. However, a proposal targeting general Internet use
	can not assume this is always the case.</t>


	<t><xref target="circuit-breakers"/> describes the impact of network transport c	Original:
	ircuit breaker	Instead, the community will use these evaluations as an input when
	algorithms. <xref target="RFC8083"/> also defines a minimal set of RTP circuit b	considering whether to progress the proposed algorithm.
	reakers that
	operate end-to-end across a path. This identifies conditions under which a sende
	r needs to
	stop transmitting media data to protect the network from excessive congestion.
	It is expected that, in the absence of long-lived excessive congestion, RTP
	applications running on best-effort IP networks will be able to operate without
	triggering these circuit breakers.</t>


	</section>	Perhaps:
	<section anchor="short-and-long-flows"><name>Short and Long Flows</name>	Instead, the community will use these evaluations as an input when
		considering whether to progress the proposed algorithm specification
		in the publication process.
		-->


	<t>The effect on short-lived and long-lived flows using other common congestion	<t>This document, except where otherwise noted, does not provide
	control algorithms MUST be evaluated, as in <xref target="short-flows"/>.</t>	normative guidance on the acceptable thresholds for any of these
		criteria. Instead, the community will use these evaluations as an input
		when considering whether to progress the proposed algorithm.</t>


	</section>	<section anchor="single-algorithm-behavior">
	</section>	<name>Single Algorithm Behavior</name>
	<section anchor="other-criteria"><name>Other Criteria</name>	<t>The criteria in the following subsections evaluate the congestion con
		trol
		algorithm when one or more flows using that algorithm share a
		bottleneck link (i.e., with no flows using a differing congestion
		control algorithm).</t>


	<section anchor="differences-with-congestion-control-principles"><name>Differenc	<section anchor="protection-against-congestion-collapse">
	es with Congestion Control Principles</name>	<name>Protection Against Congestion Collapse</name>


	<t>A proposed congestion control algorithm MUST clearly explain any deviations f	<t>A congestion control algorithm should either stop sending when
	rom	the packet drop rate exceeds some threshold <xref
	<xref target="RFC2914"/> and <xref target="RFC7141"/>.</t>	target="RFC3714"/> or include some notion of "full
		backoff". For "full backoff", at some point, the algorithm would
		reduce the sending rate to one packet per round-trip time; then, it wo
		uld
		exponentially back off the time between single packet transmissions
		if the congestion persists. Exactly when either "full backoff" or a
		pause in sending comes into play will be algorithm specific.
		However, as discussed in <xref target="RFC2914"/> and <xref
		target="RFC8961"/>, this requirement is crucial to protect the
		network in times of extreme (and persistent) congestion.</t>


	</section>	<t>If full backoff is used, this test does not require that the
	<section anchor="incremental-deployment"><name>Incremental Deployment</name>	mechanism be identical to that of TCP (see <xref
		target="RFC6298"/> and <xref target="RFC8961"/>). For example, this
		does not preclude full backoff mechanisms that would give flows with
		different round-trip times comparable capacity during backoff.</t>
		</section>


	<t>A congestion control algorithm proposal MUST discuss whether it allows for	<section anchor="protection-against-bufferbloat">
	incremental deployment in the targeted environment. For a mechanism targeted for	<name>Protection Against Bufferbloat</name>
	deployment in the current Internet, the proposal SHOULD discuss what is known	<t>A congestion control algorithm should try to avoid maintaining
	(if anything) about the correct operation of the mechanisms with some of the	excessive queues in the network. Exactly how the algorithm achieves
	equipment in the current Internet, e.g., routers, transparent proxies, WAN	this is algorithm specific; see <xref target="RFC8961"/> and
	optimizers, intrusion detection systems, home routers, and the like.</t>	<xref target="RFC8085"/> for requirements.</t>


	<t>Similarly, if the proposed congestion control algorithm is intended only for	<!-- [rfced] We were unable to find "Reno" explicitly mentioned in RFC
	specific environments (and not the global Internet), the proposal SHOULD	5681 as seen in the text below:
	consider how this intention is to be realised. The community will have to
	address the question of whether the scope can be enforced by stating the
	restrictions, or whether additional protocol mechanisms are required to enforce
	this scoping. The answer will necessarily depend on the proposed change.</t>


	<t>As an example from an Experimental RFC, deployment issues are discussed in	Original:
	Sections 10.3 and 10.4 of <xref target="RFC4782"/> (Quick-Start).</t>


	</section>	The standards-track Reno [RFC5681] and CUBIC [RFC9438]
	</section>	congestion control algorithms send at progressively higher rates
	</section>	until a First-In First-Out (FIFO) buffer completely fills...
	<section anchor="general-use"><name>General Use</name>


	<t>The criteria in <xref target="evaluation-criteria"/> will be evaluated in the	However, it does appear in RFCs 5681 and 6582 in the reference
	following	below. Should the reference to RFC 5681 be adjusted to [FF96]? [FF96]
	scenarios. Unless a proposed congestion control specification explicitly forbids	is now available at this URL:
	use on the public Internet, there MUST be IETF consensus that it meets the	https://dl.acm.org/doi/10.1145/235160.235162
	criteria in these scenarios for the proposed congestion control algorithm to
	progress.</t>


	<t>The evaluation in each scenario SHOULD occur over a representative range of	From RFC 5681:
	bandwidths, delays, and queue depths. Of course, the set of parameters
	representative of the public Internet will change over time.</t>


	<t>These criteria are intended to capture a statistically dominant set of Intern	[FF96] Fall, K. and S. Floyd, "Simulation-based Comparisons of
	et	Tahoe, Reno and SACK TCP", Computer Communication Review,
	conditions. In the case that a proposed congestion control algorithm has been	July 1996, ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.
	tested at Internet scale, the results from that deployment are often useful for
	answering these questions.</t>


	<section anchor="paths-with-tail-drop-queues"><name>Paths with Tail-drop Queues< /name>	From RFC 6582:


	<t>The performance of a congestion control algorithm is affected by the queue	"For the typical implementation of the TCP fast recovery algorithm
	discipline applied at the bottleneck link. The drop-tail queue discipline (using	described in [RFC5681] (first implemented in the 1990 BSD Reno
	a FIFO buffer) MUST be evaluated. See <xref target="aqm"/> for evaluation of oth	release, and referred to as the "Reno algorithm" in [FF96])..."
	er queue
	disciplines.</t>


	</section>	-->
	<section anchor="tunnel-behavior"><name>Tunnel Behavior</name>	<t>"Bufferbloat" refers to the building of excessive queues in the
		network <xref target="BUFFERBLOAT"/>. Many network routers are
		configured with very large buffers. The Standards Track RFCs <xref
		target="RFC5681"/> and <xref target="RFC9438"/> describing the Reno an
		d CUBIC congestion
		control algorithms (respectively) send at progressively higher rates u
		ntil a
		First In, First Out (FIFO) buffer completely fills; then packet
		losses occur. Every connection passing through that bottleneck
		experiences increased latency due to the high buffer occupancy. This
		adds unwanted latency that negatively impacts highly interactive
		applications such as videoconferencing or games, but it also affects
		routine web browsing and video playing.</t>


	<t>When a proposed congestion control algorithm relies on explicit signals from	<t>This problem has been widely discussed since 2011 <xref
	the	target="BUFFERBLOAT"/>, but was not discussed in the congestion
	path, the proposal MUST consider the effect of traffic passing through a tunnel,	control principles published in September 2002 <xref
	where routers may not be aware of the flow.</t>	target="RFC2914"/>. The Reno and CUBIC congestion control algorithms
		do not address this problem, but a new congestion control algorithm
		has the opportunity to improve the state of the art.</t>
		</section>


	<t>The design of tunnels and similar encapsulations might need to consider neste	<section anchor="protection-against-high-packet-loss">
	d	<name>Protection Against High Packet Loss</name>
	congestion control interactions. For example, when ECN is used by both an
	IP and lower layer technology <xref target="ECN-Encaps"/>.</t>


	</section>	<t>A congestion control algorithm should try to avoid causing
	<section anchor="wired-paths"><name>Wired Paths</name>	excessively high rates of packet loss. To accomplish this, it should
		avoid excessive increases in sending rate and reduce its sending
		rate if experiencing high packet loss.</t>


	<t>Wired networks are usually characterized by extremely low rates of packet los	<t>The first version of the BBR algorithm <xref
	s	target="BBRv1"/> failed this requirement. Experimental
	except for those due to queue drops. They tend to have stable aggregate	evaluation <xref target="BBRv1-EVALUATION"/> showed that it caused a
	capacity, usually higher than other types of links, and low non-queueing delay.	sustained rate of packet loss when multiple BBRv1 flows shared a
	Because the properties are relatively simple, wired links are typically used as	bottleneck and the buffer size was less than roughly one and a half
	a	times the Bandwidth Delay Product (BDP). This was unsatisfactory,
	"baseline" case even if they are not always the bottleneck link in the modern	and, indeed, further versions provided a fix for this aspect of BBR
	Internet.</t>	<xref target="I-D.cardwell-iccrg-bbr-congestion-control"/>.</t>


	</section>	<t>This requirement does not imply that the algorithm should react
	<section anchor="wireless-paths"><name>Wireless Paths</name>	to packet losses in exactly the same way as congestion control algorit
		hms described in current Standards Track RFCs (e.g., <xref target="RFC5681"/>).<
		/t>
		</section>


	<t>While the early Internet was dominated by wired links, the properties of	<section anchor="fairness-within-the-proposed-congestion-control-algorit
	wireless links have become important to Internet performance. In	hm">
	particular, a proposed congestion control algorithm should be evaluated in	<name>Fairness Within the Proposed Congestion Control Algorithm</name>
	situations where some packet losses are due to radio effects, rather than router	<t>When multiple competing flows all use the same proposed
	queue drops; the link capacity varies over time due to changing link conditions;	congestion control algorithm, the specification should explore how the
	and media access delays and link-layer retransmission lead to increased jitter	capacity is shared among the competing flows. Capacity fairness can
	in round-trip times. See <xref target="RFC3819"/> and Section 16 of <xref target	be important when a small number of similar flows compete to fill a
	="Tools"/> for further	bottleneck. However, it can also not be useful, for example, when
	discussion of wireless properties.</t>	comparing flows that seek to send at different rates or if some of
		the flows do not last sufficiently long to approach asymptotic
		behavior.</t>
		</section>


	</section>	<section anchor="short-flows">
	</section>	<name>Short Flows</name>
	<section anchor="special-cases"><name>Special Cases</name>	<t>A great deal of congestion control analysis concerns the
		steady-state behavior of long flows. However, many Internet flows
		are relatively short lived. Many short-lived flows today remain in
		the "slow start" mode of operation <xref target="RFC5681"/> that
		commonly features exponential congestion window growth because the
		flow never experiences congestion (e.g., packet loss).</t>
		<t>A proposed congestion control algorithm <bcp14>MUST</bcp14>
		consider how new and short-lived flows affect long-lived flows, and
		vice versa.</t>
		</section>
		</section>


	<t>The criteria in <xref target="evaluation-criteria"/> will be evaluated in the	<section anchor="mixed-algorithm-behavior">
	following	<name>Mixed Algorithm Behavior</name>
	scenarios, unless the proposed congestion control algorithm specifically	<t>The mixed algorithm behavior criteria evaluate the interaction of the
	excludes its use in a scenario. For these specific use-cases, the community MAY	proposed congestion control algorithms being specified with commonly dep
	allow a proposal to progress even if the criteria indicate an unsatisfactory	loyed
	result for these scenarios.</t>	congestion control algorithms.</t>
		<t>In contexts where differing congestion control algorithms are used,
		it is important to understand whether the proposed congestion control
		algorithm could result in more harm than algorithms published in previou
		s Standards Track RFCs (e.g., <xref target="RFC5681"/>, <xref target="RFC9002"/>
		,
		and <xref target="RFC9438"/>) to flows sharing a common bottleneck.
		The measure of harm is not restricted to unequal capacity, but also
		ought to consider metrics such as the introduced latency or an
		increase in packet loss. An evaluation <bcp14>MUST</bcp14> assess the
		potential to cause starvation, including assurance that a loss of all
		feedback (e.g., detected by expiry of a retransmission time out)
		results in backoff.</t>


	<t>In general, measurements from Internet-scale deployments might not expose the	<section anchor="existing-general-purpose-congestion-control">
	properties of operation in each of these scenarios, because they are not as	<name>Existing General-Purpose Congestion Control</name>
	ubiquitous as the General Use scenarios.</t>	<t>A proposed congestion control algorithm <bcp14>MUST</bcp14> be
		evaluated when competing against standard IETF congestion controls
		(e.g., <xref target="RFC5681"/>, <xref target="RFC9002"/>, and <xref
		target="RFC9438"/>). A proposed congestion control algorithm that
		has a significantly negative impact on flows using standard
		congestion control might be suspect, and this aspect should be part
		of the community's decision making with regards to the suitability
		of the proposed congestion control algorithm. The community should
		also consider other non-standard congestion control algorithms that
		are known to be widely deployed.</t>


	<section anchor="aqm"><name>Active Queue Management (AQM)</name>	<t>Note that this guideline is not a requirement for strict Reno or
		CUBIC friendliness as a prerequisite for a proposed congestion
		control mechanism to advance to Experimental or Standards Track
		status. As an example, HighSpeed TCP is a congestion control
		mechanism that is specified in an Experimental RFC and is not TCP frie
		ndly
		in all environments. When a new congestion control algorithm is
		deployed, the existing major algorithm deployments need to be
		considered to avoid severe performance degradation. Note that this
		guideline does not constrain the interaction with flows that are not
		best effort.</t>


	<t>The proposed congestion control algorithm SHOULD be evaluated under a variety	<t>As an example from an Experimental RFC, fairness with standard
	of	TCP is discussed in Sections <xref target="RFC3649"
	bottleneck queue disciplines. The effect of an AQM discipline can be hard to	sectionFormat="bare" section="4"/> and <xref target="RFC3649"
	detect by Internet evaluation. At a minimum, a proposal should reason about an	sectionFormat="bare" section="6"/> of <xref target="RFC3649"
	algorithm's response to various AQM disciplines. Simulation or empirical results	format="default"/>, and using spare capacity is
	are, of course, valuable.</t>	discussed in Sections <xref target="RFC3649" sectionFormat="bare"
		section="6"/>, <xref target="RFC3649" sectionFormat="bare"
		section="11.1"/>, and <xref target="RFC3649" sectionFormat="bare"
		section="12"/> of <xref target="RFC3649"/>.</t>
		</section>


	<t>Among the AQM techniques that might have an impact on a proposed congestion	<section anchor="real-time-congestion-control">
	control algorithm are Flow Queue CoDel (FQ-CoDel) <xref target="RFC8290"/>; Prop	<name>Real-Time Congestion Control</name>
	ortional Integral Controller
	Enhanced (PIE) <xref target="RFC8033"/>; and Low Latency, Low Loss, and Scalable
	Throughput
	(L4S) <xref target="RFC9332"/>.</t>


	<t>A proposed congestion control algorithm that sets one of the two Explicit	<t>General-purpose algorithms need to coexist in the Internet with
	Congestion Transport (ECT) codepoints in the IP header can gain the benefits of	real-time congestion control algorithms, which in general have
	receiving Explicit Congestion Notification (ECN) Congestion Experienced (CE)	finite throughput requirements (i.e., they do not seek to utilize all
	signals from an on-path AQM <xref target="RFC8087"/>. Use of ECN <xref target="R	available capacity) and more strict latency bounds. See <xref
	FC3168"/>, <xref target="RFC9332"/>	target="RFC8836"/> for a description of the characteristics of this
	requires the congestion control algorithm to react when it receives a packet	use case and the resulting requirements.</t>
	with an ECN-CE marking. This reaction needs to be evaluated to confirm that the
	algorithm conforms with the requirements of the ECT codepoint that was used.</t>


	<t>Note that evaluation of AQM techniques -- as opposed to their impact on a	<t><xref target="RFC8868"/> provides suggestions for real-time
	specific proposed congestion control algorithm -- is out of scope of this	congestion control design and <xref target="RFC8867"/> suggests test
	document. <xref target="RFC7567"/> describes design considerations for AQMs.</t>	cases. <xref target="RFC9392"/> describes some considerations for
		the RTP Control Protocol (RTCP). In particular, real-time flows can
		use less frequent feedback (acknowledgment) than that provided by
		reliable transports. This document does not change the
		Informational status of those RFCs.</t>


	</section>	<t>A proposed congestion control algorithm <bcp14>SHOULD</bcp14>
	<section anchor="circuit-breakers"><name>Operation with the Envelope set by Netw	consider coexistence with widely deployed real-time congestion
	ork Circuit Breakers</name>	control algorithms. Regrettably, at the time of writing (2024), many
		algorithms with detailed public specifications are not widely
		deployed, while many widely deployed real-time congestion control
		algorithms have incomplete public specifications. It is hoped that
		this situation will change.</t>


	<t>Some equipment in the network uses an automatic mechanism to continuously	<t>To the extent that behavior of widely deployed algorithms is
	monitor the use of resources by a flow or aggregate set of flows <xref target="R	understood, proponents of a proposed congestion control algorithm
	FC8084"/>.	can analyze and simulate a proposal's interaction with those
	Such a network transport circuit breaker can automatically detect excessive	algorithms. To the extent that they are not, experiments can be
	congestion, and when detected, it can terminate (or significantly reduce the	conducted where possible.</t>
	rate of) the flow(s). A well-designed congestion control algorithm ought to
	react before the flow uses excessive resources, and therefore will operate
	within the envelope set by network transport circuit breaker algorithms.</t>


	</section>	<t>Real-time flows can be directed into distinct queues via
	<section anchor="delay"><name>Paths with Varying Delay</name>	Differentiated Services Code Points (DSCPs) or other mechanisms,
		which can substantially reduce the interplay with other
		traffic. However, a proposal targeting general Internet use cannot
		assume this is always the case.</t>


	<t>An Internet Path can include simple links, where the minimum delay is the	<t><xref target="circuit-breakers"/> describes the impact of network
	propagation delay, and any additional delay can be attributed to link buffering.	transport circuit breaker algorithms. <xref target="RFC8083"/> also
	This cannot be assumed. An Internet Path can also include complex subnetworks	defines a minimal set of RTP circuit breakers that operate
	where the minimum delay changes over various time scales, resulting in a non-	end-to-end across a path. This identifies conditions under which a
	stationary minimum delay.</t>	sender needs to stop transmitting media data to protect the network
		from excessive congestion. It is expected that, in the absence of
		long-lived excessive congestion, RTP applications running on
		best-effort IP networks will be able to operate without triggering
		these circuit breakers.</t>
		</section>


	<t>Varying delay occurs when a subnet changes the forwarding path to optimise ca	<section anchor="short-and-long-flows">
	pacity,	<name>Short and Long Flows</name>
	resilience, etc. It could also arise when a subnet uses a capacity management	<t>The effect on short-lived and long-lived flows using other common
	method where the available resource is periodically distributed among the active	congestion control algorithms <bcp14>MUST</bcp14> be evaluated, as
	nodes. A node might then have to buffer data until an assigned transmission	in <xref target="short-flows"/>.</t>
	opportunity or until the physical path changes (e.g., when the length of a	</section>
	wireless path changes, or the physical layer changes its mode of operation).	</section>
	Variation also arises when traffic with a higher priority DSCP pre-empts
	transmission of traffic with a lower class. In these cases, the delay varies as
	a function of external factors, and attempting to infer congestion from an
	increase in the delay results in reduced throughput. This variation in the
	delay over short timescales (jitter) might not be distinguishable from jitter
	that results from other effects.</t>


	<t>A proposed congestion control algorithm SHOULD be evaluated to ensure its	<section anchor="other-criteria">
	operation is robust when there is a significant change in the minimum delay.</t>	<name>Other Criteria</name>
		<section anchor="differences-with-congestion-control-principles">
		<name>Differences with Congestion Control Principles</name>
		<t>A proposed congestion control algorithm <bcp14>MUST</bcp14>
		clearly explain any deviations from <xref target="RFC2914"/> and
		<xref target="RFC7141"/>.</t>
		</section>


	</section>	<section anchor="incremental-deployment">
	<section anchor="internet-of-things-and-constrained-nodes"><name>Internet of Thi	<name>Incremental Deployment</name>
	ngs and Constrained Nodes</name>	<t>A congestion control algorithm proposal <bcp14>MUST</bcp14>
		discuss whether it allows for incremental deployment in the targeted
		environment. For a mechanism targeted for deployment in the current
		Internet, the proposal <bcp14>SHOULD</bcp14> discuss what is known
		(if anything) about the correct operation of the mechanisms with
		some of the equipment in the current Internet (e.g., routers,
		transparent proxies, WAN optimizers, intrusion detection systems,
		home routers, and the like).</t>
		<t>Similarly, if the proposed congestion control algorithm is
		intended only for specific environments (and not the global
		Internet), the proposal <bcp14>SHOULD</bcp14> consider how this
		intention is to be realized. The IETF community will have to address
		the
		question of whether the scope can be enforced by stating the
		restrictions or whether additional protocol mechanisms are required
		to enforce this scoping. The answer will necessarily depend on the
		proposed change.</t>
		<t>As an example from an Experimental RFC, deployment issues of Quick-
		Start are
		discussed in Sections <xref target="RFC4782" section="10.3"
		sectionFormat="bare"/> and <xref target="RFC4782" section="10.4"
		sectionFormat="bare"/> of <xref target="RFC4782"/>.</t>
		</section>
		</section>
		</section>


	<t>The "Internet of Things" (IoT) is a broad concept, but when evaluating a	<section anchor="general-use">
	proposed congestion control algorithm, it is often associated with unique	<name>General Use</name>
	characteristics:	<t>The criteria in <xref target="evaluation-criteria"/> will be
	IoT nodes might be more constrained in power, CPU, or other parameters than	evaluated in the scenarios described in the following subsections. Unless
	conventional Internet hosts. This might place limits on the complexity of any	a proposed congestion
	given algorithm. These power and radio constraints might make the volume of	control algorithm specification of the IETF Stream explicitly forbids use
	control packets in a given algorithm a key evaluation metric.</t>	on the public Internet,
		there <bcp14>MUST</bcp14> be IETF consensus that it meets the criteria
		in these scenarios for the proposed congestion control algorithm to
		progress.</t>


	<t>Extremely low-power links can lead to very low throughput and a low bandwidth	<t>The evaluation of each scenario <bcp14>SHOULD</bcp14> occur over a
	-	representative range of bandwidths, delays, and queue depths. Of course,
	delay product, well below the standard operating range of most Internet flows.</	the set of parameters representative of the public Internet will change
	t>	over time.</t>


	<t>Furthermore, many IoT applications do not a have a human in the loop, and	<t>These criteria are intended to capture a statistically dominant set
	therefore might have weaker latency constraints because they do not relate to a	of Internet conditions. In the case that a proposed congestion control
	user experience. Congestion control algorithm can still need to share the	algorithm has been tested at Internet scale, the results from that
	path with other flows with different constraints.</t>	deployment are often useful for answering these questions.</t>


	</section>	<section anchor="paths-with-tail-drop-queues">
	<section anchor="paths-with-high-delay"><name>Paths with High Delay</name>	<name>Paths with Tail-Drop Queues</name>
		<t>The performance of a congestion control algorithm is affected by
		the queue discipline applied at the bottleneck link. The drop-tail
		queue discipline (using a FIFO buffer) <bcp14>MUST</bcp14> be
		evaluated. See <xref target="aqm"/> for evaluation of other queue
		disciplines.</t>
		</section>


	<t>A proposed congestion control algorithm ought not to presume that all general	<section anchor="tunnel-behavior">
	Internet paths have a low delay. Some paths include links that contribute much	<name>Tunnel Behavior</name>
	more delay than for a typical Internet path. Satellite links often have delays	<t>When a proposed congestion control algorithm relies on explicit
	longer than typical for wired paths <xref target="RFC2488"/> and high delay band	signals from the path, the proposal <bcp14>MUST</bcp14> consider the
	width	effect of traffic passing through a tunnel, where routers may not be
	products <xref target="RFC3649"/>.</t>	aware of the flow.</t>
		<!-- Updated I-D.ietf-tsvwg-ecn-encap-guidelines to RFC 9599 -->
		<t>Designers of tunnels and similar encapsulations might need to
		consider nested congestion control interactions, for example, when the
		Explicit Congestion Notification (ECN) is used by both an IP and lower-l
		ayer technology <xref target="RFC9599"/>.</t>
		</section>


	<t>Paths can also present a variable delay as described in <xref target="delay"/	<section anchor="wired-paths">
	>.</t>	<name>Wired Paths</name>
		<t>Wired networks are usually characterized by extremely low rates of
		packet loss except for those due to queue drops. They tend to have
		stable aggregate capacity, usually higher than other types of links,
		and low non-queueing delay. Because the properties are relatively
		simple, wired links are typically used as a "baseline" case even if
		they are not always the bottleneck link in the modern Internet.</t>
		</section>


	</section>	<section anchor="wireless-paths">
	<section anchor="misbehaving-nodes"><name>Misbehaving Nodes</name>	<name>Wireless Paths</name>
		<t>While the early Internet was dominated by wired links, the
		properties of wireless links have become important to Internet
		performance. In particular, a proposed congestion control algorithm
		should be evaluated in situations where some packet losses are due to
		radio effects rather than router queue drops. The link capacity
		varies over time due to changing link conditions, and media-access
		delays and link-layer retransmission lead to increased jitter in
		round-trip times. See <xref target="RFC3819"/> and Section 16 of <xref
		target="I-D.irtf-tmrg-tools"/> for further discussion of wireless
		properties.</t>
		</section>
		</section>


	<t>A proposed congestion control algorithm SHOULD explore how the algorithm	<section anchor="special-cases">
	performs with non-compliant senders, receivers, or routers. In addition, the	<name>Special Cases</name>
	proposal should explore how a proposed congestion control algorithm performs	<t>The criteria in <xref target="evaluation-criteria"/> will be
	with outside attackers. This can be particularly important for proposed	evaluated in the scenarios described in the following subsections, unless
	congestion control algorithms that involve explicit feedback from routers along	the proposed congestion
	the path.</t>	control algorithm specifically excludes its use in a scenario. For these
		specific use cases, the IETF community <bcp14>MAY</bcp14> allow a proposal
		to
		progress even if the criteria indicate an unsatisfactory result for
		these scenarios.</t>


	<t>As an example from an Experimental RFC, performance with misbehaving nodes an	<t>In general, measurements from Internet-scale deployments might not
	d	expose the properties of operation in each of these scenarios because
	outside attackers is discussed in Sections 9.4, 9.5, and 9.6 of <xref target="RF	they are not as ubiquitous as the general-use scenarios.</t>
	C4782"/>.
	This includes discussion of misbehaving senders and receivers; collusion between
	misbehaving routers; misbehaving middleboxes; and the potential use of Quick-
	Start to attack routers or to tie up available Quick-Start bandwidth.</t>


	</section>	<section anchor="aqm">
	<section anchor="extreme-packet-reordering"><name>Extreme Packet Reordering</nam	<name>Active Queue Management (AQM)</name>
	e>	<t>The proposed congestion control algorithm <bcp14>SHOULD</bcp14> be
		evaluated under a variety of bottleneck-queue disciplines. The effect
		of an AQM discipline can be hard to detect by Internet evaluation. At
		a minimum, a proposal should reason about an algorithm's response to
		various AQM disciplines. Simulation or empirical results are, of
		course, valuable.</t>


	<t>A proposed congestion control algorithm ought not to presume that all general	<!-- [rfced] FYI - We have reworked the text below into a bulleted
	Internet paths reliably deliver packets in order. <xref target="RFC4653"/> discu	list for ease of the reader and updated to use didactic
	sses the	caps. Please review and let us know any objections.
	effect of extreme packet reordering.</t>


	</section>	Original:
	<section anchor="transient-events"><name>Transient Events</name>


	<t>A proposed congestion control algorithm SHOULD consider how the proposed	Among the AQM techniques that might have an impact on a proposed
	congestion control algorithm would perform in the presence of transient events	congestion control algorithm are Flow Queue CoDel (FQ-CoDel)
	such as sudden onset of congestion, a routing change, or a mobility event.	[RFC8290]; Proportional Integral Controller Enhanced (PIE) [RFC8033];
	Routing changes, link disconnections, intermittent link connectivity, and	and Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332].
	mobility are discussed in more detail in Section 16 of <xref target="Tools"/>.</
	t>


	<t>As an example from an Experimental RFC, response to transient events is	Current:
	discussed in <xref section="9.2" sectionFormat="of" target="RFC4782"/>.</t>


	</section>	Some of the AQM techniques that might have an impact on a proposed
	<section anchor="sudden-changes-in-the-path"><name>Sudden changes in the Path</n	congestion control algorithm include:
	ame>


	<t>An IETF transport is not tied to a specific Internet path or type of path. Th	* Flow Queue CoDel (FQ-CoDel) [RFC8290];
	e
	set of routers that form a path can and do change with time. This will cause the
	properties of the path to change with respect to time. A proposed congestion
	control algorithm MUST evaluate the impact of changes in the path, and be robust
	to changes in path characteristics on the interval of common Internet re-routing
	intervals.</t>


	</section>	* Proportional Integral controller Enhanced (PIE) [RFC8033]; and
	<section anchor="multipath-transport"><name>Multipath Transport</name>


	<t>Multipath transport protocols permit more than one path to be differentiated	* Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332].
	and
	used by a single connection at the sender. A multipath sender can schedule which
	packets travel on which of its active paths. This enables a tradeoff in
	timeliness and reliability. There are various ways that multipath techniques can
	be used.</t>


	<t>One example use is to provide fail-over from one path to another when the	-->
	original path is no longer viable, or provides inferior performance. Designs
	need to independently track the congestion state of each path, and demonstrate
	independent congestion control for each path being used. Authors of a proposed
	multipath congestion control algorithm that implements path fail-over MUST
	evaluate the harm to performance resulting from a change in the path, and show t
	hat this does
	not result in flow starvation. Synchronisation of failover (e.g., where multiple
	flows change their path on similar timeframes) can also contribute to harm
	and/or reduce fairness. These effects also ought to be evaluated.</t>


	<t>Another example use is concurrent multipath, where the transport protocol	<t>Some of the AQM techniques that might have an impact on a proposed
	simultaneously schedules a flow to aggregate the capacity across multiple paths.	congestion control algorithm include:</t>
	The Internet provides no guarantee that different paths (e.g., using different	<ul>
	endpoint addresses) are disjoint. This introduces additional implications: A con	<li>Flow Queue CoDel (FQ-CoDel) <xref target="RFC8290"/>;</li>
	gestion	<li>Proportional Integral controller Enhanced (PIE) <xref target="RFC80
	control algorithm proposal MUST evaluate the potential harm to other flows when	33"/>; and</li>
	the multiple paths share a common congested bottleneck or share resources that	<li>Low Latency, Low Loss, and Scalable Throughput (L4S) <xref target="
	are coupled between different paths, such as an overall capacity limit). A propo	RFC9332"/>.</li>
	sal	</ul>
	SHOULD consider the potential for harm to other flows. Synchronisation of
	congestion control mechanisms (e.g., where multiple flows change their behaviour
	on similar timeframes) can also contribute to harm and/or reduce fairness. These
	effects also ought to be evaluated.</t>


	<t>At the time of writing (2024), there are currently no Standards Track RFCs fo	<!-- [rfced] We note that ECT is most often expanded to "ECN-Capable
	r	Transport (ECT)" (as was done in normative reference RFC 9902).
	concurrent multipath, but there is an Experimental RFC <xref target="RFC6356"/>	Would you like to update this expansion to match the usage in
	that	RFC 9902?
	specifies a concurrent multipath congestion control algorithm for MPTCP
	<xref target="RFC8684"/>.</t>


	</section>	Original:
	<section anchor="data-centers"><name>Data Centers</name>	A proposed congestion control algorithm that sets one of the two
		Explicit Congestion Transport (ECT) codepoints in the IP header can
		gain the benefits of receiving Explicit Congestion Notification (ECN)
		Congestion Experienced (CE) signals from an on-path AQM [RFC8087].


	<t>Data centers are characterized by very low latencies (< 2 ms). Many worklo	Perhaps:
	ads	A proposed congestion control algorithm that sets one of the two
	involve bursty traffic where many nodes complete a task at the same time. As a	ECN-Capable Transport (ECT) codepoints in the IP header can gain the
	controlled environment, data centers often deploy fabrics that employ rich	benefits of receiving Explicit Congestion Notification-Congestion
	signalling from switches to endpoints. Furthermore, the operator can often limit	Experienced (ECN-CE) signals from an on-path AQM [RFC8087].
	the number of operating congestion control algorithms.</t>


	<t>For these reasons, data center congestion controls are often distinct from th	-->
	ose
	running elsewhere on the Internet (see <xref target="controlled-environments"/>)
	. A proposed
	congestion control need not coexist well with all other algorithms if it is
	intended for data centers, but the proposal SHOULD indicate which are expected
	to safely coexist with it.</t>


	</section>	<t>A proposed congestion control algorithm that sets one of the two
	</section>	Explicit Congestion Transport (ECT) codepoints in the IP header can
	<section anchor="security-considerations"><name>Security Considerations</name>	gain the benefits of receiving Explicit Congestion
		Notification - Congestion Experienced (ECN-CE) signals from an on-path
		AQM <xref target="RFC8087"/>. Use of ECN (see <xref target="RFC3168"/>
		and <xref target="RFC9332"/>) requires the congestion control
		algorithm to react when it receives a packet with an ECN-CE
		marking. This reaction needs to be evaluated to confirm that the
		algorithm conforms with the requirements of the ECT codepoint that was
		used.</t>


	<t>This document does not represent a change to any aspect of the TCP/IP protoco	<t>Note that evaluation of AQM techniques -- as opposed to their
	l	impact on a specific proposed congestion control algorithm -- is out
	suite and therefore does not directly impact Internet security. The	of scope of this document. <xref target="RFC7567"/> describes design
	implementation of various facets of the Internet's current congestion control	considerations for AQMs.</t>
	algorithms do have security implications (e.g., as outlined in <xref target="RFC	</section>
	5681"/>).</t>


	<t>Proposed congestion control algorithms MUST examine any potential security or	<section anchor="circuit-breakers">
	privacy issues that may arise from their design.</t>	<name>Operation with the Envelope Set by Network Circuit Breakers</name>
		<t>Some equipment in the network uses an automatic mechanism to
		continuously monitor the use of resources by a flow or aggregate set
		of flows <xref target="RFC8084"/>. Such a network transport circuit
		breaker can automatically detect excessive congestion; when
		detected, it can terminate (or significantly reduce the rate of) the
		flow(s). A well-designed congestion control algorithm ought to react
		before the flow uses excessive resources; therefore, it will operate
		within the envelope set by network transport circuit breaker
		algorithms.</t>
		</section>


	</section>	<section anchor="delay">
	<section anchor="iana-considerations"><name>IANA Considerations</name>	<name>Paths with Varying Delay</name>


	<t>This document has no IANA actions.</t>	<t>An Internet path can include simple links, where the minimum delay
		is the propagation delay, and any additional delay can be attributed
		to link buffering. This cannot be assumed. An Internet path can also
		include complex subnetworks where the minimum delay changes over
		various time scales, resulting in a minimum delay that is not stationary
		.</t>


	</section>	<t>Varying delay occurs when a subnet changes the forwarding path to
		optimize capacity, resilience, etc. It could also arise when a subnet
		uses a capacity-management method where the available resource is
		periodically distributed among the active nodes. A node might then
		have to buffer data until an assigned transmission opportunity or
		until the physical path changes (e.g., when the length of a wireless
		path changes or when the physical layer changes its mode of operation).
		Variation also arises when traffic with a higher priority DSCP
		preempts transmission of traffic with a lower class. In these cases,
		the delay varies as a function of external factors, and attempting to
		infer congestion from an increase in the delay results in reduced
		throughput. This variation in the delay over short timescales (jitter)
		might not be distinguishable from jitter that results from other
		effects.</t>
		<t>A proposed congestion control algorithm <bcp14>SHOULD</bcp14> be
		evaluated to ensure its operation is robust when there is a
		significant change in the minimum delay.</t>
		</section>


	</middle>	<section anchor="internet-of-things-and-constrained-nodes">
		<name>Internet of Things and Constrained Nodes</name>
		<t>The "Internet of Things" (IoT) is a broad concept, but when
		evaluating a proposed congestion control algorithm, it is often
		associated with unique characteristics. For example, IoT nodes might
		be more constrained in power, CPU, or other parameters than
		conventional Internet hosts. This might place limits on the complexity
		of any given algorithm. These power and radio constraints might make
		the volume of control packets in a given algorithm a key evaluation
		metric.</t>


	<back>	<t>Extremely low-power links can lead to very low throughput and a low
		bandwidth-delay product, which is well below the standard operating
		range of most Internet flows.</t>


	<references title='Normative References'>	<t>Furthermore, many IoT applications do not a have a human in the
		loop; therefore, they might have weaker latency constraints because they
		do not relate to a user experience. Congestion control algorithms
		still may need to share the path with other flows with different
		constraints.</t>
		</section>


	<reference anchor="RFC2914">	<section anchor="paths-with-high-delay">
	<front>	<name>Paths with High Delay</name>
	<title>Congestion Control Principles</title>
	<author fullname="S. Floyd" initials="S." surname="Floyd"/>
	<date month="September" year="2000"/>
	<abstract>
	<t>The goal of this document is to explain the need for congestion control
	in the Internet, and to discuss what constitutes correct congestion control. Th
	is document specifies an Internet Best Current Practices for the Internet Commun
	ity, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="41"/>
	<seriesInfo name="RFC" value="2914"/>
	<seriesInfo name="DOI" value="10.17487/RFC2914"/>
	</reference>


	<reference anchor="RFC8085">	<t>A proposed congestion control algorithm ought not to presume that
	<front>	all general Internet paths have a low delay. Some paths include links
	<title>UDP Usage Guidelines</title>	that contribute much more delay than for a typical Internet
	<author fullname="L. Eggert" initials="L." surname="Eggert"/>	path. Satellite links often have delays longer than is typical for wired
	<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>	paths <xref target="RFC2488"/> and high-delay-bandwidth products <xref
	<author fullname="G. Shepherd" initials="G." surname="Shepherd"/>	target="RFC3649"/>.</t>
	<date month="March" year="2017"/>
	<abstract>
	<t>The User Datagram Protocol (UDP) provides a minimal message-passing tra
	nsport that has no inherent congestion control mechanisms. This document provide
	s guidelines on the use of UDP for the designers of applications, tunnels, and o
	ther protocols that use UDP. Congestion control guidelines are a primary focus,
	but the document also provides guidance on other topics, including message sizes
	, reliability, checksums, middlebox traversal, the use of Explicit Congestion No
	tification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
	<t>Because congestion control is critical to the stable operation of the I
	nternet, applications and other protocols that choose to use UDP as an Internet
	transport must employ mechanisms to prevent congestion collapse and to establish
	some degree of fairness with concurrent traffic. They may also need to implemen
	t additional mechanisms, depending on how they use UDP.</t>
	<t>Some guidance is also applicable to the design of other protocols (e.g.
	, protocols layered directly on IP or via IP-based tunnels), especially when the
	se protocols do not themselves provide congestion control.</t>
	<t>This document obsoletes RFC 5405 and adds guidelines for multicast UDP
	usage.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="145"/>
	<seriesInfo name="RFC" value="8085"/>
	<seriesInfo name="DOI" value="10.17487/RFC8085"/>
	</reference>


	<reference anchor="RFC9438">	<t>Paths can also present a variable delay as described in <xref
	<front>	target="delay"/>.</t>
	<title>CUBIC for Fast and Long-Distance Networks</title>	</section>
	<author fullname="L. Xu" initials="L." surname="Xu"/>
	<author fullname="S. Ha" initials="S." surname="Ha"/>
	<author fullname="I. Rhee" initials="I." surname="Rhee"/>
	<author fullname="V. Goel" initials="V." surname="Goel"/>
	<author fullname="L. Eggert" initials="L." role="editor" surname="Eggert"/>
	<date month="August" year="2023"/>
	<abstract>
	<t>CUBIC is a standard TCP congestion control algorithm that uses a cubic
	function instead of a linear congestion window increase function to improve scal
	ability and stability over fast and long-distance networks. CUBIC has been adopt
	ed as the default TCP congestion control algorithm by the Linux, Windows, and Ap
	ple stacks.</t>
	<t>This document updates the specification of CUBIC to include algorithmic
	improvements based on these implementations and recent academic work. Based on
	the extensive deployment experience with CUBIC, this document also moves the spe
	cification to the Standards Track and obsoletes RFC 8312. This document also upd
	ates RFC 5681, to allow for CUBIC's occasionally more aggressive sending behavio
	r.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9438"/>
	<seriesInfo name="DOI" value="10.17487/RFC9438"/>
	</reference>


	<reference anchor="RFC2119">	<section anchor="misbehaving-nodes">
	<front>	<name>Misbehaving Nodes</name>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>	<t>A proposed congestion control algorithm <bcp14>SHOULD</bcp14>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>	explore how the algorithm performs with non-compliant senders,
	<date month="March" year="1997"/>	receivers, or routers. In addition, the proposal should explore how a
	<abstract>	proposed congestion control algorithm performs with outside attackers.
	<t>In many standards track documents several words are used to signify the	This can be particularly important for proposed congestion control
	requirements in the specification. These words are often capitalized. This docu	algorithms that involve explicit feedback from routers along the
	ment defines these words as they should be interpreted in IETF documents. This d	path.</t>
	ocument specifies an Internet Best Current Practices for the Internet Community,
	and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>


	<reference anchor="RFC8174">	<!-- [rfced] FYI - For readability, we have reformatted the text below to read
	<front>	as a bulleted list. Please review and let us know any objections.
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protocol specif
	ications. This document aims to reduce the ambiguity by clarifying that only UPP
	ERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>


	<reference anchor="RFC8961">	Original:
	<front>
	<title>Requirements for Time-Based Loss Detection</title>
	<author fullname="M. Allman" initials="M." surname="Allman"/>
	<date month="November" year="2020"/>
	<abstract>
	<t>Many protocols must detect packet loss for various reasons (e.g., to en
	sure reliability using retransmissions or to understand the level of congestion
	along a network path). While many mechanisms have been designed to detect loss,
	ultimately, protocols can only count on the passage of time without delivery con
	firmation to declare a packet "lost". Each implementation of a time-based loss d
	etection mechanism represents a balance between correctness and timeliness; ther
	efore, no implementation suits all situations. This document provides high-level
	requirements for time-based loss detectors appropriate for general use in unica
	st communication across the Internet. Within the requirements, implementations h
	ave latitude to define particulars that best address each situation.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="233"/>
	<seriesInfo name="RFC" value="8961"/>
	<seriesInfo name="DOI" value="10.17487/RFC8961"/>
	</reference>


	<reference anchor="RFC5681">	As an example from an Experimental RFC, performance with misbehaving
	<front>	nodes and outside attackers is discussed in Sections 9.4, 9.5, and
	<title>TCP Congestion Control</title>	9.6 of [RFC4782]. This includes discussion of misbehaving senders
	<author fullname="M. Allman" initials="M." surname="Allman"/>	and receivers; collusion between misbehaving routers; misbehaving
	<author fullname="V. Paxson" initials="V." surname="Paxson"/>	middleboxes; and the potential use of Quick- Start to attack routers
	<author fullname="E. Blanton" initials="E." surname="Blanton"/>	or to tie up available Quick-Start bandwidth.
	<date month="September" year="2009"/>
	<abstract>
	<t>This document defines TCP's four intertwined congestion control algorit
	hms: slow start, congestion avoidance, fast retransmit, and fast recovery. In ad
	dition, the document specifies how TCP should begin transmission after a relativ
	ely long idle period, as well as discussing various acknowledgment generation me
	thods. This document obsoletes RFC 2581. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5681"/>
	<seriesInfo name="DOI" value="10.17487/RFC5681"/>
	</reference>


	<reference anchor="RFC9002">	Current:
	<front>
	<title>QUIC Loss Detection and Congestion Control</title>
	<author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/
	>
	<author fullname="I. Swett" initials="I." role="editor" surname="Swett"/>
	<date month="May" year="2021"/>
	<abstract>
	<t>This document describes loss detection and congestion control mechanism
	s for QUIC.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9002"/>
	<seriesInfo name="DOI" value="10.17487/RFC9002"/>
	</reference>


	<reference anchor="RFC8083">	As an example from an Experimental RFC, performance with misbehaving
	<front>	nodes and outside attackers is discussed in Sections 9.4, 9.5, and
	<title>Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessi	9.6 of [RFC4782]. This includes discussion of:
	ons</title>
	<author fullname="C. Perkins" initials="C." surname="Perkins"/>
	<author fullname="V. Singh" initials="V." surname="Singh"/>
	<date month="March" year="2017"/>
	<abstract>
	<t>The Real-time Transport Protocol (RTP) is widely used in telephony, vid
	eo conferencing, and telepresence applications. Such applications are often run
	on best-effort UDP/IP networks. If congestion control is not implemented in thes
	e applications, then network congestion can lead to uncontrolled packet loss and
	a resulting deterioration of the user's multimedia experience. The congestion c
	ontrol algorithm acts as a safety measure by stopping RTP flows from using exces
	sive resources and protecting the network from overload. At the time of this wri
	ting, however, while there are several proprietary solutions, there is no standa
	rd algorithm for congestion control of interactive RTP flows.</t>
	<t>This document does not propose a congestion control algorithm. It inste
	ad defines a minimal set of RTP circuit breakers: conditions under which an RTP
	sender needs to stop transmitting media data to protect the network from excessi
	ve congestion. It is expected that, in the absence of long-lived excessive conge
	stion, RTP applications running on best-effort IP networks will be able to opera
	te without triggering these circuit breakers. To avoid triggering the RTP circui
	t breaker, any Standards Track congestion control algorithms defined for RTP wil
	l need to operate within the envelope set by these RTP circuit breaker algorithm
	s.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8083"/>
	<seriesInfo name="DOI" value="10.17487/RFC8083"/>
	</reference>


	<reference anchor="RFC7141">	* misbehaving senders and receivers;
	<front>
	<title>Byte and Packet Congestion Notification</title>
	<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
	<author fullname="J. Manner" initials="J." surname="Manner"/>
	<date month="February" year="2014"/>
	<abstract>
	<t>This document provides recommendations of best current practice for dro
	pping or marking packets using any active queue management (AQM) algorithm, incl
	uding Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), an
	d newer schemes such as CoDel (Controlled Delay) and PIE (Proportional Integral
	controller Enhanced). We give three strong recommendations: (1) packet size shou
	ld be taken into account when transports detect and respond to congestion indica
	tions, (2) packet size should not be taken into account when network equipment c
	reates congestion signals (marking, dropping), and therefore (3) in the specific
	case of RED, the byte- mode packet drop variant that drops fewer small packets
	should not be used. This memo updates RFC 2309 to deprecate deliberate preferent
	ial treatment of small packets in AQM algorithms.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="41"/>
	<seriesInfo name="RFC" value="7141"/>
	<seriesInfo name="DOI" value="10.17487/RFC7141"/>
	</reference>


	<reference anchor="RFC8084">	* collusion between misbehaving routers;
	<front>
	<title>Network Transport Circuit Breakers</title>
	<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
	<date month="March" year="2017"/>
	<abstract>
	<t>This document explains what is meant by the term "network transport Cir
	cuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunn
	els and applications when using non-congestion- controlled traffic and explains
	where CBs are, and are not, needed. It also defines requirements for building a
	CB and the expected outcomes of using a CB within the Internet.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="208"/>
	<seriesInfo name="RFC" value="8084"/>
	<seriesInfo name="DOI" value="10.17487/RFC8084"/>
	</reference>


	</references>	* misbehaving middleboxes; and


	<references title='Informative References'>	* the potential use of Quick-Start to attack routers or to tie up
		available Quick-Start bandwidth.


	<reference anchor="BBR-draft">	-->
	<front>
	<title>BBR Congestion Control</title>
	<author fullname="Neal Cardwell" initials="N." surname="Cardwell">
	<organization>Google</organization>
	</author>
	<author fullname="Yuchung Cheng" initials="Y." surname="Cheng">
	<organization>Google</organization>
	</author>
	<author fullname="Soheil Hassas Yeganeh" initials="S. H." surname="Yeganeh
	">
	<organization>Google</organization>
	</author>
	<author fullname="Ian Swett" initials="I." surname="Swett">
	<organization>Google</organization>
	</author>
	<author fullname="Van Jacobson" initials="V." surname="Jacobson">
	<organization>Google</organization>
	</author>
	<date day="7" month="March" year="2022"/>
	<abstract>
	<t> This document specifies the BBR congestion control algorithm. BBR
	("Bottleneck Bandwidth and Round-trip propagation time") uses recen
	t
	measurements of a transport connection's delivery rate, round-trip
	time, and packet loss rate to build an explicit model of the network
	path. BBR then uses this model to control both how fast it sends
	data and the maximum volume of data it allows in flight in the
	network at any time. Relative to loss-based congestion control
	algorithms such as Reno [RFC5681] or CUBIC [RFC8312], BBR offers
	substantially higher throughput for bottlenecks with shallow buffers
	or random losses, and substantially lower queueing delays for
	bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be
	implemented in any transport protocol that supports packet-delivery
	acknowledgment. Thus far, open source implementations are available
	for TCP [RFC793] and QUIC [RFC9000]. This document specifies version
	2 of the BBR algorithm, also sometimes referred to as BBRv2 or bbr2.


	</t>	<t>As an example from an Experimental RFC, performance with
	</abstract>	misbehaving nodes and outside attackers is discussed in Sections <xref
	</front>	target="RFC4782" section="9.4" sectionFormat="bare"/>, <xref
	<seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-congestion-	target="RFC4782" section="9.5" sectionFormat="bare"/>, and <xref
	control-02"/>	target="RFC4782" section="9.6" sectionFormat="bare"/> of <xref
		target="RFC4782"/>. This includes discussion of:</t>
		<ul>
		<li>misbehaving senders and receivers;</li>
		<li>collusion between misbehaving routers;</li>
		<li>misbehaving middleboxes; and</li>
		<li>the potential use of Quick-Start to attack routers or to tie up
		available Quick-Start bandwidth.</li>
		</ul>
		</section>


	</reference>	<section anchor="extreme-packet-reordering">
		<name>Extreme Packet Reordering</name>
		<t>A proposed congestion control algorithm ought not to presume that
		all general Internet paths reliably deliver packets in order. <xref
		target="RFC4653"/> discusses the effect of extreme packet
		reordering.</t>
		</section>


	<reference anchor="BBRv1-draft">	<section anchor="transient-events">
	<front>	<name>Transient Events</name>
	<title>BBR Congestion Control</title>	<t>A proposed congestion control algorithm <bcp14>SHOULD</bcp14>
	<author fullname="Neal Cardwell" initials="N." surname="Cardwell">	consider how it would perform
	<organization>Google, Inc</organization>	in the presence of transient events such as a sudden onset of
	</author>	congestion, a routing change, or a mobility event. Routing changes,
	<author fullname="Yuchung Cheng" initials="Y." surname="Cheng">	link disconnections, intermittent link connectivity, and mobility are
	<organization>Google, Inc</organization>	discussed in more detail in Section 16 of <xref
	</author>	target="I-D.irtf-tmrg-tools"/>.</t>
	<author fullname="Soheil Hassas Yeganeh" initials="S. H." surname="Yeganeh
	">
	<organization>Google, Inc</organization>
	</author>
	<author fullname="Van Jacobson" initials="V." surname="Jacobson">
	<organization>Google, Inc</organization>
	</author>
	<date day="3" month="July" year="2017"/>
	<abstract>
	<t> This document specifies the BBR congestion control algorithm. BBR
	uses recent measurements of a transport connection's delivery rate
	and round-trip time to build an explicit model that includes both the
	maximum recent bandwidth available to that connection, and its
	minimum recent round-trip delay. BBR then uses this model to control
	both how fast it sends data and the maximum amount of data it allows
	in flight in the network at any time. Relative to loss-based
	congestion control algorithms such as Reno [RFC5681] or CUBIC
	[draft-ietf-tcpm-cubic], BBR offers substantially higher throughput
	for bottlenecks with shallow buffers or random losses, and
	substantially lower queueing delays for bottlenecks with deep buffers
	(avoiding "bufferbloat"). This algorithm can be implemented in any
	transport protocol that supports packet-delivery acknowledgment (thus
	far, open source implementations are available for TCP [RFC793] and
	QUIC [draft-ietf-quic-transport-00]).


	</t>	<t>As an example from an Experimental RFC, a response to transient
	</abstract>	events is discussed in <xref section="9.2" sectionFormat="of"
	</front>	target="RFC4782"/>.</t>
	<seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-congestion-	</section>
	control-00"/>


	</reference>	<section anchor="sudden-changes-in-the-path">
		<name>Sudden Changes in the Path</name>
		<t>An IETF transport is not tied to a specific Internet path or type
		of path. The set of routers that form a path can and do change with
		time. This will cause the properties of the path to change with
		respect to time. A proposed congestion control algorithm
		<bcp14>MUST</bcp14> evaluate the impact of changes in the path and be
		robust to changes in path characteristics on the interval of common
		Internet rerouting intervals.</t>
		</section>


	<reference anchor="ECN-Encaps">	<section anchor="multipath-transport">
	<front>	<name>Multipath Transport</name>
	<title>Guidelines for Adding Congestion Notification to Protocols that Enc	<t>Multipath transport protocols permit more than one path to be
	apsulate IP</title>	differentiated and used by a single connection at the sender. A
	<author fullname="Bob Briscoe" initials="B." surname="Briscoe">	multipath sender can schedule which packets travel on which of its
	<organization>Independent</organization>	active paths. This enables a trade-off in timeliness and
	</author>	reliability. There are various ways that multipath techniques can be
	<author fullname="John Kaippallimalil" initials="J." surname="Kaippallimal	used.</t>
	il">
	<organization>Futurewei</organization>
	</author>
	<date day="5" month="December" year="2023"/>
	<abstract>
	<t> The purpose of this document is to guide the design of congestion
	notification in any lower layer or tunnelling protocol that
	encapsulates IP. The aim is for explicit congestion signals to
	propagate consistently from lower layer protocols into IP. Then the
	IP internetwork layer can act as a portability layer to carry
	congestion notification from non-IP-aware congested nodes up to the
	transport layer (L4). Following these guidelines should assure
	interworking among IP layer and lower layer congestion notification
	mechanisms, whether specified by the IETF or other standards bodies.
	This document is included in BCP 89 and updates the single paragraph
	of advice to subnetwork designers about ECN in Section 13 of RFC
	3819, by replacing it with a reference to the whole of this document.


	</t>	<t>One example use is to provide failover from one path to another
	</abstract>	when the original path is no longer viable or provides inferior
	</front>	performance. Designs need to independently track the congestion state
	<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-ecn-encap-guideline	of each path and demonstrate independent congestion control for each
	s-22"/>	path being used. Authors of a proposed multipath congestion control
		algorithm that implements path failover <bcp14>MUST</bcp14> evaluate
		the harm to performance resulting from a change in the path and show
		that this does not result in flow starvation. Synchronization of
		failover (e.g., where multiple flows change their path on similar
		time frames) can also contribute to harm and/or reduce fairness. These
		effects also ought to be evaluated.</t>


	</reference>	<t>Another example use is concurrent multipath, where the transport
		protocol simultaneously schedules a flow to aggregate the capacity
		across multiple paths. The Internet provides no guarantee that
		different paths (e.g., using different endpoint addresses) are
		disjoint. This introduces additional implications. A congestion
		control algorithm proposal <bcp14>MUST</bcp14> evaluate the potential
		harm to other flows when the multiple paths share a common congested
		bottleneck or share resources that are coupled between different
		paths, such as an overall capacity limit. A proposal
		<bcp14>SHOULD</bcp14> consider the potential for harm to other
		flows. Synchronization of congestion control mechanisms (e.g., where
		multiple flows change their behavior on similar time frames) can also
		contribute to harm and/or reduce fairness. These effects also ought to
		be evaluated.</t>


	<reference anchor="HRX08" target="https://doi.org/10.1145/1400097.1400105">	<t>At the time of writing (2024), there are currently no Standards
	<front>	Track RFCs for concurrent multipath, but there is an Experimental RFC
	<title>CUBIC: a new TCP-friendly high-speed TCP variant</title>	<xref target="RFC6356"/> that specifies a concurrent multipath
	<author initials="S." surname="Ha" fullname="Sangtae Ha">	congestion control algorithm for Multipath TCP (MPTCP) <xref target="RFC
	<organization></organization>	8684"/>.</t>
	</author>	</section>
	<author initials="I." surname="Rhee" fullname="Injong Rhee">
	<organization></organization>
	</author>
	<author initials="L." surname="Xu" fullname="Lisong Xu">
	<organization></organization>
	</author>
	<date year="2008" month="July"/>
	</front>
	<seriesInfo name="ACM SIGOPS Operating Systems Review, vol. 42, no. 5, pp. 64-
	74" value=""/>
	</reference>
	<reference anchor="Tools" target="https://datatracker.ietf.org/doc/draft-irtf-tm
	rg-tools">
	<front>
	<title>Tools for the Evaluation of Simulation and Testbed Scenarios</title>
	<author initials="S." surname="Floyd">
	<organization></organization>
	</author>
	<author initials="E." surname="Kohler">
	<organization></organization>
	</author>
	<date year="2007" month="July"/>
	</front>
	<seriesInfo name="Work in Progress" value=""/>
	</reference>
	<reference anchor="Bufferbloat" target="https://queue.acm.org/detail.cfm?id=2071
	893">
	<front>
	<title>Bufferbloat: Dark Buffers in the Internet</title>
	<author initials="" surname="Kathleen Nichols">
	<organization></organization>
	</author>
	<date year="2011"/>
	</front>
	<seriesInfo name="ACM Queue Volume 9, Issue 11" value=""/>
	</reference>
	<reference anchor="BBRv1-Evaluation" target="https://ieeexplore.ieee.org/documen
	t/8117540">
	<front>
	<title>Experimental evaluation of BBR congestion control</title>
	<author initials="M." surname="Zitterbart">
	<organization></organization>
	</author>
	<date year="2017"/>
	</front>
	<seriesInfo name="2017 IEEE 25th International Conference on Network Protocols
	(ICNP)" value=""/>
	</reference>


	<reference anchor="RFC5033">	<section anchor="data-centers">
	<front>	<name>Data Centers</name> <t>Data centers are characterized by very
	<title>Specifying New Congestion Control Algorithms</title>	low latencies (< 2 ms). Many workloads involve bursty traffic where
	<author fullname="S. Floyd" initials="S." surname="Floyd"/>	many nodes complete a task at the same time. As a controlled
	<author fullname="M. Allman" initials="M." surname="Allman"/>	environment, data centers often deploy fabrics that employ rich
	<date month="August" year="2007"/>	signaling from switches to endpoints. Furthermore, the operator can
	<abstract>	often limit the number of operating congestion control algorithms.</t>
	<t>The IETF's standard congestion control schemes have been widely shown t
	o be inadequate for various environments (e.g., high-speed networks). Recent res
	earch has yielded many alternate congestion control schemes that significantly d
	iffer from the IETF's congestion control principles. Using these new congestion
	control schemes in the global Internet has possible ramifications to both the tr
	affic using the new congestion control and to traffic using the currently standa
	rdized congestion control. Therefore, the IETF must proceed with caution when de
	aling with alternate congestion control proposals. The goal of this document is
	to provide guidance for considering alternate congestion control algorithms with
	in the IETF. This document specifies an Internet Best Current Practices for the
	Internet Community, and requests discussion and suggestions for improvements.</t
	>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="133"/>
	<seriesInfo name="RFC" value="5033"/>
	<seriesInfo name="DOI" value="10.17487/RFC5033"/>
	</reference>


	<reference anchor="RFC8312">	<t>For these reasons, data center congestion controls are often
	<front>	distinct from those running elsewhere on the Internet (see <xref
	<title>CUBIC for Fast Long-Distance Networks</title>	target="controlled-environments"/>). A proposed congestion control
	<author fullname="I. Rhee" initials="I." surname="Rhee"/>	need not coexist well with all other algorithms if it is intended for
	<author fullname="L. Xu" initials="L." surname="Xu"/>	data centers, but the proposal <bcp14>SHOULD</bcp14> indicate which
	<author fullname="S. Ha" initials="S." surname="Ha"/>	are expected to safely coexist with it.</t>
	<author fullname="A. Zimmermann" initials="A." surname="Zimmermann"/>	</section>
	<author fullname="L. Eggert" initials="L." surname="Eggert"/>	</section>
	<author fullname="R. Scheffenegger" initials="R." surname="Scheffenegger"/>
	<date month="February" year="2018"/>
	<abstract>
	<t>CUBIC is an extension to the current TCP standards. It differs from the
	current TCP standards only in the congestion control algorithm on the sender si
	de. In particular, it uses a cubic function instead of a linear window increase
	function of the current TCP standards to improve scalability and stability under
	fast and long-distance networks. CUBIC and its predecessor algorithm have been
	adopted as defaults by Linux and have been used for many years. This document pr
	ovides a specification of CUBIC to enable third-party implementations and to sol
	icit community feedback through experimentation on the performance of CUBIC.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8312"/>
	<seriesInfo name="DOI" value="10.17487/RFC8312"/>
	</reference>


	<reference anchor="RFC8869">	<section anchor="security-considerations">
	<front>	<name>Security Considerations</name>
	<title>Evaluation Test Cases for Interactive Real-Time Media over Wireless N	<t>This document does not represent a change to any aspect of the TCP/IP
	etworks</title>	protocol suite; therefore, it does not directly impact Internet security.
	<author fullname="Z. Sarker" initials="Z." surname="Sarker"/>	The implementation of various facets of the Internet's current
	<author fullname="X. Zhu" initials="X." surname="Zhu"/>	congestion control algorithms do have security implications (e.g., as
	<author fullname="J. Fu" initials="J." surname="Fu"/>	outlined in <xref target="RFC5681"/>).</t>
	<date month="January" year="2021"/>	<t>Proposed congestion control algorithms <bcp14>MUST</bcp14> examine
	<abstract>	any potential security or privacy issues that may arise from their
	<t>The Real-time Transport Protocol (RTP) is a common transport choice for	design.</t>
	interactive multimedia communication applications. The performance of these app	</section>
	lications typically depends on a well-functioning congestion control algorithm.
	To ensure a seamless and robust user experience, a well-designed RTP-based conge
	stion control algorithm should work well across all access network types. This d
	ocument describes test cases for evaluating performances of candidate congestion
	control algorithms over cellular and Wi-Fi networks.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8869"/>
	<seriesInfo name="DOI" value="10.17487/RFC8869"/>
	</reference>


	<reference anchor="RFC6928">	<section anchor="iana-considerations">
	<front>	<name>IANA Considerations</name>
	<title>Increasing TCP's Initial Window</title>	<t>This document has no IANA actions.</t>
	<author fullname="J. Chu" initials="J." surname="Chu"/>	</section>
	<author fullname="N. Dukkipati" initials="N." surname="Dukkipati"/>	</middle>
	<author fullname="Y. Cheng" initials="Y." surname="Cheng"/>
	<author fullname="M. Mathis" initials="M." surname="Mathis"/>
	<date month="April" year="2013"/>
	<abstract>
	<t>This document proposes an experiment to increase the permitted TCP init
	ial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 s
	egments with a fallback to the existing recommendation when performance issues a
	re detected. It discusses the motivation behind the increase, the advantages and
	disadvantages of the higher initial window, and presents results from several l
	arge-scale experiments showing that the higher initial window improves the overa
	ll performance of many web services without resulting in a congestion collapse.
	The document closes with a discussion of usage and deployment for further experi
	mental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TC
	PM) working group.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6928"/>
	<seriesInfo name="DOI" value="10.17487/RFC6928"/>
	</reference>


	<reference anchor="RFC4614">	<!-- [rfced] We had the following additional questions related to
	<front>	references and citations in the document:
	<title>A Roadmap for Transmission Control Protocol (TCP) Specification Docum
	ents</title>
	<author fullname="M. Duke" initials="M." surname="Duke"/>
	<author fullname="R. Braden" initials="R." surname="Braden"/>
	<author fullname="W. Eddy" initials="W." surname="Eddy"/>
	<author fullname="E. Blanton" initials="E." surname="Blanton"/>
	<date month="September" year="2006"/>
	<abstract>
	<t>This document contains a "roadmap" to the Requests for Comments (RFC) d
	ocuments relating to the Internet's Transmission Control Protocol (TCP). This ro
	admap provides a brief summary of the documents defining TCP and various TCP ext
	ensions that have accumulated in the RFC series. This serves as a guide and quic
	k reference for both TCP implementers and other parties who desire information c
	ontained in the TCP-related RFCs. This memo provides information for the Interne
	t community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4614"/>
	<seriesInfo name="DOI" value="10.17487/RFC4614"/>
	</reference>


	<reference anchor="RFC3649">	a.) [BUFFERBLOAT] Would you like to use the following URL for this
	<front>	reference (as this URL has a DOI and an open access PDF)?
	<title>HighSpeed TCP for Large Congestion Windows</title>
	<author fullname="S. Floyd" initials="S." surname="Floyd"/>
	<date month="December" year="2003"/>
	<abstract>
	<t>The proposals in this document are experimental. While they may be depl
	oyed in the current Internet, they do not represent a consensus that this is the
	best method for high-speed congestion control. In particular, we note that alte
	rnative experimental proposals are likely to be forthcoming, and it is not well
	understood how the proposals in this document will interact with such alternativ
	e proposals. This document proposes HighSpeed TCP, a modification to TCP's conge
	stion control mechanism for use with TCP connections with large congestion windo
	ws. The congestion control mechanisms of the current Standard TCP constrains the
	congestion windows that can be achieved by TCP in realistic environments. For e
	xample, for a Standard TCP connection with 1500-byte packets and a 100 ms round-
	trip time, achieving a steady-state throughput of 10 Gbps would require an avera
	ge congestion window of 83,333 segments, and a packet drop rate of at most one c
	ongestion event every 5,000,000,000 packets (or equivalently, at most one conges
	tion event every 1 2/3 hours). This is widely acknowledged as an unrealistic con
	straint. To address his limitation of TCP, this document proposes HighSpeed TCP,
	and solicits experimentation and feedback from the wider community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3649"/>
	<seriesInfo name="DOI" value="10.17487/RFC3649"/>
	</reference>


	<reference anchor="RFC4782">	https://dl.acm.org/doi/10.1145/2063166.2071893
	<front>
	<title>Quick-Start for TCP and IP</title>
	<author fullname="S. Floyd" initials="S." surname="Floyd"/>
	<author fullname="M. Allman" initials="M." surname="Allman"/>
	<author fullname="A. Jain" initials="A." surname="Jain"/>
	<author fullname="P. Sarolahti" initials="P." surname="Sarolahti"/>
	<date month="January" year="2007"/>
	<abstract>
	<t>This document specifies an optional Quick-Start mechanism for transport
	protocols, in cooperation with routers, to determine an allowed sending rate at
	the start and, at times, in the middle of a data transfer (e.g., after an idle
	period). While Quick-Start is designed to be used by a range of transport protoc
	ols, in this document we only specify its use with TCP. Quick-Start is designed
	to allow connections to use higher sending rates when there is significant unuse
	d bandwidth along the path, and the sender and all of the routers along the path
	approve the Quick-Start Request.</t>
	<t>This document describes many paths where Quick-Start Requests would not
	be approved. These paths include all paths containing routers, IP tunnels, MPLS
	paths, and the like that do not support Quick- Start. These paths also include
	paths with routers or middleboxes that drop packets containing IP options. Quick
	-Start Requests could be difficult to approve over paths that include multi-acce
	ss layer- two networks. This document also describes environments where the Quic
	k-Start process could fail with false positives, with the sender incorrectly ass
	uming that the Quick-Start Request had been approved by all of the routers along
	the path. As a result of these concerns, and as a result of the difficulties an
	d seeming absence of motivation for routers, such as core routers to deploy Quic
	k-Start, Quick-Start is being proposed as a mechanism that could be of use in co
	ntrolled environments, and not as a mechanism that would be intended or appropri
	ate for ubiquitous deployment in the global Internet. This memo defines an Exper
	imental Protocol for the Internet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4782"/>
	<seriesInfo name="DOI" value="10.17487/RFC4782"/>
	</reference>


	<reference anchor="RFC9049">	b.) FYI - We have added the following RFCs to the Informative
	<front>	References section, as they are included in the text but were not
	<title>Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads N	cited as references.
	ot Taken)</title>
	<author fullname="S. Dawkins" initials="S." role="editor" surname="Dawkins"/
	>
	<date month="June" year="2021"/>
	<abstract>
	<t>This document is a product of the Path Aware Networking Research Group
	(PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog
	and analyze past efforts to develop and deploy Path Aware techniques, most of w
	hich were unsuccessful or at most partially successful, in order to extract insi
	ghts and lessons for Path Aware networking researchers.</t>
	<t>This document contains that catalog and analysis.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9049"/>
	<seriesInfo name="DOI" value="10.17487/RFC9049"/>
	</reference>


	<reference anchor="RFC8799">	RFC 9293
	<front>	RFC 4340
	<title>Limited Domains and Internet Protocols</title>	RFC 9260
	<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>	RFC 9000
	<author fullname="B. Liu" initials="B." surname="Liu"/>	RFC 8257
	<date month="July" year="2020"/>
	<abstract>
	<t>There is a noticeable trend towards network behaviors and semantics tha
	t are specific to a particular set of requirements applied within a limited regi
	on of the Internet. Policies, default parameters, the options supported, the sty
	le of network management, and security requirements may vary between such limite
	d regions. This document reviews examples of such limited domains (also known as
	controlled environments), notes emerging solutions, and includes a related taxo
	nomy. It then briefly discusses the standardization of protocols for limited dom
	ains. Finally, it shows the need for a precise definition of "limited domain mem
	bership" and for mechanisms to allow nodes to join a domain securely and to find
	other members, including boundary nodes.</t>
	<t>This document is the product of the research of the authors. It has bee
	n produced through discussions and consultation within the IETF but is not the p
	roduct of IETF consensus.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8799"/>
	<seriesInfo name="DOI" value="10.17487/RFC8799"/>
	</reference>


	<reference anchor="RFC3714">	-->
	<front>
	<title>IAB Concerns Regarding Congestion Control for Voice Traffic in the In
	ternet</title>
	<author fullname="S. Floyd" initials="S." role="editor" surname="Floyd"/>
	<author fullname="J. Kempf" initials="J." role="editor" surname="Kempf"/>
	<date month="March" year="2004"/>
	<abstract>
	<t>This document discusses IAB concerns about effective end-to-end congest
	ion control for best-effort voice traffic in the Internet. These concerns have t
	o do with fairness, user quality, and with the dangers of congestion collapse. T
	he concerns are particularly relevant in light of the absence of a widespread Qu
	ality of Service (QoS) deployment in the Internet, and the likelihood that this
	situation will not change much in the near term. This document is not making any
	recommendations about deployment paths for Voice over Internet Protocol (VoIP)
	in terms of QoS support, and is not claiming that best-effort service can be rel
	ied upon to give acceptable performance for VoIP. We are merely observing that v
	oice traffic is occasionally deployed as best-effort traffic over some links in
	the Internet, that we expect this occasional deployment to continue, and that we
	have concerns about the lack of effective end-to-end congestion control for thi
	s best-effort voice traffic. This memo provides information for the Internet com
	munity.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3714"/>
	<seriesInfo name="DOI" value="10.17487/RFC3714"/>
	</reference>


	<reference anchor="RFC6298">	<back>
	<front>	<displayreference target="RFC9599" to="ECN-ENCAPS"/>
	<title>Computing TCP's Retransmission Timer</title>	<displayreference target="I-D.cardwell-iccrg-bbr-congestion-control" to="BBR
	<author fullname="V. Paxson" initials="V." surname="Paxson"/>	"/>
	<author fullname="M. Allman" initials="M." surname="Allman"/>	<displayreference target="I-D.irtf-tmrg-tools" to="TOOLS"/>
	<author fullname="J. Chu" initials="J." surname="Chu"/>	<references>
	<author fullname="M. Sargent" initials="M." surname="Sargent"/>	<name>References</name>
	<date month="June" year="2011"/>	<references>
	<abstract>	<name>Normative References</name>
	<t>This document defines the standard algorithm that Transmission Control	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	Protocol (TCP) senders are required to use to compute and manage their retransmi	914.xml"/>
	ssion timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upg	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	rades the requirement of supporting the algorithm from a SHOULD to a MUST. This	085.xml"/>
	document obsoletes RFC 2988. [STANDARDS-TRACK]</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	</abstract>	438.xml"/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<seriesInfo name="RFC" value="6298"/>	119.xml"/>
	<seriesInfo name="DOI" value="10.17487/RFC6298"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	</reference>	174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		961.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		681.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		002.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		083.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		141.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		084.xml"/>
		</references>
		<references>
		<name>Informative References</name>


	<reference anchor="RFC8836">	<!-- [-00] [BBRv1] [I-D.cardwell-iccrg-bbr-congestion-control]
	<front>	Note to PE: This is the first version of [BBRv1]. -->
	<title>Congestion Control Requirements for Interactive Real-Time Media</titl
	e>
	<author fullname="R. Jesup" initials="R." surname="Jesup"/>
	<author fullname="Z. Sarker" initials="Z." role="editor" surname="Sarker"/>
	<date month="January" year="2021"/>
	<abstract>
	<t>Congestion control is needed for all data transported across the Intern
	et, in order to promote fair usage and prevent congestion collapse. The requirem
	ents for interactive, point-to-point real-time multimedia, which needs low-delay
	, semi-reliable data delivery, are different from the requirements for bulk tran
	sfer like FTP or bursty transfers like web pages. Due to an increasing amount of
	RTP-based real-time media traffic on the Internet (e.g., with the introduction
	of the Web Real-Time Communication (WebRTC)), it is especially important to ensu
	re that this kind of traffic is congestion controlled.</t>
	<t>This document describes a set of requirements that can be used to evalu
	ate other congestion control mechanisms in order to figure out their fitness for
	this purpose, and in particular to provide a set of possible requirements for a
	real-time media congestion avoidance technique.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8836"/>
	<seriesInfo name="DOI" value="10.17487/RFC8836"/>
	</reference>


	<reference anchor="RFC8868">	<reference anchor="BBRv1" target="https://datatracker.ietf.org/doc/html/d
	<front>	raft-cardwell-iccrg-bbr-congestion-control-00">
	<title>Evaluating Congestion Control for Interactive Real-Time Media</title>	<front>
	<author fullname="V. Singh" initials="V." surname="Singh"/>	<title>BBR Congestion Control</title>
	<author fullname="J. Ott" initials="J." surname="Ott"/>	<author initials="N." surname="Cardwell" fullname="Neal Cardwell">
	<author fullname="S. Holmer" initials="S." surname="Holmer"/>	<organization>Google</organization>
	<date month="January" year="2021"/>	</author>
	<abstract>	<author initials="Y." surname="Cheng" fullname="Yuchung Cheng">
	<t>The Real-Time Transport Protocol (RTP) is used to transmit media in tel	<organization>Google</organization>
	ephony and video conferencing applications. This document describes the guidelin	</author>
	es to evaluate new congestion control algorithms for interactive point-to-point	<author initials="S. H." surname="Yeganeh" fullname="Soheil Hassas Ye
	real-time media.</t>	ganeh">
	</abstract>	<organization>Google</organization>
	</front>	</author>
	<seriesInfo name="RFC" value="8868"/>	<author initials="V." surname="Jacobson" fullname="Van Jacobson">
	<seriesInfo name="DOI" value="10.17487/RFC8868"/>	<organization>Google</organization>
	</reference>	</author>
		<date month="July" day="3" year="2017"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-conge
		stion-control-00"/>
		</reference>


	<reference anchor="RFC8867">	<!-- [-02] [BBR-DRAFT] [I-D.cardwell-iccrg-bbr-congestion-control] -->
	<front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
	<title>Test Cases for Evaluating Congestion Control for Interactive Real-Tim	draft-cardwell-iccrg-bbr-congestion-control-02.xml"/>
	e Media</title>
	<author fullname="Z. Sarker" initials="Z." surname="Sarker"/>
	<author fullname="V. Singh" initials="V." surname="Singh"/>
	<author fullname="X. Zhu" initials="X." surname="Zhu"/>
	<author fullname="M. Ramalho" initials="M." surname="Ramalho"/>
	<date month="January" year="2021"/>
	<abstract>
	<t>The Real-time Transport Protocol (RTP) is used to transmit media in mul
	timedia telephony applications. These applications are typically required to imp
	lement congestion control. This document describes the test cases to be used in
	the performance evaluation of such congestion control algorithms in a controlled
	environment.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8867"/>
	<seriesInfo name="DOI" value="10.17487/RFC8867"/>
	</reference>


	<reference anchor="RFC9392">	<!-- [ECN-ENCAPS] I-D was published as RFC9599. Replaced I-D with RFC 9599. -->
	<front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<title>Sending RTP Control Protocol (RTCP) Feedback for Congestion Control i	599.xml"/>
	n Interactive Multimedia Conferences</title>
	<author fullname="C. Perkins" initials="C." surname="Perkins"/>
	<date month="April" year="2023"/>
	<abstract>
	<t>This memo discusses the rate at which congestion control feedback can b
	e sent using the RTP Control Protocol (RTCP) and the suitability of RTCP for imp
	lementing congestion control for unicast multimedia applications.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9392"/>
	<seriesInfo name="DOI" value="10.17487/RFC9392"/>
	</reference>


	<reference anchor="RFC3819">	<!-- [HRX08] -->
	<front>	<reference anchor="HRX08" target="https://doi.org/10.1145/1400097.140010
	<title>Advice for Internet Subnetwork Designers</title>	5">
	<author fullname="P. Karn" initials="P." role="editor" surname="Karn"/>	<front>
	<author fullname="C. Bormann" initials="C." surname="Bormann"/>	<title>CUBIC: a new TCP-friendly high-speed TCP variant</title>
	<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>	<author initials="S." surname="Ha" fullname="Sangtae Ha">
	<author fullname="D. Grossman" initials="D." surname="Grossman"/>	<organization/>
	<author fullname="R. Ludwig" initials="R." surname="Ludwig"/>	</author>
	<author fullname="J. Mahdavi" initials="J." surname="Mahdavi"/>	<author initials="I." surname="Rhee" fullname="Injong Rhee">
	<author fullname="G. Montenegro" initials="G." surname="Montenegro"/>	<organization/>
	<author fullname="J. Touch" initials="J." surname="Touch"/>	</author>
	<author fullname="L. Wood" initials="L." surname="Wood"/>	<author initials="L." surname="Xu" fullname="Lisong Xu">
	<date month="July" year="2004"/>	<organization/>
	<abstract>	</author>
	<t>This document provides advice to the designers of digital communication	<date year="2008" month="July"/>
	equipment, link-layer protocols, and packet-switched local networks (collective	</front>
	ly referred to as subnetworks), who wish to support the Internet protocols but m	<refcontent>ACM SIGOPS Operating Systems Review, vol. 42, no. 5, pp. 6
	ay be unfamiliar with the Internet architecture and the implications of their de	4-74</refcontent>
	sign choices on the performance and efficiency of the Internet. This document sp	<seriesInfo name="DOI" value="10.1145/1400097.1400105"/>
	ecifies an Internet Best Current Practices for the Internet Community, and reque	</reference>
	sts discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="89"/>
	<seriesInfo name="RFC" value="3819"/>
	<seriesInfo name="DOI" value="10.17487/RFC3819"/>
	</reference>


	<reference anchor="RFC8290">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ir
	<front>	tf-tmrg-tools-05.xml"/>
	<title>The Flow Queue CoDel Packet Scheduler and Active Queue Management Alg
	orithm</title>
	<author fullname="T. Hoeiland-Joergensen" initials="T." surname="Hoeiland-Jo
	ergensen"/>
	<author fullname="P. McKenney" initials="P." surname="McKenney"/>
	<author fullname="D. Taht" initials="D." surname="Taht"/>
	<author fullname="J. Gettys" initials="J." surname="Gettys"/>
	<author fullname="E. Dumazet" initials="E." surname="Dumazet"/>
	<date month="January" year="2018"/>
	<abstract>
	<t>This memo presents the FQ-CoDel hybrid packet scheduler and Active Queu
	e Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reduc
	ing latency.</t>
	<t>FQ-CoDel mixes packets from multiple flows and reduces the impact of he
	ad-of-line blocking from bursty traffic. It provides isolation for low-rate traf
	fic such as DNS, web, and videoconferencing traffic. It improves utilisation acr
	oss the networking fabric, especially for bidirectional traffic, by keeping queu
	e lengths short, and it can be implemented in a memory- and CPU-efficient fashio
	n across a wide range of hardware.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8290"/>
	<seriesInfo name="DOI" value="10.17487/RFC8290"/>
	</reference>


	<reference anchor="RFC8033">	<reference anchor="BUFFERBLOAT" target="https://queue.acm.org/detail.cfm
	<front>	?id=2071893">
	<title>Proportional Integral Controller Enhanced (PIE): A Lightweight Contro	<front>
	l Scheme to Address the Bufferbloat Problem</title>	<title>Bufferbloat: Dark Buffers in the Internet</title>
	<author fullname="R. Pan" initials="R." surname="Pan"/>	<author initials="K." surname="Nichols">
	<author fullname="P. Natarajan" initials="P." surname="Natarajan"/>	<organization/>
	<author fullname="F. Baker" initials="F." surname="Baker"/>	</author>
	<author fullname="G. White" initials="G." surname="White"/>	<author initials="J." surname="Gettys">
	<date month="February" year="2017"/>	<organization/>
	<abstract>	</author>
	<t>Bufferbloat is a phenomenon in which excess buffers in the network caus	<date month="November" year="2011"/>
	e high latency and latency variation. As more and more interactive applications	</front>
	(e.g., voice over IP, real-time video streaming, and financial transactions) run	<refcontent>ACM Queue Volume 9, Issue 11</refcontent>
	in the Internet, high latency and latency variation degrade application perform	</reference>
	ance. There is a pressing need to design intelligent queue management schemes th
	at can control latency and latency variation, and hence provide desirable qualit
	y of service to users.</t>
	<t>This document presents a lightweight active queue management design cal
	led "PIE" (Proportional Integral controller Enhanced) that can effectively contr
	ol the average queuing latency to a target value. Simulation results, theoretica
	l analysis, and Linux testbed results have shown that PIE can ensure low latency
	and achieve high link utilization under various congestion situations. The desi
	gn does not require per-packet timestamps, so it incurs very little overhead and
	is simple enough to implement in both hardware and software.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8033"/>
	<seriesInfo name="DOI" value="10.17487/RFC8033"/>
	</reference>


	<reference anchor="RFC9332">	<!-- [BBRv1-EVALUATION] -->
	<front>	<reference anchor="BBRv1-EVALUATION" target="https://ieeexplore.ieee.org
	<title>Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low	/document/8117540">
	Loss, and Scalable Throughput (L4S)</title>	<front>
	<author fullname="K. De Schepper" initials="K." surname="De Schepper"/>	<title>Experimental evaluation of BBR congestion control</title>
	<author fullname="B. Briscoe" initials="B." role="editor" surname="Briscoe"/	<author initials="M." surname="Hock">
	>	<organization/>
	<author fullname="G. White" initials="G." surname="White"/>	</author>
	<date month="January" year="2023"/>	<author initials="R." surname="Bless">
	<abstract>	<organization/>
	<t>This specification defines a framework for coupling the Active Queue Ma	</author>
	nagement (AQM) algorithms in two queues intended for flows with different respon	<author initials="M." surname="Zitterbart">
	ses to congestion. This provides a way for the Internet to transition from the s	<organization/>
	caling problems of standard TCP-Reno-friendly ('Classic') congestion controls to	</author>
	the family of 'Scalable' congestion controls. These are designed for consistent	<date year="2017"/>
	ly very low queuing latency, very low congestion loss, and scaling of per-flow t	</front>
	hroughput by using Explicit Congestion Notification (ECN) in a modified way. Unt	<refcontent>2017 IEEE 25th International Conference on Network Protoco
	il the Coupled Dual Queue (DualQ), these Scalable L4S congestion controls could	ls (ICNP)</refcontent>
	only be deployed where a clean-slate environment could be arranged, such as in p	<seriesInfo name="DOI" value="10.1109/ICNP.2017.8117540"/>
	rivate data centres.</t>	</reference>
	<t>This specification first explains how a Coupled DualQ works. It then gi
	ves the normative requirements that are necessary for it to work well. All this
	is independent of which two AQMs are used, but pseudocode examples of specific A
	QMs are given in appendices.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9332"/>
	<seriesInfo name="DOI" value="10.17487/RFC9332"/>
	</reference>


	<reference anchor="RFC8087">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	<front>	033.xml"/>
	<title>The Benefits of Using Explicit Congestion Notification (ECN)</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
	<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>	12.xml"/>
	<author fullname="M. Welzl" initials="M." surname="Welzl"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<date month="March" year="2017"/>	869.xml"/>
	<abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<t>The goal of this document is to describe the potential benefits of appl	928.xml"/>
	ications using a transport that enables Explicit Congestion Notification (ECN).	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	The document outlines the principal gains in terms of increased throughput, redu	614.xml"/>
	ced delay, and other benefits when ECN is used over a network path that includes	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	equipment that supports Congestion Experienced (CE) marking. It also discusses	649.xml"/>
	challenges for successful deployment of ECN. It does not propose new algorithms	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	to use ECN nor does it describe the details of implementation of ECN in endpoint	782.xml"/>
	devices (Internet hosts), routers, or other network devices.</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	</abstract>	049.xml"/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<seriesInfo name="RFC" value="8087"/>	799.xml"/>
	<seriesInfo name="DOI" value="10.17487/RFC8087"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	</reference>	714.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		298.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		836.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		868.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		867.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		392.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		819.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		290.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		033.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		332.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		087.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		168.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		567.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		488.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
		653.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		356.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		414.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		684.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		166.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
		93.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43
		40.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
		60.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
		00.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
		57.xml"/>


	<reference anchor="RFC3168">	</references>
	<front>	</references>
	<title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
	<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan"/>
	<author fullname="S. Floyd" initials="S." surname="Floyd"/>
	<author fullname="D. Black" initials="D." surname="Black"/>
	<date month="September" year="2001"/>
	<abstract>
	<t>This memo specifies the incorporation of ECN (Explicit Congestion Notif
	ication) to TCP and IP, including ECN's use of two bits in the IP header. [STAND
	ARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3168"/>
	<seriesInfo name="DOI" value="10.17487/RFC3168"/>
	</reference>


	<reference anchor="RFC7567">	<section numbered="false" anchor="acknowledgments">
	<front>	<name>Acknowledgments</name>
	<title>IETF Recommendations Regarding Active Queue Management</title>
	<author fullname="F. Baker" initials="F." role="editor" surname="Baker"/>
	<author fullname="G. Fairhurst" initials="G." role="editor" surname="Fairhur
	st"/>
	<date month="July" year="2015"/>
	<abstract>
	<t>This memo presents recommendations to the Internet community concerning
	measures to improve and preserve Internet performance. It presents a strong rec
	ommendation for testing, standardization, and widespread deployment of active qu
	eue management (AQM) in network devices to improve the performance of today's In
	ternet. It also urges a concerted effort of research, measurement, and ultimate
	deployment of AQM mechanisms to protect the Internet from flows that are not suf
	ficiently responsive to congestion notification.</t>
	<t>Based on 15 years of experience and new research, this document replace
	s the recommendations of RFC 2309.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="197"/>
	<seriesInfo name="RFC" value="7567"/>
	<seriesInfo name="DOI" value="10.17487/RFC7567"/>
	</reference>


	<reference anchor="RFC2488">	<t><contact fullname="Sally Floyd"/> and <contact fullname="Mark
	<front>	Allman"/> were the authors of this document's predecessor, <xref
	<title>Enhancing TCP Over Satellite Channels using Standard Mechanisms</titl	target="RFC5033"/>, which served the community well for over a
	e>	decade.</t>
	<author fullname="M. Allman" initials="M." surname="Allman"/>	<t>Thanks to <contact fullname="Richard Scheffenegger"/> for helping to
	<author fullname="D. Glover" initials="D." surname="Glover"/>	get this revision process started.</t>
	<author fullname="L. Sanchez" initials="L." surname="Sanchez"/>	<t>The editors would like to thank <contact fullname="Mohamed
	<date month="January" year="1999"/>	Boucadair"/>, <contact fullname="Neal Cardwell"/>, <contact
	<abstract>	fullname="Reese Enghardt"/>, <contact fullname="Jonathan Lennox"/>,
	<t>The Transmission Control Protocol (TCP) provides reliable delivery of d	<contact fullname="Matt Mathis"/>, <contact fullname="Zahed Sarker"/>,
	ata across any network path, including network paths containing satellite channe	<contact fullname="Juergen Schoenwaelder"/>, <contact fullname="Dave
	ls. While TCP works over satellite channels there are several IETF standardized	Taht"/>, <contact fullname="Sean Turner"/>, <contact fullname="Michael
	mechanisms that enable TCP to more effectively utilize the available capacity of	Welzl"/>, <contact fullname="Magnus Westerlund"/>, and <contact
	the network path. This document outlines some of these TCP mitigations. This do	fullname="Greg White"/> for suggesting improvements to this
	cument specifies an Internet Best Current Practices for the Internet Community,	document.</t>
	and requests discussion and suggestions for improvements.</t>	<t>Discussions with <contact fullname="Lars Eggert"/> and <contact
	</abstract>	fullname="Aaron Falk"/> seeded the original <xref target="RFC5033"/>. <con
	</front>	tact
	<seriesInfo name="BCP" value="28"/>	fullname="Bob Briscoe"/>, <contact fullname="Gorry Fairhurst"/>,
	<seriesInfo name="RFC" value="2488"/>	<contact fullname="Doug Leith"/>, <contact fullname="Jitendra Padhye"/>,
	<seriesInfo name="DOI" value="10.17487/RFC2488"/>	<contact fullname="Colin Perkins"/>, <contact fullname="Pekka Savola"/>,
	</reference>	members of TSVWG, and participants at the TCP Workshop at Microsoft
		Research all provided feedback and contributions to that document. It
		also drew from <xref target="RFC5166"/>.</t>
		</section>


	<reference anchor="RFC4653">	<section anchor="contributors" numbered="false" toc="include" removeInRFC="f
	<front>	alse">
	<title>Improving the Robustness of TCP to Non-Congestion Events</title>	<name>Contributors</name>
	<author fullname="S. Bhandarkar" initials="S." surname="Bhandarkar"/>
	<author fullname="A. L. N. Reddy" initials="A. L. N." surname="Reddy"/>
	<author fullname="M. Allman" initials="M." surname="Allman"/>
	<author fullname="E. Blanton" initials="E." surname="Blanton"/>
	<date month="August" year="2006"/>
	<abstract>
	<t>This document specifies Non-Congestion Robustness (NCR) for TCP. In the
	absence of explicit congestion notification from the network, TCP uses loss as
	an indication of congestion. One of the ways TCP detects loss is using the arriv
	al of three duplicate acknowledgments. However, this heuristic is not always cor
	rect, notably in the case when network paths reorder segments (for whatever reas
	on), resulting in degraded performance. TCP-NCR is designed to mitigate this deg
	raded performance by increasing the number of duplicate acknowledgments required
	to trigger loss recovery, based on the current state of the connection, in an e
	ffort to better disambiguate true segment loss from segment reordering. This doc
	ument specifies the changes to TCP, as well as the costs and benefits of these m
	odifications. This memo defines an Experimental Protocol for the Internet commun
	ity.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4653"/>
	<seriesInfo name="DOI" value="10.17487/RFC4653"/>
	</reference>


	<reference anchor="RFC6356">	<contact initials="C." surname="Huitema" fullname="Christian Huitema">
	<front>	<organization>Private Octopus, Inc.</organization>
	<title>Coupled Congestion Control for Multipath Transport Protocols</title>	<address>
	<author fullname="C. Raiciu" initials="C." surname="Raiciu"/>	<email>huitema@huitema.net</email>
	<author fullname="M. Handley" initials="M." surname="Handley"/>	</address>
	<author fullname="D. Wischik" initials="D." surname="Wischik"/>	</contact>
	<date month="October" year="2011"/>	</section>
	<abstract>	</back>
	<t>Often endpoints are connected by multiple paths, but communications are
	usually restricted to a single path per connection. Resource usage within the n
	etwork would be more efficient were it possible for these multiple paths to be u
	sed concurrently. Multipath TCP is a proposal to achieve multipath transport in
	TCP.</t>
	<t>New congestion control algorithms are needed for multipath transport pr
	otocols such as Multipath TCP, as single path algorithms have a series of issues
	in the multipath context. One of the prominent problems is that running existin
	g algorithms such as standard TCP independently on each path would give the mult
	ipath flow more than its fair share at a bottleneck link traversed by more than
	one of its subflows. Further, it is desirable that a source with multiple paths
	available will transfer more traffic using the least congested of the paths, ach
	ieving a property called "resource pooling" where a bundle of links effectively
	behaves like one shared link with bigger capacity. This would increase the overa
	ll efficiency of the network and also its robustness to failure.</t>
	<t>This document presents a congestion control algorithm that couples the
	congestion control algorithms running on different subflows by linking their inc
	rease functions, and dynamically controls the overall aggressiveness of the mult
	ipath flow. The result is a practical algorithm that is fair to TCP at bottlenec
	ks while moving traffic away from congested links. This document defines an Expe
	rimental Protocol for the Internet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6356"/>
	<seriesInfo name="DOI" value="10.17487/RFC6356"/>
	</reference>


	<reference anchor="RFC8684">	<!--[rfced] Note that we have cut the "Evolution of RFC5033bis"
	<front>	section. Generally, change logs only exist in published RFCs in
	<title>TCP Extensions for Multipath Operation with Multiple Addresses</title	obsoleting documents as a "Changes Since RFC ####" section, which
	>	highlights the substantive changes that took place between the
	<author fullname="A. Ford" initials="A." surname="Ford"/>	last published RFC and this one (i.e., mentions errata addressed or
	<author fullname="C. Raiciu" initials="C." surname="Raiciu"/>	a security consideration that has changed, etc.). If the section
	<author fullname="M. Handley" initials="M." surname="Handley"/>	should be kept, may we suggest something like:
	<author fullname="O. Bonaventure" initials="O." surname="Bonaventure"/>
	<author fullname="C. Paasch" initials="C." surname="Paasch"/>
	<date month="March" year="2020"/>
	<abstract>
	<t>TCP/IP communication is currently restricted to a single path per conne
	ction, yet multiple paths often exist between peers. The simultaneous use of the
	se multiple paths for a TCP/IP session would improve resource usage within the n
	etwork and thus improve user experience through higher throughput and improved r
	esilience to network failure.</t>
	<t>Multipath TCP provides the ability to simultaneously use multiple paths
	between peers. This document presents a set of extensions to traditional TCP to
	support multipath operation. The protocol offers the same type of service to ap
	plications as TCP (i.e., a reliable bytestream), and it provides the components
	necessary to establish and use multiple TCP flows across potentially disjoint pa
	ths.</t>
	<t>This document specifies v1 of Multipath TCP, obsoleting v0 as specified
	in RFC 6824, through clarifications and modifications primarily driven by deplo
	yment experience.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8684"/>
	<seriesInfo name="DOI" value="10.17487/RFC8684"/>
	</reference>


	<reference anchor="RFC5166">	Perhaps:
	<front>	Changes Since RFC 5033
	<title>Metrics for the Evaluation of Congestion Control Mechanisms</title>
	<author fullname="S. Floyd" initials="S." role="editor" surname="Floyd"/>
	<date month="March" year="2008"/>
	<abstract>
	<t>This document discusses the metrics to be considered in an evaluation o
	f new or modified congestion control mechanisms for the Internet. These include
	metrics for the evaluation of new transport protocols, of proposed modifications
	to TCP, of application-level congestion control, and of Active Queue Management
	(AQM) mechanisms in the router. This document is the first in a series of docum
	ents aimed at improving the models that we use in the evaluation of transport pr
	otocols.</t>
	<t>This document is a product of the Transport Modeling Research Group (TM
	RG), and has received detailed feedback from many members of the Research Group
	(RG). As the document tries to make clear, there is not necessarily a consensus
	within the research community (or the IETF community, the vendor community, the
	operations community, or any other community) about the metrics that congestion
	control mechanisms should be designed to optimize, in terms of trade-offs betwee
	n throughput and delay, fairness between competing flows, and the like. However,
	we believe that there is a clear consensus that congestion control mechanisms s
	hould be evaluated in terms of trade-offs between a range of metrics, rather tha
	n in terms of optimizing for a single metric. This memo provides information for
	the Internet community.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5166"/>
	<seriesInfo name="DOI" value="10.17487/RFC5166"/>
	</reference>


	</references>	* Harmonized the "proposed congestion control algorithm"


	<?line 824?>	* Examined BCP 14 keywords and consistency with other RFCs


	<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>	* Added text on constrained environments/limited domains and circuit
		breakers and aligned with other RFCs


	<t>Sally Floyd and Mark Allman were the authors of this document's predecessor,	* Added discussion of real-time protocols, short flows, AQM response,
	<xref target="RFC5033"/>, which served the community well for over a decade.</t>	multipath transports


	<t>Thanks to Richard Scheffenegger for helping to get this revision process	* Listed properties of wired networks
	started.</t>


	<t>The editors would like to thank Mohamed Boucadair, Neal Cardwell, Reese	* Added sections addressing IoT and Multicast (noting this is out of scope)
	Enghardt, Jonathan Lennox, Matt Mathis, Zahed Sarker, Juergen Schoenwaelder,
	Dave Taht, Sean Turner, Michael Welzl, Magnus Westerlund, and Greg White for
	suggesting improvements to this document.</t>


	<t>Discussions with Lars Eggert and Aaron Falk seeded the original RFC5033. Bob	* Rewrote the "Document Status" section
	Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye, Colin Perkins, Pekka
	Savola, members of TSVWG, and participants at the TCP Workshop at Microsoft
	Research all provided feedback and contributions to that document. It also drew
	from <xref target="RFC5166"/>.</t>


	</section>	* Added improved first sentence of Abstract and Introduction
	<section numbered="false" anchor="evolution-of-rfc5033bis"><name>Evolution of RF
	C5033bis</name>


	<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-06"><name>Sin	* Reorganized central sections of the document
	ce draft-ietf-ccwg-rfc5033bis-06</name>
	<t><list style="symbols">
	<t>OPSDIR review</t>
	<t>ARTART review</t>
	</list></t>


	</section>	* Added QUIC, other congestion control standards
	<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-05"><name>Sin
	ce draft-ietf-ccwg-rfc5033bis-05</name>
	<t><list style="symbols">
	<t>AD evaluation comments</t>
	</list></t>


	</section>	* Added wireless environments
	<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-04"><name>Sin
	ce draft-ietf-ccwg-rfc5033bis-04</name>
	<t><list style="symbols">
	<t>Editorial pass after shepherd review.</t>
	</list></t>


	</section>	* Aligned motivation for this work with the CCWG charter
	<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-03"><name>Sin
	ce draft-ietf-ccwg-rfc5033bis-03</name>
	<t><list style="symbols">
	<t>Harmonised the "proposed congestion control algorithm"</t>
	<t>Addressed issues.</t>
	<t>Examined RFC-2119 keywords and consistency with other RFCs.</t>
	<t>Added text on constrained environments/limited domains</t>
	<t>Added text on circuit breakers and aligned with other RFCs.</t>
	<t>Several editorial passes</t>
	</list></t>


	</section>	* Refined discussion of Quick-Start
	<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-02"><name>Sin
	ce draft-ietf-ccwg-rfc5033bis-02</name>


	<t><list style="symbols">	* Included updated text suggested by Dave Taht
	<t>Added discussion of real-time protocols</t>
	<t>Added discussion of short flows</t>
	<t>Listed properties of wired networks</t>
	<t>Added IoT section</t>
	<t>Added discussion of AQM response</t>
	<t>Rewrote the "Document Status" section</t>
	<t>Adding improved first sentence of abstract and intro.</t>
	<t>Added section on Multicast, noting this is out of scope</t>
	<t>Editorial changes</t>
	</list></t>


	</section>	* Added criterion for bufferbloat
	<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-01"><name>Sin
	ce draft-ietf-ccwg-rfc5033bis-01</name>


	<t><list style="symbols">	* Mentioned CUBIC and BBR as motivation
	<t>Added discussion of multipath transports</t>
	<t>Totally reorganized central sections of the draft</t>
	</list></t>


	</section>	-->
	<section numbered="false" anchor="since-draft-ietf-ccwg-rfc5033bis-00"><name>Sin
	ce draft-ietf-ccwg-rfc5033bis-00</name>


	<t><list style="symbols">	<!--[rfced] We note that there are a number of instances in which an
	<t>Added QUIC, other congestion control standards</t>	algorithm or a proposed algorithm takes on human abilities.
	<t>Added wireless environments</t>	Please review the text with this in mind and let us know if any
	<t>Aligned motivation for this work with the CCWG charter</t>	updates should be made. Some examples below (not exhaustive):
	<t>Refined discussion of QuickStart</t>
	</list></t>


	</section>	Original:
	<section numbered="false" anchor="since-draft-scheffenegger-congress-rfc5033bis-	A proposed congestion control algorithm SHOULD explore...
	00"><name>Since draft-scheffenegger-congress-rfc5033bis-00</name>


	<t><list style="symbols">	Perhaps:
	<t>Renamed file to reflect WG adpotion</t>	A proposal for a congestion control algorithm SHOULD explore...
	<t>Updated authorship and acknowledgements.</t>
	<t>Include updated text suggested by Dave Taht</t>
	<t>Added criterion for bufferbloat</t>
	<t>Mentioned CUBIC and BBR as motivation</t>
	<t>Include section to track updates between revisions</t>
	<t>Update references</t>
	</list></t>


	</section>	Original:
	<section numbered="false" anchor="since-rfc5033"><name>Since RFC5033</name>	A proposed congestion control algorithm ought not to presume...


	<t><list style="symbols">	Perhaps:
	<t>converted to Markdown and xml2rfc v3</t>	Authors of a proposed congestion control algorithm ought not to presume...
	<t>various formatting changes.</t>
	</list></t>


	</section>	Original:
	</section>	A proposed congestion control algorithm MUST clearly explain any
		deviations from [RFC2914] and [RFC7141].


	<section anchor="contributors" numbered="false" toc="include" removeInRFC="f	Perhaps:
	alse">	A proposal for a congestion control algorithm MUST clearly explain any
	<name>Contributors</name>	deviations from [RFC2914] and [RFC7141].
	<contact initials="C." surname="Huitema" fullname="Christian Huitema">	-->
	<organization>Private Octopus, Inc.</organization>
	<address>
	<email>huitema@huitema.net</email>
	</address>
	</contact>
	</section>


	</back>	<!-- [rfced] FYI - We have added expansions for abbreviations upon
		first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
		review each expansion in the document carefully to ensure
		correctness.


	<!-- ##markdown-source:	Explicit Congestion Notification (ECN)
	H4sIAAAAAAAAA7V9627cSJLu/3wKHvWPkYCqast3u89iRpZlt2Z9UUvq8V4w	Multipath TCP (MPTCP)
	WLCKWVVss8gakiW52jCwD7Ln5fZJTnwRkTeqJKsX2MVi2pLIZGRk3G85Ho9N
	X/aVfZntXaztrJxvy3qRfbDX2XFTL2zXl02Nf/ZtU2VH1aJpy3656vZMPp22
	9ope42ePk78VzazOV7Rm0ebzflzafj6eza4X43Y+e/Lg0aNp2Y2rvKfVzYz+
	Qy9uX2bT2dp0fWvz1cvs9OTyjWmmXVNZeuplhpeMKdfty6xvN13/8MGDFw8e
	mpyefpm9tbVt88pcN+3nRdts1i8Jnk9vzWe7pV8VtFrd27a2/fg1wDH0lbwu
	/iOvmppA3NrOdKu87f/jH5uGP1Y3Zl2+zP69b2ajrGtagmne0b+2K/zj78Zc
	2XpjX5osc1+7ialPBAsQ+RZPZPvY/AG9sMrL6mWGn/4CpEyadoFlCG2b6cuM
	8URYwt9/DKgyxuSbftm09MkxPZ5lZU1gvp9krzefLf9CsP2edlHW4be0el6X
	v+eAjNDUNIvKZu/eHfMfrcCy4ncmy0lBb/1lgV9OZs2KH6GN0Kq2KPumTT79
	dpK9yct2uWnpBMP33zZFa4vBn1Igfq3LK9t2Zb/Nmnl2NLVtYW0dA0TE0G7/
	YtvFJJ8W9SSfTTafb0IzA57L6aYfYuV4kv28KXtaLALseNmWdD55nfwtheys
	La+IFrOPs75Zb+i8T+vZJAZsKa/+Rf87IYIypm7aFS1wReRgynoe/ZRlr16d
	j5kBiALHryezvC2ubVWNy9msXYyJfcYzTzjjmRCOvnd1+IffHD94gJdPjj+M
	T+pZvu7kXaapvrsisrKzemzxp/FiUxa2KmsifXrl5/N/efD8JW/ViYLjX1+d
	Hr/M8qwm5r48PhvP29LWRbXNluViOe7Wls6Zfp9d5S2htd/jtztLT3VAw8vs
	6Ph9dnH69uPZRfZxTezZgxsuth2hrsvO7VVpr0fZVVNNsscPR8Ryk+zJKFuv
	J9nTx+Nnj3m5go7jZUas/nz84JmAl7cLS0hZ9j3t78cfi6YEC/14+GByePj4
	yY+Hjx+QYHg2wX8PHzzhdzzr8P+N9b9KLRdELbn/lRDLRV4v+tyGPwzeOZ1k
	50trB2+d1r/RkcR/Gbz2bpL9y2bw0ruyw0v0e/rDZdNUXXIM/JuMiCrrlzY7
	ucqrDRMrWOeiXG0q+YmEWXZJxDClM7mY2ZqOpOkSfO15hOV93rf57LNtJ04A
	ERZnP6qgbkEsK6KxHp++eaoQa7QdYpZm0dquS8/p2fjZDZSPPaLfVM22iH93
	Msn+uVlWtmWi38zntp1WTd6npBj/IXud0/flNx3gAF6cdN/bSSL/2NiNJSmy
	kq3angXcfPXnsvinhw+eHT5/8WgHmTB8fy1XpFv6ftvd9sQ/5z3Bb+vsQzlb
	EsISdBwe7mSKXwBQ9rem2qxs9oLETNfRz/Sw5/xw0CkmTr4QI5UrW/d5ldmE
	GujFLIiETEXCboyU1tov66pp7QT/dCSwwcI/Pj88fPbk8YPbNkw65+dm9jn+
	1fkke1U5UgiP/VvZ07FMSbukSHl2Ayn4JSn8k5Ps4ZN+qcfJO6Ntkj6lsyap
	ZTPa1wfbQ8mD/Eg5gzn2T48/nB0YMx6Ps3zagbZJKl8uyy5ze8pau67ymSWx
	8+aYLYlRdr2kA8uKspttuo7+Ajpat2U9K9e0F3CUCTKSOZBtBpLDv0OOQSre
	RHeWexNokp32tEn7mZZujK27TWvpI3lPX2nWTUeceuf7WcMy02bX9GOz6bNl
	3q4YLDuflzOSxT3JYlgwi47AzBraQBu/r7yxqJopYdGxCINlV+tl3pW/y7ZN
	DVGOHZLWX7d2ScCSAstgnGGrEC5EamUhtNY3tAN7BbTmBTS5pU/R4oR2+nNn
	AG9mv5Ty8rxqrgkX6XEQBq4IZsJyNm9JDPKJOiFX0NpVs+YHsd0cx9Pxj0Tm
	O3C2srMlafFuRRqbVl41/GE6rWlZwcrIZ23T0dfZ7MBuhYJsfVW2TY2F5bC8
	sQkqAZFgq2TvVXbWZ/gEfdhhNYBhHBgVAduRarUTocVVWRSVNeYH4L5tig3j
	Z0iZHhUDYmOxRiYwYNgQiq/pVDzH41A8GZm7yEgorihFXM4JO0IUYi/vwKaJ
	eICoDgAV2PTXr/+HsPLwxeHjb99wnJYBzsGVZccEUBf0JEE7tQB4vqlA9yJA
	OgUWgN9N9KC1ZPtEkqtNjWMEBkyEAfpZSF4Xp+0QJPkaP5FFQpyDhdabaVXO
	hHL17CADRPoY97mC5EOz5QMZqJTJ8MAClXz9+mcllG/fnDy5zjv5ZLcUvEEn
	Zjko/RV8neNN22KVM2aXmcAYbeqesiHvTKIKaJEz9+aFiinss2PwFZUdO3e0
	bS/J/C6/87mAuLEgboJVO/ud12ZkbXesqTOClS1j0AuxUlVZ5iam6k3HqDJC
	pcBCzJrZvp0sJqPY6lQOJnafkUlMNlDLdPOpfFOStGwt66KepELdVM2CwB3x
	3yEqIfB7hqIjCqlIPtiMaPxzdyDP5FXXCFQsuGgL5IoYxdwsw2fJDCkIqr81
	OL6GZEp2eoYfT89ojUW+og3IWuBrUlGqvejXB3Qan7D2vyvd/H03vYzYrsZD
	Lx6+0IdUPZGvtiWaIZ1FwtAoh9w4A9IQ5LPStlkWO/agRbZr4oWK9IbTewU/
	IudrPDXs8GbP6bjzlihc3dnT4+PztwcT/H0mNF1tRwzlazIwFyTVzY5VnNbO
	9l8fH58d8B4fP3r8QPaokl/ESGHnJHugZ+8UcCItC/1mRtof2pHZsbIMzwUH
	FBwI5rLN625Vdh2WC/BcHF8qPC8ePiV4WstkiYO4W80bc1GCnuhT9YjkypUI
	VlUXy5wUaTNjFBUiN1v8Baps7U2YTU+aCmbFd7ZKSps06zp3opY+XG1I9//y
	6+mxwE7Oz9+Z+M4vz8x78pTz+DCPrhqV2ZfgjpIsY6Lk8/fHR5cHjs+wzPPn
	j57+fZIdFeRpsxFGZ2u6hqzVvFLT7Op7zM87n8Iyhh1B8AIqkbOks0gpka6s
	gnVD+qISMdWyZ8i4alW5zOgERUjQ12k1MArzJFklv9NqUJAzegIhmg3RKGiJ
	KILEA17okq09fPLs78KfWGSzXjetKlQ4spajEoZ+TXxd5VuILn9MLCDWa6dP
	oq8RfNW4J2kcnp5k78m+hnwYGbEYnCLDKS5yVqxduaghWMh/xsFCtuJ0mG0j
	9JZ14b5ppnbbEBxreHA9ybQOJPh+U5E2ybudghxaET/ATGzzKXE/BGS2ynuY
	pKQQqgLk2PWbYssWF71QN14TdjNiSTzQx3oQXsA1iH1EevDCsm2TPcZjUIrP
	Hzx/8u2bN25M7ilpaOesPOTA7rQl4co/bbpcuOTX12e0weN70loQIURUYhfP
	vTExUoYBoxEBVhYfIlUiRlKXX9OJk6OklBlsgpcZB0NooxwnoY0B1ldNT05Z
	bckXekU/X5cFHRqzXrOpi3HflmsWvflC7WaQxz65aQe0kA8MkTVFu+PlWQQq
	ekUZ5ERYKnYHdgybFR4eoWdVEzVhu1kzx3VqUM9zwvKd/OqNLgi8ckXmH1sW
	bLHS596V9eYLG8n4SF4RvROtqOImMGM6nqsnAMyr+KyFPjpWlyY2r+jU6Ms4
	PPDgYPc1PabxNCadNIgLk4EcR8SMvAIFcMO3YO4xxg7ZEBOr7fmjw4d6jkAZ
	v2humlD83sNH+tKLx4+e83kd9YwrPlHa5TWhkLU+fHDiEd2MJ0WBqhSvtorO
	tG1+I8yY6VYjs6qwsfa8bCHnkpPIfMhTxD+fSvYZOKmyx5PDF4qSp/6kiPdm
	9ELA5zkJ2BtoBG6ejxQZxAn+AaNPQMAtYGeR7Nis4ciLinY2MQC2V011hX1z
	cJcPWzjP05hJyd5hy5sPtHmSDEpWoEcNV5PJeVXCed+wA2FLmP0GpEXPQPWp
	OO/UepNVnKqJBYEsCCsM+qKGkOvyLQm7a+9NAGICd1HipJz3Qq/Gxj6L6hkj
	gdBl3EHTg9fNhoQpeUDXeSnuL4EYaTVH7gmMrH3M9wIKYmrGvDPKiBIE91/y
	lXhscxFV7NgAv73NidA2nfqBwc2hJ/HF2MhnqQ8Zmc2Jg2HLYotEnLANY/kz
	PFglcMIPofYDlAL9GTpmBNGgtrO8Cnzkd+8zCg7Um9WUNk0KOS+uSLaQSuhe
	kncN8oZzQV9ZBx6hAxhp1KRp1eaXqIizGyz0Jql7i1CVHhtAXOZIWpDUpiXA
	+jgR2uSS6CLdKLsdvDD+VoI1aKVADvB+WRkREmFONIT5zsVj+T34A+Vi04o2
	nwz2sm7Ij+5L8cxddqOLIEvhGdHHxe/ECqv8swVMpNZK2rRK9BWg6jaLhRV5
	Qti14ljRcj/SM4Rr+uR8S2tV5arsFbLszQbH2K6IXsWwT0/Sw8wanI4gAZkW
	I9tsUSNkJ8YHImCd2sUAKdkI8HA0+ABTLJh6RrzfldOKX8trMn+Ye7NZ2ZL8
	uXICqOQoKnNklrGxGlMGYWfLoYk615Wgw0AuZAU2m5asrta6OGMqdplYNh5o
	bIbcjBIohNmEL8XLEJvQXuEjm1diqwFNkUbw+0yJXny0UWwgYZcs0yACreEw
	QmvJwywgCpqIXMoaeACtiJntJZLyqj8kYm3LgJs0jOUZkSAhBK00cBDFmCO4
	2DKMgyJ5a4cxIDY4O8DHSu32z/lwE0en4jiTOEkcakwjR+QmVVW+7ogwnV3L
	wjYvSS52jvXXpJ/Zq0KYkbz5P9G2r+skFIGNEIl3htFEnu1iud6Q6KON5lsX
	NSALOwWLjySNHC8aRGHmWQ4Pi+3LXZvdy+lb5ADO7F6Wrxre02pteXc9/FI4
	I5ELMYw9FY0V03wB/4ukVjEmEMdz2LGt/cembJW1WczWcTDsTs9ykp3n4HXh
	811h2s5K9JUeJ1znRizmpVN37hTUzbu25WLpdceAHCMX0gwif/o8K8wQaO3t
	F/44qzLHKEqfHBVqWvCDwuaUDBTGTMLX2xAhDNEO/YpsjiW16TiqzpwpzpAy
	D73thbdqUnbpNX6lj7gQpImQMYxARhscwXpRc4AVSbBY4JsERwT25rxnLVYy
	rwM2CWqpeQLuI7lF4ocUJPMfLFJ7Q/nKdsrWeGi/GyHVyH1ecTSMtWnHIemg
	kdhjJPFDtAWLgRe4Jn+YDFkJcmjwyQmNjlxXe4O0B0FkQt5GgirZNG8JEvks
	Pcnxr3aQf/FBeI7sq6AGlifZUcde+kggqa2K7d3mVkyQEAY9cxtHWugESBax
	qkG0QRlBQruzJXmB5IIwmcaMaPSAmRGJfJnRPWinpEhICSWg3TxLEOznLJ+S
	HWvk46zpOiUeUqiFSCo2PBj7ZUVyegFRKGa6/JYTt6TZymDVtShsYG1yw79H
	4uJiSD7n8d6YAT/bLVYuumzv/a8Xl3sj+W/24SP/+/yEDPTzk9f498XPR+/e
	+X+4Jy5+/vjrO/q70X+FN48/vn9/8uG1vEy/zQa/en/0r3uy872PZ5enHz8c
	vdtzVGYS1SQayZ+huGSJb/SKvInDx07MHx6+IDEvPzw/fEYy31xzeI/1Sl1J
	MoKl5RZnS+4cO1gV2W35mkwo6HH6BAnIa1hJrWV0vk1DH0fCvvSX2/4kpx6l
	/W9VCMLo22BaRIp7RZ5NUyBatYR6oWMsnYM3jHTwBldkQG7kkEdMgLAcWRY7
	og+om5Jg97E6oNobGsT1YrQ52rfCwR6uSXYCgb4Uq6aB9+sM3FWDeFCUyXFr
	AFSSEV3W1ClE4nLr4qqFeCUEubTU6IYNS4fyBiEoaIjA+CNx1kXWRmgEV3lF
	xyE5Uo6bvPL6OkpEuqgIF2g0rRiuebXtrEjgODtJkHb53IZEZc7uYYgT0zcl
	etZFASx2B5GKmGQZNqEu4MjFN54/BQm7g+rijfB5criUac0nb69sFMdcceyY
	fU6XUvF5l0l2gbgneVR02GSlshXARhFxWQjGIC7v0wylBh988IML56IQKicU
	GBvvj87O37L1LLLzfkkxaJBhICjOkRkCx8V1uuwSFTDQc6MsDc6qEEJ8lr7L
	STqQQRqbNYO4DKCOHpE4RergZJ+YRXof1E5jbCSPIYdB3OzP2ByEyBI5OIdi
	jtHeiD1zyTmQqTDU8sRQhs1QRkO3Wa019kZG0WpKvidtk9RinXwwIg8CxTMx
	w2Hw9e62z4uBhwAg0Qxciz51GxyLCnfTZjSh75JRSfGAxL/EaddUjlog8YpM
	b4j502KWWYy2WpGsZM9/G6cPMxdvALFU1h0T/2lfjcFc/F5bkNKAOuR3oigY
	C8kDElfYPpehzD3tc9CEnAnk1CK7T9XrtZaAMq2DBQo6KObecn7j3DjKhrDq
	0ChjpQNjxIgeG0ZJt2xygKldEDf9LhxFYQwGaigCz6JPrUrYPGzc+syMJ4aB
	V6x7oO9UdsgQZRcH80axfyx0IJqRIGOjBaUBLH9oGaIEku5JkHgkUZuZRiBL
	EeVS1ARJ2m/4IGJun3xfq752SvSCVxiqVk70iM4KNqwUydyViuD4A8p+smGC
	fih8BPDJoKhv2iD1w8KZjOqmIruacdHlJJT5lEURIPTHzCJZc6sJpJk7HEDK
	a7EYqrtrq7EBkEBhF60V3WLbHqEMVZBN5x/+btLF0YddrctWpGTEICn3mMjE
	YPPwJoYEHSPyLFjXiGlFspINcD5q9oyMK10hwkLuNSbmgQJID4CteRggX9ZV
	rn4O0oriLwqOhZTYg4Vom0sELCtDPiFEeNXML5RAuBYSFS+dP2auspyk2rnT
	TNnhwxBUfvri4fM4Wfbf//lfv3L2C4C8Dog7t1BTJLBls//9n//PRXVFyWso
	2G26Mz4uqW7n5fHZ+1Q2kCaPU3cCz+OnHOXw3j+LYxPHmMkhR42Y94avodQi
	8Wdjvet95FTcJZUPdJIpMaTHGjwDln/eT4atpNkttkGd+jZso8ePItdb9htd
	79rpYiExMR7FBKL31P5Vr4qfNeKhe5uW6xP4BfV4VyqV1AqGOmRMrXNiEhSh
	gD84Nlw27b1YK8vJO5uRZ4VlHEgDtootd/KGSBbQK8ikMHtJ8YNSoxGh46GE
	I95UZSGJcj5FLXXTM5UdwzINdrnqeXKvYL+Cnjko6AnMJ5lVQaBsTPl1TPyK
	pI/PGguxcoRwZo13PwGN92qu81JdWjEJbq4/9FnZpQhS4HsGo3NP42KKnOUA
	KzOjcsKVlfpEfFR+hlhE0wesupocDXg7G8nc24iN+AjYZ0kOY6dJi3TUfYok
	XrwIW+Pf2R2yhcnuVJDcqMDy7BJcHS0RaJ1IklhXJOadTwjrdWpvW+87uKD1
	CNIUD6L6lDp7+GS7YWGcTe0sx3/L3nii0vhvhnYKbzHRQ2DLoy7JpbFv4vHV
	Oefq0dPHcK5CPd3PZDZd+IYICYgxursBvlNqwl/EU1A7egeNmJ00EgtLQYim
	N2KBl5Qx0r9kqbzrhfl+2ZSzz2MSEG0frB7VAM+eIzsebYIMMBRYrZe6sLl9
	E94LBqAqiJPSRnc4pd8cG+ZJOe5lgieP6N1kZOKtOFtYvAQOlM+JG4KR2WX7
	Ks9aTcY6lb6pHaEZrjlSZRQJWfkkp3xIfXJeiZ6+JgErp1A0QmJtM1MjxjTs
	fh0MtiRZnbv2JQU+LA5goalHecdWcfqE4nU4fPXXf5JKJ7jZdfylUbKYYAHQ
	B0ywmsPmdXdRlewNnjOB1xSgCgk2jhXXFuhA6SInVkKFc1wbkvfEJmuhpYZL
	uiLwBH0xvBLV4ri5DzKI168cDPrSuo0H4FdYiz0Zqqwf1zb/zCUbN2pFQlMJ
	18xK8SBXyGPDcHE5zucSaC4ANdRFI62+2Tqa4EpSZKLYXQyYE//fV2b7SEQU
	Hk4jFL9tioXrV0iS8mbHXqZcN6fRMjga1mcBMleU5eLlUdSfJGEF636xRPmE
	D57trAQbRtbztLBAiMFEWR9nnyQ+7o7CHaKRxCgEfFdlnmjBUJd6mXefYWuT
	+7GPSNMBEOgK3Ucato/zTa31iXt1rOOyOBJnSF5b1eDzBhkQJ6RntqBndhgg
	PqbrfiNpX5XJ3/ccXVXK1GqmHKaVlPmikOQ8FJJIxvWq1LKDeyFUEai+dQj+
	aIXsCfdVEvYuTg6i8D/Xpxyl9ba/svh2NbUQ3yexBPv6QxDs41i2fQNhJfXh
	U2dVqmJw7p0/4Lhmpb2H7nAB0GcvwPPZJxfj2f34yOCYtWaEAYo7dbgG3DCq
	yVjmMBMzqlijHkR+jPN5zPAcRDG5IxiCVmrJcUyoNEHwiEMhSbgrXW1ijuIS
	VjbpgmRjLrtlQ1oQ0sx7LocE8jozz6ck+fR7Lf4OlOecJpItdfQnH6Ovi3WD
	+oZJclwc2mjBvk0dEg3zTe2K+9pBdctAD4kUFXdZIokmlFygv+pGpZBiz39h
	X6qMOEBXC9rEEUmDWgfidMfsIF+dWavilFmKI/oOKI1Kqllv8kEQjV2VwKQs
	8yyiUS6aGfY5lrrhHDBJmY0RgRtFOkOh302hQFg/HfT6QKImSVvhgTuowG8S
	++tMmrIVizdfkDGtzRUq26TqFpb1zNXhuyS8fMQMSC0UzUVFUkDrTkr3NO7K
	9I3LqnNOhYMuYjsskVWr4a6GIlPvfLjKIKLpAiLS5U3qoBbgd0+yAfGy0PTS
	xpepzEv9Mb9lo1L4rbEon6WOjqGPWqpC0FKCqaVocYkJcn6FaKRSv1uIHFG3
	QTeaGmxa1J6G1E1qdADLt2VxFQbAjXjmlsV6FHA8dit9/SGsP3brf2OHCBU4
	KI+oUCjZc1gkrjuIat+QqNrAuB00Ekagu9JBX84n9UplF/1md5dfpCnXSCLV
	qrdDOh0WouhpZtsQ+x1WJxHLIlfvt6FR0UG/mVPueC2/alqkcLSnpLPx8l6c
	cZpmvqmMb2rUFLEWyqhmb+2CHIbIXF2S3SwdFa6OgK1H2vmMSMmX/A9MsAEU
	cADZq8jbkkOj3GkUl0fdM5E2tDcRr/U1Lfy3gGRHKYz8uCyCZcDURhnZUBGp
	aRYS58QTwwgRn8bXr9rdMWYG+PYN9shFs/LV/J1zGjj/LF/j+gsPAPO7xg2n
	cEql81WMUZUuzmVN6jk8m3MVLF500S1fejRgT3MTX4EBnYh0zoPLDAYelgrH
	tQbU4Hw6Ne88qhBXDBnJqFQz42pM8i44LbzpmajipELiqWjhVFSlElz3sAl/
	3nlUV+VDKMj2bENoS5JhomlUrKaF55ouA3woEg6tPXUT/CEPjxmWlmuybYTS
	MXFKJOcmCm7dVGiH1qI3cgXKKw03QN3TP9GSXFURm0pcdViCRLrwC85B/W82
	L66JlZzUCwEkXcgP/vCtsEYdrXCg9CNBv2yqwhXlbQP3Bu7Z7eoJ3EoBXSxH
	O99TsN70UoUWc7rXy3FqIo5BRoW3yJNdcBIvqMvslUaqhVZuOLkui+G4+/ux
	PAaR3Clk4VFRrCaxy5RDN/tnxXTIkb7SBhtu0cz2y4mdaIsECIeNc1khz0Lz
	6F1wsF9DG0bfn+7hCKn+btDzKNWlpP7u3pXKdelIIFMUtb1WysdDZaA0aiE0
	Y7ifH1QGRuEokicPF1p8htwL+xK6uAvc8uNEfpon3EPDnJnS4s18vicGL/8u
	c78bIYnNb7ExPzTSePFQZmcc4AwjEQ6qrBV29MK1oamJ60N85wwZAOz7l5wD
	14+zxOHnpmQTozFL8sRuxT5qwuxcQjdCNWpFYW9PspMvOSI2kkVSRKf7lBT/
	OldbzO2DuIg9dPAAGeROI4UKv7HzGSZZyErkXVqzktb9smriorAXTw/pmAxz
	QyxKEb9vN1Bdynwgs8QJKqUTzOXR8J7Z1/3SCgcRGuAIzLN4s1hfMur8Za7k
	8XJJ4dgViV2RgYHNS63/TKCTQlZp0trXVOTDF9xOFu/yYJDCVAPTdkaEoRX6
	TMCMKqEkQRgFY5nxB6lroS7jyatjCzJvWYTOcqIaKKViwwyuH7mdlaN5Mfdl
	YZSVwjJE3QxGdPmYK7i1YyuWx8h0JvVpPYHuaBZBvae94ghS2UlSZkh6I4O4
	qphBAeMxoUkjJVRHXFeK6qiwSfQThp/ocXarO+e9TTdl5Vpahttx4Xy/nffQ
	UI5WXYw7b6137bVlHG1eWy1Tnso0HtbrIf897qXGypKsls08efrc7c41VIa2
	uu9U44KtMxmewvpM4ogo/4ZwwiA5cnD7ko42e4PWuTHZaPKPj4Th/Tenbz4e
	GAGUaQsjHGiBOUkF7ReIOmolvFpLIQwqNLDXEKumRzvIM6MtA0LjkboKtWBx
	9zICSPVsG/eSAH5Fn8HH1mRFbF3NdVFgT9d53Ucv86dqu3CRVKmY6Xgl/BiK
	+UzcquzL7G4MJYD4XJC70vnEmngRBBPWBQmgD//aTs20Jdb1E2GwEItW+o2z
	pbR5hIs6uR/XNbp5mdpxszxGIw2pVmtachZmJpHCQNXOaQK+dySZoXBBxpfl
	zrGHDx48NDdHlzBNBjK829vU+D0dB4+76qN9Csj5d4cBMT44jc3t5mJiIykr
	7Viif5Em9K11bX+7eEO2MTsTan1H1Po/knHwLBL5ptxkhJe4dCF0mGeXDYxa
	8I2UkZWoRfUdILJkkC2O5kH9iWEhnKZWR9l3WWJ1lPPAOfglc0fa6H7pW2O1
	zdRhDM2OYcfcaeom6EF+5mXF7Zqpup6Y2wZquQVCrAQJX5Lx2vTJWa6cY1M5
	8VbXcz+/GHgp7sQS9EV0vKwqQe07TCxdF55ToYAhTcwTWhRFNj+LHA7CihWW
	E3VVc1WbjArfjf4a2TaQEMIyZv/V67MDFS5YEkm+vuzg5jbt1s1EKHgYlFY+
	+V5e9XnwtXn5ReNWZWckyOnmjw372i+H5tEtHuRNWm1RXcMmVCyVoXyt6tve
	FcVdI/Dh24izof65k7mNToaI9ZPzEd5oN1ncM+Q7xHdII+89aegl6ot0PV5y
	7Hlw6mQHd4RlzCAs44PAzvWQMW7e+vC2UhnIixvNIGIGgEyyY/e065xzKRk6
	HpJTea2+JZE4SlyjftyuXJWYu6NTcnhh1mpQqAlFRyU/ZR86Gl2imSdFjcw8
	tjDVn4UBGLAmHWdc19R4ayCyICG22G8q5zKqRAWDvK1CvEKnHEYS+QFqPBQI
	UtF1GOTddrXuyc+axfVaIIgLbp94w+t9/YGbKca8OuKkGVklXIsnfYC7qI4b
	AMoQ1xMCgN+/HYv0dx9EmJQB03PyGORWhTRTlEmcvfKpVYaroh+KiWFrLvqN
	z0QV+VbDxk6/7nX0J2ihtt8jF10a5iUzJgLxz8GCkyxIs1pxecfccsq0i13B
	uN3wmoQKkeeCrAeSSVFQi6Eh0xNNBrHJFL2r/BlJAbDn0T1bAjgU50NZ4BFO
	TUv9scOJUTSywcNoj3HlRjmRvoIwzCVg8r78Qg/sipfIXwII7khDECUJmsQp
	odBteI+5bjoiRo/gjhRzZERLYkk7Kl2dyf0CJ0Jm4npK23sQEWluKc4J3e+U
	JCarQUSiRo4P8bRD1ncu/3BDskfACZmYWIw7of6CTMDoJ/Y1DlhSeR0sESRB
	Ziy52NrQ0kueBwCYfOVLx8UkVktcSMnllRe/YhhKzTGLu74JIfSV7TkZ60xy
	pQPW0sHSH0mW09tSwExiCx0lUV4m9SgXGVrDkZhhjgNvX/HTySCcYTcJGy3c
	p1sRa9sC7rbjw8L2vqKYOLZsOZqJPG4c0dHBKJv+IPRJ1AO3/cQNiNTR3eOz
	TQta2aFZ/yC/J1kHr0pE7+ViQnsnNbtlglonidHsDoIyMUFNsvuCyEiWnrdo
	aE61Nc6nCz0QSYzUQ7xjdUny0b7JEIU5NtKcM5xIsc9CpzY6KZyk8YHmP3Xc
	mcJnt+LCKK0U4EwVl7WzrtqUvm1tIKzu3LQ4XSGs7bwGMIbnikbTJPX4rq0O
	62VIKpnPtfaSTO1w+AvmkTS9D4mV0ZhNx8h5YqDKnFcwNjuJYzAhO4ljo/Ov
	S7aT+ABJMvG7XanDJu/OsIVwHAZjcn86m0z3bRQ5imtARmnRqXFDvm7/qKs2
	vNEbMfIJdeADo76Nn/WtXa1pdvqT2ITf9Xq5gFcOIqr3BnWt8t+aaFhtVOTT
	+YKMdKwAUMZeJk/Ys8kUB7Sz5IU2ld563s73YEHMAzxuaGBNLdTjKe1pLFMU
	XT2OSdAvRTODFkPpJ5zHfkPgWx6sFUWXDQcqNI35mK2Mp6EHQ0uM95NDPuCn
	VB6sOSgXzP00YuJXfjrKDg8nh2LGxF0n8gWVxueoS7iE1N4lfp2IXquIjpjQ
	Hdas4bMdlh07MaJdpXePN9TSJZ5A5Ov2uD9sjnZcTpbohA6TTLvQxJDa+M5H
	kKGKluk3v8rJXYmDyYJLmBpG+d1F2KaIRaPHlaOyf9ZxiBqEdb3P69hiIw4D
	BVm+YWDW+WYGN5bQO/UhDToI5vqm3bgRyE3t8f1coTt3Bx61NwOS36/2DEEL
	WaSL2n4nLvD66MXDpEmY/aa0ycK4Ut3zy7MdYzzPQZacEA8teqMIUEnSwesD
	MjiIMeeyZchab1zQ/5AMr2yxYIwciOHnhmVfuRYT8nJKSaq6WSk8iHZnQ7wb
	NMQcHhdBapOXb3fTKbn31d9aUuDVlhJ+GNsoGsgLvrsPLR4Xfo6mvB5Z4y2n
	7nwKjdxtnTCX7T988PDxwWjYsq7pFJ5sjxlXXPg2bKLSygYzUJFuVCovOZyd
	dhfwcXReZ165wPpuCLgAgw5rKaVlTkQb35ilLfZ8cogeNao0el+k4L0pTN0b
	wJqOMlOPpGmKkRnWJ9/TLUGoAj7778LA2s1vTRg4/aduV01fKiI5dprsIzQ2
	jpJ2PY29aBWVLVwjgDadEUbOU77yBbTc9sWCv+fBREQrJNA0w4OS6dcuTlKy
	VXyhE/XMMfz8M671zPZfX0DFNM4Ui8eqhyFj3WYKlabp3ih/LNM1JNN6s4c7
	JFhDCEu6OrlWa1j0S8KC0cEGGnrYbZREu0YHgQS7uNDp61eeBFb24ynR62c6
	9kSosQhQm3ruU1th3JK+nOnLsb8cknCP/NgnHksMY2tFSglFKDoaCfJxsJSW
	zLpB/hYJ9GbMoSs36UHqFFmG6Ry2UgIgOvFB6Fjxn3PcC1ayVtoYLjlQ16sX
	y4rnNkhT3+4ENFsuIVYfp5uFP5PphqOoa8n19kYxkl3rjHj4cJJ9ajc1Z1Ph
	X0em1emZnynhK8bceLbB9QfIDZMia7V+Cpp1gOwkSgeGfYcIGofrdJaZRHhQ
	vBxFxNxk8CRAJjaWazrkuMBdLVndTc+TSwm4gCAOFIq9lX3khV3xpcDtWNQX
	y96Z8PqjMbDKcuu8a36GrC8sSQY1LogkzC2lDs8OHx96O/E0aosKncnfTUB5
	lpfaODFUfaSIU46M9js6r5QKfSd45JFIfUIe+1fuqbQn0c8U01RBKNVNQuuq
	4gOY4hyxm2n2MfWg3iIjsDjQSQLiS7ctU5ePmLrJe6EUQhyCEJs2MALXd0Mm
	cRdNxI9UbOWtjmf7wnPAPh19MDrtjh9CMGnDzrzEa/CvTu5dQql3aF4Lnb1V
	+Znb6SWsDwuk/AMOfjK9S2LChPgwiygZ549Pasfs8HKSg50nESJnkuVwH3OT
	JsRXhKlSdhiynkYbRLDIbCy43YWrhvPTFNiYiKKWUmPrG1fn6Cli+zO0OnLN
	I7sNJU9jaNpwHUUYdb1rMJBE68PoAF1fojX4MrLpsgUZxOC6FKSDrhSLx9a+
	qSsckLOb7uuoJu18PFGM6+MjN9J4N/LwweSRuJAPJvGoAGkU3Y8a86R1SF1G
	bhT6+kNc4XuzpPDr112159921xAn9cfGz1adZL/K3Ii7rbu0xQTSsCRnUOh1
	WhadCY3WzoZNhAThx0n6XX3eZR9m4Ayr9BGA9ZNgnVN1z5hhY3zdy825nMiJ
	InHlVnfyS6a48AQnxLi0aF5ijG62lJm6XHGnQy9VJrDtCAqhv0yyj0hobdrO
	DYIViwf1WSsLOWIGy7vgYIrB2LzXacZEj7KhYQl2XK5PLju35EkrNfvYcodF
	QyYYEhAKj/uOCeYTe6bOVHQB7vsh3ZWwGHd9QZDKMpdxFLn0/mqddMhyznmD
	Xu44wY04EIvC1sGO8UNdxDY4I4tQVcUluXNjFI7KjWFqxsSRL9cIdqdklsxW
	mNLAZ8vhIjIlEBmTUTeFczoHdbcSvQUYY/iXjjTC6/tsLZFbhCIrLVw4uGkR
	uYhK/o+VBlPSC8zE2hoCp1i5RBNxFeXZNAZ5v7NE4MBynbxjee1/C1ciGVji
	A/WTpg/7yIScO8/GlYK52BSB1DOoIyPemyuhW/GccY7S59dCFz4FqjytERz8
	gZfonNvJmXa+trHTC/8619jjw28KZM3EuivOFo/ZGlR0cpLk5PiDqy4FofDs
	IHRUnamFfO0vxPA362zpNMNlk864/cSqjcmYjol/8Ea+JBE3Mi7LR81+dwkl
	roblpPx1tqsOyWiFfmib0lo6pUk6uE4HwUB8+PlS0iSY5YsFMhoYhuvzdA4a
	rSSUtl8xBbZrAYDvB3LDgK85Pszfk95ewsnEvIqS2tIZiCHjN1LzpeKbkcLL
	ynhKfy3PxnWxmz10boMB9kR2YQqy2mRhLlLkCw+L5VVVIpHfhr64cEKsLN0h
	+btyxEsIAptvpICUVfERQT4abhZhKrew7E2v5ZjpLO6QLg5tekGW8YSKOIh4
	X+YOua3YUDA3xv1IKXxS5Mn2jlBQmxekOoW/aW9t3ntyEBY2EY39pDYz4dlH
	4Pn2mC7oNbcw6zuQijzuVdNPRmZtwl2XEeduOAITGj2sfaSD3KqbqhDqSn/j
	exaRTxgU6SdB7EfPeagpFncznw414cCXjKpM1sovl01w5rE72HDeoUMcdzRy
	sd/XH9K2rf8dUy8eEXZfEnFmH/EYZIhMNUH9oe+jdcuLaFR7zTkw9NQ4asWM
	er2O/lUbveO4VtR1E7FtjAieIgQLf1CE56ogQvNzsHC5eMPnRaIhrarEbh0N
	1UVdoCjRETllEtaN/FZnT/o2pQjzUfFOJIXIbJ6W5NL0qNLQgobYAYj3QOLn
	SGaNyi2o7/M6l6h/tn/0y/sDIiIYCGrq/JGQfEI+EjZL7nSKJOTQhNGBM0G7
	08EQMLGRo+4gZq7DHhfHGiLRy7J4su1R7wKEm1US8wzljRg8J+EDjMR0m/kT
	6iW7NdwK0JG7QyIFBnwd7v6FJvcj+NQcxcyCkdShidnOsEkQ+cjVA/KqfbgI
	jK1XIRWW3Cg+8bUIO6XxjuFEIArE3PR4j5vXZLbtv/llzP86cBm1hy8efPv2
	k9RTtuouA5OLVm58lS7s1pzUSyiHIts/Oz3xb/MtLD9pkO86e+cqZviHxl0A
	cEEIYb1/GfKG++8eXxz49Nejh3Kdzx+p3ej4+oTaG3C4P+pErcp4rNulDzDv
	nxxfoq2HOFIi7S5JepYtSZhbmTuxcAnpKdHovJQ7Glpy+6Wd0X0iDgt+aPrg
	zNJXPhzEfz3xFXWEveOTA5OYvDzdZAyjl8nAIfb5MxSzgGlpezAJVXkcPtW+
	oIA4l4PVWPzdDqwW9LKlWfLcIMujmHLVyHJrbM5m6Pj4BHfSf+ZIiJYQa4Yl
	bjENzC4G8LxsV76i2ER5nIbzf10YuZAkj/UY6YzCEckyXCPdDYpIUp9lwEG4
	gbjjIv/OD0/A3IfARSEodj+SoxXLzs3gSebvmDB0Rk7l2RPO94bEh/oTaT5X
	BqH+8l5l8Ucv9j12Tmq5rYHdahJw7sblY423v3LJja8/3Mi7aJf2jbimyz1s
	2Oqq0XrfICM7S4pieP9lveFhA4bEFM+jwfubzk3d1XES061e6sFVcs6ud5EA
	CeL75A36PgyPrM6/n/+RvJ+DTwINIux9riNyr/yMyNrXxvk6Z9wswqZzto+q
	orjaK06cac/AgXcH97sD1JNhPt3YT6u4k0rccFMjXKaXDrj1BOshU+Ox6MO/
	bhAarDDNu5io6t0OKOL7OExqTtOgxt9yaVSX3oSvP7DRiwrqOqhSPM4o9M2v
	7Dk5xyPMD1QVK5Yzx4LVsHGX7kUXuXDKPARn5RVV63kf36vGlrrEMbi36VLH
	cDv/nROSBc/QvgkyZwkd3JIQ/4KsqfOBzW3QuytD2YNwip89CTbo4JT48hE2
	WeGIctsQNtRu0+UI7w7Tsnx8Y0muAPlviqnNg+y4dx6b4RwckgpdqJoZwUAt
	K9Yqo8z2szBUIRo+MfiIMH3wlFbe5DM6xC2gJBTqOCrluauYP1CEq2v9Yfne
	Bp3eamoS4SiVy/APNWZ6QKMJAD1WSZBqw2DNA0FkJkzkaZm4WQuzXvhpdjqW
	246tLcaTw6GWyPrGb1xxLHeg5MExjt9wE6PCeuLw+avGYbkPC/EPJjjXUod8
	eZS7q2g0KiXa1AU11oQ9vgQBGX5ULY4xaK8ziV8ZxbT0bYn5zKq883HUcM9q
	zwErEJY6vpg670c1uSHBfN+h+DYqbZIpfyjNsclEbbVNTFz1HD4VVROLAC2i
	mjC1Fa48drS1VckfXCUXYLBrzCyV7YvvfBB5SFxPwVWKm7JbMikyUOpl66Tc
	KOgr0SKNHPzxSqKhJaPzx+jwTeSToRFziiZuR14yPyO9eVND6y70MxAHnL5V
	aYWub2QwJdhw7AoiCYIPYCDxvvZuPr6X7Z82ZMzyp/myVulmWetlhDduqb/f
	2FvtKdBYOdFbM5NCFabEDVtXZlBl99IQJMzmXSiA5taBWbQdFM2DjEfZ8dmv
	o1DcEnIXHOOBRr+SjGJchrJsut5dgSTfWFc5X/G2YgPdXVHFQl6roknNGDS6
	14P6Z55ACobiDkiONnlAvYvOV/hhzaum2kjpl0OWmwfKon/wAfoN7uFJ73wh
	h5DHakdB1bFAINE5KCsXTJJmbs6uOnbS3kL80ieJxspMa+koHMkMXZnBw4kh
	V+yqlMuNnXqLCd/pMhxyZ5JLBqW7iU41qR1x/bfqlGbLzSr3XUtV06xdubsz
	YyIX9lrMEVfaGSM8CWXoNzhWK9cMIhMYdyVNYtdqd7GYTCN2IXmZYuIyC3FR
	1M4JCBFoN0wmbvhle+n+0iW5vQrJOamhymV6qYaR0nlpncMwjlOkRnYhQVP8
	0dk0Qj3aAubuo81WZF4bZj8hEY6cSsWsu+hjMJztglBdVajrlRWF+RkECYQa
	lOW4IKxbBEtKFFqgEt/n4ePn7lpmbhoWGDzdGiXYblj7LEj2ZpsmMTVuxLJf
	VhpeF/X1q5it31w7WCeViUTwKkD/oBYY9nGGS3M1RN6F4nRpw5bEJ1c5jpw/
	3YpNoTmnSQat7UzekbeNb+sfvW/A3UEkPru7XpcUOyQUf9YZzK7hJFzd4bMA
	fMnJfTrdXGpdLsMICTxfPcxK2E+qAM1wswoT2f2LIeKsKu9rFZ2paBlImRu7
	TQcQx5X3LyaPR/Q/T8TueTGJqvulbEIdCz9lOw25x9/Xc9bmeT3qnzLcgil1
	Pjplx8QvKUp+SlZalUVR2WnzxXY/+eKf0CumfraUcxgZtAxpyLv1SJYLrfqS
	/PJ1ZLHH05k96wmDqBZyUwvOLV/ZiLD+/65A04pxnjsNpMValEFwwZPHT5+g
	xDO51NOEeLCmJl36qPXwa3YahjQaijEqhK/G+5+Wky/DkOH7NIEyD7uB9qUr
	CLK+UrP3gFkBzPUcdpui4Ilc7mLPOKKhQz8WalBKJyIpcG394qUm5jx5iCQP
	u83AYBjqPZK0M4pTAYRLgfGfrzj/CqbyKw/rjzJVKFx3EHhrmLj6A2weB9eH
	yLnRRPP1q/vgiwl3zsS8y3PTBIveYdMhAUR6Es9AiVAIkmiDVV+6aaM+FphQ
	LbPXdm3d9SE6VkfOybGgDqVuV1pDrNXqBSwZdQMkoIcKGx35wNU3zuYZpH+c
	xPQZS+tad6SBkPkdS+0k7B15AK6dSFudfQ32AF9SecH3v1p1c4wHo5O+V/Ga
	Y/vfWd9MYFeu655LdT06ydNVUjbuMbWu3vNwBizr4/TGhF/uuIwXbLZCgVcT
	TQf3OJvaYMuV7gZC44op3DVZWWANV2wjoh14Xfmva5U325SzJTm6lZUKcOPE
	F8F3ZSugwE175miB3uLHss/dm8b3XcNdo3cKyzPEaoOzdJ2MrFMgJpkH47sc
	XRBKiwzyPoIxinrjTjcZ5YBQ+cfa30cv2VV3hRbPTMQgljH74uI7Ryh0E52d
	h2uIkhZl7cIsMi1STcKrUqZlihEh3VIcS0BvSFJUQHYzX8ZjnF0e3XqHKSLc
	YTlIYPhRPHLjsCfPwq7ESu/R7hDmp++Q0Vze5N7WCzAYQf4SsqQTxQTEfj8D
	5e9a03BSwCmPak2YTtrom8S8CWFEkZODuEHYbyfayLVS+plvoVWfw8uhr5yM
	+m09IxeyLjufIwF4DF0IkEX3hOr0hdCuVbYqBWtf+gRq5ZG63UGw1SPfg8t8
	2pXRC+01tu76MJ33rREaedtfB5ZUqEFqazgnpWAEObQ0259UHIe+KS8MtwuR
	qWtldLJj5M7lLUDxPm/Rx6NbtDkk3KTK7MwhmaAoHNUTTyw2JBjpD2oOBZ9S
	bCBFu7Q0+D8aN+TdDbYCclX//obfu64UN5igi4PnfI2wOugvs6O7VUFaT5eQ
	Z7A8HaEmLvLSyg1FKSr8gNC0MwOiNqT4eYBmOoKcm3FklN1mjT45N5tygLFw
	JymE/BXsyjDZQWI/B0ERktE5NOLSnUEU7NjdLl7ZZe1FteM7GSjbwUDaJrdp
	zR/nouxOLjL346KkezEbdi/2XsMoU/Fo8V23s0pLyG7um26iW7d2GHvudr1H
	T57qyBoTLtzJd7L03cIXB/n+DM32mi1/KplF2BOvkU845rsayPp/HW5u0OGJ
	w1pHH3CT0BRA2v+/2cNshdwfT+1Bsgj3+2Lolbi+003b9dsQpRcy4HmN7J/6
	7kvS9bgMxVkYGDGlxhsqC2e33BhQxEDH10dk7vYISYCv+He4RMLc7xKJLAny
	AaTkwg35FLMVM7sfMhVFEe9unZVrnCU9IZU1XbKdHa93UW22b5jUWmBSyMY1
	rNmqszoPetDZrsPLAzbTi04wNjUylndxtr9UyDXPczRVki9IxLKsiLta5270
	TnwFQXxsniluNDP5kjPtJBxcfoPbnvgGWwUEMJR6B7ydyQ3ax2lf+G2N174V
	IBgWbNxtszArDhASH/14ehbpy03Z20FC2i/qLzZUJyJU4it00jIzvIaWPuVs
	2Hk+s6Haw73/pzA37u4G58JVEjtsxBrQCeacKzUql3gYDpU7u09EQFsJYX9w
	aT7hLagS/3USiuu2vMpnW9e6I+Y5QpWcgXVl7aQMpISAz/L06MPRd85xyfM3
	5UlXLW7MeDzm+T1Y5Mg360vb8teXwrG2+Kc9vmltD2UgnKp9Q5JCOizf5+3n
	7KiqELq/9sneYAont1b8ia94KLjlqWlHKm6fcNWX60XuyJuzxaAc01/pp10v
	tAT5PFxen3PQusnOyxnX8F2QnCJVVls0lYqOttVa05K4V1hnRV7JVBy90U3m
	o9nCdeHwjUmdxmHQQ6dzlevP2ftmmePuwlfNhoAgLTrKPlgulW0LwDnKzi0U
	6km9AEAkgP9KphU7lu9sXTdfRoS0vsf/8LTNf8sx3fSC8Ihs1l83tl2Q7KJt
	NLa+zm1FJzoixUM0epkvabULSytdbojK6fH32DU5jJ9s9XuFhRc18cQnWE1t
	tan1qtO3ZI3ikguZZmPc+AnUG8igUnE6eIvptZuvfehS49TvckLLCXAriaSj
	nCRj9iavPmM+R6En5z08Pd4JYWtqXrWIIZGqeNvgyjTMYVxC9Y2y12RwEHZK
	qP+/lhCCbZ6d5cVyS08fN8R52ZlF4Rjh68x+/pwTHZLuzFEuCxJlUru8+Nun
	t27kL2LTpPqxLVWXmNPyCYUay2aN3xHqyBwnTWH8VWN5uE2gCHFovcpGzCnG
	hJuxHSq1TnUcGFnc13Lnm9L24dOnYkpkJ0j9OemleJmWt7CZzO7HCBzM3ByX
	tp+PZ7Prxbidz/TF8YOnO98dZx/PLl6fnuuFYvTz0fkl/b/7+X5rP7ll7aPX
	6Y3tK5EV91v08S2LygVlJUcEELmY95zTt2tSGIXCPbnnNx7d8o2fyQSGSa4U
	unevMO4edqxuVKESeQKARYoXOMfxw8PDF0jTkmFXdI5aZOr7LBmaIBNJeEVA
	Yb9w6WCc1Y4tjR/18vpMb1W5+eJwKAEndispeNnx2QvLLo8KN4dte9/De7ib
	Uh1UaZIjzBfxcbZbnpTSDRknM87elezvpTHM66TXyK+DhLJeWHHL2qjidIFh
	euTcXreNOqh7g1vi99KlItlY6FxivpnI9eb56z55tC4RTThXd4cGZvfB/5jx
	xay44IErmmTYRVz4mTCABkfveSaHf+RMVjejoEDmZdPryI+mXZBDCkcGZmcr
	dolIPDWvGJZ7wvbgbth++fX0eBSuf77R0Ovvt3Yv+FKrmEnwV6X4VcO3dnOx
	kU4xZl8rFMAeH396yx4b6n1ADnJBWIolTnZxruvGPrvYtBgDaAiG+2363NZs
	NcxLmYKhd3JnBFFO/pRS3q/rQmLMYkAty7UwdTpGibn5VLP2G32FpYJqdnFF
	vc3gURhu/AGGptFtCuPsvVTJWDc7Hd/l2dtdhNnou47MJd9CalIA6XzwxZlY
	nd9X5m8FjOlbVeFtiOMCnlZrqGBtFhgKCOi+rKqHhPvs6hE95t0BnggV569I
	cfx/75CP0AqvAAA=

	-->	-->


		<!-- [rfced] Please review the "Inclusive Language" portion of the
		online Style Guide
		<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this
		nature typically result in more precise language, which is
		helpful for readers.

		Note that our script did not flag any words in particular, but this
		should still be reviewed as a best practice. -->

	</rfc>	</rfc>

End of changes. 241 change blocks.
	2301 lines changed or deleted	1425 lines changed or added
This html diff was produced by rfcdiff 1.48.