[Iccrg] updated RG CTCP review

Thu Mar 27 13:56:45 GMT 2008

Based on the responses to the first draft, and the discussion
we had in Philadelphia, I've prepared an update to the RG's
Compound TCP review (attached).  Please look this over in
the next two weeks, and we will forward it to TCPM if no major
changes are noted by then.

I've added links to some of the implementation and
experimental results, and to mailing list discussions.
If there are other links that should be added to provide
even more backup, please note it to us.

Thanks for your help (and patience!) in completing this first
review for TCPM.
-------------- next part --------------
In July 2007, the ICCRG began reviewing the Compound TCP congestion control
technique described in draft-sridharan-tcpm-ctcp-00 in terms of its safety for
widespread experimental deployment on the public Internet.  This review was
conducted as an input to the IETF TCPM working group, where the draft was being
considered for possible Experimental publication.  The scope of this review
does not include making or endorsing any claims about expected performance
gains from using Compound TCP.

Based on initial RG comments, an update to the original internet-draft was
published.  Based on further RG comments, another update is expected that
contains several clarifications (itemized later within this document).  This
review assumes that those changes are made.

After reviewing the draft and a number of other documents with results from
testing and simulation, three public evaluations were submitted to the ICCRG by
RG participants.  Several follow-on messages and comments were submitted by
these and other RG participants.  Multiple independent implementations have
been done of Compound TCP at this point in time.  Compound TCP has been
experimented with in both simulators, testbeds, and campus/enterprise networks.
On the matter of safety for experimental use, the implementers and experimenters
seem to agree that the algorithm is safe, though in individual implementations,
bugs have been found, unrelated to the algorithm itself. It is possible that
clarifications to the specification will help to avoid this.  The RG seems to
have consensus that (given the expected draft clarifications) the Compound TCP
mechanism is safe for experimental deployment on the public Internet.

References to RG participants' reviews and papers, presentations, and mailing
list messages that contributed to the consensus-forming are provided at the
end of this document.

Its novelty from the current Standards Track congestion control techniques is
that Compound TCP also contains a delay-based component.  Compound TCP's
design only utilizes the delay-based component when loss is low and the
congestion window has already grown large, and in other conditions reversts
to the current Standards Track mechanisms.  This was noted by some reviewers
as one inspiration of confidence.  The simulation results and analysis made
available were also helpful, but were not found to be overwhelmingly convincing
on their own. The implementation experiences, testbed work, and campus
deployments weighed most heavily in the RG's mind as evidence of Compound TCP's
safety.

There was an open discussion item on the use of estimation algorithms for the
queueing delay.  There was also a question lingering about how the algorithm
behaves in wireless environments where latency variations may not be completely
due to congestion, and a security-related question as to the possibility to
disrupt the delay-based component by altering the material used to take delay
samples.  These questions seem to apply to any congestion control algorithm
that utilizes delay as a source of congestion information.

Expected changes from the 01 draft version:

1. Clarify how RTT samples are captured (1323 or some other filter).

2. Clarify definition of baseRTT. (noted by 2 reviewers)

3. Clarify definition of "round" in dwnd update (is it in terms of RTT or cwnd
   worth of packets).

4. What happens to dwnd during slow-start, and when is slow-start
   exited?

5. Clarify dwnd update parameters and specific values or ranges that are safe
   for use (alpha, beta, eta, k) (noted by 3 reviewers)

6. Be precise about clipping dwnd so that it cannot become negative

Public reviews from:
Wesley Eddy (Nov 1, 2007)
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000358.html
Mark Allman (Nov 29, 2007)
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000378.html
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000379.html
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000380.html
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000381.html
Doug Leith (Jan 16, 2008)
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-January/000402.html

Additionally, several thread comments from:
Lachlan Andrew
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000416.html
Michael Welzl
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000411.html
Dino-Martin Lopez-Pacheco
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000415.html

Slides showing design and behavior:
  http://research.microsoft.com/users/dthaler/IETF%20-%20Compound%20TCP.pdf
INFOCOM 2006 paper:
  http://research.microsoft.com/users/dthaler/ctcp-infocom06.pdf
Evaluation by Doug Leith, Lachlan Andrew, Tom Quetchenbach, Bob Shorten,
 and Kfir Lavi, based on independent implementation:
  http://www.hep.man.ac.uk/PFLDnet2008/paper/Leith_DJ_Experimental%20Final.pdf
  http://www.welzl.at/iccrg-mar08-slides/iccrg_compound_mar08.ppt.pdf
Evaluation by SLAC (Yee-Ting Li):
  http://www.slac.stanford.edu/pubs/slactns/tn04/slac-tn-06-005.pdf
Behavior on under-buffered links:
  http://www.hep.man.ac.uk/PFLDnet2008/paper/Kun_T%20Final.pdf
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-March/000441.html