Hi,
On 2008-2-27, at 10:05, ext Gorry Fairhurst wrote:
This note starts the WG Last-Call for comments for the WG document
named
below:
TCP Friendly Rate Control (TFRC): Protocol Specification
http://tools.ietf.org/html/draft-ietf-dccp-rfc3448bis-05.txt
I'm trying to do my AD reviews during WGLC time. For this document,
that has actually happened.
Summary: Basically good to go. Needs a few tweaks that introduce
RFC2119 terms in order to make it a bit clearer what implementors
should be doing. Suggestions for that in the detailed comments below.
Lars
Detailed comments:
Add an "Obsoletes: 3448 (if approved)" header, and add "This document
obsoletes RFC 3448" to both the abstract and the introduction.
Section 1., paragraph 0:
> 1. Introduction
Thinking about eventually moving TFRC to Draft Standard, it would be
good to mention in the introduction which Sections of this document
contain the normative specification, and which are informative. This
will make it easier to determine whether any future changes have
impacted the specification or are informative in nature. (I'd think
that only Sections 3-6 are normative.)
Section 3.1., paragraph 2:
> The throughput equation we currently recommend for TFRC is a
> slightly simplified version of the throughput equation for Reno TCP
s/The throughput equation we currently recommend for/
The throughput equation currently REQUIRED for/
Section 3.1., paragraph 11:
> We further simplify this by setting t_RTO = 4*R.
s/We further simplify this by setting/Implementations SHOULD set/
> A more accurate
> calculation of t_RTO is possible, but experiments with the current
> setting have resulted in reasonable fairness with existing TCP
> implementations [W00].
s/A more accurate calculation of t_RTO is possible/
Implementations MAY choose to implement a more accurate
calculation of t_RTO/
> Another possibility would be to set t_RTO to
> max(4R, one second), to match the recommended minimum of one second
> on the RTO [RFC2988].
s/Another possibility would be to set/Implementatins MAY also set/
Section 3.1., paragraph 12:
> Because many TCP implementations do not use
> delayed acknowledgements, we recommend b = 1.
s/we recommend b = 1/b = 1 is RECOMMENDED/
Section 3.1., paragraph 13:
> For the revised TCP
> congestion control mechanisms, [RFC2581bis] currently specifies that
> the delayed acknowledgement algorithm SHOULD be used with TCP.
s/SHOULD/should/ (or use quotes)
Section 3.1., paragraph 17:
> In future, different TCP equations may be substituted for this
> equation. The requirement is that the throughput equation be a
> reasonable approximation of the sending rate of TCP for conformant
> TCP congestion control.
Please add a sentence stating that this will require an update to the
specification in this RFC (i.e., that it isn't up to an implementor
to
pick a different equation and still call it TFRC.)
Nit: s/In future/In the future/
Section 3.2.1., paragraph 2:
> o A sequence number. This number is incremented by one for each
> data packet transmitted. The field must be sufficiently large
> that it does not wrap causing two different packets with the
> same sequence number to be in the receiver's recent packet
> history at the same time.
s/is incremented/MUST be incremented/
s/field must be/field MUST be/
Section 3.2.1., paragraph 3:
> o A timestamp indicating when the packet is sent. We denote by
> ts_i the timestamp of the packet with sequence number i. The
> resolution of the timestamp should typically be measured in
> milliseconds.
s/should/SHOULD/
Section 3.2.1., paragraph 5:
> We note that as an alternative to a timestamp incremented in
> milliseconds, a "timestamp" that increments every quarter of a
> round-trip time would be sufficient for determining when losses
> belong to the same loss event, in the context of a protocol
> where this is understood by both sender and receiver, and where
> the sender saves the timestamps of transmitted data packets.
Rephrase to use the RFC2119 term MAY instead of "would be
sufficient".
Section 4.1., paragraph 4:
> For the first class of applications where the segment size varies
> depending on the data, the sender MAY estimate the segment size s as
> the average segment size over the last four loss intervals. The
> sender MAY also estimate the average segment size over longer time
> intervals, if so desired. The TFRC sender uses the segment size s
> in the throughput equation, in the setting of the maximum receive
> rate and the minimum and initial sending rates, and in the setting
> of the nofeedback timer.
This paragraph describes two MAYs. Can we recommend one as a SHOULD?
Section 4.1., paragraph 5:
> The TFRC receiver may use the average segment size s in initializing
> the loss history after the first loss event, but Section 6.3.1 also
> gives an alternate procedure that does not use the average segment
> size s.
s/may/MAY/
Also, its not clear is the procedure in Section 6.3.1 is a
MAY, SHOULD or a MUST. Please indicate this here and there.
Section 4.3., paragraph 2:
> When a feedback packet is received by the sender at time t_now, the
> current time in seconds, the following actions should be performed.
s/should/MUST/ (Or at least SHOULD, but what other options are
there?)
Section 4.3., paragraph 6:
> TFRC is not sensitive to the precise value for the filter
> constant q, but we recommend a default value of 0.9.
s/we recommend a default value of 0.9/
a default value of 0.9 is RECOMMENDED/
Section 4.4., paragraph 2:
> Future documents may explore other possible values for the
recover_rate.
s/Future documents/Future updates to this specification/
Section 4.4., paragraph 3:
> If the nofeedback timer expires, the sender should perform the
> following actions:
s/should/MUST/ (Or at least SHOULD, but what other options are
there?)
Section 4.5., paragraph 1:
> To reduce oscillations in queueing delay and sending rate in
> environments with a low degree of statistical multiplexing at the
> congested link, it can be useful for the sender to reduce the
> transmit rate as the queuing delay (and hence RTT) increases.
s/it can be useful for the sender to/
it is RECOMMENDED that the sender/
Section 4.5., paragraph 4:
> We recommend a value of 0.9 as the default for q2.
s/We recommend a value of 0.9 as the default for q2/
A value of 0.9 as the default for q2 is RECOMMENDED/
Section 4.5., paragraph 9:
> If it is
> not implemented, we recommend using a very low value of the weight q
> for the average round-trip time.
s/we recommend using/implementations SHOULD use/
Section 4.6., paragraph 1:
> system. To help maintain the correct average sending rate, the TFRC
> sender may send some packets before their nominal send time.
s/may/MAY/
Section 4.6., paragraph 2:
> The TFRC sender is allowed to accumulate sending 'credits' for past
> unused send times;
s/is allowed to/MAY/
Section 5.1., paragraph 1:
> For the purposes
> of this specification, we require that if a lost packet is
> retransmitted, the retransmission is given a new sequence number
> that is the latest in the transmission sequence, and not the same
> sequence number as the packet that was lost.
s/we require that/it is REQUIRED that/
Section 5.1., paragraph 4:
> Future versions of
> TFRC might make the requirement for NDUPACK subsequent packets
> adaptive based on experienced packet reordering, but we do not
> specify such a mechanism here.
s/but we do not specify such a mechanism here/
but such a mechanism is not part of the current specification/
Section 5.2., paragraph 1:
> TFRC is not sensitive
> to how the RTT measurement sent to the receiver is made, but we
> recommend using the sender's calculated RTT, R, (see Section 4.3)
> for this purpose.
s/we recommend using/it is RECOMMENDED to use/
Section 5.4., paragraph 6:
> As currently specified, TFRC SHOULD NOT
> use values of n greater than 8, for traffic that might compete in
> the global Internet with TCP.
Is 8 the RECOMMENDED value? If so, say so. If not, some uses of
that number (see some of the following comments) need to change.
Section 5.5., paragraph 1:
> As described in Section 5.4, when there have been at least eight
> loss intervals,
The "eight" is only an example in Section 5.4; it's a parameter "n".
Rephrase. (Unless 8 becomes recommended there.)
Section 5.5., paragraph 2:
> This section describes an optional history discounting mechanism,
s/optional/OPTIONAL/
Section 5.5., paragraph 16:
> This completes the description of the optional history discounting
> mechanism. We emphasize that this is an optional mechanism whose
> sole purpose is to allow TFRC to respond somewhat more quickly to
> the sudden absence of congestion, as represented by a long current
> loss interval.
s/optional/OPTIONAL/
Section 6., paragraph 1:
> Feedback packets should normally be sent at least once per RTT,
> unless the sender is sending at a rate of less than one packet per
> RTT, in which case a feedback packet should be send for every data
> packet received. A feedback packet should also be sent whenever a
> new loss event is detected without waiting for the end of an RTT,
> and whenever an out-of-order data packet is received that removes a
> loss event from the history.
s/should/SHOULD/ (twice)
Section 6.1., paragraph 4:
> An optimization might check to see if the arrival of the packet
> caused a hole in the packet history to be filled and
> consequently two loss intervals were merged into one.
s/An optimization/An OPTIONAL optimization/
Section 6.3.1., paragraph 1:
> The number of packets until the first loss can not be used to
> compute the allowed sending rate directly, as the sending rate
> changes rapidly during this time.
s/can not/MUST NOT/ (or SHOULD NOT?)
Section 6.3.1., paragraph 5:
> In this case, the loss interval length for this
> (null) loss interval should be set to give a similar sending rate to
> that of TCP.
s/should/SHOULD/
Section 9.2., paragraph 12:
> Section 5.4, clarification: Section 5.4 was modified to clarify the
> receiver's calculation of the average loss interval when the
> receiver has not yet seen eight loss intervals.
"Eight" is currently a suggestion for a parameter "n". May need to
rephrase.
------------------------------------------------------------------
Nits; only of interest to the authors
INTRODUCTION, paragraph 24:
> add CWV-styoe behavior to TFRC for data-limited periods,
Nit: s/CWV-styoe/CWV-style/
INTRODUCTION, paragraph 45:
> It must have been deleted accidently.
Nit: s/accidently./accidentally./
Section 4.1., paragraph 6:
> The second class of applications are discussed separately in a
> separate document on TFRC-SP. For the remainder of this section we
> assume the sender can estimate the segment size, and that congestion
> control is performed by adjusting the number of packets sent per
> second.
Nit: Cite RFC 4828 for TFRC-SP.
Section 7., paragraph 4:
> RFC 4340 and RFC 4342 together specify CCID 3, which can be used as
> a sender-based variant of TFRC. In CCID 3, each feedback packet
> from the receiver contains a Loss Intervals option, reporting the
> lengths of the most recent loss intervals.
Nit: s/CCID3/DCCP's CCID3/
Section 8.2.1., paragraph 4:
> Else if (NotLimited2 <= t_next)
> // Goal: Notlimited2 > t_next.
Nit: s/Notlimited2/NotLimited2/
Section 12., paragraph 103:
> window during data-limited periods (in the absense of loss).
Nit: s/absense/absence/
Section 12., paragraph 105:
> immdiately reported value of X_recv during a data-limited interval
Nit: s/immdiately/immediately/
Section 12., paragraph 112:
> losses in a data-limited period when, during the data-limied period,
Nit: s/data-limied/data-limited/
