Prepare for the Next Napster

Instructions to prevent a new, bandwidth-greedy application from engulfing the network and undermining critical performance before managers have a chance to develop a strategy for dealing with it

When Napster first hit university networks, administrators were caught by surprise. Although many solved Napster's performance impact and legal issues, they were left wondering — "What's next?" Most network managers have no desire to restrict an application just because it's new and unknown. But sometimes, on some networks, in some situations, that's just what's most appropriate.

The following procedure describes techniques to contain (not block) new applications. It implements a strategy of "guilty until proven innocent," when it comes to bandwidth allocation. All new, unknown applications are thrown into one bucket and capped. If a new application is deemed sanctioned and appropriate, it can be moved out on its own to share with other sanctioned traffic on a first come, first served basis, using the default policy; or, you can set an appropriate bandwidth-allocation policy.

These same techniques also work for situations when you want to explicitly manage a few applications with custom bandwidth-allocation strategies, and leave the remainder with a default, best-effort strategy.

The following steps cover both types of situations, calling out divergent instructions where needed.

Steps:

1. Enable traffic discovery for PacketWise as a whole.
   
   
2. Tailor your traffic classification tree so that you have explicit classes for all known and supported types of traffic. Most classes will be created automatically by the discovery process. But you'll undoubtedly want to customize the classes a bit.
   
   If your goal is to explicitly manage only a few applications, then make sure you have the traffic classes for those.
   
   For task instructions, see Create a Traffic Class and Update Class Properties.
   
   For background information, see Traffic Tree Overview and/or Traffic Classification Overview.
   
   
3. Create a traffic class called TraceEffort (or Unsanctioned, Suspicious, Else, OtherIP, or whatever you like) under both Inbound and Outbound in your traffic tree. Its matching rule should contain criteria to match all IP traffic (use IP as your service and protocol). It will serve as a parent class to all IP traffic that does not match your explicit classes. It sits beneath your explicit classes, just above the Default class for Inbound (or Outbound).
   
   
4. Move any traffic classes into TraceEffort that you don't want to explicitly manage or that you consider unsanctioned (depending on your purpose for following this procedure).
   
   
5. Determine the minimum and maximum amount of bandwidth you'd like to devote to all traffic under TraceEffort. In addition, determine the priority for its access to the maximum. (You will use these values in step 6 when you create a partition.) Your figures will vary not only with capacity, but with your motivation for choosing this management strategies. Consider these examples with a T1 or E1 link to help you decide:
   
   
• A business wants to give all games, music downloads, and Internet radio no reserved bandwidth, a maximum of 10 percent of capacity, but only if absolutely nothing else needs that bandwidth. Min = 0 Kbps; Max = 150 Kbps if using explicit sizes or 10% if using relative sizes; Priority for max = 0.
  
  
• A college wants to prevent any performance-impacting surprises, catch any new applications, and prevent them from undermining network performance. But it doesn't want to starve an application just because it's new. They decide to reserve 10 percent of the link for this traffic, cap it at 35 percent, and give it a middle priority of 3.


For background information, see Sizing a Static Partition.

6. Create a partition for the TraceEffort traffic class. Make the partition burstable, and use your minimum and maximum for the partition's field values.
   
   For background information, see Partition Overview.
   
   
7. Set a rate policy on TraceEffort's Default traffic class. It's the last class indented under TraceEffort. Choose 0 Kbps guaranteed and your priority from a previous step.
   
   All of TraceEffort's traffic classes will inherit Default's rate policy if they don't have one of their own. By setting this policy, you're giving the classes the efficiency benefits of TCP Rate Control as well as determining the urgency of their access to excess bandwidth.
   
   For background information, see Policy Overview and Inheritance Rules.