From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 DA6B63B2A4 for ; Fri, 7 Apr 2017 04:29:04 -0400 (EDT) Received: by mail-lf0-x241.google.com with SMTP id n78so5509848lfi.3 for ; Fri, 07 Apr 2017 01:29:04 -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=EGZEDLWbX3mndZn0DGS4RHA2LCsyBREixm00+M5DRtE=; b=bF2cabGNpD/d0CH4HEIiPMf+ssL0YaE0FUr6In3GGDN5xNh54O50Ts3mHMHkRRKmLI 3m666JtzvPOlHmHEYES7KRNFM/a4CQ0vVcJlnHHErZv8RSbrUMvNBA5W6J3EyFM8WVtF gE9wnQ1fMekWVp5byWvwfhA9a65T6mCWO/IvNae6medkjqlmuA9ijzDiQ9M1sEX4EBAO fenTUupMIaN2IZpPc59SeLe+9Z/zs0WGqQEWmypCJg1mwDc13u7dOSJA/i8pJgqIY7ch yRQW3V7Ji3qVeNa+7Tw3nxbjjcpDmUqsTD1omtXOEhiapxRqX0iLtYvLuIA+Umi802np cvnQ== 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=EGZEDLWbX3mndZn0DGS4RHA2LCsyBREixm00+M5DRtE=; b=CSgC+7dnZUh63iWzaEA9fX02lK3jDmuFXoCSYlwhNAReuOpVDF+bGiPC/p0hrhwtbX 5UQTl/9cHkxcl+I1Zm4IbpDm9YkGDkQfQmV5+AfMuCRk69iF4Fix6+03hIc98gdbna0Y aY8c6GQ+9DQPCgqCRgX35erWUDhAkvghHlKOkSLrcMqi2wntot9zY+0KNqBSS3QmVSXe 9eMVeLdCKfW1eJkMi0kqbBJVf8rXibH60hzKLweDssGII7tNNTwE1SWrAaRdKNG9xycM WS8VcKYeHwDnohST3J5dyKemjUJvqM/IeK2oSEPMmvg+P/c0q3+OdSzDNdPDnU2dgrGM Az7w== X-Gm-Message-State: AFeK/H1bzut6FxLHcBbrdGXajGEwHxURCOu9epw5LHsqKi5uoGp3qHkokdI2MyZ+nvbAiQ== X-Received: by 10.25.20.202 with SMTP id 71mr14255721lfu.102.1491553743402; Fri, 07 Apr 2017 01:29:03 -0700 (PDT) Received: from [192.168.100.11] (37-219-194-68.nat.bb.dnainternet.fi. [37.219.194.68]) by smtp.gmail.com with ESMTPSA id 85sm792538ljj.56.2017.04.07.01.29.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Apr 2017 01:29:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Fri, 7 Apr 2017 11:28:54 +0300 Cc: Cake List , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , =?utf-8?Q?Dave_T=C3=A4ht?= Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FD59D30-3102-4A3E-A38E-050E438DABF0@gmail.com> <6F118C46-16DB-48AC-A90D-7E6D44B6D069@gmail.com> <1E4563E2-63E2-419D-AFDD-8CD74F22539B@gmail.com> To: Pete Heist X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] flow isolation for ISPs 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: Fri, 07 Apr 2017 08:29:05 -0000 > On 7 Apr, 2017, at 11:13, Pete Heist wrote: >=20 >> On Apr 6, 2017, at 11:26 AM, Pete Heist wrote: >>=20 >>> On Apr 6, 2017, at 11:11 AM, Jonathan Morton = wrote: >>>=20 >>> On 6 Apr, 2017, at 11:27, Pete Heist wrote: >>>>=20 >>>> There is a table of member ID to a list of MAC addresses for the = member, so if there could somehow be fairness based on that table and by = MAC address, that could solve it, but I don=E2=80=99t see how it could = be implemented. >>>=20 >>> One option would be to use HTB with FLOWER filters to sort out the = subscribers into classes, and use Cake or fq_codel as a child qdisc per = class. Remember that Cake can be used in =E2=80=9Cunlimited=E2=80=9D = mode to rely on an external shaping source. >=20 > One more thought, would it be possible for Cake to optionally include = the packet=E2=80=99s mark in the hash? >=20 > I know it=E2=80=99s additional functionality, and another keyword, but = it could get you out of the business of the myriad of ways people might = want to do flow isolation, and you=E2=80=99d still have a catch-all = answer for such cases. >=20 > There could be a keyword =E2=80=98hash-mark=E2=80=99, let=E2=80=99s = say, which first includes the mark in the hash, then does on to deal = with any other flow isolation keywords as usual. So for example if I = have =E2=80=98hash-mark=E2=80=99 and =E2=80=98dual-srchost=E2=80=99, the = hash is first on the mark, then by source host, then by flow. I could = set the mark to be the member number with iptables. That isn=E2=80=99t really how hashing works; there is no =E2=80=9Cfirst, = second, third=E2=80=9D structure, just an accumulation of entropy which = is all mashed together. In order to run the triple-isolation algorithm = at all, I have to take separate hashes of the relevant host addresses, = alongside the general 5-tuple hash. However, it would be possible to use the =E2=80=9Cmark=E2=80=9D directly = as one of the host identifiers which triple-isolate operates on to = provide that layer of fairness. That=E2=80=99s probably what you meant. Since this wouldn=E2=80=99t unduly complicate the configuration = interface, it could be a feasible way of adding this functionality for = modest installations, up to a strict maximum of 1024 subscribers (and a = recommended maximum somewhat below that). > It looks like the mark could be obtained from the =E2=80=98mark' field = of the sk_buff struct, but I don=E2=80=99t know the validity of the = field in various cases. For example, I don=E2=80=99t think I can set the = mark on ingress before it reaches a qdisc on an IFB device. It has been suggested, in the context of using the =E2=80=9Cmark=E2=80=9D = for Diffserv purposes, that Linux=E2=80=99 conntrack facility could = preserve the mark between directions of flow. Cake can already query = conntrack for NAT awareness. - Jonathan Morton