[Iccrg] Re: ADPM & incremental deployment

[Bob Briscoe]

Lachlan,

I've cc'd iccrg in case anyone else can shed more light.

For those newly joining this thread on the iccrg list, ADPM = 
Adaptive Deterministic Packet Marking. See Lachlan's publications 
page for background papers. E.g. 
<http://netlab.caltech.edu/~lachlan/abstract/ADPM_CL.pdf>

responses inline...

At 23:58 02/11/2008, Lachlan Andrew wrote:
>Greetings Bob,
>
>[LA]: I agree that incremental deployment is challenging.  It is safe to
>deploy incrementally in routers, but care has to be taken in using the
>additional information to make algorithms more aggressive.  Below are
>some preliminary thoughts on possible solutions.  Should we shift this
>discussion to ICCRG for extra feedback?
>
>2008/11/3 Bob Briscoe <rbriscoe at jungle.bt.co.uk>:
>BB>
> > My question is: can a transport only react more quickly to richer 
> congestion
> > signalling if it knows that /all/ queues on the path support richer
> > signalling?
>
>[LA]: It can certainly react *down* without knowing that all queues support
>the signalling, which enables it to maintain short queues, without the
>throughput penalty imposed by halving the window on ECN marks.
>
>Unfortunately I don't know how to "safely" increase faster if some
>queues don't support it.  It is even hard to detect that quickly,
>since the packets are passed transparently by those routers.  One
>possibility would be to say "if we get an ECN mark when the ADPM
>signal is small, assume there is a non-ADPM router and ignore future
>ADPM signals".  That would allow it to be detected on long flows, but
>not necessarily on short ones.
>
>BB>
> > Let's say ADPM uses changed semantics of the ECN 01 codepoint. 
> Setting aside
> > any disputes over who gets to use this codepoint first :) what benefit do
> > you get if some queues on a path support ADPM while others only support
> > standard ECN (I'm optimistically assuming none support neither)?
> >
> > Let's say one ECN queue is marking packets with an inter-mark spacing
> > averaging  1000 packets, while one ADPM queue is giving a signal of 0.01%
> > congestion. And no other queues on the path are congested. If there's a
> > transient drop in the congestion signal from the ADPM queue, should the
> > transport react to it by quickly increasing its rate?
> >
> > Surely the transport still cannot increase its response time in case it
> > overflows the ECN queue, because it is still getting a low information rate
> > from the ECN queue.
>
>[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?

>BB>
> > Similarly, if a flow knew all queues supported ADPM it would be 
> able to do a
> > faster start. But 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)?

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


>[LA]: I know that these arguments are full of holes, but it would be
>interesting to see if they can be patched.

[BB]: Yes. But flow start theory is already thin on the ground.

Cheers


Bob


>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

____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196