[tcpm] ICCRG review of draft-sridharan-tcpm-ctcp-02

["Eddy, Wesley M. (GRC-RCN0)[VZ]" <[e-mail]>]

Some time ago the IRTF Internet Congestion Control Research Group
(ICCRG)
was asked for its position on the safety of the Compound TCP behaviors
described in draft-sridharan-tcpm-ctcp for Experimental deployment on
the Internet.  This is part of the process described here:
http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt

Below is the ICCRG review of the Compound TCP draft for input to TCPM.
The ICCRG process itself resulted in a couple of iterations of the draft
to clarify portions.  By my understanding, TCPM should now be using the
review, the updated draft, and TCPM's own discussion and feedback loop
to
decide the fate of the CTCP document with the understanding that TCPM
has a general charter item allowing TCPM WG Experimental specification
of
ICCRG-reviewed congestion control proposals (according to the ION
above).

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: [phone]
---------------------------


ICCRG Compound TCP Safety Review
--------------------------------

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 (01) to the original (00)
internet-draft
was published.  Based on further RG comments, another update (02) was
published
and contains several further clarifications.

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 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.


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.pd
f
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

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm