Re: [aqm] AQM schemes: Queue length vs. delay based

Naeem Khademi <naeem.khademi@gmail.com> Thu, 14 November 2013 15:43 UTC

Return-Path: <naeem.khademi@gmail.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BEF21F979E for <aqm@ietfa.amsl.com>; Thu, 14 Nov 2013 07:43:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.296
X-Spam-Level:
X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts3LQYpOSHhh for <aqm@ietfa.amsl.com>; Thu, 14 Nov 2013 07:43:51 -0800 (PST)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA4811E8141 for <aqm@ietf.org>; Thu, 14 Nov 2013 07:43:41 -0800 (PST)
Received: by mail-vc0-f169.google.com with SMTP id hu8so838399vcb.0 for <aqm@ietf.org>; Thu, 14 Nov 2013 07:43:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CPA5fEZvhD2L2DIir1vM98MW/c5VPtPo3iWm8AifzX0=; b=BrllpFI1DocRWP39IAfORFx53N5XDOJNkw+0J0S19HiyKPJtxrZRm2tV93gKzgqT3d rIW2635vgSApEt+Va/UzNr7flnzBNphjzosMqKNc8HPCEetzcj+Vp49DBdtdQTY2uzx8 t2+cA62lq34o5iUyH4dXWpbwDCmvHkBqLi9i2GJr4T7bQvO0l02tAyiFmaBMKqxS8Z8k lb61gqMObzGCWHkbDLwFFApij/JiXCTr6rh/u1bpqXPOtwPuhbmuvlxHAA0VoNtVsPSj /rkcnYQoKcoPTtbTdBlBB6qQpgRzOkXw/ngQjtkuSXNjdW/GJkScdZ0Ue951uEhV0d5O +v/Q==
MIME-Version: 1.0
X-Received: by 10.52.122.15 with SMTP id lo15mr44658vdb.115.1384443820731; Thu, 14 Nov 2013 07:43:40 -0800 (PST)
Received: by 10.220.109.5 with HTTP; Thu, 14 Nov 2013 07:43:40 -0800 (PST)
In-Reply-To: <CAEjQQ5VhMfgik_QS2GxWRbMDJQf7VXEC3-e_LP0tx5P16pC9PQ@mail.gmail.com>
References: <CAEjQQ5XrRX=hTP9csoRJ04cK_6MAaMWA9o1Cwwqbm3RHRdBxpw@mail.gmail.com> <CEA961B1.4B416%prenatar@cisco.com> <CAEjQQ5VhMfgik_QS2GxWRbMDJQf7VXEC3-e_LP0tx5P16pC9PQ@mail.gmail.com>
Date: Thu, 14 Nov 2013 16:43:40 +0100
Message-ID: <CAEjQQ5We5HHbePXTu4GfenM+UwcdpundVF30Zg9TCD+H7jXMCg@mail.gmail.com>
From: Naeem Khademi <naeem.khademi@gmail.com>
To: Preethi Natarajan <preethi.cis@gmail.com>
Content-Type: multipart/alternative; boundary="089e013a13302575e504eb24f233"
Cc: "aqm@ietf.org" <aqm@ietf.org>, Michael Welzl <michawe@ifi.uio.no>
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 14 Nov 2013 15:43:52 -0000

> Delay-based ARED behaves similar to tail drop at max threshold.
>>
>
I think I now understand what you mean by this sentence ;-) and therefore
please ignore the paragraph responding to this specific point in the
previous email (sorry about that, I got it mixed with max_target). Indeed
ARED drops every packet when the average queue length grows beyond th_max
as drop probability jumps to 1 (when it's not in gentle mode). For this to
happen, the "average queue length" has to grow beyond th_max and depending
on how the averaging is done, that can correspond to certain burst
allowance at AQM. Moreover, this is done over 500 ms interval which means
the average queue length has to stay above th_max for mostly few rounds of
RTTs (assuming the typical distribution of RTTs on the Internet to have a
mean/average somewhere below that value e.g. 100~200 ms). This allows burst
that don't take the average queue size to above th_max over 500 ms period
to pass and clear themselves up the queue.

 > This is unacceptable of an AQM even for max thresholds around 50ms.

 Whether this is a good thing or bad thing is a subjective matter in my
opinion, as most AQMs at some point will drop every packet whether it be
the maximum queue length or at some thresholds.

Cheers,
Naeem