Provision Bandwidth Equitably

Instructions to allocate and protect equal amounts of bandwidth for each user

Sometimes organizations care more about equitable bandwidth allocation than about performance for a particular application. Consider these scenarios:

• An educational institution wants each dormitory student to receive a minimum of 20 Kbps and a maximum of 60 Kbps to use in any way he/she wishes.
  
  
• Shared-facility buildings (apartments and office buildings) want all tenants to share bandwidth equally.
  
  
• An ISP wants to prevent users from using more than their paid-for share of bandwidth, offer bandwidth equity, and juggle oversubscription situations.

PacketWise, if requested, can create individual subpartitions on the fly as users initiate traffic of a given class. Subpartitions greatly simplify administrative overhead and allow efficient oversubscription. As always, unused bandwidth is available to others in need.

Steps:

1. Create a traffic class for the traffic you'd like to divide equitably, if one doesn't already exist.
   
   If you want to give each user a set amount of bandwidth independent of application, all you need are the Inbound and Outbound classes.
   
   If you want to give each Oracle user, for example, an equal amount, make sure you have an Oracle class.
   
   And if you want to allocate equitable bandwidth for users of groups of applications, create folder classes, as needed, and move the classes for the applications of interest under the folder class.

2. Determine the amount of bandwidth you'd like users to share. Perhaps it's the entire link size, or perhaps it's a portion of your link. Make sure your size is sufficient to accommodate the anticipated number of users. For example, perhaps you have 1.5 Mbps to be divided among users. You anticipate about 75 users, giving about 20 Kbps each.
   
   For more information on choosing appropriate sizes for a partition, see Sizing a Static Partition.
   

3. Create a partition for the traffic class (or folder class) you created earlier. The size of this partition should be the size you determined in the previous step — the bandwidth to be divvied up among users.
   

4. Create a dynamic partition within the parent partition you just created. The dynamic partition automatically generates small subpartitions that manage per-user or per-subnet bandwidth under the larger, parent partition.
   
   Consider your plan, using the questions below and their setting suggestions to help guide your choices when defining your subpartition:
   
   

   Questions and Scenarios	Suggested Dynamic Subpartition Settings
   Do you want to provide equitable bandwidth to each user? Or to each group of users on the same subnet?	Create a subpartition per: Single address Create a subpartition per: Subnet
   Do you want all users to share all available partition bandwidth equitably with no other restrictions?	Subpartition size: 0 Burstable: checked Limit: (blank)
   Do you want each user to have access to a capped amount of bandwidth and no more? For example, a service provider might want to cap each user according to purchased plan. A cap of 50 Kbps for each Bronze user, a 150 Kbps cap for each Gold user, and a 250 Kbps cap for each Platinum user.	Subpartition size: 0 Burstable: checked Limit: 50 Kbps (or whatever the maximum size you want)
   Do you want each user to have a predetermined amount of bandwidth, no more and no less? For example, a school might want to provide precisely 40 Kbps to each student. If you do use a minimum size as in this example, set a maximum number of users and (optionally) an overflow partition.	Subpartition size: 40 Burstable: not checked Limit: (blank)
   Do you want to cut off the number of users at a predetermined number? For example, you could limit the number of users to 100. Or do you want to just keep adding users, cutting the bandwidth proportionately for each? For example, if a 1 Mbps parent partition gets 200 users instead of the anticipated 50, then each user would be accommodated, but they would all have access to only 5 Kbps.	Maximum # users: 100 (or whatever the maximum number of users you want to allow)   Maximum # users: (blank)
   Do you want to refuse latecomers (those who need bandwidth after your maximum is exceeded)? Or do you want to accommodate latecomers by squeezing them into an overflow partition?	Overflow partition: (blank) Overflow partition size: <the amount of the parent partition you want to devote to latecomers when there is a surge in demand>

Complete example:

An organization generously decides to give unsanctioned music downloads (such as KaZaA, Gnutella, et al) 5 percent of their T3 WAN link, or 2.25 Mbps. They don't want one high-capacity user stealing the whole thing and leaving their other musical users without resources. But they also don't want to restrict one high-capacity user if he or she is the only active music fan at the moment.

The administrators create a traffic class using matching rules for all the popular music-download applications. They create a static parent partition of 2.25 Mbps. Then they define a dynamic partition with settings as follows:

- Subpartition per: Single address
- Subpartition size: 0 (to distribute the bandwidth evenly among takers)
- Burstable: checked (allow each subpartition to grow to consume available parent-partition bandwidth)
- Limit: (blank) (don't cap any subpartition arbitrarily)
- Maximum # users: 150 (preserve at least 15 Kbps for all users)
- Overflow partition: (blank) (just refuse anyone after 150 active users)

150 users = 150K, burstable to 2.25M each