Section 4. Overview

DCCP's high-level connection dynamics echo those of TCP.  Connections
   progress through three phases: initiation, including a three-way
   handshake; data transfer; and termination.  Data can flow both ways
   over the connection.  An acknowledgement framework lets senders
   discover how much data has been lost and thus avoid unfairly
   congesting the network.  Of course, DCCP provides unreliable datagram
   semantics, not TCP's reliable bytestream semantics.  The application
   must package its data into explicit frames and must retransmit its
   own data as necessary.  It may be useful to think of DCCP as TCP
   minus bytestream semantics and reliability, or as UDP plus congestion
   control, handshakes, and acknowledgements.
4.1.  Packet Types
   Ten packet types implement DCCP's protocol functions.  For example,
   every new connection attempt begins with a DCCP-Request packet sent
   by the client.  In this way a DCCP-Request packet resembles a TCP
   SYN, but since DCCP-Request is a packet type there is no way to send
   an unexpected flag combination, such as TCP's SYN+FIN+ACK+RST.
   Eight packet types occur during the progress of a typical connection,
   shown here.  Note the three-way handshakes during initiation and
   termination.
      Client                                      Server
      ------                                      ------
                       (1) Initiation
      DCCP-Request -->
                                       <-- DCCP-Response
      DCCP-Ack -->
                       (2) Data transfer
      DCCP-Data, DCCP-Ack, DCCP-DataAck -->
                   <-- DCCP-Data, DCCP-Ack, DCCP-DataAck
                       (3) Termination
                                       <-- DCCP-CloseReq
      DCCP-Close -->
                                          <-- DCCP-Reset
   The two remaining packet types are used to resynchronize after bursts
   of loss.
   Every DCCP packet starts with a fixed-size generic header.
   Particular packet types include additional fixed-size header data;
   for example, DCCP-Acks include an Acknowledgement Number.  DCCP
   options and any application data follow the fixed-size header.
   The packet types are as follows:
   DCCP-Request
      Sent by the client to initiate a connection (the first part of the
      three-way initiation handshake).
   DCCP-Response
      Sent by the server in response to a DCCP-Request (the second part
      of the three-way initiation handshake).
   DCCP-Data
      Used to transmit application data.
   DCCP-Ack
      Used to transmit pure acknowledgements.
   DCCP-DataAck
      Used to transmit application data with piggybacked acknowledgement
      information.
   DCCP-CloseReq
      Sent by the server to request that the client close the
      connection.
   DCCP-Close
      Used by the client or the server to close the connection; elicits
      a DCCP-Reset in response.
   DCCP-Reset
      Used to terminate the connection, either normally or abnormally.
   DCCP-Sync, DCCP-SyncAck
      Used to resynchronize sequence numbers after large bursts of loss.
4.2.  Packet Sequencing
   Each DCCP packet carries a sequence number so that losses can be
   detected and reported.  Unlike TCP sequence numbers, which are byte-
   based, DCCP sequence numbers increment by one per packet.  For
   example:
      DCCP A                                      DCCP B
      ------                                      ------
      DCCP-Data(seqno 1) -->
      DCCP-Data(seqno 2) -->
                         <-- DCCP-Ack(seqno 10, ackno 2)
      DCCP-DataAck(seqno 3, ackno 10) -->
                                 <-- DCCP-Data(seqno 11)
   Every DCCP packet increments the sequence number, whether or not it
   contains application data.  DCCP-Ack pure acknowledgements increment
   the sequence number; for instance, DCCP B's second packet above uses
   sequence number 11, since sequence number 10 was used for an
   acknowledgement.  This lets endpoints detect all packet loss,
   including acknowledgement loss.  It also means that endpoints can get
   out of sync after long bursts of loss.  The DCCP-Sync and DCCP-
   SyncAck packet types are used to recover (Section 7.5).
   Since DCCP provides unreliable semantics, there are no
   retransmissions, and having a TCP-style cumulative acknowledgement
   field doesn't make sense.  DCCP's Acknowledgement Number field equals
   the greatest sequence number received, rather than the smallest
   sequence number not received.  Separate options indicate any
   intermediate sequence numbers that weren't received.
4.3.  States
   DCCP endpoints progress through different states during the course of
   a connection, corresponding roughly to the three phases of
   initiation, data transfer, and termination.  The figure below shows
   the typical progress through these states for a client and server.
      Client                                             Server
      ------                                             ------
                        (0) No connection
      CLOSED                                             LISTEN
                        (1) Initiation
      REQUEST      DCCP-Request -->
                                   <-- DCCP-Response     RESPOND
      PARTOPEN     DCCP-Ack or DCCP-DataAck -->
                        (2) Data transfer
      OPEN          <-- DCCP-Data, Ack, DataAck -->      OPEN
                        (3) Termination
                                   <-- DCCP-CloseReq     CLOSEREQ
      CLOSING      DCCP-Close -->
                                      <-- DCCP-Reset     CLOSED
      TIMEWAIT
      CLOSED
   The nine possible states are as follows.  They are listed in
   increasing order, so that "state >= CLOSEREQ" means the same as
   "state = CLOSEREQ or state = CLOSING or state = TIMEWAIT".  Section 8
   describes the states in more detail.
   CLOSED
      Represents nonexistent connections.
   LISTEN
      Represents server sockets in the passive listening state.  LISTEN
      and CLOSED are not associated with any particular DCCP connection.
   REQUEST
      A client socket enters this state, from CLOSED, after sending a
      DCCP-Request packet to try to initiate a connection.
   RESPOND
      A server socket enters this state, from LISTEN, after receiving a
      DCCP-Request from a client.
   PARTOPEN
      A client socket enters this state, from REQUEST, after receiving a
      DCCP-Response from the server.  This state represents the third
      phase of the three-way handshake.  The client may send application
      data in this state, but it MUST include an Acknowledgement Number
      on all of its packets.
   OPEN
      The central data transfer portion of a DCCP connection.  Client
      and server sockets enter this state from PARTOPEN and RESPOND,
      respectively.  Sometimes we speak of SERVER-OPEN and CLIENT-OPEN
      states, corresponding to the server's OPEN state and the client's
      OPEN state.
   CLOSEREQ
      A server socket enters this state, from SERVER-OPEN, to order the
      client to close the connection and to hold TIMEWAIT state.
   CLOSING
      Server and client sockets can both enter this state to close the
      connection.
   TIMEWAIT
      A server or client socket remains in this state for 2MSL (4
      minutes) after the connection has been torn down, to prevent
      mistakes due to the delivery of old packets.  Only one of the
      endpoints has to enter TIMEWAIT state (the other can enter CLOSED
      state immediately), and a server can request its client to hold
      TIMEWAIT state using the DCCP-CloseReq packet type.
4.4.  Congestion Control Mechanisms
   DCCP connections are congestion controlled, but unlike in TCP, DCCP
   applications have a choice of congestion control mechanism.  In fact,
   the two half-connections can be governed by different mechanisms.
   Mechanisms are denoted by one-byte congestion control identifiers, or
   CCIDs.  The endpoints negotiate their CCIDs during connection
   initiation.  Each CCID describes how the HC-Sender limits data packet
   rates, how the HC-Receiver sends congestion feedback via
   acknowledgements, and so forth.  CCIDs 2 and 3 are currently defined;
   CCIDs 0, 1, and 4-255 are reserved.  Other CCIDs may be defined in
   the future.
   CCID 2 provides TCP-like Congestion Control, which is similar to that
   of TCP.  The sender maintains a congestion window and sends packets
   until that window is full.  Packets are acknowledged by the receiver.
   Dropped packets and ECN [RFC3168] indicate congestion; the response
   to congestion is to halve the congestion window.  Acknowledgements in
   CCID 2 contain the sequence numbers of all received packets within
   some window, similar to a selective acknowledgement (SACK) [RFC2018].
   CCID 3 provides TCP-Friendly Rate Control (TFRC), an equation-based
   form of congestion control intended to respond to congestion more
   smoothly than CCID 2.  The sender maintains a transmit rate, which it
   updates using the receiver's estimate of the packet loss and mark
   rate.  CCID 3 behaves somewhat differently than TCP in the short
   term, but is designed to operate fairly with TCP over the long term.
   Section 10 describes DCCP's CCIDs in more detail.  The behaviors of
   CCIDs 2 and 3 are fully defined in separate profile documents
   [RFC4341, RFC4342].
4.5.  Feature Negotiation Options
   DCCP endpoints use Change and Confirm options to negotiate and agree
   on feature values.  Feature negotiation will almost always happen on
   the connection initiation handshake, but it can begin at any time.
   There are four feature negotiation options in all: Change L, Confirm
   L, Change R, and Confirm R.  The "L" options are sent by the feature
   location and the "R" options are sent by the feature remote.  A
   Change R option says to the feature location, "change this feature
   value as follows".  The feature location responds with Confirm L,
   meaning, "I've changed it".  Some features allow Change R options to
   contain multiple values sorted in preference order.  For example:
      Client                                        Server
      ------                                        ------
      Change R(CCID, 2) -->
                                    <-- Confirm L(CCID, 2)
                 * agreement that CCID/Server = 2 *
      Change R(CCID, 3 4) -->
                               <-- Confirm L(CCID, 4, 4 2)
                 * agreement that CCID/Server = 4 *
   Both exchanges negotiate the CCID/Server feature's value, which is
   the CCID in use on the server-to-client half-connection.  In the
   second exchange, the client requests that the server use either CCID
   3 or CCID 4, with 3 preferred; the server chooses 4 and supplies its
   preference list, "4 2".
   The Change L and Confirm R options are used for feature negotiations
   initiated by the feature location.  In the following example, the
   server requests that CCID/Server be set to 3 or 2, with 3 preferred,
   and the client agrees.
      Client                                       Server
      ------                                       ------
                                  <-- Change L(CCID, 3 2)
      Confirm R(CCID, 3, 3 2)  -->
                 * agreement that CCID/Server = 3 *
   Section 6 describes the feature negotiation options further,
   including the retransmission strategies that make negotiation
   reliable.
4.6.  Differences from TCP
   DCCP's differences from TCP apart from those discussed so far include
   the following:
   o  Copious space for options (up to 1008 bytes or the PMTU).
   o  Different acknowledgement formats.  The CCID for a connection
      determines how much acknowledgement information needs to be
      transmitted.  For example, in CCID 2 (TCP-like), this is about one
      ack per 2 packets, and each ack must declare exactly which packets
      were received.  In CCID 3 (TFRC), it is about one ack per round-
      trip time, and acks must declare at minimum just the lengths of
      recent loss intervals.
   o  Denial of Service (DoS) protection.  Several mechanisms help limit
      the amount of state that possibly-misbehaving clients can force
      DCCP servers to maintain.  An Init Cookie option analogous to
      TCP's SYN Cookies [SYNCOOKIES] avoids SYN-flood-like attacks.
      Only one connection endpoint has to hold TIMEWAIT state; the
      DCCP-CloseReq packet, which may only be sent by the server, passes
      that state to the client.  Various rate limits let servers avoid
      attacks that might force extensive computation or packet
      generation.
   o  Distinguishing different kinds of loss.  A Data Dropped option
      (Section 11.7) lets an endpoint declare that a packet was dropped
      because of corruption, because of receive buffer overflow, and so
      on.  This facilitates research into more appropriate rate-control
      responses for these non-network-congestion losses (although
      currently such losses will cause a congestion response).
   o  Acknowledgeability.  In TCP, a packet may be acknowledged only
      once the data is reliably queued for application delivery.  This
      does not make sense in DCCP, where an application might, for
      example, request a drop-from-front receive buffer.  A DCCP packet
      may be acknowledged as soon as its header has been successfully
      processed.  Concretely, a packet becomes acknowledgeable at Step 8
      of Section 8.5's packet processing pseudocode.  Acknowledgeability
      does not guarantee data delivery, however: the Data Dropped option
      may later report that the packet's application data was discarded.
   o  No receive window.  DCCP is a congestion control protocol, not a
      flow control protocol.
   o  No simultaneous open.  Every connection has one client and one
      server.
   o  No half-closed states.  DCCP has no states corresponding to TCP's
      FINWAIT and CLOSEWAIT, where one half-connection is explicitly
      closed while the other is still active.  The Data Dropped option's
      Drop Code 1, Application Not Listening (Section 11.7), can achieve
      a similar effect, however.
4.7.  Example Connection
   The progress of a typical DCCP connection is as follows.  (This
   description is informative, not normative.)
          Client                                  Server
          ------                                  ------
      0.  [CLOSED]                              [LISTEN]
      1.  DCCP-Request -->
      2.                               <-- DCCP-Response
      3.  DCCP-Ack -->
      4.  DCCP-Data, DCCP-Ack, DCCP-DataAck -->
                   <-- DCCP-Data, DCCP-Ack, DCCP-DataAck
      5.                               <-- DCCP-CloseReq
      6.  DCCP-Close -->
      7.                                  <-- DCCP-Reset
      8.  [TIMEWAIT]
   1. The client sends the server a DCCP-Request packet specifying the
      client and server ports, the service being requested, and any
      features being negotiated, including the CCID that the client
      would like the server to use.  The client may optionally piggyback
      an application request on the DCCP-Request packet.  The server may
      ignore this application request.
   2. The server sends the client a DCCP-Response packet indicating that
      it is willing to communicate with the client.  This response
      indicates any features and options that the server agrees to,
      begins other feature negotiations as desired, and optionally
      includes Init Cookies that wrap up all this information and that
      must be returned by the client for the connection to complete.
   3. The client sends the server a DCCP-Ack packet that acknowledges
      the DCCP-Response packet.  This acknowledges the server's initial
      sequence number and returns any Init Cookies in the DCCP-Response.
      It may also continue feature negotiation.  The client may
      piggyback an application-level request on this ack, producing a
      DCCP-DataAck packet.
   4. The server and client then exchange DCCP-Data packets, DCCP-Ack
      packets acknowledging that data, and, optionally, DCCP-DataAck
      packets containing data with piggybacked acknowledgements.  If the
      client has no data to send, then the server will send DCCP-Data
      and DCCP-DataAck packets, while the client will send DCCP-Acks
      exclusively.  (However, the client may not send DCCP-Data packets
      before receiving at least one non-DCCP-Response packet from the
      server.)
   5. The server sends a DCCP-CloseReq packet requesting a close.
   6. The client sends a DCCP-Close packet acknowledging the close.
   7. The server sends a DCCP-Reset packet with Reset Code 1, "Closed",
      and clears its connection state.  DCCP-Resets are part of normal
      connection termination; see Section 5.6.
   8. The client receives the DCCP-Reset packet and holds state for two
      maximum segment lifetimes, or 2MSL, to allow any remaining packets
      to clear the network.
   An alternative connection closedown sequence is initiated by the
   client:
   5b. The client sends a DCCP-Close packet closing the connection.
   6b. The server sends a DCCP-Reset packet with Reset Code 1, "Closed",
       and clears its connection state.
   7b. The client receives the DCCP-Reset packet and holds state for
       2MSL to allow any remaining packets to clear the network.