One document matched: draft-black-tsvwg-ecn-experimentation-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-black-tsvwg-ecn-experimentation-02"
ipr="trust200902" obsoletes="3540" updates="3168, 4341, 4342, 5622, 6679">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="ECN Experimentation">Explicit Congestion Notification (ECN)
Experimentation</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="David Black" initials="D.L." surname="Black">
<organization>Dell EMC</organization>
<address>
<postal>
<street>176 South Street</street>
<!-- Reorder these if your country does things differently -->
<city>Hopkinton</city>
<region>MA</region>
<code>01748</code>
<country>USA</country>
</postal>
<phone/>
<email>david.black@dell.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="October" year="2016"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Transport Area Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>ECN</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Multiple protocol experiments have been proposed that involve changes
to Explicit Congestion Notification (ECN) as specified in RFC 3168. This
memo summarizes the proposed areas of experimentation to provide an
overview to the Internet community and updates RFC 3168, a Proposed
Standard RFC, to allow the experiments to proceed without requiring a
standards process exception for each Experimental RFC to update RFC
3168. Each experiment is still required to be documented in an
Experimental RFC. In addition, this memo makes related updates to the
ECN specifications for RTP in RFC 6679 and to the ECN specifications for
DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the
conclusion of the ECN Nonce experiment in RFC 3540, obsoletes RFC 3540
and reclassifies it as Historic to enable new experimental use of the
ECT(1) codepoint.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Multiple protocol experiments have been proposed that involve changes
to Explicit Congestion Notification (ECN) as specified in <xref
target="RFC3168">RFC 3168</xref>. This memo summarizes the proposed
areas of experimentation to provide an overview to the Internet
community and updates RFC 3168 to allow the experiments to proceed
without requiring a standards process exception for each Experimental
RFC to update RFC 3168, a Proposed Standard RFC. This memo also makes
related updates to the ECN specification for RTP in <xref
target="RFC6679">RFC 6679</xref> for the same reason. Each experiment is
still required to be documented in one or more separate RFCs, but use of
Experimental RFCs for this purpose does not require a process exception
to modify RFC 3168 or RFC 6679 when the modification falls within the
bounds established by this memo.</t>
<t>One of these areas of experimentation involves use of the ECT(1)
codepoint that was dedicated to the ECN Nonce experiment as described in
<xref target="RFC3540">RFC 3540</xref>. This memo records the conclusion
of the ECN Nonce experiment, obsoletes RFC 3540 and reclassifies it as
Historic.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Scope of ECN Experiments">
<t>Three areas of ECN experimentation are covered by this memo; the
cited Internet-Drafts should be consulted for the goals and rationale of
each proposed experiment:<list style="hanging">
<t hangText="Alternative Backoff:">For congestion indicated by ECN,
use a different IETF-approved TCP sender response (e.g., reduce the
response so that the sender backs off by a smaller amount) by
comparison to congestion indicated by loss, e.g., as proposed in
<xref target="I-D.khademi-tcpm-alternativebackoff-ecn"/> and <xref
target="I-D.briscoe-tsvwg-ecn-l4s-id"/> - the experiment in the
latter draft couples the backoff change to ECT Differences
functionality (next bullet). This is at variance with RFC 3168's
requirement that a TCP sender's congestion control response to ECN
congestion indications be the same as to drops.</t>
<t hangText="ECT Differences:">Use ECT(1) to request ECN congestion
marking behavior in the network that differs from ECT(0)
counterbalanced by a changed response to each mark at the sender,
e.g., as proposed in <xref target="I-D.briscoe-tsvwg-ecn-l4s-id"/>.
This is at variance with RFC 3168's requirement that ECT(0)-marked
traffic and ECT(1)-marked traffic not receive different treatment in
the network.</t>
<t hangText="Generalized ECN:">Use ECN for TCP control packets
(i.e., send control packets such as SYN with ECT marking) and for
retransmitted packets, e.g., as proposed in <xref
target="I-D.bagnulo-tsvwg-generalized-ecn"/>. This is at variance
with RFC 3168's prohibition of use of ECN for TCP control packets
and retransmitted packets</t>
</list>The scope of this memo is limited to these three areas of
experimentation. This memo neither prejudges the outcomes of the
proposed experiments nor specifies the experiments in detail. The
purpose of this memo is to remove constraints in standards track RFCs
that serve to prohibit these areas of experimentation.</t>
</section>
<section anchor="ECNNonce" title="ECN Nonce and RFC 3540">
<t>As specified in RFC 3168, ECN uses two ECN Capable Transport (ECT)
codepoints to indicate that a packet supports ECN, ECT(0) and ECT(1),
with the second codepoint used to support ECN nonce functionality to
discourage receivers from exploiting ECN to improve their throughput at
the expense of other network users, as specified in experimental <xref
target="RFC3540">RFC 3540</xref>.</t>
<t>While the ECN Nonce works as specified, and has been deployed in
limited environments, widespread usage in the Internet has not
materialized. A study of the ECN behaviour of the Alexa top 1M web
servers using 2014 data <xref target="Trammell15"/> found that after ECN
was negotiated, none of the 581,711 IPv4 servers tested were using both
ECT codepoints, which would have been a possible sign of ECN Nonce
usage. Of the 17,028 IPv6 servers tested, 4 set both ECT(0) and ECT(1)
on data packets. This might have been evidence of use of the ECN Nonce
by these 4 servers, but equally it might have been due to re-marking of
the ECN field by an erroneous middlebox or router.</t>
<t>With the emergence of new experimental functionality that depends on
use of the ECT(1) codepoint for other purposes, continuing to reserve
that codepoint for the ECN Nonce experiment is no longer justified. In
addition, alternative approaches to discouraging receivers from
exploiting ECN have emerged, see Appendix B.1 of <xref
target="I-D.briscoe-tsvwg-ecn-l4s-id"/>. Therefore, in support of ECN
experimentation with the ECT(1) codepoint, this memo:<list
style="symbols">
<t>Declares that the ECN Nonce experiment <xref target="RFC3540"/>
has concluded, and notes the absence of widespread deployment.</t>
<t>Obsoletes RFC 3540 in order to facilitate experimental use of the
ECT(1) codepoint.</t>
<t>Reclassifies RFC 3540 as Historic to document the ECN Nonce
experiment and discourage further implementation of the ECN
Nonce.</t>
<t>Updates <xref target="RFC3168">RFC 3168</xref> to remove
discussion of the ECN Nonce and use of ECT(1) for that Nonce. The
specific text updates are omitted for brevity.</t>
</list>The following guidance on ECT codepoint usage in Section 5 of
RFC 3168 is relevant when the ECN Nonce is not implemented:</t>
<t><list>
<t>Protocols and senders that only require a single ECT codepoint
SHOULD use ECT(0).</t>
</list>OPEN ISSUE: Change the above requirement in RFC 3168 from
SHOULD to MUST towards reserving ECT(1) for experimentation?</t>
</section>
<section title="Updates to RFC 3168">
<t>RFC 3168 can only be updated directly by another standards track RFC
unless a standards process exception is approved by the IESG. In support
of the above areas of experimentation, and specifically to avoid
multiple uncoordinated requests to the IESG for process exceptions, this
memo updates <xref target="RFC3168">RFC 3168</xref> ito allow changes in
the following areas, provided that the changes are documented by an
Experimental RFC. It is also possible to change RFC 3168 via publication
of another standards track RFC.</t>
<section title="Alternative Backoff">
<t>Section 5 of RFC 3168 specifies that:</t>
<t><list style="empty">
<t>"Upon the receipt by an ECN-Capable transport of a single CE
packet, the congestion control algorithms followed at the
end-systems MUST be essentially the same as the congestion control
response to a *single* dropped packet."</t>
</list>In support of Alternative Backoff experimentation, this memo
updates RFC 3168 to allow the congestion control response (including
the TCP Sender's congestion control response) to a CE-marked packet to
differ from the response to a dropped packet, provided that the
changes from RFC 3168 are documented in an Experimental RFC. The
specific change to RFC 3168 is to insert the words "unless otherwise
specified by an Experimental RFC" at the end of the sentence quoted
above.</t>
<t><xref target="RFC4774">RFC 4774</xref> quotes the above text from
RFC 3168 as background, but does not impose requirements based on that
text. Therefore no update to RFC 4774 is required to enable this area
of experimentation.</t>
</section>
<section title="ECT Differences">
<t>Section 5 of RFC 3168 specifies that:<list style="empty">
<t>"Routers treat the ECT(0) and ECT(1) codepoints as equivalent.
Senders are free to use either the ECT(0) or the ECT(1) codepoint
to indicate ECT, on a packet-by-packet basis."</t>
</list>In support of ECT Differences experimentation, this memo
updates RFC 3168 to allow routers to treat the ECT(0) and ECT(1)
codepoints differently, and allow requirements to be imposed on sender
usage of ECT(0) and ECT(1), provided that the changes from RFC 3168
are documented in an Experimental RFC. That change makes the second
sentence quoted above misleading, so RFC 3168 is also updated to
remove that sentence. The specific change to RFC 3168 is to insert the
words "unless otherwise specified by an Experimental RFC" at the end
of the first sentence, and remove the second sentence with this
result:</t>
<t><list style="empty">
<t>"Routers treat the ECT(0) and ECT(1) codepoints as equivalent
unless otherwise specified by an Experimental RFC."</t>
</list>As ECT(0) was the original codepoint used to signal ECN
capability, ECT Differences experiments SHOULD modify the network
behavior for ECT(1) rather than ECT(0) if network behavior for only
one ECT codepoint is modified.</t>
<t>In support of ECT Differences experimentation, this memo also
updates RFC 3168 to remove discussion of the ECN Nonce, as noted in
Section <xref format="counter" target="ECNNonce"/> above.</t>
</section>
<section title="Generalized ECN">
<t>RFC 3168 prohibits use of ECN for TCP control packets and
retransmitted packets in a number of places:<list style="symbols">
<t>"To ensure the reliable delivery of the congestion indication
of the CE codepoint, an ECT codepoint MUST NOT be set in a packet
unless the loss of that packet in the network would be detected by
the end nodes and interpreted as an indication of congestion."
(Section 5.2)</t>
<t>"A host MUST NOT set ECT on SYN or SYN-ACK packets." (Section
6.1.1)</t>
<t>"pure acknowledgement packets (e.g., packets that do not
contain any accompanying data) MUST be sent with the not-ECT
codepoint." (Section 6.1.4)</t>
<t>"This document specifies ECN-capable TCP implementations MUST
NOT set either ECT codepoint (ECT(0) or ECT(1)) in the IP header
for retransmitted data packets, and that the TCP data receiver
SHOULD ignore the ECN field on arriving data packets that are
outside of the receiver's current window." (Section 6.1.5)</t>
<t>"the TCP data sender MUST NOT set either an ECT codepoint or
the CWR bit on window probe packets." (Section 6.1.6)</t>
</list></t>
<t>In support of Generalized ECN experimentation, this memo updates
RFC 3168 to allow the use of ECT codepoints on SYN and SYN-ACK
packets, pure acknowledgement packets, window probe packets and
retransmissions of packets that were originally sent with an ECT
codepoint, provided that the changes from RFC 3168 are documented in
an Experimental RFC. The specific change to RFC 3168 is to insert the
words "unless otherwise specified by an Experimental RFC" at the end
of each sentence quoted above.</t>
</section>
<section anchor="ECC" title="Effective Congestion Control is Required">
<t>Congestion control remains an important aspect of the Internet
architecture <xref target="RFC2914"/>. Any Experimental RFC that takes
advantage of this memo's updates to RFC 3168 or RFC 6679 is required
to discuss the congestion control implications of the experiment(s) in
order to provide assurance that deployment of the experiment(s) does
not pose a congestion-based threat to the operation of the
Internet.</t>
</section>
</section>
<section title="ECN for RTP Updates to RFC 6679">
<t><xref target="RFC6679">RFC 6679</xref> specifies use of ECN for RTP
traffic; it allows use of both the ECT(0) and ECT(1) codepoints, and
provides the following guidance on use of these codepoints in section
7.3.1 :</t>
<t><list>
<t>The sender SHOULD mark packets as ECT(0) unless the receiver
expresses a preference for ECT(1) or for a random ECT value using
the "ect" parameter in the "a=ecn-capable-rtp:" attribute.</t>
</list></t>
<t>The ECT Differences area of experimentation increases the potential
consequences of using ECT(1) instead of ECT(0), and hence the above
guidance is updated by adding the following two sentences:</t>
<t><list>
<t>Use of random ECT values is NOT RECOMMENDED, as that may expose
RTP to differences in network treatment of traffic marked with
ECT(1) and ECT(0) and differences in associated endpoint congestion
responses, e.g., as proposed in <xref
target="I-D.briscoe-tsvwg-ecn-l4s-id"/>. ECT(0) SHOULD be used
unless there is a need for more than one ECT codepoint or unless
otherwise specified in an Experimental RFC.</t>
</list>Section 7.3.3 of RFC 6679 specifies RTP's response to receipt
of CE marked packets as being identical to the response to dropped
packets:</t>
<t><list>
<t>The reception of RTP packets with ECN-CE marks in the IP header
is a notification that congestion is being experienced. The default
reaction on the reception of these ECN-CE-marked packets MUST be to
provide the congestion control algorithm with a congestion
notification that triggers the algorithm to react as if packet loss
had occurred. There should be no difference in congestion response
if ECN-CE marks or packet drops are detected.</t>
</list>In support of Alternative Backoff experimentation, this memo
updates this text in a fashion similar to RFC 3168 to allow the RTP
congestion control response to a CE-marked packet to differ from the
response to a dropped packet, provided that the changes from RFC 6679
are documented in an Experimental RFC. The specific change to RFC 6679
is to insert the words "Unless otherwise specified by an Experimental
RFC" and reformat the last two sentences to be subject to that
condition, i.e.:</t>
<t><list>
<t>The reception of RTP packets with ECN-CE marks in the IP header
is a notification that congestion is being experienced. Unless
otherwise specified by an Experimental RFC: <list style="symbols">
<t>The default reaction on the reception of these ECN-CE-marked
packets MUST be to provide the congestion control algorithm with
a congestion notification that triggers the algorithm to react
as if packet loss had occurred.</t>
<t>There should be no difference in congestion response if
ECN-CE marks or packet drops are detected.</t>
</list></t>
</list>The second sentence of the immediately following paragraph in
RFC 6679 requires a related update:</t>
<t><list>
<t>Other reactions to ECN-CE may be specified in the future,
following IETF Review. Detailed designs of such alternative
reactions MUST be specified in a Standards Track RFC and be reviewed
to ensure they are safe for deployment under any restrictions
specified.</t>
</list>The update is to change "Standards Track RFC" to "Standards
Track RFC or Experimental RFC" for consistency with the first
update.</t>
</section>
<section title="ECN for DCCP Updates to RFCs 4341, 4342 and 5622">
<t>The specifications of the three DCCP Congestion Control IDs (CCIDs)
<xref target="RFC4341">2</xref>, <xref target="RFC4342">3</xref> and
<xref target="RFC5622">4</xref> contain broadly the same wording as
follows:</t>
<t><list>
<t>each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable
with either the ECT(0) or the ECT(1) codepoint set.</t>
</list>This memo updates these sentences in each of the three RFCs as
follows:<list>
<t>each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable.
Unless otherwise specified by an Experimental RFC, such DCCP senders
SHOULD set the ECT(0) codepoint.</t>
</list>In support of ECT Differences experimentation (as noted in
Section 3), this memo also updates all three of these RFCs to remove
discussion of the ECN Nonce. The specific text updates are omitted for
brevity.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The content of this draft, including the specific portions of RFC
3168 that are updated draws heavily from <xref
target="I-D.khademi-tsvwg-ecn-response"/>, whose authors are gratefully
acknowledged. The authors of the Internet Drafts describing the
experiments have motivated the production of this memo - their interest
in innovation is welcome and heartily acknowledged. Colin Perkins
suggested updating RFC 6679 on RTP and provided guidance on where to
make the updates.</t>
<t>The draft has been improved as a result of comments from a number of
reviewers, including Spencer Dawkins, Gorry Fairhurst, Ingemar
Johansson, Naeem Khademi, Mirja Kuehlewind and Michael Welzl. Bob
Briscoe's thorough review of an early version of this draft resulted in
numerous improvments including addition of the updates to the DCCP
RFCs.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>As a process memo that makes no changes to existing protocols, there
are no protocol security considerations.</t>
<t>However, effective congestion control is crucial to the continued
operation of the Internet, and hence this memo places the responsibility
for not breaking Internet congestion control on the experiments and the
experimenters who propose them, as specified in Section <xref
format="counter" target="ECC"/>.</t>
<t>Security considerations for the proposed experiments are dicussed in
the Internet-Drafts that propose them.</t>
<t>See Appendix B.1 of <xref target="I-D.briscoe-tsvwg-ecn-l4s-id"/> for
discussion of alteratives to the ECN Nonce.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2914" ?>
<?rfc include="reference.RFC.3168" ?>
<?rfc include="reference.RFC.3540" ?>
<?rfc include="reference.RFC.4341" ?>
<?rfc include="reference.RFC.4342" ?>
<?rfc include="reference.RFC.5622" ?>
<?rfc include="reference.RFC.6679" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.khademi-tcpm-alternativebackoff-ecn" ?>
<?rfc include="reference.I-D.khademi-tsvwg-ecn-response" ?>
<?rfc include="reference.I-D.briscoe-tsvwg-ecn-l4s-id" ?>
<?rfc include="reference.I-D.bagnulo-tsvwg-generalized-ecn" ?>
<?rfc include="reference.RFC.4774" ?>
<reference anchor="Trammell15">
<front>
<title>Enabling Internet-Wide Deployment of Explicit Congestion
Notification</title>
<author initials="B." surname="Trammell">
<organization/>
</author>
<author initials="M." surname="Kuehlewind">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author initials="D." surname="Boppart">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author initials="I." surname="Learmonth">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author initials="G." surname="Fairhurst">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author initials="R." surname="Scheffenegger">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date/>
</front>
<annotation>In Proc Passive & Active Measurement (PAM'15)
Conference (2015)</annotation>
</reference>
</references>
<section title="Change History" toc="exclude">
<t>[To be removed before RFC publication.]</t>
<t>Changes from draft-black-tsvwg-ecn-experimentation-00 to -01</t>
<t><list style="symbols">
<t>Section 4.2 - also update RFC 3168 to remove sentence indicating
that senders are free to use both ECT codepoints. Add a SHOULD for
ECT Differences experiments to use ECT(1).</t>
<t>Section 5 - only discourage use of random ECT values, but use NOT
RECOMMENDED to do so. Consistent use of ECT(1) without using ECT(0)
is ok. Mention possible changes in endpoint response.</t>
<t>Add more Acknowledgements and Change History</t>
<t>Additional editorial changes.</t>
</list>Changes from draft-black-tsvwg-ecn-experimentation-01 to
-02</t>
<t><list style="symbols">
<t>Add DCCP RFC updates and one missing RFC 3168 update (probe
packets).</t>
<t>Discourage RTP usage of ECT(1).</t>
<t>Strengthen text on lack of ECN Nonce deployment.</t>
<t>Cross-reference the L4S draft appendix that discusses ECN Nonce
alternatives.</t>
<t>Additional editorial changes.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:41 |