[Iccrg] Re: ADPM & incremental deployment

[Lachlan Andrew]

Greetings Bob,

2008/11/3 Bob Briscoe <rbriscoe at jungle.bt.co.uk>:
> At 23:58 02/11/2008, Lachlan Andrew wrote:
>>
>> [LA]: True.  As long as it doesn't react faster than doubling its window
>> each RTT, then it is no more aggressive than slow-start.  If this
>> causes an ECN loss when ADPM says the congestion is low, then we can
>> disable ADPM, and so we only get one "slow-start" loss per flow, as
>> standard TCP does.
>
> [BB]: Surely, from the ECN queue's viewpoint, it is much more aggressive
> than slow start to double your window if you start from a rate you have
> established in congestion avoidance! Or is this not what you meant?

That is what I meant.  Under slow start (whether starting from idle or
from the link capacity), a flow will end up sending at twice the
"correct" rate for one RTT.  I don't see a fundamental difference
between doing that after a prior few rounds of doubling versus doing
it after a period of slow growth.  I see the "aggressiveness" of slow
start is all in the last RTT, in which it starts at the "correct"
rate.

That argument is simple in the case of an isolated flow (where the
"correct" rate is simply link capacity).  It is obviously complicated
by the presence of other flows, but I don't yet see any fatal flaws in
that case.


>> BB>
>> > if there might be non-ADPM queues on the path, surely
>> > it has to start as cautiously as it always has?
>>
>> [LA]: That is true if "as cautiously as it always has" is the right
>> default
>> behaviour.  People are proposing starting slow start faster anyway,
>
> [BB]: Are these proposals based on any theory (not that slow start is backed
> by any theory other than the 'it seems to work' theory)?

Nothing quantitative that I know of.  Dirceu, do you know?

>> [LA]: in
>> which case ADPM could be seen as an extra safety mechanism to be used
>> in conjunction with a faster default slow-start.
>
> [BB]: That would be a wrong way to look at it IMHO. Minimising harm in one
> queue is nothing to do with the harm you might cause in other queues that
> only support slower (binary) signalling mechanisms.

I agree that you wouldn't want to design a mechanism that   needed
ADPM as a safety mechanism.  However, if the new mechanism is found
not to cause   too   much harm without ADPM, then ADPM could reduce
the harm (say of overshoot) even further.

Still, I agree that it would be much better to find a way to use ADPM
if the bottleneck supports it and another mechanism otherwise.

Does Re-ECN have any techniques that may be able to be adapted to ADPM?

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +613 9214 4837