From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by lists.bufferbloat.net (Postfix) with ESMTPS id DBEF13ED64 for ; Mon, 21 Dec 2015 15:37:02 -0500 (EST) Received: by mail-lb0-x22b.google.com with SMTP id sv6so14084689lbb.0 for ; Mon, 21 Dec 2015 12:37:02 -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=Sr+0252rLalKlSyEIZuPVysTO3bjMLtwF8XdpkOun58=; b=bXsMK9ZY9/0fRSZmI5zcC5LNAdI14tSdBPZFghVnwk5r+TbuY651iURSW+9SygXqW7 Pdn6bgwGvvd3NhtEiJ/0m3UOIpO+VEswvkIth1lzVQqGBZGfJkkXCP/No2H4hKzx5PMV ooVSh04P1mRE/UHoKHY5Ok/yTnk9BWQUNXzhDFQjzqHpvZpGsYugI0UcKhyFKOMe7K9J vUjigTFjxXThVlQQQBFGLBV08SC2tTpTu4kYfSxzNZ70Ws6axUrtnHgGuYW7hFmtxVPP YjPZC7mIspllIcKwBDHbQqo9pxLQ61OEK3sY8wBubgF1Sqrx77EZ65DXEyNgrszcMeP/ JabA== X-Received: by 10.112.161.228 with SMTP id xv4mr7362185lbb.60.1450730221297; Mon, 21 Dec 2015 12:37:01 -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 r199sm3259406lfg.21.2015.12.21.12.36.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Dec 2015 12:37:00 -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: <75B32CC1-BFD2-4AA2-9179-5A41DDBB8188@gmx.de> Date: Mon, 21 Dec 2015 22:36:58 +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> <75B32CC1-BFD2-4AA2-9179-5A41DDBB8188@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 20:37:03 -0000 >> 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. >=20 > =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. True, and that=E2=80=99s why I=E2=80=99ve been trying to keep = flow-isolation work at the front of my queue, at least as far as Cake is = concerned. But I don=E2=80=99t want to be taking steps backwards. = Since I=E2=80=99ve got a theoretical handle on what appears to be the = *correct* solution, I don=E2=80=99t want to spend any time working on = anything that=E2=80=99s obviously wrong. >> 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. >=20 > 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=E2=80=A6 I might try to revisit the DSCP-to-tin allocations later on. There are = several competing specifications of such allocations in the wild, and I = might do better to align Cake with one of the more promising ones. = I=E2=80=99m also fairly keen to have a distinct =E2=80=9Cnetwork = control=E2=80=9D class right at the top of the stack, which might result = in five tins rather than four. >> 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. >=20 > A home router is a typical DSCP-domain, so clearing internally = valid marks on network egress seems quite prudent, no? No. That would be true only if you used =E2=80=9Clocal use=E2=80=9D or = =E2=80=9Cexperimental=E2=80=9D DSCPs (or some other mapping incompatible = with the published specifications) in your network. Cake doesn=E2=80=99t = understand those uses, so you should be doing your DSCP re-marking = before traffic reaches Cake, if at all. The DSCPs that Cake understands are those in the RFCs, which can be = presumed to be widely understood (if not always widely used). In = particular, they=E2=80=99re consistent with other Cake users and the = most obvious interpretation of the PHB specs. > 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=E2=80=A6 If your ISP drops traffic based solely on the DSCP, you have bigger = problems. If your ISP drops BK traffic preferentially during congested periods, = however, then they=E2=80=99re more-or-less doing the right thing. = Assuming they=E2=80=99re not permanently congested, that is. >> 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. >=20 > 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=E2=80=A6 In my book, non-experts should definitely *not* be using the =E2=80=9Cwash= =E2=80=9D feature. Early re-marking of DSCP would however be useful on ingress, to deal = with the plethora of networks out there which either fail to set = appropriate DSCPs at origin, or re-mark them inappropriately en route. = In particular, it would be useful for ingress classification of = BitTorrent traffic, since the user has a better chance of identifying = this traffic by port number than the ISP does. >> 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. >=20 > 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? Yes, that=E2=80=99s true to the extent that I=E2=80=99m putting improved = flow isolation above tuning AQM in my todo list. Good flow isolation = means that, in theory, AQM only needs to act to provide courtesy signals = to responsive flows - which is exactly what Codel is good at. However, if AQM can also act to keep unresponsive flows under control, = that relieves the overflow handling logic from having to do that job = full-time. Although I did optimise that logic somewhat some time ago, = it isn=E2=80=99t as slick or efficient as AQM could be in this role. = The difference between theory and practice... - Jonathan Morton