<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>The Some Congestion Experienced ECN Codepoint</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Terminology">
<link href="#rfc.section.2" rel="Chapter" title="2 Introduction">
<link href="#rfc.section.3" rel="Chapter" title="3 Background">
<link href="#rfc.section.4" rel="Chapter" title="4 Some Congestion Experienced">
<link href="#rfc.section.5" rel="Chapter" title="5 Examples of use">
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Cubic">
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 TCP receiver side handling">
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 Other">
<link href="#rfc.section.6" rel="Chapter" title="6 Related Work">
<link href="#rfc.section.7" rel="Chapter" title="7 IANA Considerations">
<link href="#rfc.section.8" rel="Chapter" title="8 Security Considerations">
<link href="#rfc.section.9" rel="Chapter" title="9 Acknowledgements">
<link href="#rfc.references" rel="Chapter" title="10 References">
<link href="#rfc.references.1" rel="Chapter" title="10.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="10.2 Informative References">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.17.2 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Morton, J. and D. Täht" />
<meta name="dct.identifier" content="urn:ietf:id:draft-morton-taht-SCE-00" />
<meta name="dct.issued" scheme="ISO8601" content="2019-10" />
<meta name="dct.abstract" content="This memo reclassifies ECT(1) to be an early notification of congestion on ECT(0) marked packets, which can be used by AQM algorithms and transports as an earlier signal of congestion than CE. It is a simple, transparent, and backward compatible upgrade to existing IETF-approved AQMs, , and nearly all congestion control algorithms." />
<meta name="description" content="This memo reclassifies ECT(1) to be an early notification of congestion on ECT(0) marked packets, which can be used by AQM algorithms and transports as an earlier signal of congestion than CE. It is a simple, transparent, and backward compatible upgrade to existing IETF-approved AQMs, , and nearly all congestion control algorithms." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Transport Working Group</td>
<td class="right">J. Morton</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">Bufferbloat.net</td>
</tr>
<tr>
<td class="left">Updates: 3168, 8311 (if approved)</td>
<td class="right">D. Täht</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">TekLibre</td>
</tr>
<tr>
<td class="left">Expires: September 11, 2019</td>
<td class="right">March 10, 2019</td>
</tr>
</tbody>
</table>
<p class="title">The Some Congestion Experienced ECN Codepoint<br />
<span class="filename">draft-morton-taht-SCE-00</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>This memo reclassifies ECT(1) to be an early notification of congestion on ECT(0) marked packets, which can be used by AQM algorithms and transports as an earlier signal of congestion than CE. It is a simple, transparent, and backward compatible upgrade to existing IETF-approved AQMs, <a href="#RFC3138" class="xref">[RFC3138]</a>, and nearly all congestion control algorithms.</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on September 11, 2019.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Terminology</a>
</li>
<li>2. <a href="#rfc.section.2">Introduction</a>
</li>
<li>3. <a href="#rfc.section.3">Background</a>
</li>
<li>4. <a href="#rfc.section.4">Some Congestion Experienced</a>
</li>
<li>5. <a href="#rfc.section.5">Examples of use</a>
</li>
<ul><li>5.1. <a href="#rfc.section.5.1">Cubic</a>
</li>
<li>5.2. <a href="#rfc.section.5.2">TCP receiver side handling</a>
</li>
<li>5.3. <a href="#rfc.section.5.3">Other</a>
</li>
</ul><li>6. <a href="#rfc.section.6">Related Work</a>
</li>
<li>7. <a href="#rfc.section.7">IANA Considerations</a>
</li>
<li>8. <a href="#rfc.section.8">Security Considerations</a>
</li>
<li>9. <a href="#rfc.section.9">Acknowledgements</a>
</li>
<li>10. <a href="#rfc.references">References</a>
</li>
<ul><li>10.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>10.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li><a href="#rfc.authors">Authors' Addresses</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#terminology" id="terminology">Terminology</a>
</h1>
<p id="rfc.section.1.p.1">The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in <a href="#RFC2119" class="xref">[RFC2119]</a>.</p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#introduction" id="introduction">Introduction</a>
</h1>
<p id="rfc.section.2.p.1">This memo reclassifies ECT(1) to be an early notification of congestion on ECT(0) marked packets, which can be used by AQM algorithms and transports as an earlier signal of congestion than CE ("Congestion Experienced").</p>
<p id="rfc.section.2.p.2">This memo limits its scope to the redefinition of the ECT(1) codepoint as SCE, "Some Congestion Experienced", with few brief illustrations of how it may be used.</p>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#background" id="background">Background</a>
</h1>
<p><a href="#RFC3168" class="xref">[RFC3168]</a> defines the lower two bits of the (former) TOS byte in the IPv4/6 header as the ECN field. This may take four values: Not-ECT, ECT(0), ECT(1) or CE.</p>
<p id="rfc.section.3.p.2">Binary Keyword References</p>
<p id="rfc.section.3.p.3">------------------------------------------------------------</p>
<pre> 00 Not-ECT (Not ECN-Capable Transport) [RFC 3168]
01 ECT(1) (ECN-Capable Transport(1)) [RFC 3168]
10 ECT(0) (ECN-Capable Transport(0)) [RFC 3168]
11 CE (Congestion Experienced) [RFC 3168]
</pre>
<p id="rfc.section.3.p.4">Research has shown that the ECT(1) codepoint goes essentially unused, with the "Nonce Sum" extension to ECN having not been implemented in practice and subsequently obsoleted by some RFCBLA. Additionally, known <a href="#RFC3168" class="xref">[RFC3168]</a>-compliant senders do not emit ECT(1), and compliant middleboxes do not alter the field to ECT(1), while compliant receivers all interpret ECT(1) identically to ECT(0). These are useful properties which represent an opportunity for improvement.</p>
<p id="rfc.section.3.p.5">Experience gained with 7 years of <a href="#RFC8290" class="xref">[RFC8290]</a> deployment in the field suggests that it remains difficult to maintain the desired 100% link utilisation, whilst simultaneously strictly minimising induced delay due to excess queue depth - irrespective of whether ECN is in use. This leads to a reluctance amongst hardware vendors to implement the most effective AQM schemes because their headline benchmarks are throughput-based.</p>
<p id="rfc.section.3.p.6">The underlying cause is the very sharp "multiplicative decrease" reaction required of transport protocols to congestion signalling (whether that be packet loss or CE marks), which tends to leave the congestion window significantly smaller than the ideal BDP when triggered at only slightly above the ideal value. The availability of this sharp response is required to assure network stability (AIMD principle), but there is presently no standardised and backwards-compatible means of providing a less drastic signal.</p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#some-congestion-experienced" id="some-congestion-experienced">Some Congestion Experienced</a>
</h1>
<p id="rfc.section.4.p.1">As consensus has arisen that some form of ECN signaling should be an earlier signal than drop, this Internet Draft changes the meaning of ECT(1) to be SCE, meaning "Some Congestion Experienced". The above ECN-field codepoint table then becomes:</p>
<p id="rfc.section.4.p.2">Binary Keyword References</p>
<p id="rfc.section.4.p.3">------------------------------------------------------------</p>
<pre> 00 Not-ECT (Not ECN-Capable Transport) [@RFC3168]
01 SCE (Some Congestion Experienced) [This Internet-draft]
10 ECT (ECN-Capable Transport) [@RFC3168]
11 CE (Congestion Experienced) [@RFC3168]
</pre>
<p id="rfc.section.4.p.4">This permits middleboxes implementing AQM to signal incipient congestion, below the threshold required to justify setting CE, by converting some proportion of ECT codepoints to SCE ("SCE marking"). Existing <a href="#RFC3168" class="xref">[RFC3168]</a> compliant receivers MUST transparently ignore this new signal, and existing middleboxes MUST still be able to convert SCE to CE as they presently do for ECT, thus ensuring backwards compatibility.</p>
<p id="rfc.section.4.p.5">Additionally, SCE-aware middleboxes MUST still produce CE markings as at present, retaining current behavior with <a href="#RFC3168" class="xref">[RFC3168]</a> ECN endpoints.</p>
<p id="rfc.section.4.p.6">Permitted ECN codepoint packet transitions by middleboxes are:</p>
<pre> Not-ECT -> Not-ECT or DROP
ECT -> ECT or SCE or CE or DROP
SCE -> SCE or CE or DROP
CE -> CE or DROP
</pre>
<p id="rfc.section.4.p.7">In other words, for ECN-aware flows, the ECN marking of an individual packet MAY be increased by a middlebox to signal congestion, but MUST NOT be decreased, and packets MUST NOT be altered to appear to be ECN-aware if they were not originally, nor vice versa. Note however that SCE is numerically less than ECT, but semantically greater, and the latter definition applies for this rule.</p>
<p id="rfc.section.4.p.8">New SCE-aware receivers and transport protocols must continue to apply the <a href="#RFC3168" class="xref">[RFC3168]</a> interpretation of the CE codepoint, that is, to signal the sender to back off send rate to the same extent as if a packet loss were detected. This maintains compatibility with existing middleboxes, senders and receivers.</p>
<p id="rfc.section.4.p.9">New SCE-aware receivers and transport protocols should interpret the SCE codepoint as an indication of mild congestion, with the relative incidence of ECT and SCE codepoints received indicating the relative severity of such congestion, and respond accordingly by applying send rates intermediate between those resulting from a continuous sequence of ECT codepoints, and those resulting from a CE codepoint.</p>
<p id="rfc.section.4.p.10">Details of how to implement SCE awareness at the transport layer will be left to additional Internet Drafts yet to be submitted.</p>
<p id="rfc.section.4.p.11">To maximise the benefit of SCE, middleboxes MUST be capable of producing SCE markings earlier than they presently produce CE markings.</p>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#examples-of-use" id="examples-of-use">Examples of use</a>
</h1>
<h1 id="rfc.section.5.1">
<a href="#rfc.section.5.1">5.1.</a> <a href="#cubic" id="cubic">Cubic</a>
</h1>
<p id="rfc.section.5.1.p.1">Consider a TCP transport implementing CUBIC congestion control. This presently exhibits exponential cwnd growth during slow-start, polynomial cwnd growth in steady-state, and multiplicative decrease upon detecting a single CE marking or packet loss in one RTT cycle.</p>
<p id="rfc.section.5.1.p.2">With SCE awareness, it might exit slow-start upon detecting a single SCE marking, switch from polynomial to Reno-linear cwnd growth when the SCE:ECT ratio exceeds 1:2, halt cwnd growth entirely when it exceeds 1:1, and implement a Reno-linear decline when it exceeds 2:1, in addition to retaining the sharp 40% decrease on detecting CE. In ideal circumstances, this would result in the cwnd stabilising at a level which produces between 50% and 66% SCE marking at some bottleneck on the path.</p>
<h1 id="rfc.section.5.2">
<a href="#rfc.section.5.2">5.2.</a> <a href="#tcp-receiver-side-handling" id="tcp-receiver-side-handling">TCP receiver side handling</a>
</h1>
<p id="rfc.section.5.2.p.1">SCE can potentially be handled entirely by the receiver and be entirely independent of any of the dozens of <a href="#RFC3168" class="xref">[RFC3168]</a> compliant congestion control algorithms.</p>
<p id="rfc.section.5.2.p.2">A SCE TCP aware receiver MAY (based on a setsockopt option) choose to interpret SCE markings as CE and send ECE notifications back to the sender based on the ratio of markings, and/or variations in TCP timestamps.</p>
<p id="rfc.section.5.2.p.3">A TCP receiver desiring low latency SHOULD respond with ECE signals earlier, one desiring higher bandwidth, later.</p>
<p id="rfc.section.5.2.p.4">Alternatively, a SCE aware reciever can attempt to infer what congestion control is being used on the sender side of the connection.</p>
<h1 id="rfc.section.5.3">
<a href="#rfc.section.5.3">5.3.</a> <a href="#other" id="other">Other</a>
</h1>
<p id="rfc.section.5.3.p.1">New transports under development such as QUIC SHOULD implement a multi-bit and finer grained signal back to the sender based on SCE.</p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#related-work" id="related-work">Related Work</a>
</h1>
<p><a href="#RFC8087" class="xref">[RFC8087]</a> <a href="#RFC7567" class="xref">[RFC7567]</a> <a href="#RFC7928" class="xref">[RFC7928]</a> <a href="#RFC8290" class="xref">[RFC8290]</a> <a href="#RFC8289" class="xref">[RFC8289]</a> <a href="#RFC8033" class="xref">[RFC8033]</a> <a href="#RFC8034" class="xref">[RFC8034]</a></p>
<h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#iana-considerations" id="iana-considerations">IANA Considerations</a>
</h1>
<p id="rfc.section.7.p.1">There are no IANA considerations.</p>
<h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
</h1>
<p id="rfc.section.8.p.1">There are no security considerations.</p>
<h1 id="rfc.section.9">
<a href="#rfc.section.9">9.</a> <a href="#acknowledgements" id="acknowledgements">Acknowledgements</a>
</h1>
<p id="rfc.section.9.p.1">Much thanks to the members of the "cake" bufferbloat.net mailing list, the ietf AQM mailing list, and tsvwg.</p>
<h1 id="rfc.references">
<a href="#rfc.references">10.</a> References</h1>
<h1 id="rfc.references.1">
<a href="#rfc.references.1">10.1.</a> Normative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
<td class="top">
<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
<tr>
<td class="reference"><b id="RFC3138">[RFC3138]</b></td>
<td class="top">
<a>Meyer, D.</a>, "<a href="https://tools.ietf.org/html/rfc3138">Extended Assignments in 233/8</a>", RFC 3138, DOI 10.17487/RFC3138, June 2001.</td>
</tr>
</tbody></table>
<h1 id="rfc.references.2">
<a href="#rfc.references.2">10.2.</a> Informative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="RFC3168">[RFC3168]</b></td>
<td class="top">
<a>Ramakrishnan, K.</a>, <a>Floyd, S.</a> and <a>D. Black</a>, "<a href="https://tools.ietf.org/html/rfc3168">The Addition of Explicit Congestion Notification (ECN) to IP</a>", RFC 3168, DOI 10.17487/RFC3168, September 2001.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7567">[RFC7567]</b></td>
<td class="top">
<a>Baker, F.</a> and <a>G. Fairhurst</a>, "<a href="https://tools.ietf.org/html/rfc7567">IETF Recommendations Regarding Active Queue Management</a>", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7928">[RFC7928]</b></td>
<td class="top">
<a>Kuhn, N.</a>, <a>Natarajan, P.</a>, <a>Khademi, N.</a> and <a>D. Ros</a>, "<a href="https://tools.ietf.org/html/rfc7928">Characterization Guidelines for Active Queue Management (AQM)</a>", RFC 7928, DOI 10.17487/RFC7928, July 2016.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8033">[RFC8033]</b></td>
<td class="top">
<a>Pan, R.</a>, <a>Natarajan, P.</a>, <a>Baker, F.</a> and <a>G. White</a>, "<a href="https://tools.ietf.org/html/rfc8033">Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem</a>", RFC 8033, DOI 10.17487/RFC8033, February 2017.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8034">[RFC8034]</b></td>
<td class="top">
<a>White, G.</a> and <a>R. Pan</a>, "<a href="https://tools.ietf.org/html/rfc8034">Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems</a>", RFC 8034, DOI 10.17487/RFC8034, February 2017.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8087">[RFC8087]</b></td>
<td class="top">
<a>Fairhurst, G.</a> and <a>M. Welzl</a>, "<a href="https://tools.ietf.org/html/rfc8087">The Benefits of Using Explicit Congestion Notification (ECN)</a>", RFC 8087, DOI 10.17487/RFC8087, March 2017.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8289">[RFC8289]</b></td>
<td class="top">
<a>Nichols, K.</a>, <a>Jacobson, V.</a>, <a>McGregor, A.</a> and <a>J. Iyengar</a>, "<a href="https://tools.ietf.org/html/rfc8289">Controlled Delay Active Queue Management</a>", RFC 8289, DOI 10.17487/RFC8289, January 2018.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8290">[RFC8290]</b></td>
<td class="top">
<a>Hoeiland-Joergensen, T.</a>, <a>McKenney, P.</a>, <a>Taht, D.</a>, <a>Gettys, J.</a> and <a>E. Dumazet</a>, "<a href="https://tools.ietf.org/html/rfc8290">The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm</a>", RFC 8290, DOI 10.17487/RFC8290, January 2018.</td>
</tr>
</tbody></table>
<h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Jonathon Morton</span>
<span class="n hidden">
<span class="family-name">Morton</span>
</span>
</span>
<span class="org vcardline">Bufferbloat.net</span>
<span class="adr">
<span class="vcardline">Kökkönranta 21</span>
<span class="vcardline">
<span class="locality">PITKÄJÄRVI</span>,
<span class="region"></span>
<span class="code">31520</span>
</span>
<span class="country-name vcardline">FINLAND</span>
</span>
<span class="vcardline">Phone: +358 44 927 2377</span>
<span class="vcardline">EMail: <a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">David M. Täht</span>
<span class="n hidden">
<span class="family-name">Täht</span>
</span>
</span>
<span class="org vcardline">TekLibre</span>
<span class="adr">
<span class="vcardline">20600 Aldercroft Heights Rd</span>
<span class="vcardline">
<span class="locality">Los Gatos</span>,
<span class="region">Ca</span>
<span class="code">95033</span>
</span>
<span class="country-name vcardline">USA</span>
</span>
<span class="vcardline">Phone: +18312059740</span>
<span class="vcardline">EMail: <a href="mailto:dave@taht.net">dave@taht.net</a></span>
</address>
</div>
</body>
</html>