Re: [aqm] CoDel's control law that determines drop frequency

Bob Briscoe <ietf@bobbriscoe.net> Thu, 01 October 2015 13:06 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3197C1B2C95 for <aqm@ietfa.amsl.com>; Thu, 1 Oct 2015 06:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXTmYG872mqP for <aqm@ietfa.amsl.com>; Thu, 1 Oct 2015 06:06:45 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F111ACD19 for <aqm@ietf.org>; Thu, 1 Oct 2015 06:06:45 -0700 (PDT)
Received: from 8.37.199.146.dyn.plus.net ([146.199.37.8]:47191 helo=[192.168.0.16]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <ietf@bobbriscoe.net>) id 1ZhdZK-0004CV-Js; Thu, 01 Oct 2015 14:06:42 +0100
To: Polina Goltsman <polina.goltsman@student.kit.edu>
References: <201311122230.rACMUBmH003536@bagheera.jungle.bt.co.uk> <87wpzfpbd3.fsf@alrua-karlstad.karlstad.toke.dk> <56045CA8.2060103@bobbriscoe.net> <CAPRuP3mmg_-uxmtLUXprCmPyLSUuUA7t2dRZpDs_mwtnTgrSQA@mail.gmail.com> <560BA261.6020206@bobbriscoe.net> <560BA7B9.8020800@student.kit.edu> <560BDCC1.8070106@bobbriscoe.net> <560C033C.50306@student.kit.edu>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <560D2FE2.2040609@bobbriscoe.net>
Date: Thu, 1 Oct 2015 14:06:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <560C033C.50306@student.kit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/84RGWYRo1K1S2Hz465qZzW_ifsc>
Cc: AQM IETF list <aqm@ietf.org>
Subject: Re: [aqm] CoDel's control law that determines drop frequency
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 13:06:47 -0000

Polina,

I've answered your points but changed their order...

On 30/09/15 16:43, Polina Goltsman wrote:
> Bob,
>
> If I understand Codel's law correctly, Codel "starts fresh" every time 
> it enters dropping state, so when the load increases it will take more 
> time for the control law to reach the correct "count" value for the 
> queue to drop. Thus with higher load latency is increased.
As Jeff has said, Codel has been modified to not start count fresh every 
time it enters dropping state.

My point was that no-one has questioned the control law itself, once in 
dropping state. All the activity seems to have been around avoiding 
having to start increasing count from fresh. However, the rate that the 
control law increases count is completely disconnected from how bad the 
queue is getting. Any good control system should make the strength of 
the correction depend on how far the performance metric (queue delay) is 
from its target.
>
> BTW, I haven't seen any place in the original specification that 
> suggested that fixed target delay is the intended design goal.

'target' is the fixed delay target. The whole point of CoDel is to 
detect when queue delay exceeds this target for more than interval, then 
bring it back to this target by dropping packets.

>
> Now, if I understood your curvey red report correctly, you argued that 
> AQM should increase latency when load increases since otherwise it 
> will cause too much loss. Which makes Codel's behavior at least 
> justified ...
No. At higher load CoDel's control law behaviour does not aim for a 
higher target delay. It still aims for 'target'. In this thread so far, 
we have been talking about sluggish dynamic behaviour in reaching the 
target, not the target itself.

Just because a journey to the wrong place happens to go through the 
right place, doesn't justify wandering slowly on the way to the wrong 
place. Admittedly, you will be near the right place for a little longer, 
but you'll also be in all the wrong places for longer, and once you 
reach your destination, you will stay in the wrong place.

> May I ask how curvy red is supposed to perform in those situations?
>
Like CoDel, Curvy RED has a) a target and b) a process for getting there.

a) Unlike CoDel, the target delay is not fixed, it increases a little 
with load. As you say, this avoids having to introduce too much loss. 
The precise compromise between the two depends on how strongly each of 
loss and delay affect the performance of typical applications - there is 
not one answer to that, but I'm working on finding a reasonable compromise.

b) Like any good AQM, Curvy RED doesn't jump straight to its target. We 
have introduced some smoothing delay so it doesn't start dropping 
packets too quickly when hit by a burst that might disappear. Initially 
we just used the same approach as RED - using an exponentially weighted 
moving average of the queue. It works OK. We could probably improve on 
this smoothing. But, as long as Curvy RED isn't significantly worse than 
other AQMs, my main focus is the L4S side of the DualQ AQM that Koen 
presented. I'm happy for others to improve on Curvy RED for existing TCP 
traffic if they want - I won't get round to that for a while.

CoDel's (fixed) interval addresses this burst-smoothing problem, and 
CoDel's (fixed) control law adds to its smoothing delay. It's unclear to 
me why CoDel uses this control law to find the right level of drop. 
Hence my question to Kathy & Van back in 2013 that started this thread 
and still hasn't been answered.

Cheers


Bob

> Does this make any sense?
>
> Regards,
> Polina
>
> On 09/30/2015 02:59 PM, Bob Briscoe wrote:
>> Polina,
>>
>> I think this was it:
>> <https://www.ietf.org/proceedings/85/slides/slides-85-iccrg-2.pdf>
>>
>> I have a set of charts from Rong with many more tests showing CoDel's 
>> sluggish responsiveness, but I believe the above was the published 
>> summary.
>>
>>
>> Bob
>>
>> On 30/09/15 10:13, Polina Goltsman wrote:
>>> Dear Bob,
>>>
>>> On 09/30/2015 10:50 AM, Bob Briscoe wrote:
>>>>
>>>> Early on, Rong Pan showed that it takes CoDel ages to bring high 
>>>> load under control. I think this linear increase is the reason.
>>>
>>> Is there a link to this ?
>>>
>>> Polina
>>>
>>> _______________________________________________
>>> aqm mailing list
>>> aqm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/aqm
>>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/