[Iccrg] ICCRG review of draft-sridharan-tcpm-ctcp-02
Wesley.M.Eddy@nasa.gov (Eddy, Wesley M. (GRC-RCN0)[VZ]) Wed, 17 December 2008 21:33 UTC
From: Wesley.M.Eddy@nasa.gov
Date: Wed, 17 Dec 2008 21:33:03 +0000
Subject: [Iccrg] ICCRG review of draft-sridharan-tcpm-ctcp-02
Message-ID: <B5A5E01F9387F4409E67604C0257C71E8AF7CC@NDJSEVS25A.ndc.nasa.gov>
X-Date: Wed Dec 17 21:33:03 2008
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: (216) 433-6682 --------------------------- 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
- [Iccrg] ICCRG review of draft-sridharan-tcpm-ctcp… Lachlan Andrew
- [Iccrg] ICCRG review of draft-sridharan-tcpm-ctcp… Saverio Mascolo
- [Iccrg] ICCRG review of draft-sridharan-tcpm-ctcp… Eddy, Wesley M. GRC-RCN0[VZ]