[Iccrg] Call for reviewers for CTCP
Lachlan Andrew
lachlan.andrew at gmail.com
Wed Aug 22 03:12:01 BST 2007
Greetings all,
On 21/08/07, Michael Welzl <michael.welzl at uibk.ac.at> wrote:
> SECOND CALL - so far we received nothing! are there no volunteers
> on this list? (i.e. isn't there anyone else who wants to submit
> submit a proposal one day? :-D )
Before deciding on the safeness of CTCP, I'd recommend tidying up some
loose ends in this draft, as below. I think these are mainly problems
with the explanations, rather than the algorithm.
Cheers,
Lachlan
- Calculation of BaseRTT is not clear.
"The basertt is a value that tracks the minimum RTT sample
measured seen so far and it is used as an estimation of the
transmission delay of a single packet. Basertt is usually cleared if a
retransmission timeout is hit. It is a good idea to re-measure the
basertt incase the network conditions have changed."
o Does "usually cleared" mean that the algorithm clears it, or not?
o When baseRTT is "cleared", does that mean "set to 0", "set to
infinity" or ...?
o Setting to infinity is the most aggressive setting, and so it is not clear
that this is the appropriate response to a timeout.
o What does "re-measure" mean? In Vegas, the baseRTT is continually being
measured.
o This belongs in the algorithm description, not "Implementation issues"
- The adaptive calculation of gamma is unclear and hence unconvincing.
o There is a big leap from the thought experiment without CTCP to what
CTCP can actually observe.
o From this description, it seems that Q is always
less-than-or-equal-to the number of packets the CTCP flow has in
the buffer. In that case, choosing gamma <= Q implies that the
CTCP always has more than gamma packets in the buffer, and always
reverts to standard TCP. (This description is inconsistent with
the pseudocode below it, which evaluates Q only at times of loss.)
o The line "Q is calculated as follows" is followed by equations which
don't mention Q.
- No numeric value is given for eta (although it is described as
"very important to preserve...TCP fairness").
- equations (3) and (4) contradict (5) and (7). Which is the actual update
rule for dwnd? (I assume (3) and (4) are meant to apply to wnd.)
- In (8), brackets are missing around (2-k) in the denominator
- In Section 5, B/m+l should presumably be B/(m+l). (Brackets are used
every time they are not needed, and omitted every time they are needed.)
Also, B is undefined.
- (10) doesn't follow from (8), because the constant coefficient in terms of
alpha and beta is missing from (8).
- In the sentence "The expected throughput gives the estimation of throughput
CTCP gets if it does not overrun the network path", what does
"overrun the network path" mean? Does that mean "induce queueing"?
- Neither FAST nor AFRICA halves its window if the delay becomes large.
(Hamilton's Delay-based-AIMD is the only scheme I'm aware of which does.)
- If CTCP is to be "TCP-friendly" but less sensitive to RTT, I don't understand
what will happen when it shares with two flows of unequal RTT.
Which TCP flow will it get the same rate as?
(It doesn't matter, but casts doubt on the claim that it gives "the
same" rate as TCP.)
- End of section 4: "Later sections" -- specify the section
--
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603
More information about the Iccrg
mailing list