RFC 4340-4342 Errata

The RFC Editor maintains an errata page, publishing errors in RFCs authorized by the authors and/or the IESG. The DCCP RFCs do contain some errata. We list these errata on this page when we (the authors) send them to the RFC editor, or in some cases before.

RFC 4340 Errata

These errata sent 7/11/2006.


Thanks to Alfred Hoenes for reporting several errors in RFC4340.

One technical omission has been found concerning the FGSR and FGSS
variables used to detect reordering of feature negotiation options.  We
suggest adding the following paragraph to the end of Section 6.6.4, on Page
42.


   FGSR and FGSS values always satisfy FGSR <= GSR and FGSS <= GSS,
   where GSR and GSS are the Greatest Sequence Numbers Received by and
   Sent from this endpoint.  These constraints MUST be enforced even
   when GSR and GSS wrap, as they might in a long connection.
   Implementations SHOULD thus check FGSR and FGSS after every packet
   received or sent, as follows.  (Wmax is the maximum allowed value for
   the Sequence Window feature; see Section 7.5.2.)

         If FGSR > GSR, then FGSR := GSR - Wmax.
         If FGSS > GSS, then FGSS := GSS - Wmax.

   Alternate implementations that correctly handle sequence number
   wrapping are also acceptable.



Typos and editorial clarifications include:

In Section 6.6.4, Page 41, it says:

              (Change and/or Confirm).  This value is initialized to
              ISR - 1.

It should say:

              (Change and/or Confirm).  This value is initialized to
              ISR - 1, where ISR is the Initial Sequence Number Received
              from the other endpoint.  (ISR and other sequence number
              variables are defined in Section 7.1.)

In Section 6.6.4, Page 41, it says:

              reordering.  FGSS is initialized to ISS.

It should say:

              reordering.  FGSS is initialized to ISS, the Initial
              Sequence Number Sent by this endpoint.


In Section 7.5.2, Page 49, it says:

    getting out sync after bursts of loss,

It should say:

    getting out of sync after bursts of loss,


In Section 8.1.2, Page 60, it says:

            intepreting the four-character result as a 32-bit big-endian

It should say:

            interpreting the four-character result as a 32-bit big-endian


In Appendix A, Page 116, it says:

    right to left.  The implementation maintains five variables, aside

It should say:

    right to left.  The implementation maintains four variables, aside

And it says:

       acknowledged in the buffer.  This corresponds to the "head"

It should say:

       acknowledged in the buffer.  This corresponds to the "buf_head"

On Page 117, it says:

    Ack Vector, it remembers four variables:

It should say:

    Ack Vector, it remembers five variables:


In Section A.3, Page 121, it says:

    HC-Sender packet 3, so the HC-Sender has now received HC-Receiver's

It should say:

    HC-Sender packet 3, so the HC-Sender has now received the HC-Receiver's


In Section A.4, Page 122, it says:

    a single acknowledgement number tells HC-Receiver how much ack

It should say:

    a single acknowledgement number tells the HC-Receiver how much ack

Vladimir Moltchanov points out that the RFC refers to Reset Code 6 as "Mandatory Failure" in two places. The correct name for this Reset Code is "Mandatory Error".

Vladimir Moltchanov also points out an error in Section A.1.1, page 119. The last instance of the example buffer appears as:

      ** +*******----------------------------+         *
      12 |0,0|3,0|0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0    BN[0]
      ** +*******----------------------------+         *

It should say:

      ** +*******----------------------------+         *
      12 |0,0|3,0|0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0    BN[0]
      ** +*******----------------------------+         *

(note that the "0,1" byte has changed to "0,0").

RFC 4342 Errata

These errata sent 2/7/2007.

RFC 4342, "Profile for Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)"

Reported By: Eddie Kohler and Sally Floyd, from Gerrit Renker and
	Arjuna Sathiaseelan 
Date: February 7, 2007

Section 5, 6th paragraph:
Explanation: Clarification of initial sending rates

It states:
   Translating this to the packet-based congestion control of CCID 3,
   the initial CCID 3 sending rate is allowed to be at least two packets
   per RTT, and at most four packets per RTT, depending on the packet
   size.  The initial rate is only allowed to be three or four packets
   per RTT when, in terms of segment size, that translates to at most
   4380 bytes per RTT.

It should say:
   Therefore, in contrast to [RFC3448], the initial CCID 3 sending rate
   is allowed to be at least two packets per RTT, and at most four
   packets per RTT, depending on the packet size.  The initial rate is
   only allowed to be three or four packets per RTT when, in terms of
   segment size, that translates to at most 4380 bytes per RTT.  This
   might be implemented, for example, by setting the initial sending
   rate to min(4*s, max(2*s, 4380 bytes)), where "s" as usual is the
   packet size in bytes.

Section 5, 7th paragraph:
Explanation: Clarification of round-trip time measurement

It states:
   The sender's measurement of the round-trip time uses the Elapsed Time
   and/or Timestamp Echo option contained in feedback packets, as
   described in Section 8.2. The Elapsed Time option is required, while
   the Timestamp Echo option is not.  The sender maintains an average
   round-trip time heavily weighted on the most recent measurements.

It should say:
   The sender's measurement of the round-trip time uses DCCP's mechanisms
   for round-trip time measurement.  This includes Elapsed Time and/or
   Timestamp Echo options.  As described in Section 8.2, feedback packets
   must carry an Elapsed Time option; Timestamp Echo is optional.
   The sender maintains an average round-trip time heavily weighted on the
   most recent measurements.  Senders MAY use any available round-trip time
   measurements, including from the initial Request-Response packet exchange,
   to maintain this average.  This differs from [RFC 3448], which constrains
   round-trip time measurements to feedback packets only.
 
rfc4340errata.txt · Last modified: 2007/02/21 08:00 by kohler
 
Recent changes RSS feed Driven by DokuWiki