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,
Gorry
P.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.
Done.
The abstract should also say:
"This document obsoletes RFC 3448 and updates RFC 4342."
Done.
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.
Done.
---
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.
Done.
---
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
from Lars.
---
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.
Done.
---
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.../
Done.
---
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/
