Section 10. Congestion Control

Each congestion control mechanism supported by DCCP is assigned a
   congestion control identifier, or CCID: a number from 0 to 255.
   During connection setup, and optionally thereafter, the endpoints
   negotiate their congestion control mechanisms by negotiating the
   values for their Congestion Control ID features.  Congestion Control
   ID has feature number 1.  The CCID/A value equals the CCID in use for
   the A-to-B half-connection.  DCCP B sends a "Change R(CCID, K)"
   option to ask DCCP A to use CCID K for its data packets.
   CCID is a server-priority feature, so CCID negotiation options can
   list multiple acceptable CCIDs, sorted in descending order of
   priority.  For example, the option "Change R(CCID, 2 3 4)" asks the
   receiver to use CCID 2 for its packets, although CCIDs 3 and 4 are
   also acceptable.  (This corresponds to the bytes "35, 6, 1, 2, 3, 4":
   Change R option (35), option length (6), feature ID (1), CCIDs (2, 3,
   4).)  Similarly, "Confirm L(CCID, 2, 2 3 4)" tells the receiver that
   the sender is using CCID 2 for its packets, but that CCIDs 3 and 4
   might also be acceptable.
   Currently allocated CCIDs are as follows:
           CCID   Meaning                      Reference
           ----   -------                      ---------
            0-1   Reserved
             2    TCP-like Congestion Control  [RFC4341]
             3    TCP-Friendly Rate Control    [RFC4342]
           4-255  Reserved
           Table 5: DCCP Congestion Control Identifiers
   New connections start with CCID 2 for both endpoints.  If this is
   unacceptable for a DCCP endpoint, that endpoint MUST send Mandatory
   Change(CCID) options on its first packets.
   All CCIDs standardized for use with DCCP will correspond to
   congestion control mechanisms previously standardized by the IETF.
   We expect that for quite some time, all such mechanisms will be TCP
   friendly, but TCP-friendliness is not an explicit DCCP requirement.
   A DCCP implementation intended for general use, such as an
   implementation in a general-purpose operating system kernel, SHOULD
   implement at least CCID 2.  The intent is to make CCID 2 broadly
   available for interoperability, although particular applications
   might disallow its use.
10.1.  TCP-like Congestion Control
   CCID 2, TCP-like Congestion Control, denotes Additive Increase,
   Multiplicative Decrease (AIMD) congestion control with behavior
   modelled directly on TCP, including congestion window, slow start,
   timeouts, and so forth [RFC2581].  CCID 2 achieves maximum bandwidth
   over the long term, consistent with the use of end-to-end congestion
   control, but halves its congestion window in response to each
   congestion event.  This leads to the abrupt rate changes typical of
   TCP.  Applications should use CCID 2 if they prefer maximum bandwidth
   utilization to steadiness of rate.  This is often the case for
   applications that are not playing their data directly to the user.
   For example, a hypothetical application that transferred files over
   DCCP, using application-level retransmissions for lost packets, would
   prefer CCID 2 to CCID 3.  On-line games may also prefer CCID 2.
   CCID 2 is further described in [RFC4341].
10.2.  TFRC Congestion Control
   CCID 3 denotes TCP-Friendly Rate Control (TFRC), an equation-based
   rate-controlled congestion control mechanism.  TFRC is designed to be
   reasonably fair when competing for bandwidth with TCP-like flows,
   where a flow is "reasonably fair" if its sending rate is generally
   within a factor of two of the sending rate of a TCP flow under the
   same conditions.  However, TFRC has a much lower variation of
   throughput over time compared with TCP, which makes CCID 3 more
   suitable than CCID 2 for applications such as streaming media where a
   relatively smooth sending rate is important.
   CCID 3 is further described in [RFC4342].  The TFRC congestion
   control algorithms were initially described in [RFC3448].
10.3.  CCID-Specific Options, Features, and Reset Codes
   Half of the option types, feature numbers, and Reset Codes are
   reserved for CCID-specific use.  CCIDs may often need new options,
   for communicating acknowledgement or rate information, for example;
   reserved option spaces let CCIDs create options at will without
   polluting the global option space.  Option 128 might have different
   meanings on a half-connection using CCID 4 and a half-connection
   using CCID 8.  CCID-specific options and features will never conflict
   with global options and features introduced by later versions of this
   specification.
   Any packet may contain information meant for either half-connection,
   so CCID-specific option types, feature numbers, and Reset Codes
   explicitly signal the half-connection to which they apply.
   o  Option numbers 128 through 191 are for options sent from the
      HC-Sender to the HC-Receiver; option numbers 192 through 255 are
      for options sent from the HC-Receiver to the HC-Sender.
   o  Reset Codes 128 through 191 indicate that the HC-Sender reset the
      connection (most likely because of some problem with
      acknowledgements sent by the HC-Receiver).  Reset Codes 192
      through 255 indicate that the HC-Receiver reset the connection
      (most likely because of some problem with data packets sent by the
      HC-Sender).
   o  Finally, feature numbers 128 through 191 are used for features
      located at the HC-Sender; feature numbers 192 through 255 are for
      features located at the HC-Receiver.  Since Change L and Confirm L
      options for a feature are sent by the feature location, we know
      that any Change L(128) option was sent by the HC-Sender, while any
      Change L(192) option was sent by the HC-Receiver.  Similarly,
      Change R(128) options are sent by the HC-Receiver, while Change
      R(192) options are sent by the HC-Sender.
   For example, consider a DCCP connection where the A-to-B half-
   connection uses CCID 4 and the B-to-A half-connection uses CCID 5.
   Here is how a sampling of CCID-specific options are assigned to
   half-connections.
                                   Relevant    Relevant
        Packet  Option             Half-conn.  CCID
        ------  ------             ----------  ----
        A > B   128                  A-to-B     4
        A > B   192                  B-to-A     5
        A > B   Change L(128, ...)   A-to-B     4
        A > B   Change R(192, ...)   A-to-B     4
        A > B   Confirm L(128, ...)  A-to-B     4
        A > B   Confirm R(192, ...)  A-to-B     4
        A > B   Change R(128, ...)   B-to-A     5
        A > B   Change L(192, ...)   B-to-A     5
        A > B   Confirm R(128, ...)  B-to-A     5
        A > B   Confirm L(192, ...)  B-to-A     5
        B > A   128                  B-to-A     5
        B > A   192                  A-to-B     4
        B > A   Change L(128, ...)   B-to-A     5
        B > A   Change R(192, ...)   B-to-A     5
        B > A   Confirm L(128, ...)  B-to-A     5
        B > A   Confirm R(192, ...)  B-to-A     5
        B > A   Change R(128, ...)   A-to-B     4
        B > A   Change L(192, ...)   A-to-B     4
        B > A   Confirm R(128, ...)  A-to-B     4
        B > A   Confirm L(192, ...)  A-to-B     4
   Using CCID-specific options and feature options during a negotiation
   for the corresponding CCID feature is NOT RECOMMENDED, since it is
   difficult to predict which CCID will be in force when the option is
   processed.  For example, if a DCCP-Request contains the option
   sequence "Change L(CCID, 3), 128", the CCID-specific option "128" may
   be processed either by CCID 3 (if the server supports CCID 3) or by
   the default CCID 2 (if it does not).  However, it is safe to include
   CCID-specific options following certain Mandatory Change(CCID)
   options.  For example, if a DCCP-Request contains the option sequence
   "Mandatory, Change L(CCID, 3), 128", then either the "128" option
   will be processed by CCID 3 or the connection will be reset.
   Servers that do not implement the default CCID 2 might nevertheless
   receive CCID 2-specific options on a DCCP-Request packet.  (Such a
   server MUST send Mandatory Change(CCID) options on its DCCP-Response,
   so CCID-specific options on any other packet won't refer to CCID 2.)
   The server MUST treat such options as non-understood.  Thus, it will
   reset the connection on encountering a Mandatory CCID-specific option
   or feature negotiation request, send an empty Confirm for a non-
   Mandatory Change option for a CCID-specific feature, and ignore other
   CCID-specific options.
10.4.  CCID Profile Requirements
   Each CCID Profile document MUST address at least the following
   requirements:
   o  The profile MUST include the name and number of the CCID being
      described.
   o  The profile MUST describe the conditions in which it is likely to
      be useful.  Often the best way to do this is by comparison to
      existing CCIDs.
   o  The profile MUST list and describe any CCID-specific options,
      features, and Reset Codes and SHOULD list those general options
      and features described in this document that are especially
      relevant to the CCID.
   o  Any newly defined acknowledgement mechanism MUST include a way to
      transmit ECN Nonce Echoes back to the sender.
   o  The profile MUST describe the format of data packets, including
      any options that should be included and the setting of the CCval
      header field.
   o  The profile MUST describe the format of acknowledgement packets,
      including any options that should be included.
   o  The profile MUST define how data packets are congestion
      controlled.  This includes responses to congestion events, to idle
      and application-limited periods, and to the DCCP Data Dropped and
      Slow Receiver options.  CCIDs that implement per-packet congestion
      control SHOULD discuss how packet size is factored in to
      congestion control decisions.
   o  The profile MUST specify when acknowledgement packets are
      generated and how they are congestion controlled.
   o  The profile MUST define when a sender using the CCID is considered
      quiescent.
   o  The profile MUST say whether its CCID's acknowledgements ever need
      to be acknowledged and, if so, how often.
10.5.  Congestion State
   Most congestion control algorithms depend on past history to
   determine the current allowed sending rate.  In CCID 2, this
   congestion state includes a congestion window and a measurement of
   the number of packets outstanding in the network; in CCID 3, it
   includes the lengths of recent loss intervals.  Both CCIDs use an
   estimate of the round-trip time.  Congestion state depends on the
   network path and is invalidated by path changes.  Therefore, DCCP
   senders and receivers SHOULD reset their congestion state --
   essentially restarting congestion control from "slow start" or
   equivalent -- on significant changes in the end-to-end path.  For
   example, an endpoint that sends or receives a Mobile IPv6 Binding
   Update message [RFC3775] SHOULD reset its congestion state for any
   corresponding DCCP connections.
   A DCCP implementation MAY also reset its congestion state when a CCID
   changes (that is, when a negotiation for the CCID feature completes
   successfully and the new feature value differs from the old value).
   Thus, a connection in a heavily congested environment might evade
   end-to-end congestion control by frequently renegotiating a CCID,
   just as it could evade end-to-end congestion control by opening new
   connections for the same session.  This behavior is prohibited.  To
   prevent it, DCCP implementations MAY limit the rate at which CCID can
   be changed -- for instance, by refusing to change a CCID feature
   value more than once per minute.