Product Uses

• Bandwidth iQ

The Opteq Systems International (OSI) traffic management module (Bandwidth iQ) has many features and functions designed specifically for the Service Provider/ISP market. This document highlights the use of some of these features and is not meant as a full Bandwidth iQ module description. It is recommended that the reader first becomes acquainted with the general features of the module before reading this document.

Traffic and Bandwidth management for a service provider is different from a normal businesses requirement because it directly effects profitability and can be a primary service differentiator for marketing and sales purposes. This document will therefore keep these factors in mind and attempt to explain why Opteq is a leader in this respect.

As with all equipment of this type a return on investment (ROI) calculation becomes a balance between what features or functions are used (and how often) versus what services the client is prepared to pay for and how much. Every computer based device has a fairly finite ability to process things. The more features processed per client the lower will be the number of clients that can be managed on any particular unit. This is the simple fact of life in the traffic management world and applies in a similar way regardless of number of pre-processors or CPU’s applied to the task.

The Basics

All Opteq devices are specifically designed and engineered to receive packets on an Ethernet interface on one side of a unit, get it into main memory, and then get the packet out onto the other side as quickly as is possible, every interface, component, bus, and component has been selected and designed for this task. The drivers, ARP cache, bridge and other involved software have been specifically written and tuned by OSI to the stage where the extra latency added by an Opteq unit when it is added to a network is so negligible as to be virtually un-measurable.

While the packet is in memory all functions required by the features and policies set up have to be processed and decisions made about what to do. Prior to any such policies being set-up all that is done is statistics are collected. These statistics are host based but not session or stream based and this process is very efficient. As soon as the Interface speeds are set (so that we know what the link speed is) these statistics are used by our proprietary algorithm to calculate a fair bandwidth limit for every individual user and we begin to pace every host to that speed. The method used to pace hosts is also proprietary but suffice it to say that each host will slow down sending traffic onto the network until the network is balanced perfectly. Once this is achieved we do not build any buffers or queues unlike all our competitors. This immediately and without any rules or policies and provides the following benefits for the ISP –

• No more drops or re-transmissions means happier clients and reduced demand.
• No more unruly users stealing more than their fair share of bandwidth
• More profit. This comes from less churn of clients and the ability to increase multiplex ratios without increasing churn or making clients unhappy
• Router offload. CPU and memory usage in your routers will suddenly drop to reasonable limits because we will only give packets to the router at the rate it can use them. We can also enhance this by doing packet marking more efficiently and more effectively than the router can but that capability is documented in another white paper

At this level of activity even our smallest unit can handle tens of thousands of users with many sessions each and our larger units hundreds of thousands. This is because we do not create or have to manage queues or buffers in our unit due to our pacing technology which simply does not require them. A nice side effect of no queues is still no added latency.

Managing The Link

Substantial additional gains can be obtained by tuning what is happening on the Internet pipe. Often bandwidth hogs like P2P and mail use up much more bandwidth than is sensible or necessary and/or you wish to improve sensitive traffic performance, such as VOIP and terminal interactive sessions, giving clients a better impression of your service. It is also far more economical to manage a single link with application type rules than doing it for every client separately.

The first thing to do is to gain visibility of the demand on the link by using either the Real-Time iQ Monitor or the application or traffic monitor in Bandwidth iQ so that sensible decisions can be made. It should be noted that switching on the application tracking function adds quite a large overhead to your unit because it adds stream management and layer 7 (deep packet inspection) tracking. Normally we manage traffic to and from each host as a single stream to be managed. With stream management we have to track each stream as well. Streams are more efficient than sessions as we track any number of sessions as a single stream when they are the same application between the same hosts but it still adds overhead. Unfortunately, in most networks today it is necessary to do this in order to manage it correctly but if you can manage you clients without it you will definitely be able to manage many more clients per unit.

Once a good idea of the demand is obtained then policies should be created to manage the traffic. There are three main choices or ways to do this –

Priority traffic is allowed out first

• Priority Queues. This is not recommended by Opteq but is supported because this is how our competitors do it. Basically packets are placed into one of 10 priority queues and then these are cycled through sending out packets from the highest priority queue first. The reason that we do not recommend this method is because in order for it to work we have to create queues and allow them to build up a little. Then we need to do extra processing to cycle through the queues. This has three negatives – first it adds latency to every packet equal to your queue depth and second it adds to the CPU load. The third negative is that low priority traffic can get chocked using this method which is not really a desirable effect in most cases and can be overcome with a small minimum guarantee
• Weighted priority Groups. This is a much better method of prioritizing traffic as it does not require queues. It works in a similar way to normal priorities but when the packets are flagged with a priority we use a special weighted algorithm to calculate a bandwidth setting per priority and use our normal pacing management to control which priority gets how much bandwidth. A simple example of how this would work is having 2 rules (or groups) one for priority 9 and another for priority 1. On a 1Mbs link this would allocate 90% or 900Kbs to priority 9 traffic and 10% or 100Kbs to priority 1 traffic when demand equals or exceeds 1Mbs (below 1Mbs no management is the most effective way to manage). A side benefit of this method is that in effect you get auto-bursting without worrying about it. For example if the priority 1 traffic does not need 100Kbs then the priority 9 traffic will use all available bandwidth. Of course if the priority 9 traffic does not need all 900Kbs then priority 1 traffic will be allowed to use whatever is available. This algorithm has an automatic anti-chocking method built in.
  
  
  
  
  Above: Using the above example group rule and weighted algorithm ensuring each rule gets its allocated share of bandwidth. In this case when high priority traffic is nonexistent the lower priority traffic is allowed to burst to full group link speed
• Specific policies with bursting. This is the best way if it is possible because it is more precise and controllable plus it does not use up CPU cycles to set priorities and calculate weightings. To use a similar example to above you would have two rules (or groups) one set to 900Kbs burst to 1Mbs and the other set to 100Kbs and burst to 1Mbs with the burst trigger set to the interface (default). Once burst is enabled we will allow the rule to burst to whatever is available not only to the burst setting which is considered to be just a maximum setting

  
  Exactly the same is achieved as in 2 above accept this method is more processor efficient as it does not rely on weighted algorithm calculations. The rule is limited when the link or group allocation is busy and is allowed to burst to a predefined limit when the link is not busy.
  
  

Managing Users

If you really need to manage users in addition to the automatic fair management outlined above then the most efficient method is to filter by IP address or subnet. The main reason that this is so efficient is that we have statistics and management in place for hosts anyway and we also have very efficient IP address indexing so lookups are very fast. Rules which use other match types (filters) require us to run through the ruleset looking for matches for every packet received and this can be a large amount of processing in a large ruleset. We do stop matching once we get a hit so it is always more efficient to put high packet rate rules early in the ruleset. Of course global rules always have to be run through for every packet as they do not cause a hit so due care should be taken with global rules.

In the simplest and most efficient way to manage per user each user IP address would have a rule which would set bandwidth and/or packet rates that this user is allowed to go up to if there is available bandwidth. Optionally minimum guarantees, burst rates, and priorities can also be allowed as can active time of a day or day of a week. Obviously if you can group together some users into a subnet and manage them as an entity then it will be even more efficient and we will still not allow an individual to use more than their fair share of bandwidth within that subnet. The advantage of doing this is that when there are fewer users in the subnet then they will on average get more bandwidth than when all users are active. This can be thought of as a simple group but without the behaviour modifiers that you would get with a group (see group description below).


Above, two clients have each been defined using an IP address range. Client 1 is allowed 512Kbps with a burst to 1Meg. Client 2 is allowed 256Kbps, with no burst

Automatic Rule Generation

If you need individual rules for each user then these can be automatically generated by our reverse rules function. Essentially what a reverse rule does is create a copy of a rule template for every new IP address seen (Please read a full description in the Bandwidth iQ manual). Reverse rules are actually powerful group generators with many options that modify rule and/or group behaviour but a full description is beyond this document. Suffice it to say that reverse rules will generate rule for an entire subnet or just an IP or a virtual host and by source or destination IP and/or port. It can generate rules that are copies of a template or rules that can share or balance bandwidth in a similar way to groups. You can set a maximum number of users or sessions and a rule timeout as well.


Above, we have defined a reverse rule with a timeout of 180 seconds, a maximum limit of 100 and set it to use source IP address to define the rules. We have also set it to only apply to IP addresses coming from the 10.10.0.0/16 network range, and allowed it 10Mbps of bandwidth.

This will mean, that up to 100 unique IP addresses can access this pool, and that the 10Mbps of bandwidth available will be shared amongst them.

Profiles (Action Templates

In any rule instead of setting specific parameters for any action (bandwidth, packets, or burst rates and priorities) you can setup profiles and use those instead. Profiles are basically templates that are setup separately and then can be used in any rule. This allows you to be able to change a single profile and any rule that uses that profile will be automatically changed. In the ISP world this normally equates to a service level that is sold so you would have a profile or a set of profiles for each service type. This allows modifications to services to be very easily implemented without having to change large numbers of rules.

Profiles can be an action template or a timed set of templates. Profiles have an ID and a name and sets are created by using the same id but a different name and then specifying a time of day or day of week for action activation. Bandwidth iQ will automatically use the correct profile or action for the correct time of day on each rule that uses that profile id. For example if you had a template for Gold clients you could have an action of 512Kbs in and 512Kbs out from 8h00 to 17h00 and 1Mbs in and out from 17h00 to 10h00 and then 2Mbs in and out from 10h00 to 8h00.


Above, we have defined two classes of client (using profiles). Gold clients have 1Mbps of bandwidth, and a burst to 2Mbps. They are also given priority 7 to assume them a higher quality of service.

Silver clients are given 512Kbps of bandwidth and a burst of 768Kbps with priority 4. We can now use these profiles in as many rules as we wish.


Now you can see we have utilised the Gold profile for Client 1, and the Silver profile for Client 2. We can add as many clients as we like using these profiles, and change their settings through the profile manager without having to edit every client. There is no realistic limit to profiles, or their use.

Quotas (Caps)

Many ISP’s have different action requirements that are dependant on usage generally called a CAP but called a quota in Bandwidth iQ. Two quota types are allowed by Bandwidth iQ, a daily quota and a monthly quota and two profiles are required for each quota – one which is used when the rule or group is under quota and the other that is used when the rule or group is over quota. These profiles can also be sets of profiles.

Unfortunately, while profiles are very efficient, quotas are not and require a significant amount of CPU power so it may save you some bandwidth at peak times and stop user abuse but it will significantly reduce the number of users that a single unit can manage. This is caused by that fact that every rule or group that has a quota also needs long term statistics enabled (see below for a full description) and these stats must be interrogated for every rule to detect when it transitions from under to over quota. This is typically done once per hour to try and limit the load.


Above, Every customer can be defined by a bandwidth rule (BW Rule) and have a quota allocated. Whilst under Quota one profile is applied and over quota another profile is applied.

Groups

In Bandwidth iQ groups can be thought of as buckets of managed bandwidth or virtual pipes. A group header has an action (bandwidth, packet, and burst) setting inside which all rules or groups within that group are managed. The root group in every ruleset is the Interface itself and inside that can be any number of sub-groups nested to any level. Naturally every group created has to be managed and therefore it will add some overhead to your unit but it is not a great deal in the scheme of things.

By default groups behave as if the combined rules and groups within it have a common or shared ceiling unless this behaviour is overridden by actions on a rule or a sub-group, or a behaviour modifier. Behaviour modifiers for groups are balanced and weighted and balanced. Balanced will apply fairness to each rule and weighted will invoke the priority algorithm mentioned above. A sub-group is treated in exactly the same way as a rule in the group above it in the hierarchy once its allocations and performance has been worked out.


Groups can be used in the ISP environment in a wide variety of ways to improve service offerings and/or manage clients. You could have groups to manage separate bandwidth to service levels such as a group for allocating specific bandwidth to Gold customers versus silver or bronze. Within those groups you could allocate or prioritize bandwidth by different application and it can be different by class. It often depends somewhat on how a network is numbered what you can achieve in a group. For example if you wanted to globally prioritize applications differently for each class of service then we would need to be able to globally identify those users ideally in a single rule with a single subnet. The alternative would be to have a global rule inside the group for each IP address which would be extremely inefficient and very hard to maintain.

You could have a group for every customer that will allow you very fine grained control over each and every element of that customer’s traffic but this can very quickly explode your rulesets if you are not careful. Just prioritization of applications can be 20 to 30 rules to cover each main application. If you had a unit which could handle 3,000 rules then this would reduce you to managing 100 users per unit and quickly change your ROI calculations. This is probably most cost effective if you are selling to groups of users like a business account that can be managed as a single subnet or a single NATed IP, or if you sell a superior service to a few individual customers who are prepared to pay more for the service.


Above: Applications prioritised on a per user bases. On small networks this is fine but for larger networks capacity is better utilised in managing user speed tiers with quota’s and global application priorities.

Group Templates

Opteq makes having standard groups very easy to manage and maintain by having a facility for group templates. These templates are a group header and a standard set of rules that can be maintained in the rulesets as though they were an individual rule. As with profiles, if you wish to modify a template then all the groups that were created by using that template will be automatically modified for you.

Statistics

There are two types of statistics that can be maintained by Bandwidth iQ. These are short term or real time, or long term statistics. Every Interface, group, and rule automatically has short term statistics maintained internally and these cannot be turned off because we need them to implement the rule management. Short terms statistics are maintained for a period which can be changed but by default is 20 seconds. Extending this period is good for load but reduces the grain at which we manage. Shortening it is not recommended and could result in choppiness in some rules. Long term statistics can be turned off or on by rule and some care is needed because these statistics need to be accumulated every period and written to an SQL database every 300 seconds. This is a very high load for any machine to cope with if there are lots of rules that have long term statistics.

API

Every Opteq unit has an API manager built into the server manager (Singular iQ) and Bandwidth iQ has a set of API rules within that. This API allows ISP’s to develop external programs to fully manage rules and rulesets remotely as well as also having an ODBC interface so that all statistics are fully accessible and easy to integrate into billing and accounting systems. Anything that can be done via the user interface can also be done via the API manager.

Restricted Client Access

A very popular feature of the Opteq unit is the ability for ISP’s to allow clients to access their own statistics and reports without compromising other client’s data. This access can is by using a normal Web browser and can be HTTP, Secure HTTPS, or either. Every Opteq unit has a User Manager in Singular iQ where secure access can be setup and each user can be restricted to which modules access is allowed and whether changes can be made or only viewing allowed. In addition in Bandwidth iQ individual users can be restricted to viewing a rule, a group, or a set of either or both. Standard reports can be setup which will store and/or mail reports to users every day, week or month with just their own data visible and these reports can be in HTML, PDF, text (csv), or Excel format.

Summary

Opteq allows for innovative new service plans and billing models designed to retain and attract subscribers, control Peer-to-Peer/Recreational usage, enable and manage triple play services and protect the network from malicious traffic.
Opteq enforces tiered service levels, allocates bandwidth minimums and maximums on a per-customer, per-user, per-application, or other basis, paces streaming media for optimum reception, manages over-subscription, and offers a variety of other features such as Quota’s and profile management.

Customers of premium bandwidth services have premium expectations and require more than Just a best-effort attempt at quality. We have shown you what types of services can be offered whilst still maintaining an efficient rule set. Opteq offers unrivalled flexibility so you can decide which features to use and the level of complexity you want. Opteq sits inline of the traffic and offers easy management of users through a web GUI interface or via an API for automated provisioning.
Opteq iQ integrates smoothly with any SNMP-based management tool and has a CMS (central management server) for central management & reporting on large deployments.

It should also be clear now that certain configurations are much more processor intensive than others and therefore the rule sets and service offerings need to be carefully thought out with respect to the numbers of users to be managed

Billing Examples

Opteq provides the mechanism to create billing plans on a subscription and or usage basic with tiered service levels. E.g.: customers could be charged one rate for data traffic and a higher rate for voice over IP in which a higher level of quality of service is required.
Through usage-based billing one can determine exactly how much bandwidth each customer has used, and bill appropriately

There are literally thousands of innovative billing plans that customers use Opteq to enforce.
Usage based example service offerings with no quota restrictions but cost penalties imposed:
Internet Option 1 (usage allowance of five gigabytes) 17.99
Internet Option 2 (usage allowance of eight gigabytes) 22.99
Internet Option 3 (unlimited usage allowance) 24.99

The extra usage charge - If we charge you for extra usage under the usage guideline, the charge will be XXXX a GB (gigabyte).

A more efficient method would be simply to allow higher speeds when the network is not busy rather than time of day as network load is not always linked to time of day. I.e.: allow users to burst when the network is not busy rather than have time restrictions.

Example – Global shaping with individual client speed and usage tiers. Efficient & recommended for large deployments

A mix of service types

Above: One has global rules giving priority to VoIP & streaming whilst limiting p2p across the network.
Rules 100 & 200 we have added for customers with speed restrictions according to the gold service profile and they will additionally inherit the global application priorities set above. (most efficient)

Rule 300 is a group rule for a VoIP package. We created global rule to give priority 10 to VoIP traffic and priority 5 for all other traffic for members who belong to the VoIP package group. E.g.: customers on rule 330 & 340. (more processor hungry)

Rule 400 is a balanced group rule. All members will share 512Kbps fairly between themselves and will be allowed to burst to 756Kbps when the overall bandwidth usage on the link is below the 95Mbps threshold. If there were 20 customers in this group then you would have a 20:1 contention ration for 512Kbps link. (efficient)

Above you have seen only a small sample of the endless possibilities of service offerings. Please speak to your local Opteq support partner for discussing your ideal options more intimately.

Deploying a full blown Opteq solution with multiple Opteq modules could allow you to expand to offer the following types of services.

• Basic Service – Tiered internet services
• Silver Service – Basic Service + http antivirus
• Gold Service – Silver Service plus Parental Control
• Platinum Service – Gold Service plus Anti-Virus for mail