From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by lists.bufferbloat.net (Postfix) with ESMTPS id DFE773ED0C for ; Mon, 21 Dec 2015 11:06:32 -0500 (EST) Received: by mail-lb0-x22c.google.com with SMTP id bc4so17739178lbc.2 for ; Mon, 21 Dec 2015 08:06:32 -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=X7LG/JHsuTPBdmBKAHAgk9r3DILVummm4UQKKik8mQg=; b=PAwm0LDafXQFwadnMrrpTyHaAx1pNSmzluUxPP0g5YSx6BJt4s7Ufks4Yb8XqecW/0 HSNjvx+mmuvhy8VQcCMr6IhhHfKsDqjl0tGI0DPTkE4M4bEclN3cpnjHc2nrw0OhcHsk zBbVyPpKV1MlC1/nN/2jmrXvu2EWWJ4ujjQxNqPOdWUz7qHC2RQ2bFKkZh6UU/0R7AJH pNKR1rLhJhoBxHvsm2yoHI7kLefaXVBf2yKm8wbe6B8u4gWJphtWRWBPEKfevGcQwwI3 D/20IxZyteV4CrZcNC7Ny+q7u2qeh/C4+RxEVy5T1yAPh+hQ0iNZ1gXzXG+FyiDypuin BKbQ== X-Received: by 10.112.141.201 with SMTP id rq9mr6555354lbb.4.1450713991270; Mon, 21 Dec 2015 08:06:31 -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 c201sm5117337lfb.4.2015.12.21.08.06.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Dec 2015 08:06:30 -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: <877fk7lts4.fsf@toke.dk> Date: Mon, 21 Dec 2015 18:06:26 +0200 Cc: Dave Taht , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <7CCCD9FC-0DCB-4934-8D59-E0F997972AB4@gmail.com> References: <768E4BFC-989F-49C0-97D4-38B0D926E542@gmail.com> <877fk7lts4.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3112) Subject: Re: [Cake] cake dual hash for dualdst, dualsrc 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 16:06:33 -0000 > On 21 Dec, 2015, at 17:12, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Jonathan Morton writes: >=20 >>> you thought that isolating individual machines into roughly 8 queues >>> each would help defeat bittorrent and other forms of too-many-flow >>> abuse... and that you'd get some of the benefits of fq for everyone >>> and that codel could correctly compensate for it! >>=20 >> Um, no. That isn=E2=80=99t what I had in mind at all. >>=20 >> I=E2=80=99m not at all surprised that your version doesn=E2=80=99t = work. >=20 > Do explain; or maybe show us the code, even? The scheme described above stops working as well as standard = flow-isolation just as soon as any single host (or host pair) has more = than eight flows. Note that the ordinary RRUL test employs *thirteen* = flows, and the only reason the results still look good is because most = of them aren=E2=80=99t bulk, so half the queues do double or triple = duty. The 50:1 test completely destroys it, for obvious reasons, = whereas this was something that Cake did comparatively well at. Additionally, hosts can still get up to an 8x throughput advantage over = another using multiple flows. If both source and destination hosts are = considered in the host hash, sharding gains further advantages, evading = the dual-isolation measure entirely. This is not progress. An early design I had in mind imposed an explicit two-layer structure, = with a DRR structure for hosts, and each host bucket having an = independent DRR structure for flows. This would have both avoided the = host-to-host competition by flow count (which was the whole point of = dual isolation), and avoided restricting the number of flows each host = could use without losing the entire benefit of flow isolation. However, this still forced the user to choose between source-address or = destination-address host isolation, in order to avoid the =E2=80=9Cshardin= g=E2=80=9D cheat. So I searched further for a way to treat both = addresses equally with the same overall benefit. What I now have in mind restores primary DRR control to the flow level, = but adds per-source and per-destination deficit counters which are = indexed to from the flows. All three deficit counters must be = non-negative before the queue will be serviced, making it an *implicit* = two-level structure with the upper level in two interlocked branches. = This should work well outside of pathological cases, since our = set-associative flow isolation doesn=E2=80=99t often suffer collisions. The challenge is maintaining the new deficit counters accurately, since = we can=E2=80=99t rely on the monotonic sweep behaviour as ordinary DRR = does. That=E2=80=99s what I=E2=80=99m currently trying to focus on. - Jonathan Morton