[Iccrg] Re: ADPM & incremental deployment

[Bob Briscoe]

Lachlan,

At 05:14 03/11/2008, Lachlan Andrew wrote:
>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?
>
>[LA]: 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]: There is a difference.

The Internet has always had a long-tailed distribution of flow sizes. 
This limits the number of flows doing slow start at any one time 
relative to the total traffic. That could be the only reason slow 
start has been safe enough over the years.

If flows started to slow start from the window they had already 
achieved in congestion avoidance - just because the last packet did 
not show evidence of a congestion event - surely that could severely 
upset this balance.


> >> 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)?
>
>[LA]: 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.
>
>[LA]: 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?

[BB]: Re-ECN isn't a congestion control technique. It's a policing technique.

There is an ability to distinguish packets sent without the benefit 
of congestion feedback (the feedback not established or FNE 
codepoint, which draws down the sender's congestion quota if it is 
used). This dampens the total no of flows doing a fast increase by 
turning the risk back on them. If they don't use the FNE codepoint, 
any queues that get in trouble can (optionally) preferentially drop 
packets not using FNE. This ensures there is no advantage to not using FNE.

So I believe re-ECN creates the right incentive framework to turn the 
risks of the behaviours you're describing back on those gaining from 
the risk. But there's no magic to solve this problem directly.

[BB]: The VCP-like idea of a lower virtual threshold would help.

We're writing the stds track pre-congestion notification marking I-D 
so it could be called in as a building block for any cc scheme 
needing AQM based on a virtual queue. It's primarily written for 
PCN's admission control scenario, but the history of IETF RFCs shows 
they often end up being popular in unexpected ways. 
<http://tools.ietf.org/wg/pcn/draft-ietf-pcn-marking-behaviour/>


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
>
>_______________________________________________
>Iccrg mailing list
>Iccrg at cs.ucl.ac.uk
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

____________________________________________________________________________
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