From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id E966B21F8A5 for ; Tue, 6 Oct 2015 08:08:02 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t96F7ouN025574; Tue, 6 Oct 2015 08:07:50 -0700 Date: Tue, 6 Oct 2015 08:07:50 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Taht In-Reply-To: Message-ID: References: <0EB23696-5866-48C5-AC7E-B8570C7AA900@gmx.de> <561369A9.2090607@darbyshire-bryant.me.uk> <0F1BBA35-381C-4405-967A-3E266CFCC6F1@gmx.de> <87k2r02z4d.fsf@toke.dk> <87fv1o2yfj.fsf@toke.dk> <98210F4F-DBFA-4BF4-8184-F8C3446E5605@gmx.de> <87bncc2xxo.fsf@toke.dk> <40678341-B798-4832-95E5-2659E0EF24D2@gmail.com> <46314F4D-74CA-4E3B-9F92-63F8A4136C9B@gmx.de> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1757501216-1444144070=:2943" Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] flow_hash vs host_hash X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 15:08:27 -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. --680960-1757501216-1444144070=:2943 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT only if the bottleneck router that needs to do the queuing is directly adjacent to the endpoints. Yes, home routers commonly fit this definition, but since the usual case is a router/modem from the ISP with a wifi router plugged into it and the endpoints attached to the wifi router (wired or wireless), the ISP router/modem which has the actual bottleneck and should be doing the queuing isn't going to actually see the endpoint mac addresses. David Lang On Tue, 6 Oct 2015, Dave Taht wrote: > In most scenarios the top level hash for per station queuing on > ethernet would be > source or destination macaddr, thus bypassing ipv4 or ipv6. > > Then below that goes the 5 tuple. > > On Tue, Oct 6, 2015 at 12:59 PM, Sebastian Moeller wrote: >> Hi Jonathan, >> >> On Oct 6, 2015, at 10:44 , Jonathan Morton wrote: >> >>> >>>> On 6 Oct, 2015, at 11:39, Toke Høiland-Jørgensen wrote: >>>> >>>> Sebastian Moeller writes: >>>> >>>>> Ah, I see. I guess you are right, but on egress we could get back to >>>>> the pre-nat addresses, like Vincent does in nxt_routed_hfsc.qos? >>> >>> I can’t immediately see how that works. >>> >>>> Ah, so there is a hook to get those; cool. Just need to make sure Cake >>>> uses that, then :) >>> >>> I think the better solution would be to implement that in the flow dissector. Then Cake (and all other relevant qdiscs) will receive that information automatically. >> >> Certainly. But all of this hopefully does impede the implementation of the dual-flow-classifiying cake-mode; as even without those refinements the dual-mode should work well for IPv6 (assuming people do not game this by using excessive amounts of addresses per host) and non-NATed IPv4… >> >> Best Regards >> Sebastian >> >>> >>> - Jonathan Morton >>> >> >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake > > > > -- > Dave Täht > Do you want faster, better, wifi? https://www.patreon.com/dtaht > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --680960-1757501216-1444144070=:2943--