errata logo graphic

Found 5 records.

Status: Verified (5)

RFC4342, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", March 2006

Source of RFC: dccp (tsv)

Errata ID: 610

Status: Verified
Type: Technical

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

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

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

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

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


Report New Errata