Re: [Bloat] AQM and PPP on Linux

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

On 28/07/15 15:49, Eric Dumazet wrote:
> On Tue, 2015-07-28 at 07:31 -0700, Simon Barber wrote:
>> The issue is that Codel tries to keep the delay low, and will start
>> dropping when sojourn time grows above 5ms for 100ms. For longer RTT links
>> more delay is necessary to avoid underutilizing the link. This is due to
>> the multiplicative decrease - it's worst with Reno, where the halving of
>> cWind means that you need to have a full BDP of data in the buffer to avoid
>> the link going idle when cWind is halved. With longer RTTs this means more
>> delay than Codel allows is required to avoid a throughput hit. The worst
>> case happens when a single flow is controlled, but that can be a common
>> situation. My proposal is to sense and have the target value in Codel
>> automatically adjust when this worst case scenario happens - which would
>> mitigate most of the downside.
> As I said, I've never seen what you describe.
>
> 100ms value is not a go/nogo threshold. It is a hint, based on real
> world values. We are speaking of 100 ms sojourn time in the CoDel queue,
> not sojourn time in the Internet !
>
> You can still have flows with 500 ms or even 10 sec rtt and codel just
> works fine.
>
> Are you sure you understood how this was working ?
>

The codel paper indicates utilization dropoff as RTT increases above the 
'interval' (and that interval is set based on expected rtt). They 
presented an average of several loads, so this wasn't even the 
single-stream worst case.

200ms rtt was fine, 500ms was a slightly worse & varied a lot more.

If you wanted something that was "fine" at 10s (ow), you wouldn't want 
codel's defaults.  Tuning higher values in fq_codel would probably be 
enough though.

http://queue.acm.org/detail.cfm?id=2209336