From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A54883B2A4 for ; Tue, 19 Jun 2018 05:31:59 -0400 (EDT) Received: by mail-wm0-x22c.google.com with SMTP id x6-v6so18693153wmc.3 for ; Tue, 19 Jun 2018 02:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=OFR+H3nQ5XhQqUdS4pTEPoLc7Tg+5rv8CkzmHlaaZHU=; b=Fbv89pedezAcSgCVELEN93PJRHt0lB6t+QhzNds41sOhM5edE+fFJPCX8vMmOaeUY0 WkNKuOlF/ffaL7TJHM0zKPuZQbIzoscSAIZ4r1x0tWstgTvhfbqlts0WVOI2TOBTPvXc j5I2Vw49IQ4HCmQYo32584lSkH1KwS2J71IY20hvG50PL3XAUeWBnrntGsE6Fi0Xc6Jm mkw7NnTS3I/9kckIJ2CkWFL/qiGPugT3U3N9K9/IRVh6wGoIg73QiOUb6YkfKo50mkjU vk9n0RLeaRQ90XxLbX+umRxlTYc54l3i3bUxtNr6tbCdrmlUf9Z0mxbz5HIQspx9fT/b 1m1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=OFR+H3nQ5XhQqUdS4pTEPoLc7Tg+5rv8CkzmHlaaZHU=; b=ZPi06enAtqgriaceeEP75ut2yNDxClRtEedpZXUlGfK/cDWH5mwXEsEZbOER9uRhgm kmQ9J4BSscFuZZSx5CwB90GS8t4+NfvKAtqnz6hiAGdYsJqcA7zLBSdheb5jLOtw/X8u AAhp14KVq/okR0gTYsmria7e5fizyY804twI01CM53Hn7+aPlFROFna+u7pGWkG9uv+9 TYPr6IHhWrbo71b591CjGWOJ1X04avjSi+OpFkgi+hpGgFyWU6x7ND8TryptVNdL/g6C 7B84SvU53K/9gmewliL/cV+ESgKVA5OQkEJGCwX4l4lTRHF2+/zJbm/J7YfCsjaE0VQJ h+8w== X-Gm-Message-State: APt69E0HBotPyCQQ1qyzzBIsZvfOZprko7VSPVgfEbtP6yxyxlz17nw3 jtk3eLve7ugp4una2VJgSc9J0HU1474= X-Google-Smtp-Source: ADUXVKLHMTmFFAjbO22F+1UYsKfLH8Sviviv8ubS7/rAjbrMJUcageV/Vdj/8coC1rBhqpkKUL5QXg== X-Received: by 2002:a1c:8a07:: with SMTP id m7-v6mr11941327wmd.27.1529400718514; Tue, 19 Jun 2018 02:31:58 -0700 (PDT) Received: from tron.luk.heistp.net (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id x5-v6sm18315805wrr.3.2018.06.19.02.31.57 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Jun 2018 02:31:58 -0700 (PDT) From: Pete Heist Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 19 Jun 2018 11:31:57 +0200 To: Cake List Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Subject: [Cake] the Cake stalemate 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: Tue, 19 Jun 2018 09:31:59 -0000 Whether or not it helps with the upcoming talk or future plans, I=E2=80=99= m thinking about the most recent experience with trying to upstream Cake = and how to break the stalemate. Cake stretches (arguably breaks) what qdiscs were designed for, which, = correct me if I=E2=80=99m wrong, is what caused a lot of the pushback. = I=E2=80=99m thinking of NAT support, ingress mode, host isolation, = diffserv modes, and ack filtering, at a minimum. Each of those things = can be useful in one case or another both individually and together, as = evidenced by a satisfied user base. But when upstreaming I think each = got a response with some variation on =E2=80=9Cno swimming in my = bathtub.=E2=80=9D It seems that some would rather see Cake broken into pieces, and yet = Dave points out that what makes Cake useful is the ability to easily = address some common real world scenarios from one place: > On Jun 19, 2018, at 3:46 AM, Dave Taht wrote: >=20 > One of cake's "minor" features is the *perfect* defeat of the htb > based shaper in cable modems. If you know the set-rate on the modem, > you just set it to the same thing and get vastly superior performance = to > docsis 3.1, pie, or the sqm-scripts. Some of its functionality is painful to implement using separate qdiscs, = iptables rules, misc kernel modules, etc. So Cake is something useful = that can=E2=80=99t be delivered to the world because of something like = an impedance mismatch. There=E2=80=99s something wrong here, right? = I=E2=80=99m just asking the question, what is it: 1) Should we accept qdiscs and Linux networking as they are and work = within their borders? or 2) Are there problems with the qdisc architecture or improvements from = our experience that we can suggest for Linux networking that would help? Or some combination? Thoughts on this: - The need to use an IFB device to control the ingress queue seems = cumbersome, and that one should be able to control both the egress and = ingress queues with one qdisc and one device, since egress and ingress = traffic can be related (say for half-duplex devices). - And let=E2=80=99s say you wanted to try to control the queue of a = half-duplex physical layer with varying, asymmetrical rates and airtime = considerations like WiFi. That would be a real challenge within the = qdisc architecture. Realistically, you=E2=80=99d have to write a driver = for every device that exists, right? It seems that situation could be = better. - Is there a right way to implement host isolation with NAT support? - Just as a brainstorm, if I understand it right, qdiscs and tc live = outside of the netfilter framework and within iproute2. Wouldn=E2=80=99t = it have more conceptual integrity if netfilter and iproute2 were = integrated? I=E2=80=99m thinking of a modular architecture that = regardless of whether you queue, route, filter, prioritize, etc, you = work in the same space. Or if that sounds like mayhem, then at least I = question, does queueing belong with routing? - Related: instead of a qdisc, could Cake rather be written as a = netfilter module or series of modules with a common configuration = utility? I=E2=80=99m writing a bit beyond my experience here and those who=E2=80=99= ve written a qdisc could surely have better ideas on what the path = forward is=E2=80=A6