[Iccrg] Call for reviewers for CTCP

[Murari Sridharan]

Lachlan, I'll make the appropriate changes to clarify things better and send out an update including answers to your questions below in a couple of days.

Thanks

-----Original Message-----
From: Lachlan Andrew [mailto:lachlan.andrew at gmail.com]
Sent: Tuesday, August 21, 2007 7:12 PM
To: Michael Welzl
Cc: iccrg at cs.ucl.ac.uk; Murari Sridharan
Subject: Re: [Iccrg] Call for reviewers for CTCP

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