QoS Bandwidth Allocation Calculator
Plan QoS class shares from a parent bandwidth rate, then see reserved Mbps, best-effort headroom, priority pressure, and burst ceilings.| Class | Behavior | Share | Reserved rate | Burst ceiling | Note | Copy |
|---|---|---|---|---|---|---|
| {{ row.className }} | {{ row.behaviorLabel }} | {{ row.percentDisplay }} | {{ row.reservedDisplay }} | {{ row.burstDisplay }} | {{ row.note }} |
| Check | Status | Action | Reason | Copy |
|---|---|---|---|---|
| {{ row.check }} | {{ row.status }} | {{ row.action }} | {{ row.reason }} |
Introduction:
QoS planning matters most at the point where a link, tunnel, or shaped service rate becomes congested. Before congestion, most packets can leave at line speed and class percentages may appear irrelevant. During congestion, the queuing and shaping policy decides which packets wait, which packets move first, which packets may be dropped, and how much capacity each traffic class should be able to use.
Bandwidth allocation is the capacity-budget step of that work. It turns one parent policy rate into planned shares for voice, video, business applications, background transfers, and default traffic. The parent rate may be a provider handoff, a shaped egress value, or a deliberate under-shape below the physical interface speed so congestion occurs where the QoS policy can control it.
The key terms are easy to mix up. A traffic class is a group of packets matched by markings, addresses, ports, applications, or other policy rules. A reserved share is the portion of the usable parent rate planned for that class during congestion. Best effort is the capacity left for unmatched or default traffic. A strict or priority class is treated as delay-sensitive, so it needs special care because an oversized priority queue can take capacity away from every other class.
- Voice and call control usually need low delay and low jitter more than large throughput.
- Interactive video often needs a larger reservation, but it still suffers when packet loss rises.
- Critical data classes protect important applications from being buried under bulk transfers.
- Scavenger or limited classes keep backups, sync jobs, and other background traffic from dominating a busy link.
- Default traffic still needs room for routing control, retransmissions, management access, and applications that were not matched by a more specific class.
Class percentages are easy to overread. A 20% reservation on a 100 Mbps shaped policy means 20 Mbps of planned capacity during congestion, not a guarantee that the application is marked correctly, not proof that another network honors the marking, and not a live measurement of delay or loss. The same percentage also has a different meaning on a 1 Gbps parent than it does on a 50 Mbps branch circuit.
Good QoS planning keeps capacity math and operating evidence separate. The allocation should leave room for traffic that was not explicitly classified, keep strict-priority traffic below a reviewable share, and be checked against real counters after deployment. Queue drops, shaped-rate counters, class-map matches, packet marking, and user experience decide whether the policy works in practice.
The most useful starting point is a simple capacity ledger: choose the usable parent bandwidth, assign each class a share, reserve enough for delay-sensitive traffic, and keep a visible remainder for everything else.
How to Use This Tool:
Start with the rate the QoS policy actually controls, then treat each class row as a line in a bandwidth ledger.
- Set Parent bandwidth and choose Kbps, Mbps, or Gbps. Use the shaped egress rate or WAN handoff rate when that is lower than the physical interface speed.
- Fill in Class allocation rows. Each row needs a class name, share percentage, behavior, priority from 1 to 8, and an optional note.
- Use Add class for extra classes, or reload the sample rows when you want to return to the voice, video, critical-data, and scavenger example.
- Open Advanced when you need Shaping headroom, a larger Burst ceiling multiplier, or a different Priority review threshold.
- If Check allocation inputs appears, correct the listed issue before trusting the result. The parent bandwidth must be greater than zero, and at least one class row must remain.
- Read Allocation Ledger first for class rates, then use Policy Guidance to see whether the total share, best-effort headroom, priority share, headroom setting, burst setting, or input audit needs review.
- Use QoS Share Stack for the percentage mix and Class Rate Ladder for the absolute reserved-rate comparison.
Before copying the numbers into a device policy, confirm that the input audit is clean and that Unallocated best effort is intentional rather than an accidental leftover.
Interpreting Results:
Reserved rate is the planned Mbps value for a class after unit conversion and shaping headroom. Burst ceiling is a planning column based on the selected multiplier; it does not reduce or increase the total reserved share.
The two most important warnings are over-allocation and priority pressure. Overallocated means named class shares total more than 100% of usable bandwidth. Priority review means strict and priority rows exceed the configured threshold, so policing, shaping, or smaller class shares should be reviewed before deployment.
- Best-effort headroom above 0% leaves room for default queues, control traffic, and unmatched flows.
- Input audit notes clamped values, such as a share above 100%, headroom above 50%, or burst multiplier outside 1x to 10x.
- A clean allocation does not prove traffic is marked correctly. Verify class-map matches, queue drops, shaped rate, and latency after the policy is active.
Technical Details:
Differentiated Services separates packet classification from forwarding treatment. The Differentiated Services Code Point, or DSCP, is carried in the IP header, while forwarding behavior depends on how each hop maps that marking into queues, policers, schedulers, and drop rules. A bandwidth allocation is therefore a policy budget for one enforcement point, not an end-to-end service promise.
The arithmetic starts with one parent policy rate and a set of class percentages. The parent is normalized to Mbps, optional shaping headroom is removed, and each class percentage is applied to the remaining usable parent bandwidth. Strict priority and priority classes use the same rate formula as every other class, but their combined percentage is compared with the priority review threshold because those queues can dominate congestion if they are not bounded.
Formula Core:
The core arithmetic converts the entered parent rate to Mbps, removes shaping headroom, and applies each class share to that usable parent rate.
| Symbol | Meaning | Unit or range |
|---|---|---|
| P entered | Parent bandwidth value entered by the user. | Kbps, Mbps, or Gbps |
| U unit | Conversion factor to Mbps. | Kbps = 0.001, Mbps = 1, Gbps = 1000 |
| H pct | Shaping headroom removed before class rates are calculated. | 0% to 50% |
| S class | Reserved share for one class. | 0% to 100% |
| M | Burst ceiling multiplier applied to each reserved rate. | 1x to 10x |
For example, a 100 Mbps parent with 5% shaping headroom leaves 95 Mbps usable. A class with a 20% share reserves 19 Mbps. With a 1.5x burst multiplier, its burst ceiling is 28.5 Mbps, while the class still counts as only 20% of the reserved-share total.
| Behavior | Rate calculation | Review role |
|---|---|---|
| Strict priority | Share percent times usable parent bandwidth. | Included in the strict/priority total for threshold review. |
| Priority class | Same reserved-rate formula as other classes. | Also counted toward the priority review threshold. |
| Guaranteed minimum | Share percent creates a minimum reserved rate. | Reviewed against total reserved share and remaining headroom. |
| Weighted share | Share percent creates a planned class rate. | Useful for proportional distribution when congestion occurs. |
| Scavenger / limited | Share percent creates a small planned class rate. | Usually kept low so background traffic cannot dominate. |
| Best effort | Calculated from the remaining unreserved share. | Shows whether default and unmatched traffic still have capacity. |
Boundary checks protect the planning math from impossible inputs. Class shares below 0% or above 100% are clamped into range, shaping headroom is limited to 0% through 50%, burst multiplier is limited to 1x through 10x, and the priority review threshold is limited to 0% through 100%. The input audit reports those adjustments so copied policy values are not mistaken for untouched input.
| Condition | Boundary | Result meaning |
|---|---|---|
| Total class reservation | Greater than 100% | The policy is overallocated and named classes exceed usable parent bandwidth. |
| Best-effort headroom | Less than or equal to 0% | Default and unmatched traffic have no remaining planned capacity. |
| Strict/priority share | Greater than the configured review threshold | Priority traffic may need policing, shaping, or a smaller reserved share. |
| Input audit | Any clamped numeric value | The result is calculated from the supported value, not the original out-of-range number. |
The default sample uses a 1,000 Mbps parent with four named classes totaling 70%. Voice reserves 100 Mbps, video reserves 250 Mbps, critical-data reserves 300 Mbps, and scavenger reserves 50 Mbps. Unallocated best effort remains at 30%, or 300 Mbps.
Limitations:
The result is a planning view for class rates. It does not confirm packet marking, class-map matching, provider treatment, queue depth, scheduler behavior, policing accuracy, shaping counters, or live application quality.
- Validate DSCP markings and class matches with real traffic before relying on the allocation.
- Check interface counters, queue drops, shaped rate, and application latency after deployment.
- Keep enough best-effort headroom for unmatched and control traffic unless the policy intentionally isolates that traffic elsewhere.
Worked Examples:
Branch WAN policy. A 1 Gbps parent with the sample rows produces 700 Mbps in Reserved rate values and 300 Mbps for Unallocated best effort. Because strict plus priority share is 35%, the default 33% Priority review threshold produces a Priority review status.
Under-shaped 100 Mbps circuit. A 100 Mbps parent with 5% Shaping headroom has 95 Mbps usable. Voice at 10% reserves 9.5 Mbps, video at 20% reserves 19 Mbps, and data at 50% reserves 47.5 Mbps. With a 1.5x Burst ceiling multiplier, the Burst ceiling column shows 14.25 Mbps, 28.5 Mbps, and 71.25 Mbps for those rows.
Overallocated troubleshooting case. A 100 Mbps policy with 40% voice, 35% video, and 35% data totals 110%. The summary reports 110.0% reserved, Best-effort headroom is starved, and Total class reservation tells you to reduce reserved shares by 10.0%.
FAQ:
What parent bandwidth should I enter?
Enter the rate controlled by the QoS policy, such as the shaped egress rate or provider handoff. If the physical interface is faster than the WAN path, use the lower usable policy rate.
Why does best effort matter if every important class is listed?
Not every packet is matched by a named class. The Unallocated best effort row shows the remaining capacity for default queues, control traffic, retransmissions, and unexpected application flows.
Does the burst ceiling change the reserved share?
No. Burst ceiling multiplier only changes the planning column for each class. It does not change total reserved percent, best-effort headroom, or priority threshold status.
Why did a class share or setting change?
Out-of-range values are clamped before calculation. Check Input audit when a share, shaping headroom, burst multiplier, or priority threshold was outside its supported range.
Does this prove a QoS policy will work on the network?
No. The allocation is a capacity plan. Use device counters, class-map matches, queue drops, and latency measurements to verify the deployed policy.
Glossary:
- Parent bandwidth
- The bandwidth controlled by the QoS policy before class percentages are applied.
- Shaping headroom
- A percentage removed from the entered parent rate before class rates are calculated.
- Reserved share
- The percentage of usable parent bandwidth assigned to a named traffic class.
- Reserved rate
- The Mbps value produced by multiplying usable parent bandwidth by a class share.
- DSCP
- The Differentiated Services Code Point carried in the IP header to help classify packets.
- Best effort
- Unreserved capacity left for default or unmatched traffic.
- Strict priority
- A delay-sensitive class behavior counted in the priority review total.
References:
- RFC 2474: Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers, IETF, December 1998.
- RFC 3246: An Expedited Forwarding PHB, IETF, March 2002.
- RFC 4594: Configuration Guidelines for DiffServ Service Classes, IETF, August 2006.