owncloud
[Feature Request] Bandwidth Quota Per User (Download/Upload)
Feature Request: Bandwidth Quota Per User
You must understand the difference between Network Speed vs. Bandwidth: https://obkio.com/blog/network-speed-bandwidth-throughput/#understand-the-difference-network-speed-vs-bandwidth-vs-throughput
Is your feature request related to a problem? Please describe.
A possible failure state of an OwnCloud Infinite Scale instance is exceeding the amount of Network Bandwidth provided by an ISP or Cloud service provider. For example, a Cloud service provider such as Digital Ocean may let a single virtual machine transfer 1TB over a month (download and upload bandwidth) at 10 Gbps (Network Speed). So if a user exceeds this amount, OwnCloud Infinite Scale could experience errors due to the server it's hosted on.
Configuring a reverse proxy at the server level does not prevent a single user from using all the bandwidth (on purpose or by accident). So it would be helpful to have a bandwidth quota per user that works in a similar manner to the NextCloud Storage Quota. This solution would prevent a single user from using all of the bandwidth of the server that the OwnCloud Infinite Scale instance is hosted on.
Describe the solution you'd like
Add a setting "Bandwidth Quota" that lets the administrator configure a bandwidth quota (both, download, upload) per user. Enabling this setting tracks the bandwidth usage of the user's uploads and downloads to prevent them from exceeding the specified bandwidth limit. When a user exceeds the bandwidth limit, notify them so an administrator can be contacted to review what happened.
Describe alternatives you've considered
Limiting the Network Speed (per user) is useful for download/upload consistency, but does not prevent the user from exceeding bandwidth unless you set the speed so low that the file size of downloaded/uploaded files will be limited over a specific time period.
@wkloucek @switchupcb That looks very heavy on the first look for me.
- How do we find out what the current total bandwidth is?
- How do we react to changes in the current total bandwidth?
Using simple rate limiting per user would be more straightforward IMHO
Limiting the Network Speed (per user) is useful for download/upload consistency, but does not prevent the user from exceeding bandwidth unless you set the speed so low that the file size of downloaded/uploaded files will be limited over a specific time period.
From a user perspective this would be more desirable I guess. There could be some grace bytes after which a rate limit kicks in. NGINX for example has something like this: https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_rate
One question that I have to the use case in general:
For example, a Cloud service provider such as Digital Ocean may let a single virtual machine transfer 1TB over a month (download and upload bandwidth) at 10 Gbps (Network Speed). So if a user exceeds this amount, OwnCloud Infinite Scale could experience errors due to the server it's hosted on.
How much space-quota do users have? Because if they only had 50GB, a single user would need to up- / download all those files several times to exhaust the transfer quota of 1TB. You should probably define "fair use policies" in this case and just ban users that misuse your service?
- How do we find out what the current total bandwidth is?
- How do we react to changes in the current total bandwidth?
Using simple rate limiting per user would be more straightforward IMHO
I agree, this would introduces a lot of (external) state. I also don't know if this is a limitation we should focus on. Eg. on DigitalOcean a droplet with 2TB Transfer is 6-8$ more than a droplet with 1TB transfer (while doubling the CPU and RAM, see https://slugs.do-api.dev/) If you'd use eg. Hetzner Cloud, there is 20TB included.
on DigitalOcean a droplet with 2TB Transfer is 6-8$ more than a droplet with 1TB transfer... Hetzner Cloud — @wkloucek
Using simple rate limiting per user would be more straightforward IMHO — @micbar
How much is a 100 TB transfer server?
You can use the suggested https://nginx.org/en/docs/http/ngx_http_core_module.html#limit_rate to limit each client to 38 MB transfer per second.
- 2 clients (e.g., phone and laptop) are limited to 14 MB per second.
- 3 clients are limited to 12 MB per second
- 4 clients are limited to 9 MB per second.
- 5 clients are limited to 7.6 MB per second.
- 6 clients are limited to 6.3 MB per second, repeating of course.
- 10 clients are limited to 3.8 MB per second.
- 20 clients are limited to 1.9 MB per second.
Here is the same calculation using a 20 TB server.
- 2 clients (e.g., phone and laptop) are limited to 3.8 MB per second.
- 4 clients are limited to 1.9 MB per second.
- 6 clients are limited to 1.26 MB per second, repeating of course.
- 10 clients are limited to .76 MB per second.
Which option do you prefer (when each client will not use the server for more than 16 hours a day)?
- A 25 MB .wav file takes 32 seconds to download on a bandwidth limited per client 20 TB bandwidth server with 10 clients.
- A 25 MB .wav file can take 1/4th of a second to download on a network speed limited per client 10 GBps server with 10 clients.
You should probably define "fair use policies" in this case and just ban users that misuse your service? — @wkloucek
How would you be determine who is "misusing" your service without tracking bandwidth per user?
Suppose a non-technical user uses the bandwidth of a server.
Your solution is to ban them and buy ($) a server with more transfer quota.
You have focused a solution around upgrading the server with money so that it can handle the bandwidth used, but there is no way for you to determine how much bandwidth can be used unless you make multiple assumptions or set limits (e.g., to max network speed per user).
Buying more transfer quota doesn't stop a user from using more transfer quota. A bandwidth or network limit does.
How much space-quota do users have? Because if they only had 50GB, a single user would need to up- / download all those files several times to exhaust the transfer quota of 1TB. — @wkloucek
You cannot assume the size of the files in the OCIS instance.
You assert that a user must download and re-upload files multiple times to hit a 50GB limit, when there are multiple cases where this is not true.
Suppose that one compressed file is 200MB (e.g., music trackouts). A 50GB transfer limit would let you transfer 250 "files" once. 20 transfers is 1 TB.
Your solution is to increase the amount of TB the server can transfer.
This only works when either a bandwidth limit or network limit is in place for each user to account for the total amount of TB the server can transfer.
Add a setting "Bandwidth Quota" that lets the administrator configure a bandwidth quota (both, download, upload) per user. Enabling this setting tracks the bandwidth usage of the user's uploads and downloads to prevent them from exceeding the specified bandwidth limit. When a user exceeds the bandwidth limit, notify them so an administrator can be contacted to review what happened.
That's a bad solution. By the time the admin reacts, the damage is already done. The system should take appropriate action automatically.
In any case, limiting the bandwidth ourselves is too complex if we want to implement it in a meaningful way:
- Users should maximize their available bandwidth. There is no reason for a user not to use the full bandwidth if he's the only one downloading.
- Using a fixed bandwidth will cause a bad UX.
- If we have a 1Gbps speed, assigning a maximum of 1Mbps per user to each of the 1000 users (to ensure we always stay within the limits) looks bad, specially if there is only 1 person downloading. It gets worse the more users are in the system.
- If we have a 1Gbps speed, and there are people with 100Mbps, is pretty easy to go over the limit. This means that, not only we don't fix the problem, but also we cause a bad UX because the user could be downloading faster.
- Using a dynamic approach seems the way to go (basically assign bandwidth based on the current number of users). The problem here is that it's too complex to implement it properly, and the benefits don't seem worthy the effort.
- We need a constant and precise monitoring of the users downloading and / or uploading files. A wrong user count implies wrong bandwidth assignment, which means we either hit the limit (causing problems) or the bandwidth is underused (bad UX)
- Values must be adjusted on-the-fly. UserB might start a download while userA is still downloading, so userA needs to have his bandwidth reduced to let userB download the file.
- The solution must scale. It must work with multiple replicas, so there must be some way of communication among them. Replica1 might have 4 users downloading and replica2 might have 3; the total bandwidth must be split among the 7 users, not just the 3 or 4 that a replica sees.
Taking into account that avoid hitting the limit will be too difficult, a simple rate limiter should be a solution good enough if we want to prevent a couple of users from abusing the system. It should also have a predictable behavior, which makes it ideal in order to know whether the solution works or not. We'll hit the bandwidth limit, but I don't think we should make it our problem, and we should let others (the hoster or the internet provider) to deal with it.
Regarding the transfer quota, I think it still has the same problems than the bandwidth quota. You either split the transfer size among the users somehow, or you're at risk of hitting the transfer limit.
In addition, we're loading data constantly. Even if the pages are cached in the browser, there is data that must be fetched from the server which must count towards the transfer limit. It might not be much but it will mess up with the calculations and we'll hit the transfer limit if we don't take it into account. The additional problem is what to do if we hit that limit. If we're strict, the app will be dead because we can't get data from the server.
My point is that the goal of a transfer quota must NOT be paying less money by avoiding hitting some hosting limit.
If we have a 1Gbps speed, assigning a maximum of 1Mbps per user to each of the 1000 users (to ensure we always stay within the limits) looks bad, specially if there is only 1 person downloading. It gets worse the more users are in the system. — @jvillafanez
You must understand the difference between Network Speed vs. Bandwidth: https://obkio.com/blog/network-speed-bandwidth-throughput/#understand-the-difference-network-speed-vs-bandwidth-vs-throughput
My point is that the goal of a transfer quota must NOT be paying less money by avoiding hitting some hosting limit. — @jvillafanez
The goal of a bandwidth quota is to address a security issue.
OwnCloud Infinite Scale can experience errors when it exceeds the amount of Network Bandwidth provided by the hosting server.
What is your solution when you hit a hosting limit? You have Jeff Bezos number or what?