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

Anoop Ghanwani <anoop@alumni.duke.edu> Wed, 13 November 2013 22:43 UTC

Return-Path: <ghanwani@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 5E5AB21F918F for <aqm@ietfa.amsl.com>; Wed, 13 Nov 2013 14:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.588
X-Spam-Level:
X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ZIDU8tklVEGz for <aqm@ietfa.amsl.com>; Wed, 13 Nov 2013 14:43:50 -0800 (PST)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5576321F99FD for <aqm@ietf.org>; Wed, 13 Nov 2013 14:43:49 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id q58so1114799wes.28 for <aqm@ietf.org>; Wed, 13 Nov 2013 14:43:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8twhVkVtHo14yHV5Qf5t9er3iqgriTCSD5dBm8OFyvk=; b=nPRHQKRYTfn/No9lXzSRkzYUfjl9JciwwVE6IH5wiw7YagM4nLLZLzLS7TKxMg7Wg7 srGRD1zSiqBV5OaX9SBMH/AHpjw0o4XI39CGBV5YYjd9NPi5TNdEbNlL+jEH870SNqd4 WI6oVbz9uylTJKVJpaIwSihRa+f2n8pkZttFqpxs7ImMXBtZW6Imjlp49yGO+j4vhTDG q/ZD2tQu2UG3oblNrYbQw4Hxx36yNvIsQ2cQGiVrUXprA7/IhJyP4tQx8oUaNPVAv0s1 8ShqMQqWNfR71zAtkyvZf+/UuqFMFcw+lv8FicM4nDrsyu6xNjfhsfxV8DwrRwr9NPp+ FTTg==
MIME-Version: 1.0
X-Received: by 10.180.72.238 with SMTP id g14mr22340020wiv.17.1384382628494; Wed, 13 Nov 2013 14:43:48 -0800 (PST)
Sender: ghanwani@gmail.com
Received: by 10.217.57.131 with HTTP; Wed, 13 Nov 2013 14:43:48 -0800 (PST)
In-Reply-To: <CAEjQQ5XrRX=hTP9csoRJ04cK_6MAaMWA9o1Cwwqbm3RHRdBxpw@mail.gmail.com>
References: <CAEjQQ5Vif73gWe-35nzbhmPH+Eh+gSZK+7xNm33+T-FVNsmPZw@mail.gmail.com> <CEA9034B.4B37C%prenatar@cisco.com> <CAEjQQ5XrRX=hTP9csoRJ04cK_6MAaMWA9o1Cwwqbm3RHRdBxpw@mail.gmail.com>
Date: Wed, 13 Nov 2013 14:43:48 -0800
X-Google-Sender-Auth: lypaUluzjse04EnogqoHHVukfu8
Message-ID: <CA+-tSzyKT9gS_12V=yyia8iPt9FiDg6=NRKrB3FLdCRDTi=6Pg@mail.gmail.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
To: Naeem Khademi <naeem.khademi@gmail.com>
Content-Type: multipart/alternative; boundary="f46d043d6737ce066d04eb16b29d"
Cc: Michael Welzl <michawe@ifi.uio.no>, "aqm@ietf.org" <aqm@ietf.org>, Preethi Natarajan <preethi.cis@gmail.com>
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: Wed, 13 Nov 2013 22:43:51 -0000

On Wed, Nov 13, 2013 at 12:14 PM, Naeem Khademi <naeem.khademi@gmail.com>wrote:

>
> Agreed only in general terms -- but what would be considered as "packet
> burst" and how would it be defined? This will probably have a subjective
> answer e.g. one can argue that a size of TCP sawtooth of data is a burst
> and therefore we need a BDP of buffering for that (that's what had actually
> happened implicitly over the past decade). On the other hand, the
> definition of the "burst" may likely to correspond to the application
> generating it (e.g. video frames, IW10, etc) and therefore its size (and
> even pattern) is application/transport dependent somehow.
>

There's one more case...the incast problem.  The sources themselves may not
be "bursty" but in a high port count switch, you could have 10's (or more)
ports sending traffic to a single output port at around the same time.

Perhaps it is useful to add a description of what we mean when we say
bursty.

Anoop

Anoop