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

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 18 November 2013 05:55 UTC

Return-Path: <swmike@swm.pp.se>
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 3DB7711E839A for <aqm@ietfa.amsl.com>; Sun, 17 Nov 2013 21:55:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level:
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, 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 WImF1e4MFqp1 for <aqm@ietfa.amsl.com>; Sun, 17 Nov 2013 21:55:54 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E1C7E11E80EC for <aqm@ietf.org>; Sun, 17 Nov 2013 21:55:53 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8197FA1; Mon, 18 Nov 2013 06:55:49 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 75EA59A; Mon, 18 Nov 2013 06:55:49 +0100 (CET)
Date: Mon, 18 Nov 2013 06:55:49 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Anoop Ghanwani <anoop@alumni.duke.edu>
In-Reply-To: <CA+-tSzz+KR2OSLHF4ovAh2FycfQ-1duX=1LFPrB4y1A9gMPDsA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1311180653430.5805@uplift.swm.pp.se>
References: <CAEjQQ5WpeB0L7pN3joh233QgvNV2VMkN2U9BPCwFmBYjoVCrAQ@mail.gmail.com> <CEAAB727.4B5D1%prenatar@cisco.com> <CA+-tSzz+KR2OSLHF4ovAh2FycfQ-1duX=1LFPrB4y1A9gMPDsA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: "aqm@ietf.org" <aqm@ietf.org>
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: Mon, 18 Nov 2013 05:55:58 -0000

On Sun, 17 Nov 2013, Anoop Ghanwani wrote:

> This should give you an idea of the kind of buffering that is actually 
> available.  As port-counts go up, the amount of buffering per port goes 
> down. http://people.ucsc.edu/~warner/buffer.html

Not only that, but some switches actually have shared buffer space for 
some or all ports, so if one port is congested, you can get immediate 
drops on other ports because of lack of buffer space.

> For the simulations to be relevant for such switches, they would have to 
> be done with significantly smaller buffer sizes.  The sizing gets even 
> worse when we consider there may be multiple priorities and some of 
> those may be lossless (requiring dedicated buffers be set aside for 
> them).

For instance, I have a switch at home with 24 gig ports that have 128 
kilobytes of memory total, shared for the entire switch for all ports. 
It's a really cheap one, but still meant for enterprise deployment.

How would we model something like that?

Guess it won't add much to bufferbloat so perhaps moot discussion :)

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se