[aqm] Policy-oriented AQM Steering (was Re: Status of the GSP AQM?)

"Bless, Roland (TM)" <roland.bless@kit.edu> Thu, 03 May 2018 13:40 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 00AE612D953 for <aqm@ietfa.amsl.com>; Thu, 3 May 2018 06:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cIe3r7NPUCeW for <aqm@ietfa.amsl.com>; Thu, 3 May 2018 06:40:20 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de []) (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 3C574126BF3 for <aqm@ietf.org>; Thu, 3 May 2018 06:40:20 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface id 1fEET3-0007tz-Rw; Thu, 03 May 2018 15:40:17 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id CB0BA4204C7; Thu, 3 May 2018 15:40:17 +0200 (CEST)
To: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" <wolfram.lautenschlaeger@nokia-bell-labs.com>, "aqm@ietf.org" <aqm@ietf.org>
Cc: "Francini, Andrea (Nokia - US/Murray Hill)" <andrea.francini@nokia-bell-labs.com>
References: <468c391d-7e18-e67c-d1b6-b6526eb8d9e3@kit.edu> <HE1PR07MB3370329512DA3865538206C4E9130@HE1PR07MB3370.eurprd07.prod.outlook.com>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <1e441d24-afbc-5e78-ca34-20391c16385f@kit.edu>
Date: Thu, 3 May 2018 15:40:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <HE1PR07MB3370329512DA3865538206C4E9130@HE1PR07MB3370.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1525354817.932595329
Archived-At: <https://mailarchive.ietf.org/arch/msg/aqm/iQgyT_4Mm8HVsA_XZsEYlj_SLyI>
Subject: [aqm] Policy-oriented AQM Steering (was Re: Status of the GSP AQM?)
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.22
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, 03 May 2018 13:40:23 -0000

Hi all,

in our paper "Policy-oriented AQM Steering" that will be published
at Networking 2018 shortly, we used also plain GSP and
CoDel for comparison. Maybe this is convincing enough that GSP is
also worth to be considered as alternative. We especially found
it much easier to implement AQM Steering for GSP since GSP's
implementation is simpler than others.

The basic idea of AQM Steering is to modify the delay target
setpoint of the AQM in order to adapt to the current traffic
Depending on the traffic the same setpoint value can result either
in unnecessary large delays or under-utilization of the link.
Policy-oriented AQM Steering automatically adapts the target delay
setpoint to the current traffic situation, in order to fulfill a
given quality-of-service policy.
Such a policy consists of a utilization goal and an upper delay bound.
This improves AQM performance with varying traffic situations and makes
the impact of deploying an AQM predictable. A prototypical
implementation of AQM Steering for GSP showed its performance advantages
compared to static AQM variants at speeds of 10 Gbit/s and 1 Gbit/s.

The pre-published version can be accessed here


Am 08.01.2018 um 17:17 schrieb Lautenschlaeger, Wolfram (Nokia -
> Hi Roland,
> Yes, of course, I am still interested in finishing the GSP draft.
> If you have new results on GSP, we could finally take the long pending "independent opinion" hurdle, thank you.
> If there is still some interest in the tsvwg, we could make a trial. My co-author Andrea Francini of the corresponding GSP paper (http://ieeexplore.ieee.org/document/7483103/)  could contribute as well. 
> Regards
> Wolfram
> -----Original Message-----
> From: Roland Bless [mailto:roland.bless@kit.edu] 
> Sent: Thursday, December 14, 2017 10:36 PM
> To: aqm@ietf.org; Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart) <wolfram.lautenschlaeger@nokia-bell-labs.com>
> Subject: Status of the GSP AQM?
> Hi folks,
> I was wondering what happened to the GSP AQM proposal (draft-lauten-aqm-gsp see (https://tools.ietf.org/html/draft-lauten-aqm-gsp).
> Discussion seems to have ended after IETF 93 and we probably missed the point of discussing WG adoption.
> IMHO this AQM should also be documented as RFC. It performs extremely well in some settings (better than CoDel or PIE) and its implementation complexity is also lower. Wolfram, are you interested in finishing this?
> Should we continue in tsvwg?