[Cake] flow_hash vs host_hash

[Cake] flow_hash vs host_hash

[Dave Taht]

as near as I can tell, in the current codebase there is no need to
calculate the host_hash, as it is thrown away.

https://github.com/dtaht/sch_cake/blob/master/sch_cake.c#L303

Enlightenment sought.

-- 
Dave Täht
Do you want faster, better, wifi? https://www.patreon.com/dtaht

Re: [Cake] flow_hash vs host_hash

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 97 bytes --]

It's a precursor to the dual host/flow isolation, which I'm still working
on.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 144 bytes --]

Re: [Cake] flow_hash vs host_hash

[Sebastian Moeller]

Hi Jonathan,

On Oct 5, 2015, at 14:30 , Jonathan Morton <chromatix99@gmail.com> wrote:

> It's a precursor to the dual host/flow isolation, which I'm still working on.

	I believe that this is the single most asked-for feature in the openwrt forums, people somehow want to enforce per internal-IP fairness. I am not sure whether all/most people actually need this, since only a few have tries pure flow-isolation before declaring per-internal-SRC-IP fairness a requirement. But once this is in (and we get cake into openwrt default builds), you will have saved a considerable amount of people gray hair ;) Just to be clear, I am a huge cake fan (despite my occasionally sceptic emails about obscure side issues) and hope with the dual isolation cake will offer almost everything a typical user might actually want (well, except the ponies)

Best Regards
	Sebastian

> 
> - Jonathan Morton
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] flow_hash vs host_hash

[Dave Taht]

I would like the dual-flow pony in this net-next merge window please.

Otherwise I am sore inclined to get what we have out there! I hope to
get the api and abi changes in today or tomorrow for the bits I
understand....

On Mon, Oct 5, 2015 at 2:45 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Jonathan,
>
> On Oct 5, 2015, at 14:30 , Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> It's a precursor to the dual host/flow isolation, which I'm still working on.
>
>         I believe that this is the single most asked-for feature in the openwrt forums, people somehow want to enforce per internal-IP fairness. I am not sure whether all/most people actually need this, since only a few have tries pure flow-isolation before declaring per-internal-SRC-IP fairness a requirement. But once this is in (and we get cake into openwrt default builds), you will have saved a considerable amount of people gray hair ;) Just to be clear, I am a huge cake fan (despite my occasionally sceptic emails about obscure side issues) and hope with the dual isolation cake will offer almost everything a typical user might actually want (well, except the ponies)
>
> 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

Re: [Cake] flow_hash vs host_hash

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On 05/10/15 15:01, Dave Taht wrote:
> I would like the dual-flow pony in this net-next merge window please.
>
> Otherwise I am sore inclined to get what we have out there! I hope to
> get the api and abi changes in today or tomorrow for the bits I
> understand....
>
The view that it should just get out there has already been expressed.

Silly question time (IPv4): This dual flow host isolation pony, how will
it work on the WAN facing link on a 'domestic' router when the WAN side
is post NAT.  Won't the ip source address just be the router's external
interface?  But let this question not distract from proper coding not
the semi-intelligent cut'n'paste stuff that I do.




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] flow_hash vs host_hash

[Sebastian Moeller]

Hi Kevin,

On Oct 6, 2015, at 08:26 , Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:

> On 05/10/15 15:01, Dave Taht wrote:
>> I would like the dual-flow pony in this net-next merge window please.
>> 
>> Otherwise I am sore inclined to get what we have out there! I hope to
>> get the api and abi changes in today or tomorrow for the bits I
>> understand....
>> 
> The view that it should just get out there has already been expressed.
> 
> Silly question time (IPv4): This dual flow host isolation pony, how will
> it work on the WAN facing link on a 'domestic' router when the WAN side
> is post NAT.  Won't the ip source address just be the router's external
> interface?  But let this question not distract from proper coding not
> the semi-intelligent cut'n'paste stuff that I do.

	I believe you nailed it, but the pony will still work on egress, and a sufficiently motivated user can instantiate sqm on an inward facing interface so that the real ingress (from the users perspective) will be processed after NAT. Also as you allude to IPv6 should work out of the box. I believe there were rumblings on net-dev to hook up iptables with the ingress qdisc, which in the long run might allow to get the de-NATed addresses from packets arriving on an IFB device (or it might not, who knows ;) ). In any case we should write up some documentation about the expected behavior and configuration options for the dual-isolation option, once it lands...

Best Regards
	Sebastian


> 
> 
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] flow_hash vs host_hash

[Toke Høiland-Jørgensen]

Sebastian Moeller <moeller0@gmx.de> writes:

> 	I believe you nailed it, but the pony will still work on egress,

Don't packets hit the qdisc after NAT has been applied?

-Toke

Re: [Cake] flow_hash vs host_hash

[Sebastian Moeller]

Hi Toke,

On Oct 6, 2015, at 10:13 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@gmx.de> writes:
> 
>> 	I believe you nailed it, but the pony will still work on egress,
> 
> Don't packets hit the qdisc after NAT has been applied?

	As far as I know not for IFBs; that is the reason why we need tc filters on ingress and can not use netfilter. And why using iptables to map the DSCP to zero will still result in our shaper seeing the DSCP markings from upstream (which I could confirm happening for IPv6, as my ISP conserved flent’s DSCP marks, so I saw nice priority band based stratification in flent's graphics). I think that IFBs predecessor IMQ was different in that regard.

Best Regards
	Sebastian

> 
> -Toke

Re: [Cake] flow_hash vs host_hash

[Toke Høiland-Jørgensen]

Sebastian Moeller <moeller0@gmx.de> writes:

> Hi Toke,
>
> On Oct 6, 2015, at 10:13 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>> Sebastian Moeller <moeller0@gmx.de> writes:
>> 
>>> 	I believe you nailed it, but the pony will still work on egress,
>> 
>> Don't packets hit the qdisc after NAT has been applied?
>
> 	As far as I know not for IFBs; that is the reason why we need tc filters
> on ingress and can not use netfilter. And why using iptables to map the DSCP to
> zero will still result in our shaper seeing the DSCP markings from upstream
> (which I could confirm happening for IPv6, as my ISP conserved flent’s DSCP
> marks, so I saw nice priority band based stratification in flent's graphics). I
> think that IFBs predecessor IMQ was different in that regard.

No, I meant on egress...

-Toke

Re: [Cake] flow_hash vs host_hash

[Sebastian Moeller]

Hi Toke,


On Oct 6, 2015, at 10:28 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@gmx.de> writes:
> 
>> Hi Toke,
>> 
>> On Oct 6, 2015, at 10:13 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>>> Sebastian Moeller <moeller0@gmx.de> writes:
>>> 
>>>> 	I believe you nailed it, but the pony will still work on egress,
>>> 
>>> Don't packets hit the qdisc after NAT has been applied?
>> 
>> 	As far as I know not for IFBs; that is the reason why we need tc filters
>> on ingress and can not use netfilter. And why using iptables to map the DSCP to
>> zero will still result in our shaper seeing the DSCP markings from upstream
>> (which I could confirm happening for IPv6, as my ISP conserved flent’s DSCP
>> marks, so I saw nice priority band based stratification in flent's graphics). I
>> think that IFBs predecessor IMQ was different in that regard.
> 
> No, I meant on egress...
> 
> -Toke

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?

Best Regards
	Sebastian

Re: [Cake] flow_hash vs host_hash

[Toke Høiland-Jørgensen]

Sebastian Moeller <moeller0@gmx.de> 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?

Ah, so there is a hook to get those; cool. Just need to make sure Cake
uses that, then :)

-Toke

Re: [Cake] flow_hash vs host_hash

[Jonathan Morton]

> On 6 Oct, 2015, at 11:39, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Sebastian Moeller <moeller0@gmx.de> 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.

 - Jonathan Morton

Re: [Cake] flow_hash vs host_hash

[Sebastian Moeller]

Hi Toke,

On Oct 6, 2015, at 10:39 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@gmx.de> 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?
> 
> Ah, so there is a hook to get those; cool. Just need to make sure Cake
> uses that, then :)

	I have not done sufficient research, but I think that this requires the net filter conn track module to be available? So this does not seem generally available, though we might be able to make this a requirement for sqm-scripts (if Vincent did not already do so).

Best Regards
	Sebastian

> 
> -Toke

Re: [Cake] flow_hash vs host_hash

[Sebastian Moeller]

Hi Jonathan,

On Oct 6, 2015, at 10:44 , Jonathan Morton <chromatix99@gmail.com> wrote:

> 
>> On 6 Oct, 2015, at 11:39, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> Sebastian Moeller <moeller0@gmx.de> 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
> 

Re: [Cake] flow_hash vs host_hash

[Dave Taht]

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 <moeller0@gmx.de> wrote:
> Hi Jonathan,
>
> On Oct 6, 2015, at 10:44 , Jonathan Morton <chromatix99@gmail.com> wrote:
>
>>
>>> On 6 Oct, 2015, at 11:39, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>
>>> Sebastian Moeller <moeller0@gmx.de> 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

Re: [Cake] flow_hash vs host_hash

[Jonathan Morton]

> On 6 Oct, 2015, at 15:51, Dave Taht <dave.taht@gmail.com> 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.

Not when we’re talking about a router connected to a separate modem over Ethernet, or some device that pretends to be Ethernet (as one of my 3G dongles does).  That’s a very common scenario, and it would hide all of the host information if it relied entirely on MAC addresses.

MAC addresses are more relevant to wifi links.

 - Jonathan Morton

Re: [Cake] flow_hash vs host_hash

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2245 bytes --]

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 <moeller0@gmx.de> wrote:
>> Hi Jonathan,
>>
>> On Oct 6, 2015, at 10:44 , Jonathan Morton <chromatix99@gmail.com> wrote:
>>
>>>
>>>> On 6 Oct, 2015, at 11:39, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>
>>>> Sebastian Moeller <moeller0@gmx.de> 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