[Iccrg] ctcp review: big picture issues (3 of 4)
mallman at icir.org
Thu Nov 29 18:13:31 GMT 2007
[[ 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
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
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
+ 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
Saad Biaz, Auburn University
Nitin H. Vaidya, University of Illinois at Urbana-Champaign
Internet Measurement Conference, 2003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071129/399e2c50/attachment.bin
More information about the Iccrg