Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multiple service classes #426

Open
syadnom opened this issue Nov 23, 2023 · 2 comments
Open

multiple service classes #426

syadnom opened this issue Nov 23, 2023 · 2 comments
Labels
enhancement New feature or request
Milestone

Comments

@syadnom
Copy link

syadnom commented Nov 23, 2023

I'm looking for a way to offer multiple service classes. This most likely means different commit rates, not any sort of 'priority' (premium plan demand doesn't cut in line, it just claws back the extra).

I was thinking, what about having an integrations file integrationUISPserviceclass.csv that could include the service plan name from UISP and the ratio of max vs commit or maybe a multiplier for burst on that plan. UISP actually has a burst option so that could be used as well, setting the plan speed as the commit and the burst as the limit.

Basically a means to alter the HTB allocations for each child queue based on service class.

~~

some rational to this request. I would rather end users USE the service, get their data and get off the wire sooner. I'm currently selling a number of 25x5 (prov 30x7) as a base line package so that they don't use up service that higher speed plans would like. In the current model of libreqos as well as other products, it's basically just the service speed that it uses in the HTB or the commit is a fixed % of that speed. So to let those 25x5 users use up what's available on the AP when there's excess capacity, they have to have a higher speed plan, however for the cheaper price I really need them to get dialed back to their commit rate when the AP is under pressure.

Might look like
20x 25x5 users
5x 100x20 users.
mostly idle AP, but one of the 25x5 users is pulling in a game update. I would like to offer them access to the 100 speed plan since it's available.
however, if a couple of the 100x20 users pop on, I need to pull the 'extra' given to the basic plan back to satisfy the premium package.

Further, I would like to give the 100x20 users access to basically the AP's capacity when it's available. So if it's a 160M capable AP, then I probably want them to have a 150x50 commit 100x20, and the base users have a 100x20 commit 25x5 plan.

I find that fairly often I'm looking at APs that have 1-2 users at max plan speed but airtime on the AP is like 25% and the head end is also at 25%. Why not make this available. I'd likely offer it as a minor upgrade on a plan, ie get the 25x5 standard plan or for 5-10 get the 'boost' version of that plan, sort of a in-between to the next higher plan.

@rchac rchac added the enhancement New feature or request label Nov 2, 2024
@rchac
Copy link
Member

rchac commented Nov 2, 2024

Idea: we can use the HTB priority field

@rchac rchac added this to the v2.0 milestone Nov 2, 2024
@syadnom
Copy link
Author

syadnom commented Nov 2, 2024

I'm not sure if I can answer that. Can you change the priority on the non-commit?

Honestly, I think Herbert's updates to bursting sort of do most of the work here. ie, residential might be on 10x5 commit and burst to 100x20 while business is on 20x20 burst 100x50.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants