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

Anoop Ghanwani <anoop@alumni.duke.edu> Sun, 17 November 2013 18:54 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 B0AFD11E90AA for <aqm@ietfa.amsl.com>; Sun, 17 Nov 2013 10:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[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 4lnZHfkbSrV9 for <aqm@ietfa.amsl.com>; Sun, 17 Nov 2013 10:54:00 -0800 (PST)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6094611E90A9 for <aqm@ietf.org>; Sun, 17 Nov 2013 10:53:58 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id k14so5387542wgh.35 for <aqm@ietf.org>; Sun, 17 Nov 2013 10:53:57 -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=/xUpevsSy/fLukR/0M1nrdEsETD7PF4EZcHDEqT2lOM=; b=kdZJ3v4vQS3Ps9gnen/OA6EXvpGCh5VMWu7DbZrAN9vRfDeI8sz0NgFjfQj+Ok3Tvl qd2NhmSEyr02t/BcIkNWQbAruK2hu4G/kXpoDgiJkI/QvBN0zVHz+9JiEsV9HUkdfnAp LV0KRVkxdL5LCWGd1H+d0ulF7jjYuUUOMKoC1LPKntAE+yhlbflhD10p/+WUgM79Xsn/ 4etPzK8L7OdQ53TFI+OE8b6srjYrikDFhC09+MmPJyeafhaq1THArfHhcBd0hE3ihIzu EnzeLLyr5NHeVuVe68N+vOTzshqI0RYyYpJUZ3hbLoLgCKM9sdKhSPxUK+teit7CQZ+U iHIg==
MIME-Version: 1.0
X-Received: by 10.195.13.45 with SMTP id ev13mr13766932wjd.20.1384714437502; Sun, 17 Nov 2013 10:53:57 -0800 (PST)
Sender: ghanwani@gmail.com
Received: by 10.217.57.131 with HTTP; Sun, 17 Nov 2013 10:53:57 -0800 (PST)
In-Reply-To: <CEAAB727.4B5D1%prenatar@cisco.com>
References: <CAEjQQ5WpeB0L7pN3joh233QgvNV2VMkN2U9BPCwFmBYjoVCrAQ@mail.gmail.com> <CEAAB727.4B5D1%prenatar@cisco.com>
Date: Sun, 17 Nov 2013 10:53:57 -0800
X-Google-Sender-Auth: GqyYZY2u1kRxXkSGrUDYeFr61HI
Message-ID: <CA+-tSzz+KR2OSLHF4ovAh2FycfQ-1duX=1LFPrB4y1A9gMPDsA@mail.gmail.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
To: Preethi Natarajan <preethi.cis@gmail.com>
Content-Type: multipart/alternative; boundary="047d7bfced1e29b27004eb63f4db"
Cc: "aqm@ietf.org" <aqm@ietf.org>, Naeem Khademi <naeem.khademi@gmail.com>, Michael Welzl <michawe@ifi.uio.no>, curtis <curtis@ipv6.occnc.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: Sun, 17 Nov 2013 18:54:00 -0000

On Thu, Nov 14, 2013 at 5:33 PM, Preethi Natarajan <preethi.cis@gmail.com>wrote:
>
>
> Just pointing out the evidence here --
> http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-5.pdf
>
> The slides contain preliminary results from DC scenarios, showing PIE's
> parameters and adaptability to DC scenarios. Thank god for the IETF
> archives :)
>
> Hi Preethi,

In these simulations what was the buffer size used?  From my read, it looks
like the setup had ~400 KB per port before any marking/discarding would
take place.  This is significantly more than what is available in
top-of-the-rack switches used in many data centers.

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

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).

Anoop