Traffic Shaping

The rXg traffic shaping mechanism offers five key bandwidth management capabilities: rate limiting, link share equalization, burst rates, bandwidth guarantees and packet prioritization.

All shaping capabilities are configured through bandwidth queue records which are specified to operate on each individual IP, each group or the policy as a whole. Multiple bandwidth queue records may be associated with a single policy to define a hierarchy of shaping controls.

Furthermore, enforcement may be limited to specific applications and/or WAN targets. The rXg applies more specific definitions first when multiple bandwidth queues records are associated with the same policy.

Rate Limiting

Rate limiting is a key capability that enables operators to oversubscribe WAN uplinks. In most usage scenarios, end-users consume little to no bandwidth most of the time interspersed with occasional spikes of heavy utilization. Rate limiting controls the maximum value of the heavy utilization periods. Preventing a handful of end-users from overwhelming the network with heavy utilization enables operators to dramatically oversubscribe WAN uplinks and profit from the results.

Rate limiting is a central aspect to the marketing program of most revenue generating networks. For example, the operator may choose to offer three tiers of service (768k / 256k, 1.5M / 512k, 5M / 1M) at prices that increase appropriately ($19, $39, $99). These tiers of service are configured as rate limits and tied to the billing system through group membership. When an end-user comes to the captive portal, they are given the opportunity to choose from the plans being offered. Once a plan is selected, they will be charged appropriately and then placed into a group automatically which has been associated with the appropriate bandwidth queue. Thus the rXg enables operators to offer multiple tiers of service that are integrated into the billing system and self-provisioned by the end-user with zero operator intervention.

Profitable networks are oversubscribed and heavily oversubscribed networks will have periods where uplinks will be saturated. Many traffic shaping solutions fail to address the potential for random flow starvation with saturated uplinks that is a result of the nature of packet based network architectures. For example, if the uplink is 10 Mbps and the rate limit is 3 Mbps and there are 10 end-users, then just 4 out of the 10 end-users can fully saturate the uplink at which point some of the end-users will undoubtedly have a very poor experience due to the random nature of packets being dropped.

The rXg automatically enforces heuristic link sharing and per-flow packet rate equalization when traffic shaping is enabled. This feature prevents flow rate reduction from being exacerbated into extremely poor service. The rXg automatically slows down the highest rate flows as uplinks begin to saturate. Given a 10 Mbps uplink and 10 end-users that are all attempting to pull the full 3 Mbps specified in their rate limit, the rXg would automatically enforce link sharing at 1 Mbps to each end-user.

Burst Rates

Highly profitable revenue generating networks depend on creative service offerings that entice end-users to purchase premium services. Burst rate limiting enables operators to make service offerings that have a higher initial rate. The burst rate is typically much higher than the sustained rate limit in order to maximize marketing potential. For example, an operator may wish to offer a basic service that has a 3 Mbps sustained rate limit and a premium service that has a 5 Mbps sustained rate limit. The premium service could be enhanced with a 20 Mbps burst rate without dramatically affecting the oversubscription ratio. A premium service of 20 Mbps burst with 5 Mbps sustained is dramatically more attractive than the 5 Mbps sustained without the burst rate.

The rXg enforces burst rate limiting when the queue for an end-user is empty. The end-user will be delivered the burst rate at best effort for the configured burst time. Once the burst time has expired then the sustained rate limit will be delivered at best effort. The burst rate may be delivered to the end-user again if the end-user queue empties. It is important to note that the burst rate is delivered with best effort. It is unlikely that burst rates will ever be delivered when a link is saturated as the rXg will enforce linkshare equalization on highly oversaturated links.

Bandwidth Guarantees

Bandwidth guarantees enables operators to offer service level agreements that specify a minimum committed rate. In a typical deployment scenario, bandwidth guarantees are packaged as a premium service offering to end-users. For example, a "business class" offering may include a committed symmetric rate of 1.544 Mbps as a T-1 equivalent. Another common offering is a 128 Kbps committed symmetric rate for VoIP.

Bandwidth guarantees may not compose more than a fraction of the total available bandwidth on a WAN uplink. A good rule of thumb is that no more than 25% of the total available bandwidth should be allocated as a guarantee. Furthermore, bandwidth guarantees are only relevant within traffic shaping definitions that have the same priority.

The automatic link sharing and flow equalization feature of the rXg traffic shaping mechanism obviates the need to explicitly specify a rate guarantee for "best effort" service delivery. Guarantees should deployed carefully and always in conjunction with a premium service offerings to maximize revenue potential. In most cases, it is appropriate to think of the bandwidth guarantee as a mechanism to override linkshare equalization and give a small population of end-users an unequal share of the bandwidth.

Packet Prioritization

Packet prioritization enables operators to enforce hard priority on different classes of traffic. This enables the operator to ensure that certain end-users or devices are always serviced before other end-users or devices.

In a typical usage scenario a very high priority is assigned for VoIP and infrastructure management traffic. This ensures proper voice quality and the ability to manage the devices that power the infrastructure. In addition, "free" and pre-authenticated end-user traffic is typically given a very low priority.

Hierarchachal Enforcement

The rXg enables the operator to specify the traffic shaping enforcement at three different levels. Shaping by IP address is the finest grain enforcement support of the rXg and is at the bottom of a shaping hierarchy. Enforcement of shaping by group and policy enables operators to configure aggregate queuing and build up two more levels of a traffic shaping hieararchy.

The operator may specify up to three hierarchachal levels of enforcement for a given set of applications and WAN targets. Levels of the heirarchy that are omitted default to 100% of the parent. The implied parent of all policies is the uplink.

Shaping by IP address treats the configured bandwidth queue as a template to be replicated to each and every associated IP address. Every IP in the CIDR range that is associated with a linked bandwidth queue is assigned independent rate limits, bursts and guarantees when shaping by IP enforcement is enabled for policies associated with IP groups. Similarly, when shaping by IP enforcement is enabled for other types of groups (e.g., MAC groups, Account groups, RADIUS groups, etc.), each resolved IP address that is a member of associated groups is assigned an independent rate limit, burst and guarantee.

Shaping by group treats the configured bandwidth queue as a template to be replicated for each group linked to the bandwidth queue. This shaping mode is useful for applying the same rate limits to a set of groups linked through a single policy. Consider a network where VLANs are being used to identify end-users. Unique IP groups could be created for each VLAN and then the IP groups could all be associated through one or more policies associated with a single bandwidth queue.

Shaping by policy creates a single aggregate queue for each policy associated with the bandwidth queue. This shaping mode is less granular than shaping by group. All IP groups , MAC groups , etc., associated with a single policy will be assigned to the same aggregate queue. However if multiple policies are associated with the bandwidth queue then each policy will each be shaped independently.

The rXg generates a diagram of the configured hierarchy to help operators visualize the enforcement. The lowest level of the hierarchy (shaping by IP) is on the left. Packets are first shaped by IP, then by group and then by policy moving from the left to the right of the diagram.

The first example (shown above) depicts the simplest case of traffic shaping where an aggregate queue over all entities within a policy is desired. Since only the policy level of the hierarchy is defined the other levels default to 100%.

Alternatively the operator might desire to only configure shaping by IP without any aggregate queueing. This scenario is depicted in the example shown above. The diagram gets more interesting when more levels of the traffic shaping heirarchy are configured.

In the example given above, all three levels of the heirarchy are explicity specified. Thus an individual IP address is limited to 1 Mbps / 512 Kbps (with a 2 Mbps / 1 Mbps burst), while the group that the IP belongs (which in this case represents a corporate account) to is limited to 2 / 1 Mbps (with a 3 / 2 burst) and finally the set of all corporate accounts that fall within this structure are limited to 5 / 3 Mbps.

Bandwidth Queues

Bandwidth queues define traffic shaping policies.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The priority field determines the relative priority of the traffic that is assigned to this bandwidth queue. All packets waiting in a queue with higher priority are forwarded before packets waiting queues in lower priorities are serviced. The priority is completely independent from the rate limits and guarantees of a queue.

The absolute value of the priority field has no meaning as the enforcement of the packet priority policy is based on the relative values of each queue. The priority of 0 is the lowest and used to designate queues that are filled with packets that are least important or the least sensitive to delay. For example, bulk web traffic might be assigned a priority of 1 while VoIP traffic might be assigned a priority of 5.

The download rate limit and upload rate limit fields configure the absolute maximum steady-state transfer rate for this queue. These values are often described as being delivered with "best effort" in oversubscribed networks. This is because the actual maximum transfer rate is determined by numerous factors such as the size of the WAN uplink and the amount of traffic being generated by other end-users.

In heavily oversubscribed scenarios, the actual achievable maximum transfer rate experienced by the end-user will likely be much lower than the rates specified. In lightly used networks or networks with lower oversubscription ratios the data transfer rate may come be equal to but will never exceed the rate specified by these values unless a burst setting is configured.

The download rate burst and upload rate burst determine the initial maximum traffic rates for the specified burst time. These optional values allow the operator to offer end-users an initial burst of higher speed for a short period of time. These values are similar to the download rate limit and upload rate limit fields in that the specified rates are delivered with "best effort" and the actual maximum rate is determined by the amount of traffic being generated by the end-user population.

The download rate guarantee and upload rate guarantee are optional fields that configure the desired of amount of bandwidth that is dedicated to the queue. This value must be set carefully as it is a true dedicated guarantee and may not be oversubscribed. The operator should never guarantee more than 25% of the available bandwidth at any given time as doing so will likely result in an unstable network. It is particularly important to be very judicious with the use guarantees when configuring per-device Bandwidth Queues scenarios because the actual bandwidth guaranteed is determined by the specified value multiplied by the number of end-user devices. The bandwidth required to configure the guarantee may quickly become unmanageably large if an unexpectedly large number of end-users joins the network.

The WAN targets field limits traffic admitted to the queue defined by this record to traffic that is originating from the IP addresses or DNS names listed in the selected WAN targets. By default, a bandwidth queue will admit all traffic that is originating from and destined for the end-users and devices linked through the associated policies. Setting a WAN target causes the bandwidth queue to limit the breadth of admission to traffic destined for and originating from the designated hosts.

The applications field configures the kinds of packets that will be admitted to the bandwidth queue defined by this record. Selecting multiple application groups admits the packets from all of the selected applications (logical or). By default, all types of packets that match the chosen policy and WAN targets are admitted. Selecting one or more applications reduces the breadth of the queue admission configured by this record to the packets classified as being part of the chosen applications.

The shaping field configures the granularity of the traffic shaping enforcement. Setting this field to policy , group account or IP results in the configured settings being used as a template that is replicated for each associated policy , group or IP respectively. See the full traffic shaping help page for details.

The disable auto-IP queues field (a.k.a. LPV-mode) can be enabled only for queues configured for group or account sharing. This option disables the generation of the auto-IP queues for each IP member of an IP group, unless there is an explicit device sharing queue that also applies to the device. This drastically reduces the number of queues and firewall rules, thereby enhancing packet processing performance in scenarios where there is no portal and no device-specific rules. The trade-off to this is that there are no longer per-IP queue counters to instrument, meaning some visibility into device traffic rates is lost. This mode is not enabled if the policy has multiple link controls, since it would cause all traffic within the group to use a single uplink, or if there is a Captive Portal, since device-specific rules are required to pass traffic after authentication.

The policy field relates this record to a set of groups through a policy record.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.