tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4340


Datagram Congestion Control Protocol (DCCP)

Part 4 of 5, p. 76 to 101
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 76 
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.

Top      Up      ToC       Page 77 
   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.

Top      Up      ToC       Page 78 
   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

   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

Top      Up      ToC       Page 79 
   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

                                   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)

Top      Up      ToC       Page 80 
   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

   o  The profile MUST include the name and number of the CCID being

   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.

Top      Up      ToC       Page 81 
   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

   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.

11.  Acknowledgements

   Congestion control requires that receivers transmit information about
   packet losses and ECN marks to senders.  DCCP receivers MUST report
   all congestion they see, as defined by the relevant CCID profile.
   Each CCID says when acknowledgements should be sent, what options
   they must use, and so on.  DCCP acknowledgements are congestion
   controlled, although it is not required that the acknowledgement
   stream be more than very roughly TCP friendly; each CCID defines how
   acknowledgements are congestion controlled.

Top      Up      ToC       Page 82 
   Most acknowledgements use DCCP options.  For example, on a half-
   connection with CCID 2 (TCP-like), the receiver reports
   acknowledgement information using the Ack Vector option.  This
   section describes common acknowledgement options and shows how acks
   using those options will commonly work.  Full descriptions of the ack
   mechanisms used for each CCID are laid out in the CCID profile

   Acknowledgement options, such as Ack Vector, depend on the DCCP
   Acknowledgement Number and are thus only allowed on packet types that
   carry that number.  Acknowledgement options received on other packet
   types, namely DCCP-Request and DCCP-Data, MUST be ignored.  Detailed
   acknowledgement options are not necessarily required on every packet
   that carries an Acknowledgement Number, however.

11.1.  Acks of Acks and Unidirectional Connections

   DCCP was designed to work well for both bidirectional and
   unidirectional flows of data, and for connections that transition
   between these states.  However, acknowledgements required for a
   unidirectional connection are very different from those required for
   a bidirectional connection.  In particular, unidirectional
   connections need to worry about acks of acks.

   The ack-of-acks problem arises because some acknowledgement
   mechanisms are reliable.  For example, an HC-Receiver using CCID 2,
   TCP-like Congestion Control, sends Ack Vectors containing completely
   reliable acknowledgement information.  The HC-Sender should
   occasionally inform the HC-Receiver that it has received an ack.  If
   it did not, the HC-Receiver might resend complete Ack Vector
   information, going back to the start of the connection, with every
   DCCP-Ack packet!  However, note that acks-of-acks need not be
   reliable themselves: when an ack-of-acks is lost, the HC-Receiver
   will simply maintain, and periodically retransmit, old
   acknowledgement-related state for a little longer.  Therefore, there
   is no need for acks-of-acks-of-acks.

   When communication is bidirectional, any required acks-of-acks are
   automatically contained in normal acknowledgements for data packets.
   On a unidirectional connection, however, the receiver DCCP sends no
   data, so the sender would not normally send acknowledgements.
   Therefore, the CCID in force on that half-connection must explicitly
   say whether, when, and how the HC-Sender should generate acks-of-

   For example, consider a bidirectional connection where both half-
   connections use the same CCID (either 2 or 3), and where DCCP B goes
   "quiescent".  This means that the connection becomes unidirectional:

Top      Up      ToC       Page 83 
   DCCP B stops sending data and sends only DCCP-Ack packets to DCCP A.
   In CCID 2, TCP-like Congestion Control, DCCP B uses Ack Vector to
   reliably communicate which packets it has received.  As described
   above, DCCP A must occasionally acknowledge a pure acknowledgement
   from DCCP B so that B can free old Ack Vector state.  For instance, A
   might send a DCCP-DataAck packet instead of DCCP-Data every now and
   then.  In CCID 3, however, acknowledgement state is generally
   bounded, so A does not need to acknowledge B's acknowledgements.

   When communication is unidirectional, a single CCID -- in the
   example, the A-to-B CCID -- controls both DCCPs' acknowledgements, in
   terms of their content, their frequency, and so forth.  For
   bidirectional connections, the A-to-B CCID governs DCCP B's
   acknowledgements (including its acks of DCCP A's acks) and the B-to-A
   CCID governs DCCP A's acknowledgements.

   DCCP A switches its ack pattern from bidirectional to unidirectional
   when it notices that DCCP B has gone quiescent.  It switches from
   unidirectional to bidirectional when it must acknowledge even a
   single DCCP-Data or DCCP-DataAck packet from DCCP B.

   Each CCID defines how to detect quiescence on that CCID, and how that
   CCID handles acks-of-acks on unidirectional connections.  The B-to-A
   CCID defines when DCCP B has gone quiescent.  Usually, this happens
   when a period has passed without B sending any data packets; in CCID
   2, for example, this period is the maximum of 0.2 seconds and two
   round-trip times.  The A-to-B CCID defines how DCCP A handles
   acks-of-acks once DCCP B has gone quiescent.

11.2.  Ack Piggybacking

   Acknowledgements of A-to-B data MAY be piggybacked on data sent by
   DCCP B, as long as that does not delay the acknowledgement longer
   than the A-to-B CCID would find acceptable.  However, data
   acknowledgements often require more than 4 bytes to express.  A large
   set of acknowledgements prepended to a large data packet might exceed
   the allowed maximum packet size.  In this case, DCCP B SHOULD send
   separate DCCP-Data and DCCP-Ack packets, or wait, but not too long,
   for a smaller datagram.

   Piggybacking is particularly common at DCCP A when the B-to-A
   half-connection is quiescent -- that is, when DCCP A is just
   acknowledging DCCP B's acknowledgements.  There are three reasons to
   acknowledge DCCP B's acknowledgements: to allow DCCP B to free up
   information about previously acknowledged data packets from A; to
   shrink the size of future acknowledgements; and to manipulate the
   rate at which future acknowledgements are sent.  Since these are

Top      Up      ToC       Page 84 
   secondary concerns, DCCP A can generally afford to wait indefinitely
   for a data packet to piggyback its acknowledgement onto; if DCCP B
   wants to elicit an acknowledgement, it can send a DCCP-Sync.

   Any restrictions on ack piggybacking are described in the relevant
   CCID's profile.

11.3.  Ack Ratio Feature

   The Ack Ratio feature lets HC-Senders influence the rate at which
   HC-Receivers generate DCCP-Ack packets, thus controlling reverse-path
   congestion.  This differs from TCP, which presently has no congestion
   control for pure acknowledgement traffic.  Ack Ratio reverse-path
   congestion control does not try to be TCP friendly.  It just tries to
   avoid congestion collapse, and to be somewhat better than TCP in the
   presence of a high packet loss or mark rate on the reverse path.

   Ack Ratio applies to CCIDs whose HC-Receivers clock acknowledgements
   off the receipt of data packets.  The value of Ack Ratio/A equals the
   rough ratio of data packets sent by DCCP A to DCCP-Ack packets sent
   by DCCP B.  Higher Ack Ratios correspond to lower DCCP-Ack rates; the
   sender raises Ack Ratio when the reverse path is congested and lowers
   Ack Ratio when it is not.  Each CCID profile defines how it controls
   congestion on the acknowledgement path, and, particularly, whether
   Ack Ratio is used.  CCID 2, for example, uses Ack Ratio for
   acknowledgement congestion control, but CCID 3 does not.  However,
   each Ack Ratio feature has a value whether or not that value is used
   by the relevant CCID.

   Ack Ratio has feature number 5 and is non-negotiable.  It takes two-
   byte integer values.  An Ack Ratio/A value of four means that DCCP B
   will send at least one acknowledgement packet for every four data
   packets sent by DCCP A.  DCCP A sends a "Change L(Ack Ratio)" option
   to notify DCCP B of its ack ratio.  An Ack Ratio value of zero
   indicates that the relevant half-connection does not use an Ack Ratio
   to control its acknowledgement rate.  New connections start with Ack
   Ratio 2 for both endpoints; this Ack Ratio results in acknowledgement
   behavior analogous to TCP's delayed acks.

   Ack Ratio should be treated as a guideline rather than a strict
   requirement.  We intend Ack Ratio-controlled acknowledgement behavior
   to resemble TCP's acknowledgement behavior when there is no reverse-
   path congestion, and to be somewhat more conservative when there is
   reverse-path congestion.  Following this intent is more important
   than implementing Ack Ratio precisely.  In particular:

Top      Up      ToC       Page 85 
   o  Receivers MAY piggyback acknowledgement information on data
      packets, creating DCCP-DataAck packets.  The Ack Ratio does not
      apply to piggybacked acknowledgements.  However, if the data
      packets are too big to carry acknowledgement information, or if
      the data sending rate is lower than Ack Ratio would suggest, then
      DCCP B SHOULD send enough pure DCCP-Ack packets to maintain the
      rate of one acknowledgement per Ack Ratio received data packets.

   o  Receivers MAY rate-pace their acknowledgements rather than send
      acknowledgements immediately upon the receipt of data packets.
      Receivers that rate-pace acknowledgements SHOULD pick a rate that
      approximates the effect of Ack Ratio and SHOULD include Elapsed
      Time options (Section 13.2) to help the sender calculate round-
      trip times.

   o  Receivers SHOULD implement delayed acknowledgement timers like
      TCP's, whereby any packet's acknowledgement is delayed by at most
      T seconds.  This delay lets the receiver collect additional
      packets to acknowledge and thus reduce the per-packet overhead of
      acknowledgements; but if T seconds have passed by and the ack is
      still around, it is sent out right away.  The default value of T
      should be 0.2 seconds, as is common in TCP implementations.  This
      may lead to sending more acknowledgement packets than Ack Ratio
      would suggest.

   o  Receivers SHOULD send acknowledgements immediately on receiving
      packets marked ECN Congestion Experienced or packets whose out-
      of-order sequence numbers potentially indicate loss.  However,
      there is no need to send such immediate acknowledgements for
      marked packets more than once per round-trip time.

   o  Receivers MAY ignore Ack Ratio if they perform their own
      congestion control on acknowledgements.  For example, a receiver
      that knows the loss and mark rate for its DCCP-Ack packets might
      maintain a TCP-friendly acknowledgement rate on its own.  Such a
      receiver MUST either ensure that it always obtains sufficient
      acknowledgement loss and mark information or fall back to Ack
      Ratio when sufficient information is not available, as might
      happen during periods when the receiver is quiescent.

11.4.  Ack Vector Options

   The Ack Vector gives a run-length encoded history of data packets
   received at the client.  Each byte of the vector gives the state of
   that data packet in the loss history, and the number of preceding
   packets with the same state.  The option's data looks like this:

Top      Up      ToC       Page 86 
   |0010011?| Length |SSLLLLLL|SSLLLLLL|SSLLLLLL|  ...
   Type=38/39         \___________ Vector ___________...

   The two Ack Vector options (option types 38 and 39) differ only in
   the values they imply for ECN Nonce Echo.  Section 12.2 describes
   this further.

   The vector itself consists of a series of bytes, each of whose
   encoding is:

    0 1 2 3 4 5 6 7
   |Sta| Run Length|

   Sta[te] occupies the most significant two bits of each byte and can
   have one of four values, as follows:

                    State  Meaning
                    -----  -------
                      0    Received
                      1    Received ECN Marked
                      2    Reserved
                      3    Not Yet Received

                  Table 6: DCCP Ack Vector States

   The term "ECN marked" refers to packets with ECN code point 11, CE
   (Congestion Experienced); packets received with this ECN code point
   MUST be reported using State 1, Received ECN Marked.  Packets
   received with ECN code points 00, 01, or 10 (Non-ECT, ECT(0), or
   ECT(1), respectively) MUST be reported using State 0, Received.

   Run Length, the least significant six bits of each byte, specifies
   how many consecutive packets have the given State.  Run Length zero
   says the corresponding State applies to one packet only; Run Length
   63 says it applies to 64 consecutive packets.  Run lengths of 65 or
   more must be encoded in multiple bytes.

   The first byte in the first Ack Vector option refers to the packet
   indicated in the Acknowledgement Number; subsequent bytes refer to
   older packets.  Ack Vector MUST NOT be sent on DCCP-Data and DCCP-
   Request packets, which lack an Acknowledgement Number, and any Ack
   Vector options encountered on such packets MUST be ignored.

Top      Up      ToC       Page 87 
   An Ack Vector containing the decimal values 0,192,3,64,5 and for
   which the Acknowledgement Number is decimal 100 indicates that:

      Packet 100 was received (Acknowledgement Number 100, State 0, Run
      Length 0);

      Packet 99 was lost (State 3, Run Length 0);

      Packets 98, 97, 96 and 95 were received (State 0, Run Length 3);

      Packet 94 was ECN marked (State 1, Run Length 0); and

      Packets 93, 92, 91, 90, 89, and 88 were received (State 0, Run
      Length 5).

   A single Ack Vector option can acknowledge up to 16192 data packets.
   Should more packets need to be acknowledged than can fit in 253 bytes
   of Ack Vector, then multiple Ack Vector options can be sent; the
   second Ack Vector begins where the first left off, and so forth.

   Ack Vector states are subject to two general constraints.  (These
   principles SHOULD also be followed for other acknowledgement
   mechanisms; referring to Ack Vector states simplifies their

   1. Packets reported as State 0 or State 1 MUST be acknowledgeable:
      their options have been processed by the receiving DCCP stack.
      Any data on the packet need not have been delivered to the
      receiving application; in fact, the data may have been dropped.

   2. Packets reported as State 3 MUST NOT be acknowledgeable.  Feature
      negotiations and options on such packets MUST NOT have been
      processed, and the Acknowledgement Number MUST NOT correspond to
      such a packet.

   Packets dropped in the application's receive buffer MUST be reported
   as Received or Received ECN Marked (States 0 and 1), depending on
   their ECN state; such packets' ECN Nonces MUST be included in the
   Nonce Echo.  The Data Dropped option informs the sender that some
   packets reported as received actually had their application data

   One or more Ack Vector options that, together, report the status of a
   packet with a sequence number less than ISN, the initial sequence
   number, SHOULD be considered invalid.  The receiving DCCP SHOULD
   either ignore the options or reset the connection with Reset Code 5,
   "Option Error".  No Ack Vector option can refer to a packet that has
   not yet been sent, as the Acknowledgement Number checks in Section

Top      Up      ToC       Page 88 
   7.5.3 ensure, but because of attack, implementation bug, or
   misbehavior, an Ack Vector option can claim that a packet was
   received before it is actually delivered.  Section 12.2 describes how
   this is detected and how senders should react.  Packets that haven't
   been included in any Ack Vector option SHOULD be treated as "not yet
   received" (State 3) by the sender.

   Appendix A provides a non-normative description of the details of
   DCCP acknowledgement handling in the context of an abstract Ack
   Vector implementation.

11.4.1.  Ack Vector Consistency

   A DCCP sender will commonly receive multiple acknowledgements for
   some of its data packets.  For instance, an HC-Sender might receive
   two DCCP-Acks with Ack Vectors, both of which contained information
   about sequence number 24.  (Information about a sequence number is
   generally repeated in every ack until the HC-Sender acknowledges an
   ack.  In this case, perhaps the HC-Receiver is sending acks faster
   than the HC-Sender is acknowledging them.)  In a perfect world, the
   two Ack Vectors would always be consistent.  However, there are many
   reasons why they might not be.  For example:

   o  The HC-Receiver received packet 24 between sending its acks, so
      the first ack said 24 was not received (State 3) and the second
      said it was received or ECN marked (State 0 or 1).

   o  The HC-Receiver received packet 24 between sending its acks, and
      the network reordered the acks.  In this case, the packet will
      appear to transition from State 0 or 1 to State 3.

   o  The network duplicated packet 24, and one of the duplicates was
      ECN marked.  This might show up as a transition between States 0
      and 1.

   To cope with these situations, HC-Sender DCCP implementations SHOULD
   combine multiple received Ack Vector states according to this table:

                               Received State
                                 0   1   3
                             0 | 0 |0/1| 0 |
                       Old     +---+---+---+
                             1 | 1 | 1 | 1 |
                      State    +---+---+---+
                             3 | 0 | 1 | 3 |

Top      Up      ToC       Page 89 
   To read the table, choose the row corresponding to the packet's old
   state and the column corresponding to the packet's state in the newly
   received Ack Vector; then read the packet's new state off the table.
   For an old state of 0 (received non-marked) and received state of 1
   (received ECN marked), the packet's new state may be set to either 0
   or 1.  The HC-Sender implementation will be indifferent to ack
   reordering if it chooses new state 1 for that cell.

   The HC-Receiver should collect information about received packets
   according to the following table:

                              Received Packet
                                 0   1   3
                             0 | 0 |0/1| 0 |
                     Stored    +---+---+---+
                             1 |0/1| 1 | 1 |
                      State    +---+---+---+
                             3 | 0 | 1 | 3 |

   This table equals the sender's table except that, when the stored
   state is 1 and the received state is 0, the receiver is allowed to
   switch its stored state to 0.

   An HC-Sender MAY choose to throw away old information gleaned from
   the HC-Receiver's Ack Vectors, in which case it MUST ignore newly
   received acknowledgements from the HC-Receiver for those old packets.
   It is often kinder to save recent Ack Vector information for a while
   so that the HC-Sender can undo its reaction to presumed congestion
   when a "lost" packet unexpectedly shows up (the transition from State
   3 to State 0).

11.4.2.  Ack Vector Coverage

   We can divide the packets that have been sent from an HC-Sender to an
   HC-Receiver into four roughly contiguous groups.  From oldest to
   youngest, these are:

   1. Packets already acknowledged by the HC-Receiver, where the
      HC-Receiver knows that the HC-Sender has definitely received the

   2. Packets already acknowledged by the HC-Receiver, where the
      HC-Receiver cannot be sure that the HC-Sender has received the

   3. Packets not yet acknowledged by the HC-Receiver; and

Top      Up      ToC       Page 90 
   4. Packets not yet received by the HC-Receiver.

   The union of groups 2 and 3 is called the Acknowledgement Window.
   Generally, every Ack Vector generated by the HC-Receiver will cover
   the whole Acknowledgement Window: Ack Vector acknowledgements are
   cumulative.  (This simplifies Ack Vector maintenance at the
   HC-Receiver; see Appendix A, below.)  As packets are received, this
   window both grows on the right and shrinks on the left.  It grows
   because there are more packets, and shrinks because the HC-Sender's
   Acknowledgement Numbers will acknowledge previous acknowledgements,
   moving packets from group 2 into group 1.

11.5.  Send Ack Vector Feature

   The Send Ack Vector feature lets DCCPs negotiate whether they should
   use Ack Vector options to report congestion.  Ack Vector provides
   detailed loss information and lets senders report back to their
   applications whether particular packets were dropped.  Send Ack
   Vector is mandatory for some CCIDs and optional for others.

   Send Ack Vector has feature number 6 and is server-priority.  It
   takes one-byte Boolean values.  DCCP A MUST send Ack Vector options
   on its acknowledgements when Send Ack Vector/A has value one,
   although it MAY send Ack Vector options even when Send Ack Vector/A
   is zero.  Values of two or more are reserved.  New connections start
   with Send Ack Vector 0 for both endpoints.  DCCP B sends a "Change
   R(Send Ack Vector, 1)" option to DCCP A to ask A to send Ack Vector
   options as part of its acknowledgement traffic.

11.6.  Slow Receiver Option

   An HC-Receiver sends the Slow Receiver option to its sender to
   indicate that it is having trouble keeping up with the sender's data.
   The HC-Sender SHOULD NOT increase its sending rate for approximately
   one round-trip time after seeing a packet with a Slow Receiver
   option.  After one round-trip time, the effect of Slow Receiver
   disappears, allowing the HC-Sender to increase its rate.  Therefore,
   the HC-Receiver SHOULD continue to send Slow Receiver options if it
   needs to prevent the HC-Sender from going faster in the long term.
   The Slow Receiver option does not indicate congestion, and the HC-
   Sender need not reduce its sending rate.  (If necessary, the receiver
   can force the sender to slow down by dropping packets, with or
   without Data Dropped, or by reporting false ECN marks.)  APIs should
   let receiver applications set Slow Receiver and sending applications
   determine whether their receivers are Slow.

Top      Up      ToC       Page 91 
   Slow Receiver is a one-byte option.


   Slow Receiver does not specify why the receiver is having trouble
   keeping up with the sender.  Possible reasons include lack of buffer
   space, CPU overload, and application quotas.  A sending application
   might react to Slow Receiver by reducing its application-level
   sending rate, for example.

   The sending application should not react to Slow Receiver by sending
   more data, however.  Although the optimal response to a CPU-bound
   receiver might be to reduce compression and send more data (a
   highly-compressed data format might overwhelm a slow CPU more
   seriously than would the higher memory requirements of a less-
   compressed data format), this kind of format change should be
   requested at the application level, not via the Slow Receiver option.

   Slow Receiver implements a portion of TCP's receive window

11.7.  Data Dropped Option

   The Data Dropped option indicates that the application data on one or
   more received packets did not actually reach the application.  Data
   Dropped additionally reports why the data was dropped: perhaps the
   data was corrupt, or perhaps the receiver cannot keep up with the
   sender's current rate and the data was dropped in some receive
   buffer.  Using Data Dropped, DCCP endpoints can discriminate between
   different kinds of loss; this differs from TCP, in which all loss is
   reported the same way.

   Unless it is explicitly specified otherwise, DCCP congestion control
   mechanisms MUST react as if each Data Dropped packet was marked as
   ECN Congestion Experienced by the network.  We intend for Data
   Dropped to enable research into richer congestion responses to
   corrupt and other endpoint-dropped packets, but DCCP CCIDs MUST react
   conservatively to Data Dropped until this behavior is standardized.
   Section 11.7.2, below, describes congestion responses for all current
   Drop Codes.

   If a received packet's application data is dropped for one of the
   reasons listed below, this SHOULD be reported using a Data Dropped
   option.  Alternatively, the receiver MAY choose to report as

Top      Up      ToC       Page 92 
   "received" only those packets whose data were not dropped, subject to
   the constraint that packets not reported as received MUST NOT have
   had their options processed.

   The option's data looks like this:

   |00101000| Length | Block  | Block  | Block  |  ...
    Type=40          \___________ Vector ___________ ...

   The Vector consists of a series of bytes, called Blocks, each of
   whose encoding corresponds to one of two choices:

    0 1 2 3 4 5 6 7                  0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+                +-+-+-+-+-+-+-+-+
   |0| Run Length  |       or       |1|DrpCd|Run Len|
   +-+-+-+-+-+-+-+-+                +-+-+-+-+-+-+-+-+
     Normal Block                      Drop Block

   The first byte in the first Data Dropped option refers to the packet
   indicated by the Acknowledgement Number; subsequent bytes refer to
   older packets.  Data Dropped MUST NOT be sent on DCCP-Data or DCCP-
   Request packets, which lack an Acknowledgement Number, and any Data
   Dropped options received on such packets MUST be ignored.

   Normal Blocks, which have high bit 0, indicate that any received
   packets in the Run Length had their data delivered to the
   application.  Drop Blocks, which have high bit 1, indicate that
   received packets in the Run Len[gth] were not delivered as usual.
   The 3-bit Drop Code [DrpCd] field says what happened; generally, no
   data from that packet reached the application.  Packets reported as
   "not yet received" MUST be included in Normal Blocks; packets not
   covered by any Data Dropped option are treated as if they were in a
   Normal Block.  Defined Drop Codes for Drop Blocks are as follows.

                  Drop Code  Meaning
                  ---------  -------
                      0      Protocol Constraints
                      1      Application Not Listening
                      2      Receive Buffer
                      3      Corrupt
                     4-6     Reserved
                      7      Delivered Corrupt

                   Table 7: DCCP Drop Codes

Top      Up      ToC       Page 93 
   In more detail:

      0   The packet data was dropped due to protocol constraints.  For
          example, the data was included on a DCCP-Request packet, but
          the receiving application does not allow such piggybacking; or
          the data was included on a packet with inappropriately low
          Checksum Coverage.

      1   The packet data was dropped because the application is no
          longer listening.  See Section 11.7.2.

      2   The packet data was dropped in a receive buffer, probably
          because of receive buffer overflow.  See Section 11.7.2.

      3   The packet data was dropped due to corruption.  See Section

      7   The packet data was corrupted but was delivered to the
          application anyway.  See Section 9.3.

   For example, assume that a packet arrives with Acknowledgement Number
   100, an Ack Vector reporting all packets as received, and a Data
   Dropped option containing the decimal values 0,160,3,162.  Then:

      Packet 100 was received (Acknowledgement Number 100, Normal Block,
      Run Length 0).

      Packet 99 was dropped in a receive buffer (Drop Block, Drop Code
      2, Run Length 0).

      Packets 98, 97, 96, and 95 were received (Normal Block, Run Length

      Packets 95, 94, and 93 were dropped in the receive buffer (Drop
      Block, Drop Code 2, Run Length 2).

   Run lengths of more than 128 (for Normal Blocks) or 16 (for Drop
   Blocks) must be encoded in multiple Blocks.  A single Data Dropped
   option can acknowledge up to 32384 Normal Block data packets,
   although the receiver SHOULD NOT send a Data Dropped option when all
   relevant packets fit into Normal Blocks.  Should more packets need to
   be acknowledged than can fit in 253 bytes of Data Dropped, then
   multiple Data Dropped options can be sent.  The second option will
   begin where the first left off, and so forth.

   One or more Data Dropped options that, together, report the status of
   more packets than have been sent, or that change the status of a
   packet, or that disagree with Ack Vector or equivalent options (by

Top      Up      ToC       Page 94 
   reporting a "not yet received" packet as "dropped in the receive
   buffer", for example) SHOULD be considered invalid.  The receiving
   DCCP SHOULD either ignore such options, or respond by resetting the
   connection with Reset Code 5, "Option Error".

   A DCCP application interface should let receiving applications
   specify the Drop Codes corresponding to received packets.  For
   example, this would let applications calculate their own checksums
   but still report "dropped due to corruption" packets via the Data
   Dropped option.  The interface SHOULD NOT let applications reduce the
   "seriousness" of a packet's Drop Code; for example, the application
   should not be able to upgrade a packet from delivered corrupt (Drop
   Code 7) to delivered normally (no Drop Code).

   Data Dropped information is transmitted reliably.  That is, endpoints
   SHOULD continue to transmit Data Dropped options until receiving an
   acknowledgement indicating that the relevant options have been
   processed.  In Ack Vector terms, each acknowledgement should contain
   Data Dropped options that cover the whole Acknowledgement Window
   (Section 11.4.2), although when every packet in that window would be
   placed in a Normal Block, no actual option is required.

11.7.1.  Data Dropped and Normal Congestion Response

   When deciding on a response to a particular acknowledgement or set of
   acknowledgements containing Data Dropped options, a congestion
   control mechanism MUST consider dropped packets, ECN Congestion
   Experienced marks (including marked packets that are included in Data
   Dropped), and packets singled out in Data Dropped.  For window-based
   mechanisms, the valid response space is defined as follows.

   Assume an old window of W.  Independently calculate a new window
   W_new1 that assumes no packets were Data Dropped (so W_new1 contains
   only the normal congestion response), and a new window W_new2 that
   assumes no packets were lost or marked (so W_new2 contains only the
   Data Dropped response).  We are assuming that Data Dropped
   recommended a reduction in congestion window, so W_new2 < W.

   Then the actual new window W_new MUST NOT be larger than the minimum
   of W_new1 and W_new2; and the sender MAY combine the two responses,
   by setting

         W_new = W + min(W_new1 - W, 0) + min(W_new2 - W, 0).

   The details of how this is accomplished are specified in CCID profile
   documents.  Non-window-based congestion control mechanisms MUST
   behave analogously; again, CCID profiles define how.

Top      Up      ToC       Page 95 
11.7.2.  Particular Drop Codes

   Drop Code 0, Protocol Constraints, does not indicate any kind of
   congestion, so the sender's CCID SHOULD react to packets with Drop
   Code 0 as if they were received (with or without ECN Congestion
   Experienced marks, as appropriate).  However, the sending endpoint
   SHOULD NOT send data until it believes the protocol constraint no
   longer applies.

   Drop Code 1, Application Not Listening, means the application running
   at the endpoint that sent the option is no longer listening for data.
   For example, a server might close its receiving half-connection to
   new data after receiving a complete request from the client.  This
   would limit the amount of state available at the server for incoming
   data and thus reduce the potential damage from certain denial-of-
   service attacks.  A Data Dropped option containing Drop Code 1 SHOULD
   be sent whenever received data is ignored due to a non-listening
   application.  Once an endpoint reports Drop Code 1 for a packet, it
   SHOULD report Drop Code 1 for every succeeding data packet on that
   half-connection; once an endpoint receives a Drop State 1 report, it
   SHOULD expect that no more data will ever be delivered to the other
   endpoint's application, so it SHOULD NOT send more data.

   Drop Code 2, Receive Buffer, indicates congestion inside the
   receiving host.  For instance, if a drop-from-tail kernel socket
   buffer is too full to accept a packet's application data, that packet
   should be reported as Drop Code 2.  For a drop-from-head or more
   complex socket buffer, the dropped packet should be reported as Drop
   Code 2.  DCCP implementations may also provide an API by which
   applications can mark received packets as Drop Code 2, indicating
   that the application ran out of space in its user-level receive
   buffer.  (However, it is not generally useful to report packets as
   dropped due to Drop Code 2 after more than a couple of round-trip
   times have passed.  The HC-Sender may have forgotten its
   acknowledgement state for the packet by that time, so the Data
   Dropped report will have no effect.)  Every packet newly acknowledged
   as Drop Code 2 SHOULD reduce the sender's instantaneous rate by one
   packet per round-trip time, unless the sender is already sending one
   packet per RTT or less.  Each CCID profile defines the CCID-specific
   mechanism by which this is accomplished.

   Currently, the other Drop Codes (namely Drop Code 3, Corrupt; Drop
   Code 7, Delivered Corrupt; and reserved Drop Codes 4-6) MUST cause
   the relevant CCID to behave as if the relevant packets were ECN
   marked (ECN Congestion Experienced).

Top      Up      ToC       Page 96 
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

   The rest of this section describes the ECN Incapable feature and the
   interaction of the ECN Nonce with acknowledgement options such as Ack

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

Top      Up      ToC       Page 97 
   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

   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

   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

Top      Up      ToC       Page 98 
   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

Top      Up      ToC       Page 99 
13.  Timing Options

   The Timestamp, Timestamp Echo, and Elapsed Time options help DCCP
   endpoints explicitly measure round-trip times.

13.1.  Timestamp Option

   This option is permitted in any DCCP packet.  The length of the
   option is 6 bytes.

   |00101001|00000110|          Timestamp Value          |
    Type=41  Length=6

   The four bytes of option data carry the timestamp of this packet.
   The timestamp is a 32-bit integer that increases monotonically with
   time, at a rate of 1 unit per 10 microseconds.  At this rate,
   Timestamp Value will wrap approximately every 11.9 hours.  Endpoints
   need not measure time at this fine granularity; for example, an
   endpoint that preferred to measure time at millisecond granularity
   might send Timestamp Values that were all multiples of 100.  The
   precise time corresponding to Timestamp Value zero is not specified:
   Timestamp Values are only meaningful relative to other Timestamp
   Values sent on the same connection.  A DCCP receiving a Timestamp
   option SHOULD respond with a Timestamp Echo option on the next packet
   it sends.

13.2.  Elapsed Time Option

   This option is permitted in any DCCP packet that contains an
   Acknowledgement Number; such options received on other packet types
   MUST be ignored.  It indicates how much time has elapsed since the
   packet being acknowledged -- the packet with the given
   Acknowledgement Number -- was received.  The option may take 4 or 6
   bytes, depending on the size of the Elapsed Time value.  Elapsed Time
   helps correct round-trip time estimates when the gap between
   receiving a packet and acknowledging that packet may be long -- in
   CCID 3, for example, where acknowledgements are sent infrequently.

Top      Up      ToC       Page 100 
   |00101011|00000100|   Elapsed Time  |
    Type=43    Len=4

   |00101011|00000110|            Elapsed Time           |
    Type=43    Len=6

   The option data, Elapsed Time, represents an estimated lower bound on
   the amount of time elapsed since the packet being acknowledged was
   received, with units of hundredths of milliseconds.  If Elapsed Time
   is less than a half-second, the first, smaller form of the option
   SHOULD be used.  Elapsed Times of more than 0.65535 seconds MUST be
   sent using the second form of the option.  The special Elapsed Time
   value 4294967295, which corresponds to approximately 11.9 hours, is
   used to represent any Elapsed Time greater than 42949.67294 seconds.
   DCCP endpoints MUST NOT report Elapsed Times that are significantly
   larger than the true elapsed times.  A connection MAY be reset with
   Reset Code 11, "Aggression Penalty", if one endpoint determines that
   the other is reporting a much-too-large Elapsed Time.

   Elapsed Time is measured in hundredths of milliseconds as a
   compromise between two conflicting goals.  First, it provides enough
   granularity to reduce rounding error when measuring elapsed time over
   fast LANs; second, it allows many reasonable elapsed times to fit
   into two bytes of data.

13.3.  Timestamp Echo Option

   This option is permitted in any DCCP packet, as long as at least one
   packet carrying the Timestamp option has been received.  Generally, a
   DCCP endpoint should send one Timestamp Echo option for each
   Timestamp option it receives, and it should send that option as soon
   as is convenient.  The length of the option is between 6 and 10
   bytes, depending on whether Elapsed Time is included and how large it

Top      Up      ToC       Page 101 
   |00101010|00000110|           Timestamp Echo          |
    Type=42    Len=6

   +--------+--------+------- ... -------+--------+--------+
   |00101010|00001000|  Timestamp Echo   |   Elapsed Time  |
   +--------+--------+------- ... -------+--------+--------+
    Type=42    Len=8       (4 bytes)

   +--------+--------+------- ... -------+------- ... -------+
   |00101010|00001010|  Timestamp Echo   |    Elapsed Time   |
   +--------+--------+------- ... -------+------- ... -------+
    Type=42   Len=10       (4 bytes)           (4 bytes)

   The first four bytes of option data, Timestamp Echo, carry a
   Timestamp Value taken from a preceding received Timestamp option.
   Usually, this will be the last packet that was received -- the packet
   indicated by the Acknowledgement Number, if any -- but it might be a
   preceding packet.  Each Timestamp received will generally result in
   exactly one Timestamp Echo transmitted.  If an endpoint has received
   multiple Timestamp options since the last time it sent a packet, then
   it MAY ignore all Timestamp options but the one included on the
   packet with the greatest sequence number.  Alternatively, it MAY
   include multiple Timestamp Echo options in its response, each
   corresponding to a different Timestamp option.

   The Elapsed Time value, similar to that in the Elapsed Time option,
   indicates the amount of time elapsed since receiving the packet whose
   timestamp is being echoed.  This time MUST have units of hundredths
   of milliseconds.  Elapsed Time is meant to help the Timestamp sender
   separate the network round-trip time from the Timestamp receiver's
   processing time.  This may be particularly important for CCIDs where
   acknowledgements are sent infrequently, so that there might be
   considerable delay between receiving a Timestamp option and sending
   the corresponding Timestamp Echo.  A missing Elapsed Time field is
   equivalent to an Elapsed Time of zero.  The smallest version of the
   option SHOULD be used that can hold the relevant Elapsed Time value.

(page 101 continued on part 5)

Next RFC Part