Dealing with datacaps; can burst help?

RouterOS General
1

Hi, this is more of a thought exercise.

Here is the premise - provider side marketing allows 1250GB data cap a month, anything more is overage. Client (or provider CPE) wants to use Mikrotik device to facilitate easy compliance with the data cap.
Here’s the though - 1250GB per month are constant load of 1866kbit symmetric (up and down each simultaneous). Setting a shaper to this speed is obviously detrimental to the user experience. If a device can track its usage and know when its usage is less than the average target it can build a reserve and when traffic passes it can allow borrowing from the reserve until it reaches zero and then stick to the average target, this will increase the user experience a lot.

e.g. max-limit=1886k burst-threshold=1866k burst-limit=500m bust-time=31days

the challenge is that per Mikrotik documentation average rate is calculated for the previous burst-time, so if you set it to 31 days, then it is useless: You can only get burst the next month for traffic unused this month, disregarding the limit of next month, e.g. does not work. If you set bust-time to 1s, then you can only build a reserve and borrow from the prior second, rather than from the entire current interval. Same goes for a day, week, etc. plus you can blow way past though the target.

With ros6 you can cobble a script with ip accounting that will check how much traffic has passed, calculate your “reserve” compared to the average, and project what the new speed limit should be, so that you don’t blow part it. Problem is a) it’s clunky, b) it diminishes the bandwidth speed needlesly as it must assume steady usage until the end of the period as to not cut service and c) there is no ip accounting in ros 7.

Has anyone found a non-braindead to enforce datacaps without allowing overage but without cutting user’s service or to have the average and burst work on current interval measurements (be running averages), rather than on previous interval?

Would Mikrotik be looking to add a feature to allow changing how the burst work, or outright data cap compliance feature, it will save a lot of heartburn for both users and small providers?

2

Interesting use-case, but I think everybody has moved to from stand-alone approaches (on the CPE itself) to centralized, API-driven solutions?
So all devices would report their usage to keep track of accounting centrally and through API/remote-control the cap would be enforced on the device.
Perhaps if you are a really small provider this makes things more complex/cumbersome ?

In ROS7, accounting may be gone, but “Kid Control” can be used in the same way to gather volume utilization and make decisions based on that.

3

True, for accounting central is the way to go, but that is also overage, and then billing, collection, etc.
This is to help give users the ability to enjoy good service when they are a good user, but stop them from blowing though the cap, and only take any action if they are actually over the cap by projection, and then don’t just kill the service completely.

Plus there are some home users that have their own CPE, and central API solutions are not helping them, but if a recipe can be given, then it’s easier for them, sometimes it is on a resold network, so not even integration possible network side.