From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 39D053B29E for ; Thu, 6 Apr 2017 04:39:11 -0400 (EDT) Received: from dlang-laptop ([10.2.0.162]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id v368d7r2003870; Thu, 6 Apr 2017 01:39:07 -0700 Date: Thu, 6 Apr 2017 01:39:07 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang-laptop To: Pete Heist cc: cake@lists.bufferbloat.net In-Reply-To: <2FD59D30-3102-4A3E-A38E-050E438DABF0@gmail.com> Message-ID: References: <2FD59D30-3102-4A3E-A38E-050E438DABF0@gmail.com> User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-167408565-1491467947=:3412" 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: Thu, 06 Apr 2017 08:39:11 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-167408565-1491467947=:3412 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 6 Apr 2017, Pete Heist wrote: > Suppose there is a cooperative ISP that has some members who access the network through a single device (like a router with NAT), while others use multiple devices and leave routing to the ISPs routers. (No need to suppose, actually.) > > There’s fairness at the IP address level (currently with esfq, maybe soon with Cake), but it's not fair that members with multiple devices effectively get one hash bucket per device, so if you have more devices connected at once, you win. 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’t see how it could be implemented. well, if the congested link is not the last-mile link to a user, the right answer is probably to increase the capacity of the link, and fairness issues would be a temporary thing until the link was upgraded. remember that the fairness is a means to an end, good reponsive service. As long as the result is responsive for all users, a bit of unfairness is acceptable. David Lang > Is it possible to customize the hashing algorithm used for flow isolation, either with Cake or some other way? > > The only options I can think of now: > > - force each member to use only one IP address (probably impractical at this point with hundreds of members) > - use one queue per member in an HTB hierarchy, for example, with filters matching each member’s devices, but that seems difficult to manage > - wait years for IPv6 deployment, allocate subnets to each member and wait for qdiscs that have the ability to hash by IPv6 subnet :) > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --8323328-167408565-1491467947=:3412--