Section 12. Explicit Congestion Notification

The DCCP protocol is fully ECN-aware [RFC3168].  Each CCID specifies
   how its endpoints respond to ECN marks.  Furthermore, DCCP, unlike
   TCP, allows senders to control the rate at which acknowledgements are
   generated (with options like Ack Ratio); since acknowledgements are
   congestion controlled, they also qualify as ECN-Capable Transport.
   Each CCID profile describes how that CCID interacts with ECN, both
   for data traffic and pure-acknowledgement traffic.  A sender SHOULD
   set ECN-Capable Transport on its packets' IP headers unless the
   receiver's ECN Incapable feature is on or the relevant CCID disallows
   it.
   The rest of this section describes the ECN Incapable feature and the
   interaction of the ECN Nonce with acknowledgement options such as Ack
   Vector.
12.1.  ECN Incapable Feature
   DCCP endpoints are ECN-aware by default, but the ECN Incapable
   feature lets an endpoint reject the use of Explicit Congestion
   Notification.  The use of this feature is NOT RECOMMENDED.  ECN
   incapability both avoids ECN's possible benefits and prevents senders
   from using the ECN Nonce to check for receiver misbehavior.  A DCCP
   stack MAY therefore leave the ECN Incapable feature unimplemented,
   acting as if all connections were ECN capable.  Note that the
   inappropriate firewall interactions that dogged TCP's implementation
   of ECN [RFC3360] involve TCP header bits, not the IP header's ECN
   bits; we know of no middlebox that would block ECN-capable DCCP
   packets but allow ECN-incapable DCCP packets.
   ECN Incapable has feature number 4 and is server-priority.  It takes
   one-byte Boolean values.  DCCP A MUST be able to read ECN bits from
   received frames' IP headers when ECN Incapable/A is zero.  (This is
   independent of whether it can set ECN bits on sent frames.)  DCCP A
   thus sends a "Change L(ECN Inapable, 1)" option to DCCP B to inform
   it that A cannot read ECN bits.  If the ECN Incapable/A feature is
   one, then all of DCCP B's packets MUST be sent as ECN incapable.  New
   connections start with ECN Incapable 0 (that is, ECN capable) for
   both endpoints.  Values of two or more are reserved.
   If a DCCP is not ECN capable, it MUST send Mandatory "Change L(ECN
   Incapable, 1)" options to the other endpoint until acknowledged (by
   "Confirm R(ECN Incapable, 1)") or the connection closes.
   Furthermore, it MUST NOT accept any data until the other endpoint
   sends "Confirm R(ECN Incapable, 1)".  It SHOULD send Data Dropped
   options on its acknowledgements, with Drop Code 0 ("protocol
   constraints"), if the other endpoint does send data inappropriately.
12.2.  ECN Nonces
   Congestion avoidance will not occur, and the receiver will sometimes
   get its data faster, if the sender isn't told about congestion
   events.  Thus, the receiver has some incentive to falsify
   acknowledgement information, reporting that marked or dropped packets
   were actually received unmarked.  This problem is more serious with
   DCCP than with TCP, since TCP provides reliable transport: it is more
   difficult with TCP to lie about lost packets without breaking the
   application.
   ECN Nonces are a general mechanism to prevent ECN cheating (or loss
   cheating).  Two values for the two-bit ECN header field indicate
   ECN-Capable Transport, 01 and 10.  The second code point, 10, is the
   ECN Nonce.  In general, a protocol sender chooses between these code
   points randomly on its output packets, remembering the sequence it
   chose.  On every acknowledgement, the protocol receiver reports the
   number of ECN Nonces it has received thus far.  This is called the
   ECN Nonce Echo.  Since ECN marking and packet dropping both destroy
   the ECN Nonce, a receiver that lies about an ECN mark or packet drop
   has a 50% chance of guessing right and avoiding discipline.  The
   sender may react punitively to an ECN Nonce mismatch, possibly up to
   dropping the connection.  The ECN Nonce Echo field need not be an
   integer; one bit is enough to catch 50% of infractions, and the
   probability of success drops exponentially as more packets are sent
   [RFC3540].
   In DCCP, the ECN Nonce Echo field is encoded in acknowledgement
   options.  For example, the Ack Vector option comes in two forms, Ack
   Vector [Nonce 0] (option 38) and Ack Vector [Nonce 1] (option 39),
   corresponding to the two values for a one-bit ECN Nonce Echo.  The
   Nonce Echo for a given Ack Vector equals the one-bit sum (exclusive-
   or, or parity) of ECN nonces for packets reported by that Ack Vector
   as received and not ECN marked.  Thus, only packets marked as State 0
   matter for this calculation (that is, valid received packets that
   were not ECN marked).  Every Ack Vector option is detailed enough for
   the sender to determine what the Nonce Echo should have been.  It can
   check this calculation against the actual Nonce Echo and complain if
   there is a mismatch.  (The Ack Vector could conceivably report every
   packet's ECN Nonce state, but this would severely limit its
   compressibility without providing much extra protection.)
   Each DCCP sender SHOULD set ECN Nonces on its packets and remember
   which packets had nonces.  When a sender detects an ECN Nonce Echo
   mismatch, it behaves as described in the next section.  Each DCCP
   receiver MUST calculate and use the correct value for ECN Nonce Echo
   when sending acknowledgement options.
   ECN incapability, as indicated by the ECN Incapable feature, is
   handled as follows: an endpoint sending packets to an ECN-incapable
   receiver MUST send its packets as ECN incapable, and an ECN-
   incapable receiver MUST use the value zero for all ECN Nonce Echoes.
12.3.  Aggression Penalties
   DCCP endpoints have several mechanisms for detecting congestion-
   related misbehavior.  For example:
   o  A sender can detect an ECN Nonce Echo mismatch, indicating
      possible receiver misbehavior.
   o  A receiver can detect whether the sender is responding to
      congestion feedback or Slow Receiver.
   o  An endpoint may be able to detect that its peer is reporting
      inappropriately small Elapsed Time values (Section 13.2).
   An endpoint that detects possible congestion-related misbehavior
   SHOULD try to verify that its peer is truly misbehaving.  For
   example, a sending endpoint might send a packet whose ECN header
   field is set to Congestion Experienced, 11; a receiver that doesn't
   report a corresponding mark is most likely misbehaving.
   Upon detecting possible misbehavior, a sender SHOULD respond as if
   the receiver had reported one or more recent packets as ECN-marked
   (instead of unmarked), while a receiver SHOULD report one or more
   recent non-marked packets as ECN-marked.  Alternately, a sender might
   act as if the receiver had sent a Slow Receiver option, and a
   receiver might send Slow Receiver options.  Other reactions that
   serve to slow the transfer rate are also acceptable.  An entity that
   detects particularly egregious and ongoing misbehavior MAY also reset
   the connection with Reset Code 11, "Aggression Penalty".
   However, ECN Nonce mismatches and other warning signs can result from
   innocent causes, such as implementation bugs or attack.  In
   particular, a successful DCCP-Data attack (Section 7.5.5) can cause
   the receiver to report an incorrect ECN Nonce Echo.  Therefore,
   connection reset and other heavyweight mechanisms SHOULD be used only
   as last resorts, after multiple round-trip times of verified
   aggression.