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

saverio.mascolo@gmail.com (Saverio Mascolo) Wed, 17 December 2008 22:00 UTC

From: saverio.mascolo@gmail.com
Date: Wed, 17 Dec 2008 22:00:17 +0000
Subject: [Iccrg] ICCRG review of draft-sridharan-tcpm-ctcp-02
In-Reply-To: <B5A5E01F9387F4409E67604C0257C71E8AF7CC@NDJSEVS25A.ndc.nasa.gov>
References: <B5A5E01F9387F4409E67604C0257C71E8AF7CC@NDJSEVS25A.ndc.nasa.gov>
Message-ID: <b98e548c0812171413n6914f4e8oda3b7831711bcf37@mail.gmail.com>
X-Date: Wed Dec 17 22:00:17 2008

did someone measure goodput and retransmissions? TCPs using a more
aggressive probing than VJ TCP usually seem to end up - in  good
cases- with similar goodput but at the expense of larger packet
retransmissions, which is not good!
-saverio

On Wed, Dec 17, 2008 at 10:45 PM, Eddy, Wesley M. (GRC-RCN0)[VZ]
<Wesley.M.Eddy@nasa.gov> wrote:
> 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 mailing list
> Iccrg@cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>



-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4
70125 Bari
Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:mascolo@poliba.it

http://www-dee.poliba.it/dee-web/Personale/mascolo.html


=================================
 This message may contain confidential and/or legally privileged information.
  If you are not the intended recipient of the message, please destroy it.
 Any unauthorized dissemination, distribution, or copying of the material in
 this message, and any attachments to the message, is strictly forbidden.