I have about 6 services all using https ports. Some I want low priority (aka CrashPlan) others high priority (aka Video Streaming like Netflix or Apple, or other VPNs)
Since Peplink QoS is only on ports makes it hard to prioritize. If I could make things high or low based on IP src and/or dst then I could target those services.
Hi Michael, I see where you’re coming from, and its something we’ll definitely review in upcoming development planning meetings.
In the meantime you might be able to take advantage of the QoS user groups to achieve something along those lines.
As you know we currently support three QoS user groups (Manager, Staff & Guest), and membership of these groups can be defined by source IP/Subnet. You can then apply custom application prioritisation for each User group.
So lets say you have a PC that runs a SSL VPN client, a Smart TV that streams video over SSL and a server running Crashplan (again SSL). You could identify them as being members of different groups (PC in Admin, Smart TV in Staff, and crashplan server in Guest) then set the application level QOS to reflect which device should get the highest priority HTTPS traffic (high for SSL VPN, normal for the TV and low for crashplan). it would end up looking like this:
Hope that is of some help for now. Thanks for your feature request!
As you know we currently support three QoS user groups (Manager, Staff & Guest), and membership of these groups can be defined by source IP/Subnet. You can then apply custom application prioritisation for each User group.
I wish this was true on all devices—it doesn’t appear to be available on my Balance 20 running 6.1.2 build 2717.
This is just one example of a larger issue for your customers. I really don’t understand why so many features aren’t presented to all customers using the same firmware. It’s not like someone with a “lower class” device wouldn’t want/need the same feature set as other installations. I would imagine it would greatly simplify firmware releases/testing, sales and customer service if the great divide of features were eliminated. Sure, charge more for the more advanced / complex hardware solutions but let the same software be used everywhere it could possibly be used… putting the customers in charge of deciding what to turn on/off for their current needs.
/Marty
You’re right of course, user group bandwidth control is only available on the B305 and above -apologies, I should have checked which model balance you were using.
I agree that in a perfect world we would have all features available across all of our devices, and you’re right when you say that this would make things easier for us from a firmware management (and sales/support) perspective. The main reason why this isn’t the case is hardware resource availability across the different hardware platforms in each product line.
We’ve been developing new software capabilities in our products since our inception in 2004, with our developers furiously working on new product features and capabilities adding them to new hardware products as we build them. Each year has seen new hardware platforms with faster processors, more RAM, new network controllers, embedded modem modules and in the case of the mediafast product range the addition of SSD storage for local active web caching.
Every time a new feature is developed it is tested and bench marked by our QA department. They run tests on the new feature/capability and monitor the key hardware consumption metrics (eg CPU, Memory and network usage) consumed by the feature under normal, heavy, and extreme usage. The results of these tests are then passed to the product management team who compare the hardware resources required by the feature against the available resources of each hardware platform in the full product range, and then they decide which platforms have the hardware capacity to cope with the new feature.
At that point, the feature/capability is flagged as to its suitability for inclusion in the respective products. Some products are simply not capable of supporting every feature we currently have available across the whole product line, either because required hardware is missing, or because there are not enough resources available to cope with running every feature simultaneously. That said, sometimes we will add the feature anyways, but limit its use so that it doesn’t overwhelm the available resources. The number of supported SpeedFusion profiles on a device is a great example of this (since SpeedFusion with its AES encryption and packet level routing is resource intensive), with lower end SF enabled devices (with less hardware resources available) supporting 2 remote peers and high end devices supporting as many as 4000 peers.
Our primary aim then in restricting the number of features available in the entry level products is to make sure that our customers always get the best possible user experience, whilst taking into account the underlying capability (and ultimately the limitations) of the devices available hardware resources. It becomes a balancing act where we need to choose the right combination of available features and hardware, whilst keeping in mind the target customer demographic and how much they would be happy to pay for it. At the end of the day, we need to build products that our customers not only find useful but can also afford.
Its very rare for us to not include a feature on a lower end model for purely commercial reasons - however it does happen sometimes as we’d be foolish not to look for ways to encourage our customers to buy our enterprise grade devices. That said, we regularly review customer and partner feedback internally, identifying trends in the ways our products are used (and by whom) to better understand the requirements of our global customer base. When that review highlights substantial demand for a new feature or capability (or the enabling of an existing enterprise feature on an entry level device), we work hard to make it happen technically and commercially. An example of this are the 7 load balancing algorithms. In fw v5.x the B20/30/50 only had support for 5 of them, with fw v6 all 7 are now available across the whole product line. This decision was made because of feedback from our community where many customers use B20/30’s for real time streaming services (like VoIP, and Video) and wanted to be able to use the Lowest latency algorithm to get the best possible user experience.
I hope that helps explain why some features are not currently available in the firmware of our prosumer/entry level devices, and be assured that your feedback as to QoS usergroups on the B20 will be carefully considered in our next review meeting.
Martin
Thank you Martin for your well written and reasoned explanation.
I knew that my post was making some presumptions and of course, that different hardware does provide for additional/different software features. Some of your prosumers desire to become SOHOs, and some SOHOs likely aspire to become enterprises. By having the feature sets be as consistent as possible across all those blurred lines means less retraining (and fewer complaints about “missing features on my device type”) as we traverse through your hardware product lines.
/Marty
No worries Marty - thanks for taking the time to read it.
I’m sure you’ll be interested to hear of other customers asking for usergroup based QoS to be included on the B20/30 too. Peplink | Pepwave - Forum We’ll definitely be considering all the options relating to this possibility.
Hello All,
As we know, Peplink does not support IP Based QoS, now. Is this feature on your roadmap?
While working on some projects, especially this feature is demanded by customers. In our view, this feature helps to empower potential projects much more.
Regards.
