RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (2)

RFC 5348, "TCP Friendly Rate Control (TFRC): Protocol Specification", September 2008

Source of RFC: dccp (tsv)

Errata ID: 1614

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Verifier Name: Lars Eggert
Date Verified: 2008-11-28

Section 4.6, pg. 19 says:

<<  last paragraph of Section 4.6 >>

   For TFRC senders allowed to accumulate sending credits for unused
   send time over the last T seconds, the sender would be allowed to use
|  unused nominal send times t_j for t_j < now - T, for T set to the
   round-trip time.
                                          ^^^^

It should say:

   For TFRC senders allowed to accumulate sending credits for unused
   send time over the last T seconds, the sender would be allowed to use
|  unused nominal send times t_j for t_j < t_now - T, for T set to the
   round-trip time.
                                          ^^^^^^

Notes:

Rationale:
Consistent use of variable names.

Errata ID: 1615

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Verifier Name: Lars Eggert
Date Verified: 2008-11-28

Section 6.2, pg.28 says:

   2)  Calculate the measured receive rate, X_recv, based on the packets
       received within the previous R_(m-1) seconds.  This is performed
       whether the feedback timer expired at its normal time or expired
|      early due to a new lost or marked packet (i.e., step (3) in
       Section 6.1).
                                                             ^

It should say:

   2)  Calculate the measured receive rate, X_recv, based on the packets
       received within the previous R_(m-1) seconds.  This is performed
       whether the feedback timer expired at its normal time or expired
|      early due to a new lost or marked packet (i.e., step (4) in
       Section 6.1).
                                                             ^

Notes:

Rationale:
The steps in 6.1 have been renumbered since RFC 3448, due to
the insertion of a new step (2); this change apparently has
been missed here.

Status: Held for Document Update (4)

RFC 5348, "TCP Friendly Rate Control (TFRC): Protocol Specification", September 2008

Source of RFC: dccp (tsv)

Errata ID: 1612

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Held for Document Update by: Magnus Westerlund

Section 4, pg.9 says:

<< 5th bullet >>

   o   Oscillation prevention (optional).

It should say:

   o   Oscillation reduction (optional).
                   ^^^^^^^^^

Notes:

Rationale:
Consistency in change of emphasis (since RFC 3448),
cf. new title of Section 4.5 !

Errata ID: 1613

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Held for Document Update by: Lars Eggert

Section 4.4, pg.15 says:

<< 1st paragraph in Section 4.4 >>

|  This section specifies the sender's response to a nofeedback timer.
   The nofeedback timer could expire because of an idle period or
   because of data or feedback packets dropped in the network.

It should say:

                                                                vvvvvvv
|  This section specifies the sender's response to a nofeedback timeout.
   The nofeedback timer could expire because of an idle period or
   because of data or feedback packets dropped in the network.

Errata ID: 1616

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Held for Document Update by: Lars Eggert

Section 7, pg.30 says:

<<  second paragraph of section, at the bottom of pg. 30 >>

   The main advantage of a sender-based variant of TFRC is that the
   sender does not have to trust the receiver's calculation of the
   packet loss rate.  However, with the requirement of reliable delivery
   of loss information from the receiver to the sender, a sender-based
|  TFRC would have much tighter constraints on the transport protocol in
   which it is embedded.

It should say:

   The main advantage of a sender-based variant of TFRC is that the
   sender does not have to trust the receiver's calculation of the
   packet loss rate.  However, with the requirement of reliable delivery
   of loss information from the receiver to the sender, a sender-based
|  TFRC has much tighter constraints on the transport protocol in which
   it is embedded.

Notes:

Rationale:
Consistency in style broken by incomplete change since
RFC 3448; present tense is now used in the first sentence;
so it should be used in the second one as well, for clarity.

Errata ID: 1617

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-11-24
Held for Document Update by: Lars Eggert

Section C.1, pg.48 says:

<<  second paragraph on page 48 >>

   Recovery after idle or data-limited periods: When TCP reduces the
|  congestion window after an idle or data-utilized period, TCP can set
   the slow-start threshold, ssthresh, to allow the TCP sender to slow-
   start back up towards its old sending rate when the idle or data-
   limited period is over.  [...]

It should say:

   Recovery after idle or data-limited periods: When TCP reduces the
|  congestion window after an idle or data-limited period, TCP can set
   the slow-start threshold, ssthresh, to allow the TCP sender to slow-
   start back up towards its old sending rate when the idle or data-
   limited period is over.  [...]

Notes:

Rationale:
The term "data-utilized period" does not appear anywhere else in
the RFC; apparently, "data-limited period" is meant here as well.

Report New Errata