This may be due to improperly configured rate policies with guarantees that are set too high. Unlike with partition guarantees, rate policy guarantees are not shareable. Also, partitions work on aggregate traffic while policies work per-flow. For example, if one assigns a 1M guarantee within a rate policy and a particular flow only utilizes 50% of 1M, PacketShaper will allocate the full 1M to the flow while it is active. No other flows will be allowed to utilize the unused portion of the 1M guarantee.
As another example, consider a 10M partition on a folder which contains classes with 1M guarantees.
Viewing a single page may download multiple elements such as graphics, ads, HTML, etc. With ten flows, ten 1M rate guarantees are allocated, saturating the parent partition in /Inbound/Admin. Although the actual utilization may be much less than 10M (this will be shown on the Monitor page), additional flows will be denied bandwidth allocation. If a flow that is denied has a rate policy guarantee, this results in a "guaranteed rate failure". The FTP class in this example will also get no bandwidth since falls within the same partition and it does not have a rate guarantee of it's own. This does not apply to the 5M rate limit in this example. This works solely to limit a single flow to 5M and since this is not a guarantee, allocations in excess of the guarantee up to the 5M limit will not result in guaranteed rate failures.
It is recommended that a rate policy guarantee only be assigned to less aggressive, latency-sensitive such as Citrix or VoIP. For bursty traffic such as HTTP, the rate guarantee is best left blank, or zero. If the intent is to distribute bandwidth equitably per-user, rather than per-flow, dynamic subpartitions should be considered.