24 Feb
2022
24 Feb
'22
2:23 p.m.
Andy Smith said:
Just on this point: it's not easy to throttle traffic that is sent
TO a customer (traffic police), because that is not in the control
of either BitFolk or the customer.
Indeed. Been there (at work) :-)
However, I have not seriously thought about offering
that as a
setting on the panel because this situation happens rarely and
traffic throttling is quite complex. It feels like either it would
need to be simplified to the point of being quite poor and blunt > instrument, or else
it would be dauntingly complex.
I was thinking in terms of a very blunt instrument indeed. e.g. "if over
quota, limit rate to (say) 2MBits", maybe with a tick box that says "I
acknowledge it this time around - remove the throttle until the next
accounting period starts". So, if (serving) something takes me over
quota, my liability is under 6p/hour until I do anything about it.
With all of this achievable from within the
customer's VM, I kind of
don't want to get into it from BitFolk's side. :)
Also perfectly sensible. Again, availability of your accounting data
would make the VM side of things easier.
I've been thinking a bit about how I could maintain my own stats, over
lunch. The easiest way of getting a raw count (in my setup) would just
be ip(6)tables rules in the INPUT, FORWARD and OUTPUT chains. Just use
the counters from those. But then I started thinking about when the VM
reboots (or I reload the firewall) and then started thinking about
recording to a database. Catching edge cases like this does make it less
trivial than just scraping your existing, definitive data from somewhere.
Cheers,
Alun.