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.







Luckie                        Experimental                      [Page 1]

RFC 7514                          RECN                      1 April 2015


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



Luckie                        Experimental                      [Page 2]

RFC 7514                          RECN                      1 April 2015


  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



Luckie                        Experimental                      [Page 3]

RFC 7514                          RECN                      1 April 2015


  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>.




Luckie                        Experimental                      [Page 4]

RFC 7514                          RECN                      1 April 2015


  [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: [email protected]






























Luckie                        Experimental                      [Page 5]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.