[bitfolk] Configurable traffic throttling (was Re: predicted…

Hello,

On Thu, Feb 24, 2022 at 12:55:44PM +0000, Alun Jones via users wrote:
> On a wider note, I wonder whether configurable throttling would be handy. If
> someone does something that hammers my VPS, it'd be a comfort to know that,
> at the point you're (imminently) going to start charging me per GByte, I can
> have my bandwidth throttled down to limit how quickly that charge goes up.

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.

If someone is determined to send traffic to a BitFolk VM then a
filter has to be applied upstream at the far end of all of Jump's
transit and peering links to prevent that traffic getting on to
Jump's network and being chargeable to BitFolk and thus the
customer. Realistically this cannot be done except in cases of
denial of service and even then it's mostly done by dropping all
traffic to the destination IP, so that is a total outage for the
customer.

The good news is that most legitimate overage is outbound, because
the customer VM is serving something, so when the customer stops
doing that the traffic goes away.

Also outbound traffic is amenable to throttling and that can be done
inside the customer's VM or on the BitFolk side. Typically using the
"tc" command.

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.

For example, you don't normally want to set a hard limit on port
speed. 2TB in 30 days?

$ units "2TB/30 days" "megabits/sec"
        * 6.1728395

so set the port speed to 6Mbit/s and never go over quota? Well, yes,
but also then you never burst past 6Mbit/s even when you aren't
anywhere near your quota. Pretty sucky when it's easy to get near
100Mbit/s out of a VM for a single TCP conversation.

So then you start thinking, well, how about no throttling until say
75% of the quota is gone and then set the needed port speed so that
the last 25% can never be used.

Or use a token bucket filter to allow bursts but still maintain the
required average.

And so on.

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. :)

When customers are predicted to go over their quota or have gone
over it and are having problems locating the cause of it, I do
generally offer to limit their port speed or shut off network
completely, in order to control their costs.

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting