[aqm] review of fq-codel draft

Wesley Eddy <wes@mti-systems.com> Tue, 17 March 2015 17:14 UTC

Return-Path: <wes@mti-systems.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 69CF21A87BB for <aqm@ietfa.amsl.com>; Tue, 17 Mar 2015 10:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 2yMecRYmbsCc for <aqm@ietfa.amsl.com>; Tue, 17 Mar 2015 10:14:28 -0700 (PDT)
Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 677BC1A87B1 for <aqm@ietf.org>; Tue, 17 Mar 2015 10:14:28 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t2HHEQru027393 for <aqm@ietf.org>; Tue, 17 Mar 2015 13:14:26 -0400
Received: (qmail 389 invoked by uid 0); 17 Mar 2015 17:14:26 -0000
X-TCPREMOTEIP: 207.54.183.210
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@207.54.183.210) by 0 with ESMTPA; 17 Mar 2015 17:14:26 -0000
Message-ID: <550860E4.6040908@mti-systems.com>
Date: Tue, 17 Mar 2015 13:14:12 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "aqm@ietf.org" <aqm@ietf.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/KKPt1zuQOVG4-hU8qyou8VlikeQ>
Subject: [aqm] review of fq-codel draft
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: <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: Tue, 17 Mar 2015 17:14:30 -0000

I reviewed the fq-codel draft and have some comments:
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/

Overall, it's a clear document that someone could definitely
write code from without much difficulty, and I hope we can
quickly finish it in this working group.  I do have a few
comments below that I think would improve it though.

In section 1, the 2nd-to-last paragraph, I had some
confusion on the sentence:
"Exactly how much data a flow has to send to keep its
queue in this state ..."
By my understanding, it would be a matter of how _little_,
not "how much" data the flow has to send to remain in that
state of never having a queue that persists between rounds
of the scheduler.

In section 3, something big is missing here in terms of
explaining the intention to have N queues such that flows
mostly uniquely hash to their own queue.

It would also be worth explaining here what the impact will
be of things like tunnels and people doing things like using
multiple DSCP values within the same 5-tuple (like in the
TSVWG RTCWEB QoS draft).  If everything in a tunnel and
everything on a 5-tuple (regardless of DSCP) hash into the
same flow/queue, then it should be clearly noted.

(I know there's brief mention later in the document about
DiffServ, but IMO it's a big enough architectural issue that
it should be well-understood by the reader and clear up front
in the document)

In section 5.1, it could/should be stressed more strongly that
configuration of a custom filter for classification has a huge
impact on how the system performs, and in this light, it seems
to me like the "standard filter" should be more strongly
recommended, and custom rules noted as not really encouraged
for people that won't actively be measuring and possibly updating
them.

The decapsulation capability described in 5.1 seems like something
that can't generically be assumed in an implementation because
there are N different encapsulations and more on the way.  I think
the paragraph mentioning this should stress that it's a feature of
one implementation, that others could mimic, that it does impact
performance, and that it isn't a panacea for all flavors of tunnel,
especially ones that use encryption.

Section 7.3 should probably reference the LEDBAT RFC directly.

I believe from notes scattered throughout the document that it
would be helpful to have a "Further Research" section near the end
of the document to collect and summarize the productive future
work that the authors would suggest.  For instance, the things
that I can see would be:

- alternate FQ mechanisms like QFQ
- variations of the classification algorithm
- measured interactions with delay-based CC (e.g. LEDBAT)
- sensitivity of parameters (interval, # of queues, etc)
- including other fields in the hash (i.e. "entropy fields") in
  order to deal with tunnels more elegantly (e.g. the way that
  flow label or other things are being used for ECMP).

-- 
Wes Eddy
MTI Systems