Partition Overview

A partition manages bandwidth for a traffic class' aggregate flows, so that all of the flows for the class are controlled together as one. For information on managing individual flows, see Policy Overview.

For details on creating partitions, see Create a Partition.

Managing Bandwidth

You can use partitions to:

• Protect mission-critical traffic by guaranteeing that a traffic class always gets a defined amount of bandwidth
• Limit aggressive, non-critical traffic by allowing that traffic class to consume only a defined amount of bandwidth
• Divide capacity
• Assign bandwidth dynamically to users
• Oversubscribe your link

Protecting Traffic

Partitions protect traffic by guaranteeing a defined amount of bandwidth for your mission-critical traffic classes.

For example, you could set a 128 Kbps partition for SNA traffic. This partition ensures that SNA will always have at least 128 Kbps of bandwidth available. Unpredictable surges of competing traffic will not interfere with SNA traffic.

Limiting Traffic

Partitions limit less important traffic by putting a cap on the amount of bandwidth a traffic class can use.

For example, say you have a 128K link. You can assign a 64 Kbps partition to FTP traffic. This prevents FTP traffic from consuming your entire link and blocking more important traffic (like Oracle or Citrix).

Another example of limiting traffic is restricting how much bandwidth a Class C subnet can use, regardless of how many sessions are active. You could create a 256 Kbps partition, burstable to 512 Kbps. The subnet's traffic would always get at least 256 Kbps, and could use as much as 512 Kbps if that bandwidth is available.

Dividing Capacity

Some traffic, such as Voice over IP (VoIP), requires a certain amount of bandwidth in order for the transmission quality to be acceptable.

For example, you could create a traffic class for VoIP traffic. A partition for the VoIP traffic class manages the aggregate VoIP traffic and the concurrent flows for the class. You could then combine the partition with a rate policy that defines a minimum rate for each flow.

In this example, by combining a rate policy with a partition, you can ensure that VoIP always has enough bandwidth to support the multiple flows during a VoIP session. Without this reserved chunk of bandwidth, the online conversation would be choppy and unintelligible, and the quality of service would suffer.

Note: Partitions, like traffic classes, are one-way, so it is necessary to create a partition for each direction of a traffic type.

Assigning Bandwidth Dynamically

With dynamic partitions, subpartitions are created on the fly as users become active in a traffic class. This capability allows service providers or enterprise customers to guarantee a user a minimum amount of bandwidth at all times. This strategy is useful when a small portion of users will be active in any given time period.

For example, an ISP might have 20,000 customers, with up to 2,000 users logged on at a given time. With a dynamic partition established, subpartitions are automatically created for users as they log on. The dynamic subpartition allocates a minimum and maximum amount of bandwidth to each user. To accommodate new users when the maximum number of users is reached, the oldest non-active subpartition is removed so that bandwidth can be released to active users.

Oversubscribing

While not generally recommended, PacketWise allows you to oversubscribe a partition — that is, create partitions that allocate more total bandwidth than your link can provide. PacketWise adjusts partition sizes to accommodate changing demands. For examples of this concept, see Hierarchical Partition Examples.

Initial Configuration

When you complete Guided Setup (see the Getting Started Guide for more information), the initial configuration provides a partition for the built-in /Inbound traffic class and a partition for the built-in /Outbound traffic class. Both /Inbound and /Outbound partition sizes correspond to the link bandwidth. You may also create additional partitions to divide the link bandwidth into multiple pieces. The number of partitions you can define depends on your model. For details, see Configuration Limits.

Types of Partitions

There are two types of partitions you can create: static or dynamic.

A static partition manages bandwidth for all flows within a particular traffic class. Static partitions can be fixed or burstable.

• A fixed partition allows an aggregate traffic class to use a defined amount of bandwidth, if needed. A fixed partition not only ensures that a specific amount of bandwidth will be available, but it also limits traffic to that same level.
• A burstable partition allows an aggregate traffic class to use a defined amount of bandwidth, and also allows that traffic class to access additional unused bandwidth, if needed. You can put a cap on a burstable partition, allowing it to access up to a maximum amount of bandwidth, or you can allow a burstable partition potentially to consume all available bandwidth.

In situations where you want to apply bandwidth limits to individual users, you can establish dynamic subpartitions for the traffic class. A dynamic partition carves up a static partition's bandwidth, creating subpartitions on the fly for new users. Subpartitions are children of a static partition.

Accessing Available Bandwidth

If a partition doesn't need all of its reserved bandwidth, only the excess unused bandwidth is available to be given out as guaranteed rate to other traffic. The reserved bandwidth can only be given out to other traffic as excess rate. For example, suppose the TCP class has a partition size of 100k with a limit of 400k and there is currently no TCP traffic. Up to 400k can be used by other traffic, but only 300k can be given out as guaranteed rate. The reserved bandwidth (100k in this example) cannot be given away as guaranteed rate.

When a partition needs its reserved bandwidth but other traffic is using it, the necessary bandwidth is returned to the partition and bandwidth usage by other traffic shrinks proportionately.

Hierarchical Partitions

All partitions are defined as hierarchical — that is, partitions can contain partitions. For example, you might define a fixed partition for FTP and then create burstable child partitions for user groups that use this application.

This hierarchical approach enables application management for multiple groups, while controlling the group as a whole. For example, an ISP can subdivide a subscriber's partition with child partitions for each of the subscriber's departments. Likewise, an enterprise can allocate different amounts of bandwidth for a particular application to different groups of users. For instance, an enterprise might have a PeopleSoft class with a fixed partition. Within this partition, Human Resources could have a large burstable child partition and Accounting could have a smaller burstable partition.

Note: The key concept for hierarchical partitions is that child partition minimums are limited to the parent partition minimum. When the sum of the minimum size of the child partitions exceeds the minimum size of the parent partition, the parent is oversubscribed and the child partitions are scaled proportionately. See the following examples.

Hierarchical Partition Examples

An ISP could set up one partition per customer (by server name or IP address) to match the customer's Service Level Agreement (SLA). The partitions enable the ISP to enforce SLAs for customers who consistently burst beyond their limits. In the following example, the FTP and HTTP classes (both 384 Kbps minimum) have oversubscribed their parent partition (512 Kbps minimum) by 256 Kbps. When a partition is oversubscribed by its child partitions, all partitions in its subtree are scaled accordingly. In this example, both child classes will be allocated 256 Kbps so that the sum does not exceed the parent's minimum size.

Inbound
   Customer1 (minimum partition size = 1 Mbps)
   Customer2 (minimum partition size = 512 Kbps)
      FTP (minimum partition size = 384 Kbps)
      HTTP (minimum partition size = 384 Kbps)
   Default

In the next example, the sum of the minimum size for the FTP and HTTP partitions is less than their parent, Customer2. In this case, both child classes will get at least 256 Kbps and can burst up to the size of Customer2 (1024 Kbps). Remember that if a partition is burstable and bandwidth is available, the partition can access the available bandwidth if needed.

Inbound
   Customer1 (minimum partition size = 512 Kbps)
   Customer2 (minimum partition size = 1024 Kbps)
      FTP (minimum partition size = 256 Kbps, burstable to 512 Kbps)
      HTTP (minimum partition size = 256 Kbps, burstable to 512 Kbps)
   Default

See also:

Reserve Bandwidth

Limit an Application's Total Bandwidth

Subdivide Bandwidth

Protect Critical Application Performance