[Iccrg] ctcp review: safety (1 of 4)

[Murari Sridharan]

I see 3 key asks based on reading the mails, Lachlan has been stressing on some of these as well.

1. The draft is missing standards language (SHOULD, MUST etc)
2. The exact parameters used must be clearly documented as this can skew the fairness/safety implications of the algorithm if arbitrary values are chosen.
3. A better documentation of experiments run, possibly a summary
-----Original Message-----
From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of Mark Allman
Sent: Thursday, November 29, 2007 10:13 AM
To: iccrg at cs.ucl.ac.uk
Subject: [Iccrg] ctcp review: safety (1 of 4)


[[ I am sending four notes to the ICCRG list about the C-TCP document
   that I agree to review.  I am just dividing things up along the lines
   of my major points instead of constructing one massive email.  Some
   of these issues are perhaps not germane within the context of the
   RG.  But, the line between what the RG cares about and what the TCPM
   WG cares about are blurry enough in my head that I am sending all my
   comments here for the moment.  If useful, I will repeat them within
   TCPM.

   Also, let me note that this review is from me as an individual and
   does not in any way represent any feelings as TCPM co-chair. ]]


It seems the central question for the RG (if I understand correctly) has to do with the safety of the proposal.  The statement in the draft says:

  Compound TCP has been implemented as an optional component in
  Microsoft Windows Vista. It has been tested and experimented through
  broad Windows Vista beta deployments where it has been verified to
  meet its objectives without causing any adverse impact. The Stanford
  Linear Accelerator Center (SLAC) has also evaluated Compound TCP on
  production links. Based on testing and evaluation done so far, we
  believe Compound TCP is safe to deploy on the current Internet. We
  welcome additional analysis, testing and evaluation of Compound TCP by
  Internet community at large and continue to do additional testing
  ourselves.

I am of a mixed mind as to whether I buy this statement.

  + Just looking at the math in the document I am inclined to buy that
    the scheme is pretty safe.  I like the diff_reno notion as using
    what a Reno connection might plausibly attain as an input into the
    scheme.

  + But, the document gives no sense of the experiments that actually
    show this works out in practice.  I don't think this needs to be a
    research paper that goes into fine-grained details, but the draft
    tries to say "we have good results" without even trying to summarize
    or distill the high-order bits from these results.

    There are references to research papers that give these results.  In
    a later note I will have more to say about these.

So, for safety sake, I sort of buy the analytical stuff and don't buy the experimental stuff.  Since I am muddled and tend to believe reality before math I guess if I had to pick I'd vote that I do not buy the statement above.  That is, I'd rather see a statement that said CTCP was not ready for prime-time, but needs more experimentation before we can make that assessment.

allman