Hi Kevin,
thanks for the information!
> On Mar 20, 2019, at 10:01, Kevin Darbyshire-Bryant
> <ke...@darbyshire-bryant.me.uk> wrote:
>
>
>
>> On 20 Mar 2019, at 08:38, Sebastian Moeller <moell...@gmx.de> wrote:
>>
>> Hi Kevin,
>>
>> Impressive! I had a look at your_layer_cake.qos, and with half the brain at
>> my disposal currently, I am confused. I had thought the idea is to set dscp
>> marks on internal hosts or the LAN interface ofva router and copy those to
>> incoming packets of the same flow, but you seem to set dscps in ingress.
>> What am missing?
>> I ask because I fully bought your cool-aid ;) I want a "mode" for sqm
>> scripts where easy to set and control egress dscp from internal hosts is
>> also used for ingress packets of the same flows. I also bought your argument
>> to preferably only do that once per flow hook line and sinker.
>>
>> AFAICT this is one feature that would solve a lot of issues regarding dscps
>> in home networks. Especially in the light of how easy it turned out to dscp
>> mark packets on windows10, and a lot of the potential dscp users come from
>> the gaming crowd and need something that works on Windows. Sidenote, I
>> really like how easy win10 makes it to dscp marks all egress packets of a
>> given binary, I wish I knew a similarly straightforward way to do this in
>> Linux and macosx....
>>
>> Thanks for this cool feature….
>
> Ha, ok, probably not helped by my commit message having get & set swapped
> with regards to the typical usage comments. I’ll try to go through it in
> context of my layer cake script.
>
>
> Egress is packet leaving router on wan interface to ‘Internet’
> Ingress is packet arriving at router on wan interface from ‘Internet’
>
> Egress packet goes through iptables mangle table, postrouting. It doesn’t
> have ’statemask’ bit set so is sent to the DSCP mangling rule where it may
> have had the DSCP changed..it doesn’t matter. Then it will hit conndscp
> running in ‘both’ mode. Internally conndscp will go through the ’set’ check
> first, where it will do nothing because the ’statemask’ bit is unset. Then
> it will go through the ‘get’ check, which it will go through, storing the
> DSCP into the mark and setting the ’statemask’ bit. This is then passed to
> cake as before which uses the DSCP to do tin selection.
>
> The ‘reply’ packet will come in on the ingress path. There it will hit
> conndscp which will find the conntrack entry and hence the mark. Conndscp is
> in ’set’ mode, so it will look at the ’statemask’ bit which is set and
> restore the mark stored DSCP into the diffserv field on the packet. The
> packet is passed on to the cake which uses the now restored DSCP to do tin
> selection.
>
> Subsequent egress packets will take this path: It goes through iptables
> mangle table, postrouting but this time the conntrack mark has the
> ’statemask’ bit set, so it is NOT sent to the DSCP mangling rules. Then it
> will hit conndscp running in ‘both’ mode. As before internally it look at
> the ’set’ code first and because the ’statemask’ bit is now set, it will
> restore the DSCP contained in the mark to the egress packet. The get action
> won’t run because the statemask bit is set. The packet is passed on to cake
> which will use the (restored) DSCP to do tin selection.
Ah, but why is that necessary, why not simply keep the DSCP on the
packet as is? Do you want to make sure that packet-captures on wan will show
the effective DSCP in case that differs from the application set DSCP?
>
> The ingress path is exactly the same as before.
>
> I suspect the subtlety is the ‘both’ action and its internal order of set ->
> get which allows the ‘one off’/’set forget’ type operation.
Much simpler, was/am puzzeled about lines like:
iptables -t mangle -A QOS_MARK_${IFACE} -p tcp -s 192.168.219.5 -m comment
--comment "Skybox DSCP CS1 Bulk" -j DSCP --set-dscp-class CS1
in the ingress section. with -s (source?) 192.168.219.5 this looks like it is
processed post-cake (due to ifb preceding iptables), so the packet looks like
it already is in the internal network, as if you would override the DSCP mark
just set by conndscp. That surely seems like a wrng interpretation, so I would
appreciate if you could walk me through the subtleties here. Thank you very
much in advance! Or am I just daft and this truly is intended to mark outgoing
packets and simply kives inside the ingress() function because it does not
really amtter as long as both shapers are set to rates >0?
>
> Does that help?
Yes, just not all the way, as I said half a brain ATM (aka a cold).
Best Regards
Sebastian
>
>
> Cheers,
>
> Kevin D-B
>
> gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
