Really Explicit Congestion Notification (RECN)
An April Fools' approach to telling hosts to slow down, very explicitly.
Luckie, M., "Really Explicit Congestion Notification (RECN)", RFC 7514, DOI 10.17487/RFC7514, April 2015, <https://www.rfc-editor.org/info/rfc7514>.
@misc{rfc7514,
series = {Request for Comments},
number = 7514,
howpublished = {RFC 7514},
publisher = {RFC Editor},
doi = {10.17487/RFC7514},
url = {https://www.rfc-editor.org/info/rfc7514},
author = {M. Luckie},
title = {{Really Explicit Congestion Notification (RECN)}},
pagetotal = 5,
year = 2015,
month = apr,
} RFC text
Contents
Independent Submission M. Luckie
Request for Comments: 7514 CAIDA
Category: Experimental 1 April 2015
ISSN: 2070-1721
Really Explicit Congestion Notification (RECN)
Abstract
This document proposes a new ICMP message that a router or host may
use to advise a host to reduce the rate at which it sends, in cases
where the host ignores other signals provided by packet loss and
Explicit Congestion Notification (ECN).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This is a contribution to the RFC Series, independently
of any other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7514.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. RECN Message Format . . . . . . . . . . . . . . . . . . . . . 2
2.1. Advice to Implementers . . . . . . . . . . . . . . . . . 3
2.2. Relationship to ICMP Source Quench . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The deployment of Explicit Congestion Notification (ECN) [RFC3168]
remains stalled. While most operating systems support ECN, it is
currently disabled by default because of fears that enabling ECN will
break transport protocols. This document proposes a new ICMP message
that a router or host may use to advise a host to reduce the rate at
which it sends, in cases where the host ignores other signals such as
packet loss and ECN. We call this message the "Really Explicit
Congestion Notification" (RECN) message because it delivers a less
subtle indication of congestion than packet loss and ECN.
1.1. Requirements Language
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 [RFC2119].
2. RECN Message Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Explicit Notification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of the invoking packet as possible |
+ without the ICMP packet exceeding 576 bytes |
| in IPv4 or the minimum MTU in IPv6 |
Type
IPv4: 4
IPv6: 201
Code
0
Checksum
The checksum is the 16-bit ones's complement of the one's
complement sum of the ICMP message starting with the ICMP type
field. When an RECN message is encapsulated in an IPv6 packet,
the computation includes a "pseudo-header" of IPv6 header fields
as specified in Section 8.1 of [RFC2460]. For computing the
checksum, the checksum field is first set to zero.
Explicit Notification
A 4-byte value that conveys an explicit notification in the ASCII
format defined in [RFC20]. This field MUST NOT be set to zero.
Description
An RECN message SHOULD be sent by a router in response to a host
that is generating traffic at a rate persistently unfair to other
competing flows and that has not reacted to previous packet losses
or ECN marks.
The contents of an RECN message MUST be conveyed to the user
responsible for the traffic. Precisely how this is accomplished
will depend on the capabilities of the host. If text-to-speech
capabilities are available, the contents should be converted to
sound form and audibly rendered. If the system is currently
muted, a pop-up message will suffice.
2.1. Advice to Implementers
As the Explicit Notification field is only 4 bytes, it is not
required that the word be null terminated. A client implementation
should be careful not to use more than those 4 bytes. If a router
chooses a word less than 4 bytes in size, it should null-terminate
that word.
A router should not necessarily send an RECN message every time it
discards a packet due to congestion. Rather, a router should send
these messages whenever it discards a burst of packets from a single
sender. For every packet a router discards in a single burst, it
should send an RECN message. A router may form short sentences
composed of different 4-byte words, and a host should play these
sentences back to the user. A router may escalate the content in the
Explicit Notification field if it determines that a sender has not
adjusted its transmission rate in response to previous RECN messages.
There is no upper bound on the intensity of the escalation, either in
content or sentence length.
2.2. Relationship to ICMP Source Quench
The RECN message was inspired by the ICMP Source Quench message,
which is now deprecated [RFC6633]. Because the RECN message uses a
similar approach, an RECN message uses the same ICMP type when
encapsulated in IPv4 as was used by the ICMP Source Quench message.
3. IANA Considerations
This is an Experimental RFC; the experiment will conclude two years
after the publication of this RFC. During the experiment,
implementers are free to use words of their own choosing (up to four
letters) in RECN messages. If RECN becomes a Standard of any kind, a
list of allowed words will be maintained in an IANA registry. There
are no IANA actions required at this time.
4. Security Considerations
ICMP messages may be used in various attacks [RFC5927]. An attacker
may use the RECN message to cause a host to reduce their transmission
rate for no reason. To prevent such an attack, a host must ensure
the quoted message corresponds to an active flow on the system, and
an attacker MUST set the security flag defined in [RFC3514] to 1 when
the RECN message is carried in an IPv4 packet.
5. Normative References
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, October 1969,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998,
<http://www.rfc-editor.org/info/rfc2460>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC
3514, April 2003,
<http://www.rfc-editor.org/info/rfc3514>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010,
<http://www.rfc-editor.org/info/rfc5927>.
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages",
RFC 6633, May 2012,
<http://www.rfc-editor.org/info/rfc6633>.
Author's Address
Matthew Luckie
CAIDA
University of California, San Diego
9500 Gilman Drive
La Jolla, CA 92093-0505
United States
EMail: mjl@caida.org
AI ELI5
On this page
§1The Problem with Silent Signals
RFC 7514 proposes Really Explicit Congestion Notification (RECN), a tongue-in-cheek solution to hosts that stubbornly ignore both packet loss and Explicit Congestion Notification (ECN) [RFC3168]. Some senders continue to transmit at unfair rates regardless of congestion signals. RECN delivers congestion information in a form a host cannot miss: a 4-byte ASCII message in an ICMP packet.
If a host ignores both dropped packets and polite hints, the router sends an actual message, 4 letters long, telling it to slow down.
§2RECN Message Structure
An RECN message is an ICMP packet with a 32-bit Explicit Notification field containing a 4-byte ASCII value. The type is IPv4 type 4 (reusing the deprecated ICMP Source Quench type) and IPv6 type 201. A router SHOULD NOT send an RECN message for every dropped packet, but rather for each packet in a burst from a congestion-causing sender. The specification humorously suggests that routers can form short sentences composed of different 4-byte RECN messages and escalate the content if the host does not respond, with no upper bound on intensity.
The message is 4 letters, sent in an ICMP packet. A router can send one for each packet in a burst, and can even send sentences of multiple 4-letter words to naughty hosts.
§3Implementer Advice and Deployment
The RFC notes that implementers are free to choose their own 4-letter words during the experimental period. The specification advises that if the system has text-to-speech, the message should be converted to sound and audibly rendered; if muted, a pop-up will do. Hosts must verify the quoted message corresponds to an active flow to prevent spoofing attacks. The document wryly references RFC 3514 ("The Security Flag in the IPv4 Header"), implying attackers must set the security flag when sending RECN messages.
If your computer can speak, the message is spoken out loud. If it is muted, a pop-up appears. Attackers must follow the rules too.
§4Inspiration and Status
RECN was inspired by the deprecated ICMP Source Quench message [RFC6633], which was removed from the specification because it was ineffective and could be abused. This RFC acknowledges that relationship by reusing the same ICMP type. The document is Experimental, with the experiment concluding two years after publication. No real-world implementations were anticipated.
This idea builds on an old system called Source Quench that nobody uses anymore. It is a joke about what a more literal approach would look like.