Re: [aqm] PIE vs. RED

"Francini, Andrea (Andrea)" <andrea.francini@alcatel-lucent.com> Thu, 13 August 2015 23:07 UTC

Return-Path: <andrea.francini@alcatel-lucent.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 6A3271ACE99 for <aqm@ietfa.amsl.com>; Thu, 13 Aug 2015 16:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 JqjJICUbSQOo for <aqm@ietfa.amsl.com>; Thu, 13 Aug 2015 16:07:12 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922821ACE98 for <aqm@ietf.org>; Thu, 13 Aug 2015 16:07:12 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 913EDF7B04AE9; Thu, 13 Aug 2015 23:07:07 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t7DN78W3025479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Aug 2015 23:07:09 GMT
Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.242]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 13 Aug 2015 19:07:08 -0400
From: "Francini, Andrea (Andrea)" <andrea.francini@alcatel-lucent.com>
To: Roland Bless <roland.bless@kit.edu>, Jonathan Morton <chromatix99@gmail.com>
Thread-Topic: [aqm] PIE vs. RED
Thread-Index: AQHQ1hj1JNTnP9Wpi0Omyy4DEGnv6J4KhuYQ
Date: Thu, 13 Aug 2015 23:07:07 +0000
Message-ID: <1BFAC0A1D7955144A2444E902CB628F865B08093@US70TWXCHMBA12.zam.alcatel-lucent.com>
References: <55CC8D6B.7030007@kit.edu> <CAJq5cE2sNFvLPvrB82dRrN+nbZLNRuo+TmCVgSYCp4TumN70Sw@mail.gmail.com> <55CD1C9A.9040406@kit.edu>
In-Reply-To: <55CD1C9A.9040406@kit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/4PbPAatKQSQdbqd20MOPnUP0Sos>
Cc: "aqm@ietf.org" <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 23:07:14 -0000

To second Roland's point, the advantage of PIE over RED should not be entirely in the use of delay-based thresholds instead of queue-length ones, otherwise it could be argued that a version of RED with delay-based thresholds is not too hard to design (Wolfram easily did it for his GSP scheme). 

With such a RED version in place, hopefully PIE would still show better performance, so the same superiority should also emerge when the queue-length thresholds of conventional RED are reasonably tuned around the traffic scenario of each experiment.

Andrea

-----Original Message-----
From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Roland Bless
Sent: Thursday, August 13, 2015 6:39 PM
To: Jonathan Morton
Cc: aqm@ietf.org
Subject: Re: [aqm] PIE vs. RED

Hi Jonathan,

Am 13.08.2015 um 19:35 schrieb Jonathan Morton:
> 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.

Yep, sure. My point was not to promote setting the buffers according to
"the BDP", but rather arguing that one should use comparable target
settings when comparing AQMs, see below...

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

That's correct. However, IMHO if one compares AQMs one should set/tune
the individual parameters of the AQMs so that they achieve a similar
target value (and not more than an order of magnitude apart).
This is probably relevant for the aqm eval guidelines, but
I'll come up with a detailed review for the draft within the next days...

Regards,
 Roland

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm