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

[Murari Sridharan]

Due to internal deadlines I am pretty slow in catching up, in fact my rebuttal mail to mark including a summary of experiments is still in progress. In any case we did do a number of tests for both random losses *and* congestion both represent very useful data points. Random losses represents the showcase for all high-speed congestion control algorithms since it clearly makes the case for the need for such algorithms and how TCP fails. Having said that I agree that congestion due to queue build up is very essential to test delay based algorithms (although as Lachlan notes below the effect it has varies depending on the specific delay controller). If you look at our gamma auto-tuning paper there are a number of such experiments.

Thanks

-----Original Message-----
From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of Mark Allman
Sent: Tuesday, December 04, 2007 3:23 PM
To: Lachlan Andrew
Cc: iccrg at cs.ucl.ac.uk
Subject: Re: [Iccrg] ctcp review: big picture issues (3 of 4)


> I think that the "experiments with only random loss" are incomplete
> rather than inappropriate in themselves.

Well, fair enough.  I should have been more careful.  If these were a first set of experiments and there were others then OK.  Perhaps I should have said that my opinion is that such experiments are "not sufficient" and should not have said "inappropriate".

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

OK, but if these tests are designed to show that there is no problem when there is no congestion then I can't make a determination of whether I think a **congestion control** scheme is "safe" or not.  If you don't test a congestion controller in the presence of congestion then it is a non-starter in my book.  Maybe I am weird.

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

I am not sure what the RG's job is in general.  With regards to reviewing this for TCPM the job of the RG is, as far as I understand it, to evaluate the safety statement in the document.  In this document that statement does not say it is safe enough to play with, it says it "is safe to deploy on the current Internet".

I would like to think that the RG provides more than simply this review for TCPM and that in fact other technical comments about proposed CC schemes would be in bounds.

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

Perhaps you're right.  I am not sure I feel like I understand it well enough to weigh in on that.  But, certainly if this is the case it'd be nice to see.

I still beleve my high-order bit, however.  If you have no contention in the network (or, at least little and an unassessed amount) and yet are relying on that contention (in terms of queue buildup) as part of the controller then how can that be an effective evaluation?

allman