From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 6BC433B2A0 for ; Tue, 29 Mar 2016 19:31:15 -0400 (EDT) Received: by mail-ob0-x22d.google.com with SMTP id x3so34199189obt.0 for ; Tue, 29 Mar 2016 16:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ADwQs+jTH1W3GR3AXzqKOPDPvbuwewU1PP+ncSwwPOE=; b=hJ0eG4pmtlgoGkS5DXbf943zy0jqkCg7UjWjQz/8W5mFndzj+L1o2aYo5MQaD/cYfR P+Kr+xx9smjyuSC5KSbPmVkXUwyC6aDR3i3jmaoeqg3av+UCPtoYLdtmSTpz3cChpGaD bqaTM1pI/p81F/O0gJePdNbLJm7sHgLeMRVRmYSpsoGI3C+hEMEdYbGiHNnT8tFxkmqE AyLjXFG9eNbCoYyDsj9ORa8Pg73IAh1Q0AnULbu0bicD8lTxP2a5H/7EVTRkbYturajX 6FwWYSWwJdLUq7tI003sJjU0dB2qNl2pSznc8agHWSeN+6qGfxrzbOYAiSnQ6I7joCG3 xl0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ADwQs+jTH1W3GR3AXzqKOPDPvbuwewU1PP+ncSwwPOE=; b=M7F3p8e+jCyyEtlUVItmuMTScMu+C+OL6zNmpRR7a0rtp0XEjVDbyj1gLg8dFsG/b6 HzUSHXp9dudC7I2MsOR7yumRV2Wo4Lohv0My0gbPI2bkFm1dLLpgiCex5YttFYwocsrb 1V2Vd1M4VJJzSdekJrKwxalAQpYzTBMmVTjtlqcAGzw2Vls2y9ID+2KTDKHyI/poAVRf 28zCgDtqvJPa+SYDTrMsp+HQd82M10+hRnWLVvB2RORxGXdEMEcVlauqtNhHyRRk4CVe mJAhSWQQvNIPva3p3YBBSNxF3GBQg9I+TK2r4rqBcpey/1at9r1DkFMePhNq5bUXH+zB BVwQ== X-Gm-Message-State: AD7BkJK8LNAYT1IHa7ekcHXaAYpDdXz9Fzdh2c6P2u9mSvJZFCPK6CWIvQVGUexPoY4DfoyOdKKoFwJEccWE+g== MIME-Version: 1.0 X-Received: by 10.182.225.168 with SMTP id rl8mr2644497obc.57.1459294274772; Tue, 29 Mar 2016 16:31:14 -0700 (PDT) Received: by 10.202.168.129 with HTTP; Tue, 29 Mar 2016 16:31:14 -0700 (PDT) In-Reply-To: <87lh51bjx9.fsf@toke.dk> References: <34953EAA-4C76-456E-9B9E-3A73D0DACCDE@gmail.com> <855E3354-30E6-4658-AF38-A0C1E92085CE@gmail.com> <66A00804-E571-4A44-BE3E-422F78C1F1F7@gmail.com> <198CD4FC-6BD4-40DA-BE2F-22BBBA1E204D@gmail.com> <20160328140104.3c55079e@xeon-e3> <87lh51bjx9.fsf@toke.dk> Date: Tue, 29 Mar 2016 16:31:14 -0700 Message-ID: From: Dave Taht To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Jonathan Morton , cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Subject: Re: [Cake] cake separate qos for lan 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: Tue, 29 Mar 2016 23:31:15 -0000 An overall ISP in tc need exposed by this discussion is some means of mapping multiple ipv4 and ipv6 addresses and netmasks into something that will return a (key,value) pair. This would work something like ipset does, although what you would return is not "present or not" but present and a value insert customers 1.1.1.1,1 insert customers 2001:db1::/64,1 insert customers 2.2.2.2,2 insert customers 2001:db2::/64,1 then on the relevant path you'd set up the qdisc hierarchy and do a lookup into that to get the right number to go to the right cake instance. You'd also have to do a longest prefix match into the above, so a 1x1 hash won't do. the massive tc filter option discussed already does not scale to a random number of customers with randomly different numbers of ip addresses, types, and netmasks. Code like this must exist in dedicated devices already, CMTSes, BRASes, deep packet inspection devices, etc. Secondly, in the case of cake the hierarchy could just be a bunch of somewhat unassociated queues, not htb or drr, letting cake do the scheduling of deliveries. Regrettably I know of few ISPs that are actively using linux in any way they have sources to. I suspect a few dslams are linux based, but nobody's talking. ... Another way to maybe get there is to use the ip route functionality instead and send stuff to virtual devices layered on top of the real device. ip route add from :: to 1.1.1.0/24 dev dev1 ip -6 route add from :: to 2001:db1::/64 dev dev1 ip -6 route add from :: to 2001:db2::/64 dev dev2 ip route add from :: to 2.2.2.0/24 dev dev2 Then the reverse would be out one of two devices, one device configured for the "fast, local cache server", the other for the regular internet. solution too long to fit in the margins of this email.