Explicit Congestion Notification (ECN) Experimentation

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 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 RFC 6679 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. One of these areas of experimentation involves use of the ECT(1) codepoint that was dedicated to the ECN Nonce experiment as described in RFC 3540. This memo records the conclusion of the ECN Nonce experiment, obsoletes RFC 3540 and reclassifies it as Historic.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Three areas of ECN experimentation are covered by this memo; in each case, the cited Internet-Draft should be consulted for the goals and rationale of the proposed experiment: For congestion indicated by ECN, use a different TCP sender response (e.g., backoff by a smaller amount) by comparison to congestion indicated by loss, e.g., as specified in . 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. Use ECT(1) to request ECN congestion marking behavior in the network that differs from ECT(0), e.g., as specified in . 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. Use ECN for TCP control packets (i.e., send control packets such as SYN with ECT marking) and for retransmitted packets, e.g., as specified in . This is at variance with RFC 3168's prohibition of use of ECN for TCP control packets and retransmitted packets The scope of this memo is limited to these three areas of experimentation.

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 RFC 3540. While the ECN Nonce works as specified, and has been deployed in limited environments, widespread usage in the Internet has not materialized, as the potential for this sort of receiver ECN exploitation has not turned out to be a significant concern in practice. 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 is no longer justified. Therefore, in support of ECN experimentation with the ECT(1) codepoint, this memo: Declares that the ECN Nonce experiment has concluded, and notes the absence of widespread deployment. Obsoletes RFC 3540 in order to facilitate experimental use of the ECT(1) codepoint. Reclassifies RFC 3540 as Historic to document the ECN Nonce experiment and discourage further implementation of the ECN Nonce. Updates RFC 3168 to remove discussion of the ECN Nonce and use of ECT(1) for that Nonce. The specific text updates are omitted for brevity. The following guidance on ECT codepoint usage in Section 5 of RFC 3168 is relevant when the ECN Nonce is not implemented: Protocols and senders that only require a single ECT codepoint SHOULD use ECT(0).

In support of these areas of experimentation, this memo updates RFC 3168 to 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 a standards track RFC.

Section 5 of RFC 3168 specifies that: "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." 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. RFC 4774 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.

Section 5 of RFC 3168 specifies that: "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." 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. The specific change to RFC 3168 is to insert the words "Unless otherwise specified by an Experimental RFC" and combine the two sentences into a single sentence with this result: "Unless otherwise specified by an Experimental RFC, routers treat the ECT(0) and ECT(1) codepoints as equivalent, and senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." As ECT(0) was the original codepoint used to signal ECN capability, it is preferable for ECT Differences experiments to modify the behavior of ECT(1) rather than ECT(0) if behavior of only one ECT codepoint is modified. In support of ECT Differences experimentation, this memo also updates RFC 3168 to remove discussion of the ECN Nonce, as noted in Section above.

RFC 3168 prohibits use of ECN for TCP control packets and retransmitted packets in a number of places: "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) "A host MUST NOT set ECT on SYN or SYN-ACK packets." (Section 6.1.1) "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) "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) 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, 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.

Congestion control remains an important aspect of the Internet architecture . 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.

RFC 6679 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 : 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. 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 sentence: Use of ECT(1) and random ECT values is discouraged, as that may expose RTP to differences in network treatment of ECT(1) and ECT(0), e.g., as proposed in . 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: 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. 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 3168 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.: 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: 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. The second sentence of the immediately following paragraph in RFC 6679 requires a related update: 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. The update is to change "Standards Track RFC" to "Standards Track RFC or Experimental RFC" for consistency with the first update.

The content of this draft, including the specific portions of RFC 3168 that are updated draws heavily from , 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 and provided guidance on where to make the updates.

This memo includes no request to IANA.

As a process memo that makes no changes to existing protocols, there are no protocol security considerations. 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 .