Section 3. Conventions and Terminology

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 [RFC2119].
3.1.  Numbers and Fields
   All multi-byte numerical quantities in DCCP, such as port numbers,
   Sequence Numbers, and arguments to options, are transmitted in
   network byte order (most significant byte first).
   We occasionally refer to the "left" and "right" sides of a bit field.
   "Left" means towards the most significant bit, and "right" means
   towards the least significant bit.
   Random numbers in DCCP are used for their security properties and
   SHOULD be chosen according to the guidelines in [RFC4086].
   All operations on DCCP sequence numbers use circular arithmetic
   modulo 2^48, as do comparisons such as "greater" and "greatest".
   This form of arithmetic preserves the relationships between sequence
   numbers as they roll over from 2^48 - 1 to 0.  Implementation
   strategies for DCCP sequence numbers will resemble those for other
   circular arithmetic spaces, including TCP's sequence numbers [RFC793]
   and DNS's serial numbers [RFC1982].  It may make sense to store DCCP
   sequence numbers in the most significant 48 bits of 64-bit integers
   and set the least significant 16 bits to zero, since this supports a
   common technique that implements circular comparison A < B by testing
   whether (A - B) < 0 using conventional two's-complement arithmetic.
   Reserved bitfields in DCCP packet headers MUST be set to zero by
   senders and MUST be ignored by receivers, unless otherwise specified.
   This allows for future protocol extensions.  In particular, DCCP
   processors MUST NOT reset a DCCP connection simply because a Reserved
   field has non-zero value [RFC3360].
3.2.  Parts of a Connection
   Each DCCP connection runs between two hosts, which we often name DCCP
   A and DCCP B.  Each connection is actively initiated by one of the
   hosts, which we call the client; the other, initially passive host is
   called the server.  The term "DCCP endpoint" is used to refer to
   either of the two hosts explicitly named by the connection (the
   client and the server).  The term "DCCP processor" refers more
   generally to any host that might need to process a DCCP header; this
   includes the endpoints and any middleboxes on the path, such as
   firewalls and network address translators.
   DCCP connections are bidirectional: data may pass from either
   endpoint to the other.  This means that data and acknowledgements may
   flow in both directions simultaneously.  Logically, however, a DCCP
   connection consists of two separate unidirectional connections,
   called half-connections.  Each half-connection consists of the
   application data sent by one endpoint and the corresponding
   acknowledgements sent by the other endpoint.  We can illustrate this
   as follows:
      +--------+  A-to-B half-connection:         +--------+
      |        |    -->  application data  -->    |        |
      |        |    <--  acknowledgements  <--    |        |
      | DCCP A |                                  | DCCP B |
      |        |  B-to-A half-connection:         |        |
      |        |    <--  application data  <--    |        |
      +--------+    -->  acknowledgements  -->    +--------+
   Although they are logically distinct, in practice the half-
   connections overlap; a DCCP-DataAck packet, for example, contains
   application data relevant to one half-connection and acknowledgement
   information relevant to the other.
   In the context of a single half-connection, the terms "HC-Sender" and
   "HC-Receiver" denote the endpoints sending application data and
   acknowledgements, respectively.  For example, DCCP A is the
   HC-Sender and DCCP B is the HC-Receiver in the A-to-B
   half-connection.
3.3.  Features
   A DCCP feature is a connection attribute on whose value the two
   endpoints agree.  Many properties of a DCCP connection are controlled
   by features, including the congestion control mechanisms in use on
   the two half-connections.  The endpoints achieve agreement through
   the exchange of feature negotiation options in DCCP headers.
   DCCP features are identified by a feature number and an endpoint.
   The notation "F/X" represents the feature with feature number F
   located at DCCP endpoint X.  Each valid feature number thus
   corresponds to two features, which are negotiated separately and need
   not have the same value.  The two endpoints know, and agree on, the
   value of every valid feature.  DCCP A is the "feature location" for
   all features F/A, and the "feature remote" for all features F/B.
3.4.  Round-Trip Times
   DCCP round-trip time measurements are performed by congestion control
   mechanisms; different mechanisms may measure round-trip time in
   different ways, or not measure it at all.  However, the main DCCP
   protocol does use round-trip times occasionally, such as in the
   initial values for certain timers.  Each DCCP implementation thus
   defines a default round-trip time for use when no estimate is
   available.  This parameter should default to not less than 0.2
   seconds, a reasonably conservative round-trip time for Internet TCP
   connections.  Protocol behavior specified in terms of "round-trip
   time" values actually refers to "a current round-trip time estimate
   taken by some CCID, or, if no estimate is available, the default
   round-trip time parameter".
   The maximum segment lifetime, or MSL, is the maximum length of time a
   packet can survive in the network.  The DCCP MSL should equal that of
   TCP, which is normally two minutes.
3.5.  Security Limitation
   DCCP provides no protection against attackers who can snoop on a
   connection in progress, or who can guess valid sequence numbers in
   other ways.  Applications desiring stronger security should use IPsec
   [RFC2401]; depending on the level of security required, application-
   level cryptography may also suffice.  These issues are discussed
   further in Sections 7.5.5 and 18.
3.6.  Robustness Principle
   DCCP implementations will follow TCP's "general principle of
   robustness": "be conservative in what you do, be liberal in what you
   accept from others" [RFC793].