Bandwidth is a peak problem, not an average one
Averages mislead badly here. A 200-person office might average 30 Mbps across a working day and still be unusable at 09:30, because that is when the all-hands starts, the overnight backups are still draining and everyone opens their mail at once. Circuits are sized for the busy hour, and the busy hour is built from three numbers per application: how many people could use it, how many are using it at the same instant, and what each active session costs.
Concurrency is the number that carries the most uncertainty and the most leverage. Two hundred people with browsers do not generate two hundred simultaneous streams; browsing is bursty, and 40–60% simultaneity is a normal planning figure. Two hundred people with softphones generate far fewer — a general office rarely exceeds 10–20% of extensions in a call at once, though a contact centre can approach 90%. Video sits in between and is the one that has moved most in the last decade.
The per-session bitrate is the number with the firmest ground under it. Voice codecs have exact payload rates defined by ITU-T recommendations, and the header overhead on top of them is arithmetic. Video conferencing bitrates are published by each platform as ranges. Web and SaaS traffic is the vaguest of the three, because a user reading a document and a user syncing a 2 GB folder are both “one browsing user”.
Two further multipliers finish the job. Protocol overhead accounts for headers, retransmissions and any tunnelling. Target utilisation converts a requirement into a purchase: you do not buy a link the size of your peak, you buy one large enough that your peak sits comfortably inside it.
Why you divide by a utilisation target
The core sum is straightforward: for each profile, multiply users by concurrency by per-session bitrate, add the profiles together, then multiply by one plus the overhead fraction. That gives the peak offered load in Mbps.
The division by a utilisation target is the step people skip, and it is the one that decides whether the link feels fast. A packet-switched link is a queueing system, and in a queueing system the average waiting time rises non-linearly as the arrival rate approaches the service rate. In the simplest model the queue length scales with ρ ÷ (1 − ρ), where ρ is utilisation: at 50% load the factor is 1, at 70% it is 2.33, at 90% it is 9, and at 95% it is 19. Real traffic is burstier than that model assumes, so the practical degradation arrives earlier still.
That is why a 70% target is a common design point and 85% is where engineers start replanning. A link at 70% has room to absorb a burst without building a queue that voice and video can feel; a link at 95% converts every burst into jitter. Dividing the requirement by 0.70 rather than 0.95 costs about 36% more capacity and buys a qualitatively different experience.
Upstream is calculated separately because applications are not symmetric in the same way. A video call sends roughly what it receives, and so does a voice call, so both count at full rate in each direction. Browsing and SaaS are heavily download-weighted, typically 20–30% upstream, unless the site runs file synchronisation or cloud backup. If your total upstream requirement comes out above half your downstream requirement, an asymmetric consumer product will fail on upload first, whatever its download headline says.
Worked example: a 200-person office
A single site has 200 staff. All 200 use SaaS and browsing, 100 have VoIP extensions, and 60 are regular video-conference users. You plan for 12% protocol overhead and want to run the link at no more than 70% at peak.
- Video. 60 users × 30% concurrency = 18 simultaneous streams. At 2,500 kbps each, that is 45,000 kbps = 45.0 Mbps.
- VoIP. 100 extensions × 20% = 20 simultaneous calls. At 87 kbps each (G.711 with RTP, UDP, IP and Ethernet headers), that is 1,740 kbps = 1.74 Mbps.
- SaaS and browsing. 200 users × 50% = 100 active sessions. At 1,200 kbps each, that is 120,000 kbps = 120.0 Mbps.
- Add the payload. 45.0 + 1.74 + 120.0 = 166.74 Mbps of application traffic.
- Add protocol overhead. 166.74 × 1.12 = 186.75 Mbps peak downstream requirement.
- Divide by the utilisation target. 186.75 ÷ 0.70 = 266.8 Mbps. You buy a 300 Mbps or 500 Mbps circuit, whichever the carrier sells.
- Now upstream. Video and voice count in full: 45.0 + 1.74 = 46.74 Mbps. Browsing contributes 25% of its downstream: 120.0 × 0.25 = 30.0 Mbps. Total payload 76.74, × 1.12 = 85.9 Mbps required, ÷ 0.70 = 122.8 Mbps recommended.
Read those last two lines together. The upstream recommendation is 46% of the downstream one, which rules out any asymmetric product with a 20:1 ratio. A 300/30 service would satisfy the download requirement and fail the upload requirement by a factor of four — and the symptom would not be slow downloads, it would be video calls breaking up whenever the office is busy.
Sanity-check the per-session figure too. 166,740 kbps of payload across 138 concurrent sessions averages 1,208 kbps each, which is dominated by the browsing profile, as you would expect when browsing accounts for 72% of demand.
How to read the result
The recommended figure is a floor for procurement, not a prediction of usage. Round up to the next product the carrier actually sells. Circuits come in fixed sizes, and the gap between 200 Mbps and 500 Mbps is usually far smaller in price than the gap in risk.
Check the upstream line before you compare products. Symmetric fibre and asymmetric cable can carry the same download headline and behave completely differently for a site with voice and video. The ratio between the two figures on this page is the specification to shop against.
Treat the per-session figure as a sanity check on your inputs. If it comes out at 3 Mbps per session for a general office, your browsing bitrate is set for a streaming-heavy population. If it comes out at 150 kbps, you have probably left video out.
The monthly volume figure tests a data cap, not a bill. It assumes the peak rate sustained for eight hours a day across 22 working days, which is deliberately pessimistic; real busy-hour traffic tapers. Use it to check whether a metered product could plausibly be breached, then compare against the Mbps to MB/s converter if you need the figure in other units.
Sizing does not fix prioritisation. A correctly sized link still delivers poor voice quality if a single backup job can fill it. Quality-of-service marking and shaping, so that voice and interactive traffic pre-empt bulk transfer, is a separate control and a necessary one on any link below a few hundred megabits.
Per-session bitrate planning figures
| Application | Payload rate | With RTP/UDP/IP + Ethernet | Direction |
|---|---|---|---|
| G.711 voice, 20 ms packets | 64 kbps | 87.2 kbps | Symmetric |
| G.729 voice, 20 ms packets | 8 kbps | 31.2 kbps | Symmetric |
| G.722 wideband voice, 20 ms | 64 kbps | 87.2 kbps | Symmetric |
| Video call, 360p | ~400 kbps | ~450 kbps | Symmetric |
| Video call, 720p | ~1,200 kbps | ~1,350 kbps | Symmetric |
| Video call, 1080p | ~2,500 kbps | ~2,800 kbps | Symmetric |
| HD video streaming | ~5,000 kbps | ~5,600 kbps | Download |
| 4K video streaming | ~15,000 kbps | ~16,800 kbps | Download |
| General SaaS and browsing | 500-2,000 kbps | 560-2,240 kbps | Mostly download |
G.711 header math: 160-byte payload + 40 bytes RTP/UDP/IP + 18 bytes Ethernet = 218 bytes × 50 packets/s × 8 = 87,200 bps. G.729 uses a 20-byte payload: 78 bytes × 50 × 8 = 31,200 bps.
Concurrency assumptions are where sizing goes wrong
Every other input on this page is measurable. Concurrency is a guess, and the answer scales linearly with it, so a 30% guess against a real 50% under-sizes the circuit by 67%. Two things reduce the risk. First, take the number from your own monitoring — a call-manager report gives simultaneous call counts directly, and a firewall or NetFlow collector gives concurrent session counts. Second, remember that concurrency is not additive with headcount growth: doubling staff on the same site usually raises the peak by less than double, because the busy hour spreads.
Assumptions and limits of this model
- It sizes one link, not a path. End-to-end performance is set by the narrowest hop, including the far end's own circuit and any provider aggregation point.
- It assumes traffic is additive. In reality flows interact — TCP backs off, video adapts its bitrate downward under loss — so a slightly undersized link degrades gracefully rather than failing outright. That is a reason to measure, not a reason to under-buy.
- It ignores caching and local breakout. A site with a local software-update cache or split-tunnel SaaS access can cut the requirement substantially, and none of that appears in the arithmetic here.
- Backup and replication traffic is not modelled. Those are scheduled bulk flows; give them their own window and their own shaping policy rather than adding them to the busy-hour peak.
- Latency is a separate specification. Voice needs one-way delay below roughly 150 ms and jitter in the low tens of milliseconds. No amount of bandwidth fixes a satellite path.
- Wireless changes the numbers. The figures here are for the wired circuit. A Wi-Fi network delivers well under its nominal PHY rate once contention, management frames and retries are counted, so the access layer needs sizing separately.
Sizing, monitoring and the tools next door
Sizing is the first half of a loop; measurement is the second. Once the circuit is in, take five-minute averages from your router's interface counters and look at the 95th percentile over a month. If that number sits well below your target utilisation, your concurrency assumptions were pessimistic and the next renewal can be smaller. If it is above target, revisit the profile mix before you buy more capacity — a single unmanaged backup job is a more common cause than genuine user growth.
The 95th-percentile convention matters for another reason: it is how most transit and colocation bandwidth is billed. Under that model, the highest 5% of five-minute samples in the month are discarded and you pay on the next one down, which is why a short daily burst is cheap and a sustained plateau is not.
Related tools cover the neighbouring questions. Converting a rate into download times or monthly volumes is the Mbps to MB/s converter. Working out how many addresses those users need on the LAN side is the hosts per subnet calculator, and resolving a specific range is the IPv4 subnet calculator. If the site's uptime obligation is written into an SLA, the MTBF, MTTR and availability calculator converts a target such as 99.9% into the outage minutes you are actually allowed, which usually decides whether a second circuit is justified.
Finally, remember what a second circuit buys and what it does not. Two links from the same carrier over the same duct do not give you independent failure modes; two links from different carriers, entering the building by different routes, do. The availability arithmetic only pays off when the failures really are independent.