Re: [PATCH RFC nf-next 0/3] named expressions for nf_tables

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Thu, Apr 07, 2016 at 11:49:42PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Several examples on how this would look from userspace:
> > 
> > * Add the 'tcp-counter' counter to the 'filter' table:
> > 
> >  # nft add counter filter tcp-counter
> > 
> > * Delete this counter (only possible if not dereferenced from a rule):
> > 
> >  # nft delete counter filter tcp-counter
> > 
> > * List existing named counters:
> > 
> >  # nft lists counters
> >  table ip filter {
> >         counter tcp-counter {
> >                 packets 6086 bytes 6278052
> >         }
> >         counter udp-counter {
> >                 packets 272 bytes 64690
> >         }
> >         counter icmp-counter {
> >                 packets 10 bytes 840
> >         }
> >  }
> 
> Can't you already create a 'named counter' via
> 
> chain tcp-counter {
> 	counter
> }
> 
> ?
> 
> Seems to me we only would have to teach nft list to
> allow filtering output on chain names, e.g.
> 
> nft list table filter \*-counter
> 
> to have something similar using exsiting feature set.

Right, but we still need a way to uniquely identify this stateful
expression for atomic dump'n'reset.

> > So far, only counters are supported, but it should be possible to
> > support named limits. I have another (imcomplete) patch that allows to
> > update the named expressions parameters, this can be useful to
> > dynamically update the ratelimiting policies, the command line should
> > look like:
> > 
> >  # nft update limit name user01234 rate 250 mbytes/day
> 
> Similar comment here, you could create
> 
> chain user01234 {
> 	limit rate 100 mbytes/day
> }

Right, we can replace this rule via the handle, but I see two problems
with this:

1) The user needs to track the rule handle, not so much of a problem
   since userspace can do this at the cost of a bit of more
   complexity.

2) When replacing the rule, the new expression starts from no history
   as it will be a new expression, we'll be basically reseting it.

Using 'nft update limit...' I think we should be capable of upgrading
the ratelimit by keeping around the quota that the user has already
consumed.

The idea is, if we know the previous cost of every byte/packets in
terms of tokens, given that tokens are generated per nanosecond and
that know how many tokens we have already consumed, then we can
recalculate the quota that has been already consumed and add this to
the limit update, eg. if limit rate is 100 mbytes/day but the user
already consumed 50 mbytes, when calling:

        nft update limit rate 200 mbytes/day

we can keep the 50 mbytes that were already consumed around.

Let me know, thanks.