RFC Errata
Found 5 records.
Status: Verified (5)
RFC 4342, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", March 2006
Note: This RFC has been updated by RFC 5348, RFC 6323, RFC 8311
Source of RFC: dccp (tsv)
Errata ID: 610
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2007-10-24
Section 6 says:
2. A Receive Rate option, defined in Section 8.3, specifying the rate at which data was received since the last DCCP-Ack was sent.
It should say:
2. A Receive Rate option, defined in Section 8.3, specifying the rate at which data was received over the last round-trip time.
Notes:
Section 8.3 of RFC 4342 (DCCP CCID 3) specifies that the Receive
Rate option reports the receive rate since the last feedback packet
was sent. In contrast, Section 6.2 of RFC 3448 (TFRC) specifies
that the feedback packet reports the receive rate over the last
round-trip time. As a result, the receive rate specified by
RFC 4342 differs from that of TFRC for a feedback packet after an
idle period; the receive rate report specified in RFC 4342 reports
the receive rate over the entire idle period. The receive rate
reported by RFC 4342 also differs from that of TFRC for an early
feedback packet reporting a new loss event. This errata updates
RFC 4342 to use the definition of the receive rate as specified in
RFC 3448.
Errata ID: 611
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2007-10-24
Section 8.3 says:
Its four data bytes indicate the rate at which the receiver has received data since it last sent an acknowledgement, in bytes per second. To calculate this receive rate, the receiver sets t to the larger of the estimated round- trip time and the time since the last Receive Rate option was sent.
It should say:
Its four data bytes indicate the rate at which the receiver has received data over the last round-trip time, in bytes per second. To calculate the time interval t for calculating this receive rate, the receiver follows Section 6.2 of [RFC3448].
Notes:
This errata updates RFC 4342 to use the definition of the receive rate
as specified in RFC 3448.
Errata ID: 612
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2007-10-24
Section 8.3 says:
It should say:
Assume that the sender receives two feedback packets with Acknowledgement Numbers A1 and A2, respectively. Further assume that the sender sent no data packets in between Sequence Numbers A1+1 and A2, inclusive. (All those packets must have been pure acknowledgements, Sync and SyncAck packets, and so forth.) Then the sender MAY, at its discretion, ignore the second feedback packet's Receive Rate option. Note that when the sender decides to ignore such an option, it MUST NOT reset the nofeedback timer as it normally would; the nofeedback timer will expire as if the second feedback packet had not been received.
Notes:
This is a new paragraph to be added to the end of Section 8.3.
It specifies that if the interval covered by a feedback packet doesn't include
any data packets, then the sender doesn't have to use the reported receive rate.
Errata ID: 829
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eddie Kohler
Date Reported: 2007-02-07
Section 5 says:
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.
Notes:
Clarification of initial sending rates.
Reported By: Eddie Kohler and Sally Floyd, from Gerrit Renker and Arjuna Sathiaseelan
from pending
Errata ID: 830
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eddie Kohler
Date Reported: 2007-02-07
Section 5 says:
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.
Notes:
Clarification of round-trip time measurement.
Reported By: Eddie Kohler and Sally Floyd, from Gerrit Renker and Arjuna Sathiaseelan
from pending