Re: [aqm] PIE vs. RED

Jonathan Morton <chromatix99@gmail.com> Thu, 13 August 2015 17:36 UTC

Return-Path: <chromatix99@gmail.com>
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 6F0FA1A8ABA for <aqm@ietfa.amsl.com>; Thu, 13 Aug 2015 10:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.951
X-Spam-Level:
X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 KEMbutax6dnA for <aqm@ietfa.amsl.com>; Thu, 13 Aug 2015 10:36:00 -0700 (PDT)
Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5F41A88C2 for <aqm@ietf.org>; Thu, 13 Aug 2015 10:36:00 -0700 (PDT)
Received: by ykdt205 with SMTP id t205so47635028ykd.1 for <aqm@ietf.org>; Thu, 13 Aug 2015 10:35:59 -0700 (PDT)
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=F7pSHO9OCEqvEZfrwmArwsEjX/ea0lKqislFCjtRaCQ=; b=WM6YOm9jBYdCKYu51DKXa4ItQ70I6W2XBFPBdi4NOOV4Wynbm3YMjIF5eVfIZldTte xv4Q9qs5qv94blE0/eK8H2YmFLVsmdaAjlgiXTXSRcx81pAHjiQ4ntZNHeonfhH7ksWN aaa7gBusm4JOx+5uX5veSWsdaYAKtZbHYoBz8HfC9GApq9RPmkcePhf6qWfIZtCXr3lK a1W3YXjo4f0YcNfdjLsfhUEflk/WbKZahhWKzEhl750P9WUurqSzacqU6ZN4bZkzGO6b vr+hIk5JMk8AFCKp2DD/lo9UkCoNLkmgkflyFjR2DrpLdME7/5q4fdag8olLh1/ljv/a BAOw==
MIME-Version: 1.0
X-Received: by 10.170.176.87 with SMTP id s84mr41004230ykd.46.1439487359506; Thu, 13 Aug 2015 10:35:59 -0700 (PDT)
Received: by 10.37.214.203 with HTTP; Thu, 13 Aug 2015 10:35:59 -0700 (PDT)
Received: by 10.37.214.203 with HTTP; Thu, 13 Aug 2015 10:35:59 -0700 (PDT)
In-Reply-To: <55CC8D6B.7030007@kit.edu>
References: <55CC8D6B.7030007@kit.edu>
Date: Thu, 13 Aug 2015 20:35:59 +0300
Message-ID: <CAJq5cE2sNFvLPvrB82dRrN+nbZLNRuo+TmCVgSYCp4TumN70Sw@mail.gmail.com>
From: Jonathan Morton <chromatix99@gmail.com>
To: Roland Bless <roland.bless@kit.edu>
Content-Type: multipart/alternative; boundary="001a11393376b8e149051d34c4bf"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/tpwvkIrbaxvDggSAwzu00hrBwvU>
Cc: aqm@ietf.org
Subject: Re: [aqm] PIE vs. RED
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, 13 Aug 2015 17:36:01 -0000

In the real world, the hardware buffer size is rarely matched to the real
BDP.  There are several reasons for this, but a couple of fundamental ones
are:

- BDP varies with RTT, which is in general different for flows
simultaneously using the same link/queue to reach different remote hosts,
and therefore cannot be accurately predicted by a hardware vendor.

- Frequently, the queue size is tuned for the maximum capability of the
device and a pessimistic value for RTT, but the same hardware is more often
used (at least initially) at lower link speeds and thebqueue size is not
adjusted to compensate.  Eg. DOCSIS 2 cable but DOCSIS 3 modem, Ethernet
NIC or switch capable of 1000Mbps but operating at 100 or even 10, 802.11ac
wifi struggling with a marginal 802.11g link...

Thus substantially oversized raw buffers are quite normal.  It is AQM's job
to keep the *actual* queue occupancy low; with a properly functioning AQM,
the effects of an oversized raw queue are nil.

- Jonathan Morton