[Cake] Using firewall connmarks as tin selectors

[Kevin Darbyshire-Bryant]

Be afraid, be very afraid.

I’ve woken up with two ideas in my head, one is bad, the other is very bad.  The bad one is already implemented and lurking in the mine branch of my cake git tree:

The bad idea:

An extension of the ‘fwmark’ tin allocation idea is to get cake to automagically update the conntrack mark based on the DSCP tin allocation chosen on egress.  That way, well behaved applications using DSCP (e.g. dropbear) get their return path packets similarly classified on ingress.  Badly behaved applications can have iptables rules put in place to ‘manually’ add fwmarks as is already done.


The very bad idea:

And it’s bad ‘cos it’s sort of incompatible with the existing fwmark implementation as described above.  So an awful lot of our shenanigans above is due to DSCP not traversing the internet particularly well.  The solution above abstracts DSCP into ’tins’ which we put into fwmarks.  Another approach would be to put the DSCP *into* the fwmark.  CAKE could (optionally) copy the FWMARK contained DSCP into the diffserv field onto the actual packets.  Voila DSCP traversal across ’tinternet with tin/bandwidth allocation in our local domain preserved.


> On 28 Feb 2019, at 03:24, gamanakis at gmail.com wrote:
> 
> I think it's much simpler to use than tc-filter, BPF or even DSCP bits.
> Manipulating DSCP bits seems the simplest of the currently available mechanisms to classify traffic. Even in this case, fwmarks are essentially simpler.
> E.g. if you want to classify outgoing traffic on the LAN interface:
> with DSCP you need to manipulate DSCP bits on incoming packets on the WAN interface. 
> with fwmark you can directly mark outgoing packets on the LAN interface and cake will classify them appropriately.
> 
> 
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A