[Iccrg] ctcp review: big picture issues (3 of 4)

[Mark Allman]

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

Several big picture sort of things about the document ...

  - The document isn't written using standards language (e.g., MUST,
    SHOULD, etc.).  This causes me some heartburn in the particular case
    of parameter setting.  MUST we set the parameters as you suggest?
    Or, is this guidance?  Or, is it merely an illustration?

  - The response function has a bunch of knobs.  But, there is really no
    guidance on turning those knobs.  Some of the results in the papers
    referenced do deal with turning those knobs.  But, it seems to me
    that this is such a key facet of an implementation that the draft
    needs to help an implementer understand how sensitive those knobs
    are.  This pertains to the last point.  If the document intends for
    these to be constants and not knobs (i.e., MUSTs) then this concern
    at least diminishes quite a bit, if not going away.  But, if these
    are not supposed to be hard-and-fast then the document really needs
    to help an implementer understand the impact of various tunings.

  - As I said in another note, a summary of the experiments would be
    useful.

    But, beyond this, I skimmed through the infocom and pfldnet papers
    (the latter which I read in detail some time back) and I have a
    pretty big problem with the experiments.  The problem is when the
    network is setup with dummynet to induce random losses with some
    probability then these schemes run in a network that does not
    include congestion.  And, I don't understand how *congestion
    control* can be effectively evaluated in the absence of
    *congestion*.  So, 

      + Loss != congestion.  Enough congestion causes loss, for sure.
        But, loss can happen for all sorts of reasons.  And, congestion
        causes more than loss (e.g., increased queue sizes and delays).

      + It somehow seems non-sensical to not have actual congestion with
        actual queue build-up when assessing delay-based congestion
        control.  I am not saying that there was none in the
        experiments, but we are at least led to believe that the queue
        was able to absorb all the congestion.  If that is the case then
        the contention wasn't really all that great.

    For me, all this adds up to being pretty skeptical of the overall
    results that show CTCP to be "better".  

    For sure, CTCP performs better in this environment, but that is to
    be expected because it is more aggressive.  I don't feel like I have
    an accurate sense of the implications of this aggressiveness.

    Further, there is this paper that is perhaps preliminary and perhaps
    about old data, but that shows that congestion window size and delay
    are not correlated.  Every time I think about delay-based congestion
    control I think about this paper.  If there is no correlation in
    real networks (where this data is from) then how is this scheme
    going to work?

      Is the Round-trip Time Correlated with the Number of Packets in
      Flight?
      Saad Biaz, Auburn University
      Nitin H. Vaidya, University of Illinois at Urbana-Champaign 
      Internet Measurement Conference, 2003

allman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071129/399e2c50/attachment.bin