An ECN CE mark conveys a higher likelihood than a dropped packet that a short AQM-managed queue exists at the bottleneck, because AQM indicates congestion before queue overflow. This asymmetry motivates experimenting with a smaller sender backoff in response to CE marks than to drops (e.g., TCP-ABE), which RFC 3168 previously prohibited.

ecn, congestion, tcp

ECT(1) was reserved for the ECN nonce (RFC 3540) to deter receivers from exploiting ECN to improve throughput unfairly, but the nonce saw no widespread Internet deployment. New approaches to discouraging receiver exploitation have emerged, and new experiments need ECT(1), so the nonce experiment is declared concluded and ECT(1) is freed.

ecn, congestion, security

RFC 8311 relaxes RFC 3168 restrictions on ECN experimentation to allow Experimental RFCs to deviate from RFC 3168 without requiring a standards-process exception for each one. The three target areas are: congestion response differences, congestion marking differences, and ECN on TCP control packets and retransmissions.

ecn, congestion

Using ECT(1) versus ECT(0) to distinguish traffic classes at network nodes is the proposed means of enabling very-shallow-queue AQM experiments (e.g., L4S) without harming conventional ECT(0) traffic. Differentiating by codepoint avoids requiring network nodes to use other per-flow state to identify experimental traffic.

ecn, congestion

With ECN now widely deployed, extending ECN to TCP SYNs and retransmissions (ECN++) would allow congestion signaling in connection setup and recovery phases, but RFC 3168 explicitly prohibited this. Allowing it only under an Experimental RFC ensures IETF oversight while removing the blanket prohibition.

ecn, tcp, congestion

The ECN nonce experiment (RFC 3540) has concluded without widespread deployment. A 2014 study of the top one million web servers found none of the 581,711 IPv4 servers tested used both ECT codepoints; only four of 17,028 IPv6 servers set both ECT(0) and ECT(1), possibly due to middlebox re-marking. RFC 3540 is reclassified from Experimental to Historic, freeing the ECT(1) codepoint for new experimental use.

ecn, congestion

ECN field handling for tunnel encapsulation and decapsulation remains governed by RFC 6040 (being updated by ECN-SHIM), and related guidance for non-IP outer headers is in ECN-ENCAP. These requirements apply to all traffic including ECN experimental traffic.

ecn, congestion

Routers not involved in ECN experiments should continue to treat ECT(0) and ECT(1) as equivalent, as specified in RFC 3168. This preserves backwards compatibility with deployed infrastructure while experiments that require differentiated treatment must be governed by their own Experimental RFC.

ecn, congestion

Systems or protocols that inspect or monitor network traffic SHOULD be prepared to encounter ECN usage on packets and traffic that currently do not use ECN, specifically TCP control packets and retransmissions, as these may appear in ECN experiments enabled by this memo.

ecn, tcp, congestion

A network node MUST NOT originate traffic marked with ECT(1) unless the network node is participating in a Congestion Marking Differences experiment that uses ECT(1). This prevents spurious ECT(1) injection outside of sanctioned experiments.

ecn, congestion

Any Experimental RFC in the IETF document stream that takes advantage of this memo's updates MUST discuss the congestion control implications of the experiment to provide assurance that deployment does not pose a congestion-based threat to Internet operation.

ecn, congestion, security

Congestion Marking Differences experiments SHOULD modify network behavior for ECT(1) rather than ECT(0) if only one codepoint's behavior is modified. Experiments MUST NOT modify network behavior for ECT(0) in a fashion that requires sender congestion response changes to obtain desired network behavior.

ecn, congestion

DCCP CCIDs 2 (RFC 4341), 3 (RFC 4342), and 4 (RFC 5622) are updated so that DCCP-Data and DCCP-DataAck senders MUST set the ECT(0) codepoint unless otherwise specified by an Experimental RFC in the IETF document stream, replacing language that allowed either ECT(0) or ECT(1).

ecn, congestion

If a Congestion Marking Differences experiment modifies ECT(1) network behavior in a way requiring sender congestion response changes, the Experimental RFC MUST specify both: the sender congestion response to CE marking, and router behavior changes (or absence thereof) in forwarding CE-marked experiment packets.

ecn, congestion

Middleboxes SHOULD NOT discard TCP control packets and retransmitted TCP packets solely because the ECN field does not contain Not-ECT. An exception applies when responding to an attack using ECN codepoints other than Not-ECT; any such exceptional discarding MUST NOT be done routinely and SHOULD only be done if ECN is determined to be contributing to the attack.

ecn, tcp, congestion, security

Network nodes that forward packets SHOULD NOT assume that the ECN CE codepoint indicates that the packet would have been dropped if ECN were not in use, and CE-marked packets SHOULD NOT be arbitrarily dropped, because Congestion Response Differences experiments employ different congestion responses to drops versus CE marks.

ecn, congestion

Protocols and senders MUST use the ECT(0) codepoint to indicate ECN-Capable Transport (ECT) unless otherwise specified by an Experimental RFC in the IETF document stream. Protocols and senders MUST NOT use the ECT(1) codepoint to indicate ECT unless otherwise specified by an Experimental RFC in the IETF document stream.

ecn, congestion

RFC 3168 prohibitions on ECN for TCP control packets (SYN, SYN-ACK, pure ACKs, window probes) and retransmitted packets are updated to allow such use provided the changes are documented in an Experimental RFC in the IETF document stream, with 'unless otherwise specified by an Experimental RFC in the IETF document stream' appended to each prohibiting sentence.

ecn, tcp, congestion

RFC 3168 Section 5 text requiring that senders respond identically to dropped packets and ECN CE marks is updated to allow different congestion control responses, provided the changes are documented in an Experimental RFC in the IETF document stream. The specific change inserts 'unless otherwise specified by an Experimental RFC in the IETF document stream' into the relevant sentences.

ecn, congestion, tcp

RFC 3168 text that routers treat ECT(0) and ECT(1) as equivalent is updated to allow routers to treat the two codepoints differently, provided the changes are documented in an Experimental RFC in the IETF document stream.

ecn, congestion

RFC 6679 (ECN for RTP) is updated: random ECT values MUST NOT be used in RTP because they may expose RTP to differences in network treatment of ECT(1) versus ECT(0) traffic, and ECT(0) MUST be used unless otherwise specified in an Experimental RFC in the IETF document stream.

ecn, rtp, congestion

RFC 6679 Section 7.3.3 is updated to allow the RTP congestion control response to a CE-marked packet to differ from the response to a dropped packet, provided changes are documented in an Experimental RFC. The default reaction (treat CE marks like loss) and the no-difference rule both become conditional on absence of a governing Experimental RFC.

ecn, rtp, congestion

ECN uses four codepoints in the two-bit ECN field of the IP header: Not-ECT (not ECN capable), ECT(0) and ECT(1) (both indicate ECN-Capable Transport), and CE (Congestion Experienced). Senders set ECT(0) or ECT(1) to signal ECN capability; network nodes set CE to signal congestion.

ecn, ip, congestion

IANA updated the 'Transmission Control Protocol (TCP) Header Flags' registry to remove the registration of TCP header bit 7 as the NS (Nonce Sum) bit and added an annotation stating that bit 7 was used by Historic RFC 3540 as the NS bit but is now Reserved.

registry, tcp, ecn

As a process memo relaxing experimentation restrictions, RFC 8311 itself introduces no new protocol security risks. Security considerations for specific experiments are deferred to their respective Experimental RFCs, and IETF/IESG review of those documents provides assurance that Internet congestion control is not broken.

security, ecn, congestion

Effective congestion control is crucial to Internet operation; this memo places responsibility for maintaining it on experimenters. Middleboxes may respond to ECN-based attacks (e.g., ECT-marked SYN floods) by dropping ECT-marked packets at higher probability, but only during an actual attack and only if ECN is determined to be contributing.

security, ecn, tcp, congestion