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 the
transmit 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 the
transmit 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_MAX
Everywhere else S is used, so perhaps here is should be Dist(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.
----------------------------------------------------------------------
--
----------------------------------------------------------------------
--
-------
