Vladimir, said I could forward this to the authors and list.
To remind people, we're expecting a revised I-D that addresses the comments from the reviewers and any from this list. We then hope to be able to start a WGLC.
Best wishes, Gorry (DCCP WG Co-Chair)
Hello Gorry, I have not found any technical issues with the document. I'll try to have another pass on it, if I will have time. But here is a list of editorial&readability comments. B.R. Vladimir.Some ideas: i) For the throughput equation on page 13/14 it could be nice to also present a simplified version with recommended values. ii) data-limited period is defined on page 20, but it is not very easy to spot. Since it has quite a bit of text to itself and is mentioned all around the document it could have a sub-section of its-own, hence, be referenced in TOC. Comments: ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------- 1) page 5: missing a "-" for data-limited ? * Added a fix so that when datalimited and p = 0, the sender doesn't double the allowed sending rate after each feedback packet. Step (4) of Section 4.3. Problem reported by Arjuna. same as on page 9 - Change for a datalimited sender: When the sender has been datalimited, the sender doesn't let the receive rate limit it to a sending rate less than the initial rate. ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------- 2) Page 11 paragraph 3 (Coma after Thus, ) Thus TFRC should only be used when the application has a requirement for smooth throughput, in particular, avoiding TCP's halving of the sending rate in response to a single packet drop. => Thus, TFRC should only be used when the application has a requirement for smooth throughput, in particular, avoiding TCP's halving of the sending rate in response to a single packet drop. ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------- 3) Page 23, section 4.5, paragraph 1. (queueing => queuing) (This word is misspelled in several places in the document, unless its another way to write it :) ) 4.5. Reducing Oscillations 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 thetransmit rate as the queuing delay (and hence RTT) increases.=> 4.5. Reducing Oscillations To reduce oscillations in queuing 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 thetransmit rate as the queuing delay (and hence RTT) increases.------------------------------------------------------------------------ ------------------------------------------------------------------------ ------- 4) There is a bit of inconsistency in using S vs Seqno in section 5.2 Dist(Seqno_A, Seqno_B) = (Seqno_A + S_MAX - Seqno_B) % S_MAXEverywhere else S is used, so perhaps here is should beDist(S_A, S_B) = (S_A + S_MAX - S_B) % S_MAX ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------- 5) Such variables as X_target and X_recv_set are not in the terminology section. At least X_recv_set is being used some 10 pages after it is defined, so it could be put to terminology. ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------- 6) Page 35, paragraph 1. (the the => the) (For slow-start, for a particular round-trip time, the sender's sending rate is generally twice the the receiver's receive rate for data sent over the previous round-trip time.) => (For slow-start, for a particular round-trip time, the sender's sending rate is generally twice the receiver's receive rate for data sent over the previous round-trip time.) ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------- 7) Page 45 t_gran: Schedular granularity (constant) (Section 8.3). => t_gran: Scheduler granularity (constant) (Section 8.3). Or perhaps the original definition from section 8.3 is good enough "Let t_gran be _the scheduling timer granularity of the operating system_ + (constant)" ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------- 8) R_m variable could be added to the terminology section as it is used in several places. For example in section 6 (10 pages away from the declaration). ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------- 9) definition for t_recvdata could be added to the terminology section ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------- 10) Paragraph 3 on page 34 is not easy to read: If no data packets have been received since the last feedback was sent, no feedback packet is sent, and the feedback timer is restarted to expire after R_m seconds. => If no data packets have been received since the last feedback was sent, then no feedback packet is sent, and the feedback timer is restarted to expire after R_m seconds. ------------------------------------------------------------------------ ------------------------------------------------------------------------ -------
