|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Gorry - Many thanks for the feedback. I have revised the draft, and submitted it to the internet-drafts editor. On Mar 12, 2008, at 11:05 AM, Gorry Fairhurst wrote:
As a part of my WG Chair read-through, I have some more comments. I'm sending these now in case others wish to comment and to allow the authors to incorporate these into their working revision.Best wishes, GorryP.S. This Last-Call will end on midnight, Friday 21st March 2008, so there are still opportunities for people to comment.--- The WG decided that it is OK to update RFC 4342.The document therefore also needs an UPDATES RFC43432 line in the header.
The abstract should also say: "This document obsoletes RFC 3448 and updates RFC 4342."
The authors should add an explicit paragraph to the end of the introduction concerning the update to RFC4342, since my understanding is that RFC4342 was not intended to be updated by a change to TFRC, and we therefore need to explain this.
--- Section 3.1 page 14.The authors seem to give two methods for calculating t_RTO. One option includes a minimum RTO setting of 1 sec, which seems like it could offer some help in stabilising the value of X_Bps in the presence of low and varying RTT, where R could vary by many orders of magnitude. As I read it, this is not the default. What are you recommending?
This has been clarified in draft-ietf-dccp-rfc3448bis-06b.txt.
--- Section 3.1 page 14. NiT /max(4R/ seems to be written /max(4*R/ in other places.
--- Section 4.1 page 17.The TFRC sender can either compute the average segment size or use the maximum segment size for the segment size s. This seems a problem, for applications where the segment size varies. I'd expect many applications to start exchanging control data that is either larger or smaller than used in the remainder of the session. Since the segment size can be different by two orders of magnitude, this seems a significant issue. Bounding s to the largest segment size used would seem one possibility, setting this to the largest possible segment size.- Current guidance is weak, and includes only a MAY followed by another MAY indicating a longer (but unbounded) measurement interval.I would like to see some more careful RFC2219 language here: Is there some size that MUST be the upper bound? Is there some upper bound on the measurement period, or at least a recommended upper bound?
The first MAY was changed to a SHOULD, following the February 29 feedback
--- Section 4.1 page 17.Two algorithms are suggested for initialising the loss history. There is no guidance on which is recommended. If there is different applicability, please say, if they are both equivalent, please choose and recommend one as the default.
I rephrased it. It depends on which one is more convenient for the receiver.
--- Section 4.3 page 19. The role of t_delay should be briefly mentioned here.
--- Section 4.6 page 26.True, TCP could send upto one RTT's of packets in a burst. I thought pacing of the TCP sender was also encouraged and this had received some deployment?
I don't think that it is generally deployed in TCP. My web page at "http://www.icir.org/floyd/tcp_small.html" lists some articles about pacing, under the subject heading "Pacing, Rate-Halving, and other Mechanisms for Reducing Bursts". Mark Allman was a co-author of the most recent paper cited in that section, so he might know more. RFC 3649 on HighSpeed TCP also has a discussion on short-term burstiness in Section 10.2.
--- Section 4.6 page 27.TFRC MAY use pacing... Given the assertion that this is slower than the currently deployed TCP. Is this really true?
I think so (e.g., the papers on TCP pacing cited a few paragraphs above). But I deleted the sentence about "However, we note that such limits also constrain TFRC's performance beyond the case for the current TCP", and deleted the phrase "if so desired".
I'd have liked to have seen a more strong encouragement to support the use of pacing (at least prevention of large bursts), since a bursty source raises significant issues when sharing link capacity.
My preference is to leave it as MAY, at least as long as I don't have anything to cite to support a SHOULD. Do you have specific language that you would suggest?
--- Section C page 51. The para staring, /In particular, ..../ could be better phrased as in /In particular, an Experimental RFC [RFC2861] specifies.../
--- NiTs Please replace /doesn't/does not/ /can't/can not/ /hasn't/has not/ /immdiately/immediately/
Done. Again, many thanks. - Sally http://www.icir.org/floyd/