Re: [aqm] FQ-PIE kernel module implementation

"Bless, Roland (TM)" <roland.bless@kit.edu> Tue, 07 July 2015 08:06 UTC

Return-Path: <roland.bless@kit.edu>
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 648E01A1A99 for <aqm@ietfa.amsl.com>; Tue, 7 Jul 2015 01:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.55
X-Spam-Level:
X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] 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 hZgwfazi7BVv for <aqm@ietfa.amsl.com>; Tue, 7 Jul 2015 01:06:54 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 A35411A017A for <aqm@ietf.org>; Tue, 7 Jul 2015 01:06:54 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1ZCNtz-0000JO-6p; Tue, 07 Jul 2015 10:06:51 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 2570BB0071F; Tue, 7 Jul 2015 10:06:51 +0200 (CEST)
Message-ID: <559B889B.4060409@kit.edu>
Date: Tue, 07 Jul 2015 10:06:51 +0200
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Agarwal, Anil" <Anil.Agarwal@viasat.com>, "Fred Baker (fred)" <fred@cisco.com>, Toke Høiland-Jørgensen <toke@toke.dk>, Polina Goltsman <uucpf@student.kit.edu>
References: <D1961A16.1087%hokano@cisco.com> <5577FBD3.5000804@student.kit.edu> <97EDD2D8-CC0A-4AFA-9A74-3F2C282CF5C2@cisco.com> <87mvzem9i9.fsf@alrua-karlstad.karlstad.toke.dk> <7E6C797B-EE6F-4390-BC8F-606FDD8D5195@cisco.com> <559659A8.9030104@student.kit.edu> <87fv55mtpz.fsf@alrua-karlstad.karlstad.toke.dk> <559674B7.5050004@kit.edu> <7A2801D5E40DD64A85E38DF22117852C70AD0859@wdc1exchmbxp05.hq.corp.viasat.com>
In-Reply-To: <7A2801D5E40DD64A85E38DF22117852C70AD0859@wdc1exchmbxp05.hq.corp.viasat.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1436256411.
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/PgaorH-PBsFVzrvUZryj-fzG1mw>
Cc: "draft-ietf-aqm-pie@tools.ietf.org" <draft-ietf-aqm-pie@tools.ietf.org>, "Hironori Okano -X (hokano - AAP3 INC at Cisco)" <hokano@cisco.com>, AQM IETF list <aqm@ietf.org>
Subject: Re: [aqm] FQ-PIE kernel module implementation
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: Tue, 07 Jul 2015 08:06:57 -0000

Hi,

thanks for your analysis. Indeed, Polina came up with
a similar analysis for an unresponsive UDP flow and
a TCP flow. Flow queueing can achieve link share fairness
despite the presence of unresponsive flows, but is ineffective
if the AQM is applied to the aggregate and not to the individual
flow queue. Polina used the FQ-PIE implementation
to verify this behavior (post will follow).

Regards,
 Roland


Am 04.07.2015 um 22:12 schrieb Agarwal, Anil:
> Roland, Fred,
> 
> Here is a simple example to illustrate the differences between FQ-AQM with AQM per queue vs AQM per aggregate queue.
> 
> Let's take 2 flows, each mapped to separate queues in a FQ-AQM system.
> 	Link rate = 100 Mbps
> 	Flow 1 rate = 50 Mbps, source rate does not go over 50 Mbps
> 	Flow 2 rate >= 50 Mbps, adapts based on AQM.
> 
> FQ-Codel, AQM per queue:
> 	Flow 1 delay is minimal
> 	Flow 1 packet drops = 0
> 	Flow 2 delay is close to target value
> 
> FQ-Codel, AQM for aggregate queue:
> 	Does not work at all
> 	Packets are dequeued alternatively from queue 1 and queue 2
> 	Packets from queue 1 experience very small queuing delay
> 	Hence, CoDel does not enter dropping state, queue 2 is not controlled :(
> 
> FQ-PIE, AQM per queue:
> 	Flow 1 delay is minimal
> 	Flow 1 packet drops = 0
> 	Flow 2 delay is close to target value
> 
> FQ-PIE, AQM for aggregate queue:
> 	Flow 1 delay and queue 1 length are close to zero.
> 	Flow 2 delay is close to 2 * target_del :(
> 		qlen2 = target_del * aggregate_depart_rate
> 	Flow 1 experiences almost the same number of drops or ECNs as flow 2 :(
> 		Same drop probability and almost same packet rate for both flows
> 	(If flow 1 drops its rate because of packet drops or ECNs, the analysis gets slightly more complicated).
> 
> See if this makes sense.
> 
> If the analysis is correct, then it illustrates that flow behaviors are quite different
> between AQM per queue and AQM per aggregate queue schemes.
> In FQ-PIE for aggregate queue, 
> 	- The total number of queued bytes will slosh between 
> 	  queues depending on the nature and data rates of the flows.
> 	- Flows with data rates within their fair share value will experience 
> 	  non-zero packet drops (or ECN marks).
> 	- Flows that experience no queuing delay will increase queuing delay of other flows.
> 	- In general, the queuing delay for any given flow will not be close to target_delay and can be
> 	  much higher