From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) by lists.bufferbloat.net (Postfix) with ESMTPS id 83BFA3ED3C for ; Mon, 21 Dec 2015 10:36:07 -0500 (EST) Received: by mail-lf0-x234.google.com with SMTP id z124so108450507lfa.3 for ; Mon, 21 Dec 2015 07:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C9As34U2MBCoYh+ysuRAgz/Za1SpeLLWv8UOQ1HmYXU=; b=XcTPu2mSjkAquJGv+L0ABqOBdSBygN/F1NTXtFIAPMvTWAYHqo2MCHTLVo80ONt0EA ysdqpGXFs0U47kzXMJUxtHia98BgPNFfkKr1WZhGmfPwof7PlBTtMS5QbHP6o5LrHsHU NiDtFNCZmzRw3g3yzip/9BG8EpAOMKsiIO8Z0FOVDAo3v9qg72ysfmrHt1ZTe0KdOpjP QcPa3mzQGTsKDtVy+LW45NGYs6QSAG7gvGhGybXfSGu8BnHXx4l65MOue5fs59BmQnno raqoynsckxkCkDQBLKF3xQVP8RsiOVQZ7POPzbM2pSBE27rNW6RUi/CgM+TXGxhUVtZE y5Xg== X-Received: by 10.25.65.7 with SMTP id o7mr5388416lfa.115.1450712166261; Mon, 21 Dec 2015 07:36:06 -0800 (PST) Received: from bass.home.chromatix.fi (37-33-99-74.bb.dnainternet.fi. [37.33.99.74]) by smtp.gmail.com with ESMTPSA id k15sm5146042lfe.35.2015.12.21.07.36.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Dec 2015 07:36:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Jonathan Morton In-Reply-To: <85A5A21C-E468-4F81-8A36-0F1AD6C84435@gmx.de> Date: Mon, 21 Dec 2015 17:36:03 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Kevin Darbyshire-Bryant , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <6F86FBB0-AA69-44F3-82D0-31465906974D@gmx.de> <56657A82.2080601@darbyshire-bryant.me.uk> <95560E7E-DEAF-40D8-B704-CEA38A0CDE62@gmx.de> <85A5A21C-E468-4F81-8A36-0F1AD6C84435@gmx.de> To: moeller0 X-Mailer: Apple Mail (2.3112) Subject: Re: [Cake] second system syndrome X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 15:36:07 -0000 Addressing the subject line of this thread directly: I intended, from the start, for Cake to integrate the best available = algorithms for shaping, AQM, flow isolation, and priority queuing. This = has, of necessity, resulted in Cake becoming larger and more complex = than most other qdiscs. I do agree that it=E2=80=99s important to avoid = *needless* complexity, for performance reasons if none other. Shaping, AQM, flow isolation and priority queuing are Cake=E2=80=99s = core feature set. I=E2=80=99m not going to remove or cripple any of = those functions in the name of elegance - that would be = counter-productive. So features that directly contribute to those = functions - such as the packet-size compensation which the shaper relies = upon, and the GSO peeling which the packet-size compensator relies upon = - are also clearly within scope, even though they might complicate the = configuration interface. The =E2=80=9Cdual flow isolation=E2=80=9D, which after a great deal of = thought I=E2=80=99ve decided to rename =E2=80=9Ctriple flow isolation=E2=80= =9D (for reasons that will become clear later), is within scope because = it improves the flow-isolation feature. If and when I can get my head = around all the little changes that keep (potentially) breaking = everything behind my back, I=E2=80=99ll be able to actually implement it = some day. It could reasonably be argued that some logic should be moved out of = kernel space and into userspace, and/or vice versa. However, we need = concrete justifications for doing so, and a certain level of = self-consistency. We also need *really* strong justification before = making optimisations which make future adjustments more difficult. One such justification might be to more clearly separate the = user-visible link characteristics (such as bandwidth, inherent latency = and encapsulation) from the algorithm implementation parameters required = to make best use of it (such as interval, target, etc). These are = parameters that are calculated at configuration time, so they do not = need to be especially fast. The most difficult function to define and scope has been the priority = queue, due in no small part to the hilariously weak specification that = is Diffserv. I have tried to carve a fresh path of clarity here, = interpreting the existing specifications into a coherent implementation = in the hope that it=E2=80=99ll actually get used as such in future. In that context, the =E2=80=9Csquash=E2=80=9D and =E2=80=9Cwash=E2=80=9D = features truly baffle me. I=E2=80=99d prefer to see them both gone. = Either you want to *use* Diffserv, in which case downstream networks = might also benefit from the same markings, or you want to *ignore* it, = in which case you might as well leave the existing marks alone, or you = want to do something more sophisticated that Cake=E2=80=99s core feature = set doesn=E2=80=99t support. In short, Cake is *not* the right place to change the DSCP field. A = separate qdisc could be written to do that job with minimal overhead and = a dedicated configuration interface, and be inserted either before or = after Cake as required. Or we could wait for pre-ingress-qdisc firewall = rules to become available. The AQM layer is also apparently a source of controversy. Codel is = really, *really* good at dealing with single, well-behaved TCP flows in = the congestion-avoidance phase. It=E2=80=99s also really, *really* bad = at dealing with unresponsive UDP flows, and somewhat mediocre at dealing = with TCP in slow-start or multiple TCP flows in the same queue. This is = a problem that we need to address, one way or another - whether by = modifying Codel or finding some way to switch between two or more = different AQM schemes based on traffic characteristics. In the = meantime, we have to experiment. I am happy to see optimisations go in, as long as they=E2=80=99re = clearly beneficial, don=E2=80=99t change the logic, and don't preclude = changes to areas that are not entirely settled. For anything else, = please make it a separate branch with a pull request, so that I don=E2=80=99= t have to be distracted by reverting stuff that doesn=E2=80=99t work. - Jonathan Morton