Policy/Partition Guidelines
Guidelines for choosing suitable policies and partitions
for specific types of traffic and for setting appropriate field values
Managing bandwidth allocation for today's traffic diversity is a learned
skill. The following table should give you a head start. But keep in mind
that these are just guidelines and that your own context heavily influences
the types of policies and partitions that are appropriate for your environment.
See Policy
Overview and Partition
Overview for background information what PacketWise policies
and partitions are and what they do. See Control
Strategy Overview for a more broad and introductory approach. Deployment
Size's Impact on Defining Policies/Partitions is also helpful.
First figure out how to characterize
the types of traffic you want to manage, then consult the following
tables.
By Traffic Characteristics:
| Traffic Characteristics |
Traffic Examples |
Control Suggestions |
| Non-TCP traffic |
IPX, SNA, AppleTalk |
Priority
policy with a priority selected from the priority-guidelines
table that reflects importance. |
| Small, time-sensitive, important flows |
Telnet, DNS, LDAP, SNMP |
Priority
policy with a high priority. |
| Large, bandwidth-hungry, important, non-time-sensitive
flows |
File transfers, email |
Rate
policy with 0 guaranteed, burstable, medium priority.
Partition
to contain the aggregate of all users
|
| Large, bandwidth-hungry, unimportant flows |
Games (in a business setting) |
Rate
policy with 0 guaranteed, burstable, very low priority, and, if desired,
a cap of the appropriate per-session Kbps amount that a particular
game needs for acceptable performance.
Partition
to contain the aggregate of all users to less than 5 percent of
capacity (or whatever you are willing to devote). |
| Large, bandwidth-hungry, interactive, time-sensitive
flows |
SAP |
Rate
policy with 0 guaranteed, burstable, high priority.
Partition
to protect the aggregate for all users. |
| Real-time streaming audio or video flows that need smooth
reception and are sensitive to jitter |
Streamworks, WindowsMedia |
Rate
policy with 25 Kbps guaranteed (or the minimum, per-session amount
needed for acceptable performance), burstable, medium-to-high priority,
and a cap, perhaps 60 Kbps, that prevents sessions from getting
bandwidth beyond that which improves reception.
Priority
policy for the control flows (as opposed to the flows of data) with
a high priority.
Partition
with a size that accommodates the maximum number of allowed users
with minimum per-session bandwidth (500 Kbps for 20 users, for example).
Admission
Control to refuse more than the maximum number of users (or
redirect them).
|
| Unimportant, unsanctioned flows that you'd rather not
block but want to vigorously contain |
Music downloads, URLs of questionable content |
Rate
policy with 0 guaranteed, burstable, priority 0, and 2 Kbps cap
(or the per-session amount you'd like to give).
Partition
to contain the aggregate of all users to less than 3 percent
of capacity (or lower, if desired).
|
| Prohibited, unsanctioned flows |
Same as previous, but you want to block it |
To block UDP traffic, set
a discard policy.
To redirect web traffic, set
a never-admit policy using the web-redirect option with
the alternate URL.
To block web traffic without redirection, set
a never-admit policy using the web-refuse option.
Otherwise, set
a never-admit policy with the refuse option. |
| Flows that are not destined for the managed link
router |
Traffic to and from an Intranet server |
Ignore
policy. |
| Flows that are part of a contracted amount of bandwidth |
ISP customers' bandwidth, dormitory students, office
tenants |
Static
partition for all users' bandwidth. Dynamic
partition to allocate each user's or each subnet's bandwidth equitably. |
| Traffic to and from multiple branches, managed from
a main site |
SAP, Oracle, Web, and HTTP from Oslo, Milan, and Paris,
managed from a main site in London |
Should be hub-and-spoke topology. Static partition for
each branch with a size equal to branch's WAN capacity. See Control
Branch Traffic from a Main Site for instructions. |
By Traffic Type:
| Application or Protocol |
Traffic Details |
Control Suggestions |
| Email, FTP, Telnet, DNS, SNMP, LDAP, and ERP applications |
|
For applications and protocols that are included in
the examples in the previous table, consult that table's suggestions. |
|
Web browsing, to a web server (get requests, typically one packet)
|
Inbound HTTP to an inside server,
Outbound HTTP to an outside server |
Priority
policy with a priority selected from the priority-guidelines
table that reflects importance. |
| Web browsing, from a web server (responses, typically
large and graphic laden) |
Inbound HTTP from an outside server,
Outbound HTTP from an inside server |
Rate
policy with 0 guaranteed, burstable, a middle priority, and a cap
of the appropriate per-session amount that would keep high-capacity
web users from usurping the bandwidth for other web users (100 Kbps,
for example, if capacity is available).
Partition
to contain the aggregate of all web users to less than 40 percent
of capacity (or whatever you are willing to devote). |
|
Voice over IP
Voice clients typically use UDP streams. H.323, the industry standard,
starts a conversation on one port (H.323), jumps to another port
(Q.931), and eventually splits up into a data flow (RTP) and control
flow (RTCP).
Note: Video over IP is managed similarly, except the bandwidth
amounts are greater. For help and details, see Manage
Voice and Video Sessions.
|
Setup traffic (H.323 and Q.931), small |
Priority
policy at a medium-to-high priority, for example 6. |
| RTCP, small and intermittent |
Priority
policy at a medium-to-high priority, for example 6. |
| RTP and other VoIP data protocols, large and data laden |
Rate
policy with a guaranteed rate (see next comment), burstable at a
high priority for the data flows.
For determining the guaranteed rate, use the Monitor Traffic
window to look at several RTP flows. Observe usage characteristics
(current, one-minute average, and peak rate). Typically, if a manufacturer
claims that its flow requires 8 Kbps, it will actually need 17 to
21 Kbps due to additional overhead and forward error correction.
In addition, it is best to overstate the guarantee in rate policies
for UDP traffic by 15 to 20 percent.
For example: Rate policy with 25 Kbps guaranteed, burstable at
6.
Note: Many links do not deliver full-rated bandwidth.
For instance, if you have a 128 Kbps link and are running sustained
streaming traffic (such as voice), you will probably need to set
the link speed 10 percent lower than actual capacity. This lower
rate reflects the overhead for framing and routing updates running
on the same line. This is critical for slower (sub-T1) links.
|
| Print |
Citrix ICA with tag = 3, LPR, TN5250p, TN3287, NetBIOS
IP |
Rate
policy with 0 guaranteed, burstable, priority 2. |
| Database traffic |
Oracle |
Try a rate
policy with 0 guaranteed, burstable, at priority 6 or a relatively
high priority. Examine response times. If latency is a problem, switch
to a priority
policy at a high priority such as 6. |
| Citrix application |
Citrix-based ICA applications, classified individually
or together |
Rate
policy: 5 to 20 Kbps guaranteed, burstable, priority 4 or 5. If
you have a slow link or a larger number of concurrent Citrix users,
use less guaranteed rate.
Partition on the Citrix parent class of 25 to 50 percent of the
link size, burstable, no limit.
|
| Encrypted traffic |
SSL, IPSec, others |
It's impossible to suggest one management strategy for all encrypted
traffic because its characteristics and needs vary, just as those
for unencrypted traffic vary.
If the encrypted traffic is bursty, batch-oriented, and uses TCP
(such as FTP over SSL), use a rate
policy.
If it's not bursty and doesn't use TCP (such as an IPSec tunnel
of Telnet traffic), use a priority
policy.
A partition on IPSec to
protect (if it needs protection) and/or to
contain (if other traffic's performance is impacted by IPSec's
bandwidth demands) is appropriate.
A rate policy with guaranteed bandwidth is usually not
appropriate for IPSec traffic, as it may not need the reserved amount
or it may need more than what is allocated. A priority policy is
a better choice.
|
See also:
Rate
Policy Examples
Priority
Policy Examples
Never-Admit
Policy Examples
|