From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by lists.bufferbloat.net (Postfix) with ESMTPS id 261483ED32 for ; Mon, 21 Dec 2015 13:19:14 -0500 (EST) Received: from hms-beagle.home.lan ([217.247.221.45]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MMXVC-1a69tQ2Nig-008GO2; Mon, 21 Dec 2015 19:19:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Mon, 21 Dec 2015 19:19:08 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Kevin Darbyshire-Bryant , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <75B32CC1-BFD2-4AA2-9179-5A41DDBB8188@gmx.de> 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: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:QjZ6TpEcnvgtzpFDCI5F3gk8xE6guXnD80FSsS3iRVF7u/nhCVE pm/SLOCBpOkFvn4w3J8cAENJDonowdJwNnQJh6sLCg8z04B7pzynob8rqokw5l7+ooOEGzo 4TrKcMo55/gxZlQLRZzMv54aIQOz64KxQVWLTr0LH8WiIc8tdhTWm8d4ixYOsYbDmj+FtS9 1m+B8awMW68WtVX+KOTPA== X-UI-Out-Filterresults: notjunk:1;V01:K0:PI5WAlu6WOA=:n30oR4EJ1a0hVcqTPsMR1p Xe+76UwcVYarKOZpnfrh7QBi5DxpLg2ewGuzkwKE4w6IgcmfOYlKpVX6h9Jp5TkI+ofIqvZbO L9B1Nb6ieT80Xk4fTWzybrurxtl1wUy+c39feFv2yKsGVNWU5icgR616372vEwppoMQYWLLEm rC1K/F6gc8juKu6Z/Ioxmz+jNBZkaqKoqi0FZRDJ+O+E8/0gnaSF/25aXP4DHIaJhS03yynw2 NIyNXPmkxT4h9JlWuW9yeYZHuWkEDgLUJGUhTYYj1FwF6YBun4UNatl9Pwf5vr83xQtWE/Bqx gTyPoYbyJSwOTZu8LO07xlzod3gPvNWZEWHUzichLYY4l33b1Dgpa53fvK9m+y0BMPi5NYhYq WgG/YC8bvpvew3SCTWpQZfSMpbshgDySc0xVQDUHDNcLxMPQY9QdNNlLyuxb78vamfsc7QqL3 MiDjR7X4s5Gl7N6p7r4mW448kbGqN/UXYoOzVRR741SctbDdrCtqMgpkTVO0BKF7aQUF8qFWO 4nvkbyWzOyonRzJTksqW2UE6VRBa37pOIoNNeUHUl0bUtYR01z2EL/uDPZt83KZifwmu21bv+ 3NXczAfHYDBvaKjlOu2IpNNEbMoaocY/Q7p3cNRY+gBivHnErPP00+me1CV5+MNDNpYjVEJbf ySV5Bbu/pEJ+ZvDpFloJ8W5f2apa2ic96FQmJq06qU8SM18OW6OtqN5Xa42Z0KUmTYDqErVXS RjEK1EBEsxO6kXRj9PapqSGoKTQ7EYlIl1dSRM4/bbyLl7a6v6IjhksaWGDIJCfTkoHcu6a5a oaiHoDx 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 18:19:15 -0000 Hi Jonathan, > On Dec 21, 2015, at 16:36 , Jonathan Morton = wrote:\ [...] > 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. =46rom supporting users on the openwrt forums I know that an = easy way to compartmentalize bitttorrent traffic would find lots of = users. And if in an initial implementation a host with too many flows = suffers increasing delay under load, that might not be too bad, given = that bitterness can use this added delay to throttle itself back. It is = not about perfect here, just about good enough. [...] >=20 > 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. I would argue differently, instead of trying to make lemonade = why not collect the few actual constraints (probably 0=3DBE, 1=3DBK and = XX=3DEF should be sufficient to account for al actual marking = encountered in a typical home) and come up with something simple that = will just work? Simplicity wise I believe the classic precedence 3-bit = patterns are simple enough, but they fail; the CS1=3DBK test... >=20 > 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. A home router is a typical DSCP-domain, so clearing internally = valid marks on network egress seems quite prudent, no? Also it seems = not a bad idea to use DSCP at home to push bitterness in the BK without = giving an ISP a convenient marker to drop packets, but since I rarely = use bitterness I am making this argument up... >=20 > 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. Both of these are decidedly not-easy, and as far as I am = concerned cake=E2=80=99s reason to be is to make commonly wanted but due = to the involved complexity rarely configured home-network setups easy. = So if cake would offer this we can make non experts use it, which I = would count as a win... >=20 > 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. The beauty of fq, as I understand, is, given enough flows, the = misbehaving flows will mainly help themselves to a healthy portion of = delay before the dropper ramps up, no? Best Regards Sebastian >=20 > 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. >=20 > - Jonathan Morton >=20