Management and Configuration Guide (Includes ACM xl) 2005-12

2-20 ProCurve Secure Access 700wl Series Management and Configuration Guide
Using the 700wl Series System
force for that client. This implementation does not attempt to shape bandwidth usage, just enforce a per-
client cap.
Because bandwidth limits are set in the Access Policy, you can set different limits for different sets of
clients even if they are connecting through the same physical port. The bandwidth limit is imposed per
client—even if there is additional bandwidth available on the specific port, a given client will be limited
to the specified limit, and cannot take advantage of the additional unused bandwidth.
For example, suppose you select a bandwidth limit of 1Mbps (upstream and downstream) for an Access
Policy named Sales. Once this is done, each user that gets rights via the Sales Access Policy will receive
a bandwidth limit of 1Mbps. The 700wl Series system algorithm does not apply an overall cap to a
group of users. This means you cannot, for instance, define a 10Mbps limit for the Sales Access Policy
and allow all users affected by that Access Policy to freely use bandwidth within that limit. Since a
WLAN is a relatively low bandwidth shared medium and the purpose of a bandwidth cap is to prevent
a single user from choking all access to other users on the same AP, it generally does not make sense to
set per user limits above 1.5Mbps since most APs only support total actual bandwidth between 5 and
25Mbps.
For non-TCP traffic, bandwidth limits work in a straightforward manner. For TCP traffic there are some
performance considerations that may limit the throughput to less than the configured limit, especially if
client traffic is being encrypted via IPSec or PPTP.
If a client is logged onto the 700wl Series system using PPTP or IPSec encryption, overhead related to
packet encryption can reduce the actual throughput experienced relative to the specified throughput. If
encrypted traffic is tunneled between Access Controllers due to client roaming, throughput may be
further affected. When a client roams between Access Controllers, existing client sessions are tunneled
through the new Access Controller back to the original Access Controller. For non-encrypted traffic,
new sessions initiated after the roam are handled directly by the new Access Controller, but even new
sessions involving encrypted traffic are tunneled back to the original Access Controller. For
non-encrypted traffic that is tunneled, bandwidth limits are enforced both on the new Access Controller
(to avoid tunneling packets that should be dropped) and on the original Access Controller, which makes
the actual determination of whether to drop packets. However, with encrypted packets the new Access
Controller cannot determine which packets should be dropped and thus tunnels all to the original
Access Controller.
If the 700wl Series system is used to pass through encrypted traffic and is not the termination of the
VPN, the bandwidth limitation algorithm cannot use the packet contents to help determine which
packets to drop. In this case, it adopts a very conservative algorithm to ensure that throughput will not
exceed the configured limits, and may in fact result in a throughput that is below the configured limits.
In general, when setting bandwidth limits you may need to adjust your bandwidth settings based on
actual client experience. If clients are experiencing bandwidth significantly below the configured limits,
you may want to increase the limits so that throughput more closely approaches the limits you intend.
Note:
If you are measuring throughput at layer 2, you must take into account headers,
acknowledgements and other overhead, in addition to the data itself. For example, transferring a 10
megabit file via FTP at 1 megabit per second will take more than 10 seconds due to the additional
information involved in the transfer.