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.
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?
---
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?
---
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.
---
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?
---
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'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.
---
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/
