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

[Lachlan Andrew]

Greetings Mark,

I think that the "experiments with only random loss" are incomplete
rather than inappropriate in themselves.  If my interpretation is
correct, it should probably be made more explicit in the draft.

I assume that they are   modelling   the case in which current TCP
fails.  That is the case in which a long flow is repeatedly
interrupted by slow-start of short-lived connections, giving losses
which cause the window to be reduced, but not hanging around long
enough to give link utilization.  They're taking the short-cut of just
forcing the sporadic losses.  It is no more or less valid than
considering a "response function" which considers losses without
specifying where the come from.  These tests are also useful show that
the congestion control doesn't do as much harm when there is no
congestion as current TCP does.

I think they chose this scenario because it is the "worst case" --
where it is most aggressive.  They show that in this case, it is no
more aggressive than an existing experimental RFC.  In other cases it
is less aggressive.

To me, that is (a model of) one interesting scenario, although many
other scenarios should also be tested eventually.

Regarding the correlation between delay and congestion:
1. I didn't think our job way to say how often there will be a benefit
in real networks.  I thought our job was to say whether they're
"allowed" to do experiments in real networks to   find out   if there
is a significant benefit.
2. CTCP isn't as sensitive to the actual queue estimate as algorithms
like Vegas are.  Vegas sets its rate based on the estimated queue
size, while CTCP simply detects whether or not to be aggressive based
on whether or not it thinks the queue is empty.  For that, it isn't
clear that we need a correlation between our own number of packets in
flight and our precise observed queueing delay.  That means it will
only be aggressive (but no more than existing experimental RFCs) if it
has a   reason   to think the link is underutilized.  Imperfect as it
may be, this is a step in the right direction compared with the
existing RFCs.

$0.02,
Lachlan

On 29/11/2007, Mark Allman <mallman at icir.org> wrote:
>   - 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


-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan