Author: Alun Jones Date: To: users Subject: Re: [bitfolk] Configurable traffic throttling (was Re: predicted
network usage / "Predicted to exceed transfer quota")
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.
