From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 BD6CF3B2A4 for ; Thu, 26 Jul 2018 17:38:16 -0400 (EDT) Received: by mail-lj1-x236.google.com with SMTP id r13-v6so2730413ljg.10 for ; Thu, 26 Jul 2018 14:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d7nEgKzQ9/xLIRbzeEmL0ceFQn9uEAcZv6luh+oL/Vg=; b=sOreB4ciVkN+b0qmDeA6ALwq6D/esqujgtT4KEPnkeTkFe4W2K8AwcNTSotDzmE0a+ BQxUS/3hx9WM7HRy/LsJ3cPh13KHeD7LFnly+GJ9bidJ7FxRESMk7NZyQyhOixkM0poL b1wW2lCisywxKIDXdlTalnUlhAiTK53bJpXALszAykki+oQ2JIaYojOXdDUtH6vzAqJb YbVPEKcJ2WccFdg8YlMZk9E4RbA94i2d6VD+ZScADtgu8HBuQbY5C56AGGtwxlqdfINS PELkPx83zC4vkyqPzrMXxuQ2pl774884aF0fvSCTFEA2V3NVcqJMGzPggxpmk+bXhO7o Ld7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d7nEgKzQ9/xLIRbzeEmL0ceFQn9uEAcZv6luh+oL/Vg=; b=qN9W2Su2tVhS8gOMTckPm9+BOI7wym1yId6sxTQHIiVD2qih+S+jgYLGzClrfcvqj3 yO5jcP/G93UZnDHXTElsfxoYFR0BXN2vS6CFGDAF5MYswgEChP21dhSR/6IBDsWQzNUe o8N535ayM3fUgygRkRo4EEkgOegI/dUAutzNamuu1kXtUw4RCMy4eSkCj4tnhc3YTlIB mPJMs13XEIdrZIr8EGNL+A9gB/K30oEwqJOA0aiKvqDy9aExddnits/zuWnBi4zumBAV vs+ByjMhFqW/Fnb/K9JsYTvB6dSCjbY3+4i1+9ORg4WcbCaUj9bBnNdVgrai+U7Z0W4H 1v8Q== X-Gm-Message-State: AOUpUlGKpCnxWH6Ms7w09NGO9zdrFOLxL1+hL3xxnA+zqDKLSLf+Y9qP qmyfUS6w8fiz4+A0wzXJOGc= X-Google-Smtp-Source: AAOMgpfrvsEVQ8aUiLHbtRrOa3/q6pl6VYfPAtZQBgXvqeahtwQNEXndHpfiJisfMQ/rPMwY8b8/rw== X-Received: by 2002:a2e:4186:: with SMTP id d6-v6mr2792817ljf.36.1532641095626; Thu, 26 Jul 2018 14:38:15 -0700 (PDT) Received: from [192.168.239.216] (83-245-232-26-nat-p.elisa-mobile.fi. [83.245.232.26]) by smtp.gmail.com with ESMTPSA id u4-v6sm387609ljh.36.2018.07.26.14.38.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jul 2018 14:38:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: <87tvol1z6h.fsf@toke.dk> Date: Fri, 27 Jul 2018 00:38:13 +0300 Cc: Dan Siemon , Dave Taht , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: References: <1357421162.31089.1531812291583@webmail.strato.de> <1c323544b3076c0ab31b887d6113f25f572e41ae.camel@coverfire.com> <87woth28rw.fsf@toke.dk> <87tvol1z6h.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Cake] =?utf-8?q?Using_cake_to_shape_1000=E2=80=99s_of_users=2E?= 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: Thu, 26 Jul 2018 21:38:17 -0000 > On 27 Jul, 2018, at 12:09 am, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 >>>> I haven't had time to try Cake in this context yet but hope to get = to >>>> that in the next couple months. I believe this will require one = Cake >>>> instance per-subscriber like we do with FQ-CoDel today. >>>=20 >>> Yup, currently it would. It might be possible to extend CAKE's >>> architecture to not require this, though. If you are interested in >>> pursuing this in the future, let us know; having someone actually >>> using it would be quite useful if we were to pursue development of = this :) >>=20 >> Yes, I'm very interested in this. A single QDisc would simplify = things >> quite a bit and hopefully be a perf win. >>=20 >> I'm happy to test this locally and with real subscribers once it is >> stable enough. >=20 > Cool. No promises as to when (or even if) I get around to looking at > this; but will ping you when/if I do :) Alternatively, I could look into it. I have time, but funding would be = nice. Perhaps if several organisations have some commercial interest in = the idea, they could pool some resources to keep my fridge stocked and a = roof over my head? It would also be valuable to have a firmer handle on the actual = requirements in the field. For example, if it is feasible to focus only = on current Linux kernels, then a lot of backwards compatibility cruft = can be excised when importing existing code from Cake. If all users = will have the same link-layer technology (with the same overhead = parameters), then these can be set globally - or if not, they can be set = per-tier. Is the Diffserv support from Cake likely to be useful, and if = so how flexible should the configuration be? And are there only a few = discrete settings for bandwidth per user, or do we have to be more = flexible to handle a BRAS environment? Is it also necessary to account = per-user traffic accurately, or will an external tool be used for that? Many other low-level considerations can be adjusted on the fly during = the conversion, so they are not in themselves a problem. In this = category are questions like "how many simultaneous users and flows can = be supported". There are ways to design the code so that it scales up = much more nicely in these dimensions than Cake does, at the expense of a = few extra CPU cycles per packet. - Jonathan Morton