From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by lists.bufferbloat.net (Postfix) with ESMTPS id DDB493ECFB for ; Mon, 21 Dec 2015 16:19:25 -0500 (EST) Received: from hms-beagle.home.lan ([217.247.221.45]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LoKHN-1ae9560N57-00gDm1; Mon, 21 Dec 2015 22:19:21 +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 22:19:19 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Kevin Darbyshire-Bryant , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <2ADA29E6-725A-417F-958E-C82F88B886C8@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> <75B32CC1-BFD2-4AA2-9179-5A41DDBB8188@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:3aPLmofmTbHgscBuGVk/sXm2DPUw6tKx9t586UDgFn4rnaeBIt9 Lik9hcKOW4aKFSP9WvlZqSlir3DKJB+1PdpHBPTluDdKPvFVOphJUSV9t+wYPXFlU2hoLFc qbSoftB5TSQrfpPQXf9i004lfF70qqP6x3gAc6giVBZqWc87qKV1gnfOCz9rr+6k7S616sY R9qY+1KhkpZaUjxcTm2BQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:A5t3vG6cnXc=:GNI7ye4cVbU545gWiVezpo +XjftkOKdkx3KBLcp5vzpXcNJQv/GShODMUX26CsufIUcM4bVwyclViTO9wIjW2utWZ0avj7p vyeICjZ5FIGMq5W9U656j8FmlFFMdCNxeoxG08gnrhormtnWADHguBp1LJa78xXhEzp2iJjsA dmTtH1T/w2nIbmA1uPxN8X2OEeoi/6d/zQueLEQ2SFxQiFGscfmSe18PVK1z4vHyzfed1S6/p aoycJcgwylEDUHdAmsxldJ7JwtO+PZ9nBH7A7l2volIsV+7KlZ14+zxJSaQ6WG3oaV7zfXoR3 HTDvPdlvMpMg8AQQPTj1+0OWIVEXPEOknujfUhfTf4XF3Gp0kkV72tFfj2qm4gCCpRh+UVdvQ wTKC555QEFoN9TcixFXTcN2pEpyNwaBW/nt0QOOmNAHRRwvg4CxPTm7fdKH/9HAQ5SHL/BnmX L+BoSQVoAjhScP6UlpFarYvELFQG9APc6r2MDWsjW0LoX1R7/YgMu1H54HUsiHnUou6L3MhaJ umoRIJ4CSPPuxmx06ERH8FE+cJ9dXhjmoC43NOuQeW/J1pVFz03Y+k78h1rXohzMxRydA/usm uMK9KT9PQqh8gpo6NvRa6Oya2oI9ziVezbY8Ff9cJIUjO5fYm6Tu6BZnCRp3ENckuIg1gAGG2 we+o6Nex2U7eHWNF5A3Qj5LeVq4wZ3/Am/xCGH4guUU5ixK+3wmqxHZ/IiTbPT8ty0L+YYCVD T1av6SbdKWvsM6a1b/u7Yt3tU1QoU7Q0P7Mi55TdW8XfDpsOzfO98ahrXdEGAdpxAH+1hmSUm zqfTLJV 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 21:19:26 -0000 Hi Jonathan, > On Dec 21, 2015, at 21:36 , Jonathan Morton = wrote: >=20 >>> 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. >=20 > 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. As long as we are not missing out on =E2=80=9Cgood enough=E2=80=9D= for a perfect solution, I am fine with waiting, except then I vote for = getting cake upstream ASAP. >=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. >>=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 >=20 > 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. Network control is tricky, because even in the home you need to = control access to this tier strictly. That said, I want to play with a = 4th tier in simple.qos for basically the same reason (specifically to = keep PPP-LCP packets on highest priority); but in sqm, since we use tc = filters/iptables to do the filtering, it is rather easy to only accept = these marks from the router itself and I know the required bandwidth = pretty well (less than 1 kbps) so this should work okay. >=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. >>=20 >> A home router is a typical DSCP-domain, so clearing internally = valid marks on network egress seems quite prudent, no? >=20 > 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. All the published specs are hardly worth the bits the use up, as = many ISPs simply re-map everything to zero=E2=80=A6 Really local use or = experimental are just an attempt to make the published schemes look more = respectable ;) >=20 > 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. I disagree, there is no real consensus in the field AND there is = the recommendation to not trust any unsolicited ingress DSCP markings = (on networks that honor them) so there is zero benefit in trying to = second guess which scheme a specific ISP will honor/not-remapp to zero. = The sorry state of affairs is that if at all DSCP marks leaving a home = net are an information leak... Really to repeat myself and play = devil=E2=80=99s advocate we only need to honor CS0 and EF and I bet = almost nobody using DSCP in the home will notice by behavior alone ;) Or = let me try again, all of the PHB description come with their own agenda, = and none of these agendas align well with what I believe to be a typical = home network setting. Since the native scope of DSCP is a network all we = need to offer a scheme that works well in the network we are aiming for. = Or put different again, none of the competing proposals so far has shown = any =E2=80=9Cfitness" in the real world so why select any of those to = base a simple scheme on?=20 >=20 >> 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 >=20 > If your ISP drops traffic based solely on the DSCP, you have bigger = problems. >=20 > 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. Arguably, but do I really want my bit-torrent (I just noticed = autocorrect turn bit-torrent into bitterness...) to be dropped while my = neighbor=E2=80=99s CS0 marked bit-torrent goes through? This is = hypothetical I rarely use torrents at all, so I really do not know. >=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. >>=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 >=20 > In my book, non-experts should definitely *not* be using the = =E2=80=9Cwash=E2=80=9D feature. Because you believe in the idea that our DSCP marks might have = use later on, but for example my ISP zeros out the TOS bits on IPv4 = while keeping them on IPv6 this is a big mess=E2=80=A6 Let me explain, = wash as far as I can tell allows the use of DSCP on egress without = leaking unwanted information toward the upstream network, and hence is a = good candidate for a default setting in my book. (Yes, I realize I have = no leverage here, but that never stopped me from voicing an opinion ;) ) >=20 > 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. You are onto a great idea here, DSCP re-mapping on network entry = and potentially zeroing on network egress. >=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. >>=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? >=20 > 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. >=20 > 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=E2=80=A6 Thanks for your thoughts Sebastian >=20 > - Jonathan Morton >=20