Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4340

Datagram Congestion Control Protocol (DCCP)

Pages: 129
Proposed Standard
Errata
Updated by:  5595559663356773
Part 4 of 5 – Pages 76 to 101
First   Prev   Next

Top   ToC   RFC4340 - Page 76   prevText

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   ToC   RFC4340 - 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   ToC   RFC4340 - 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 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).
Top   ToC   RFC4340 - 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
   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)
Top   ToC   RFC4340 - 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 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.
Top   ToC   RFC4340 - 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
      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.

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   ToC   RFC4340 - 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
   specifications.

   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- acks. 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   ToC   RFC4340 - 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   ToC   RFC4340 - 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   ToC   RFC4340 - 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   ToC   RFC4340 - 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   ToC   RFC4340 - 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
   explanation.)

   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
   dropped.

   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   ToC   RFC4340 - 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   ToC   RFC4340 - 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 acknowledgements; 2. Packets already acknowledged by the HC-Receiver, where the HC-Receiver cannot be sure that the HC-Sender has received the acknowledgements; 3. Packets not yet acknowledged by the HC-Receiver; and
Top   ToC   RFC4340 - 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   ToC   RFC4340 - Page 91
   Slow Receiver is a one-byte option.

   +--------+
   |00000010|
   +--------+
    Type=2

   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
   functionality.

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   ToC   RFC4340 - 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   ToC   RFC4340 - 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
          9.3.

      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
      3).

      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   ToC   RFC4340 - 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   ToC   RFC4340 - 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   ToC   RFC4340 - 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 it. The rest of this section describes the ECN Incapable feature and the interaction of the ECN Nonce with acknowledgement options such as Ack Vector.

12.1. ECN Incapable Feature

DCCP endpoints are ECN-aware by default, but the ECN Incapable feature lets an endpoint reject the use of Explicit Congestion Notification. The use of this feature is NOT RECOMMENDED. ECN incapability both avoids ECN's possible benefits and prevents senders from using the ECN Nonce to check for receiver misbehavior. A DCCP stack MAY therefore leave the ECN Incapable feature unimplemented, acting as if all connections were ECN capable. Note that the inappropriate firewall interactions that dogged TCP's implementation of ECN [RFC3360] involve TCP header bits, not the IP header's ECN bits; we know of no middlebox that would block ECN-capable DCCP packets but allow ECN-incapable DCCP packets. ECN Incapable has feature number 4 and is server-priority. It takes one-byte Boolean values. DCCP A MUST be able to read ECN bits from received frames' IP headers when ECN Incapable/A is zero. (This is independent of whether it can set ECN bits on sent frames.) DCCP A thus sends a "Change L(ECN Inapable, 1)" option to DCCP B to inform it that A cannot read ECN bits. If the ECN Incapable/A feature is one, then all of DCCP B's packets MUST be sent as ECN incapable. New connections start with ECN Incapable 0 (that is, ECN capable) for both endpoints. Values of two or more are reserved. If a DCCP is not ECN capable, it MUST send Mandatory "Change L(ECN Incapable, 1)" options to the other endpoint until acknowledged (by "Confirm R(ECN Incapable, 1)") or the connection closes. Furthermore, it MUST NOT accept any data until the other endpoint
Top   ToC   RFC4340 - 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 application. ECN Nonces are a general mechanism to prevent ECN cheating (or loss cheating). Two values for the two-bit ECN header field indicate ECN-Capable Transport, 01 and 10. The second code point, 10, is the ECN Nonce. In general, a protocol sender chooses between these code points randomly on its output packets, remembering the sequence it chose. On every acknowledgement, the protocol receiver reports the number of ECN Nonces it has received thus far. This is called the ECN Nonce Echo. Since ECN marking and packet dropping both destroy the ECN Nonce, a receiver that lies about an ECN mark or packet drop has a 50% chance of guessing right and avoiding discipline. The sender may react punitively to an ECN Nonce mismatch, possibly up to dropping the connection. The ECN Nonce Echo field need not be an integer; one bit is enough to catch 50% of infractions, and the probability of success drops exponentially as more packets are sent [RFC3540]. In DCCP, the ECN Nonce Echo field is encoded in acknowledgement options. For example, the Ack Vector option comes in two forms, Ack Vector [Nonce 0] (option 38) and Ack Vector [Nonce 1] (option 39), corresponding to the two values for a one-bit ECN Nonce Echo. The Nonce Echo for a given Ack Vector equals the one-bit sum (exclusive- or, or parity) of ECN nonces for packets reported by that Ack Vector as received and not ECN marked. Thus, only packets marked as State 0 matter for this calculation (that is, valid received packets that were not ECN marked). Every Ack Vector option is detailed enough for the sender to determine what the Nonce Echo should have been. It can check this calculation against the actual Nonce Echo and complain if there is a mismatch. (The Ack Vector could conceivably report every packet's ECN Nonce state, but this would severely limit its compressibility without providing much extra protection.) Each DCCP sender SHOULD set ECN Nonces on its packets and remember which packets had nonces. When a sender detects an ECN Nonce Echo
Top   ToC   RFC4340 - 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 aggression.
Top   ToC   RFC4340 - 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   ToC   RFC4340 - 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 is.
Top   ToC   RFC4340 - 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 Section