Hi All, What is the relationship of this update to CCID 3? Should CCID 3 implementations follow this instead of RFC 3448? I thought that was the intent but RFC 4342 (CCID 3) says CCID 3 implementations MAY track changes to the throughput equation, but SHOULD wait for explicit updates to CCID 3 for other changes... Tom P. > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Lars Eggert > Sent: Friday, February 29, 2008 9:53 AM > To: gorry@xxxxxxxxxxxxxx > Cc: ''dccp' working group' > Subject: AD review of draft-ietf-dccp-rfc3448bis-05.txt > > 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/
