====== RFC 4340-4342 Errata ======
The RFC Editor maintains an [[http://www.rfc-editor.org/errata.html|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.