95th percentile billing: how burstable bandwidth is calculated

02How is the 95th percentile calculated? A worked month

Each sample is an average rate over five minutes: the change in the interface's byte counter, times 8, divided by 300 seconds. Monitoring and billing systems typically read the 64-bit SNMP counters ifHCInOctets and ifHCOutOctets defined in RFC 2863, one per direction.

A 30-day month has 30 × 24 × 12 = 8,640 samples, and 5% of 8,640 is 432. Sort the samples from highest to lowest, discard the top 432, and the 433rd highest is the billable rate; counted from the bottom it is sample 8,208, which is 95% of 8,640. The 432 discarded samples cover 432 × 5 = 2,160 minutes, exactly 36 hours.

Months differ in length, and each contract defines its own rounding. With the nearest-rank method used here, a 31-day month has 8,928 samples and discards 446, and a 28-day month has 8,064 samples and discards 403. The bandwidth and packets-per-second calculator includes a 95th percentile calculator that applies the same rule to samples you enter.

# octets.txt: unix time and interface octet counter, one reading per line
awk 'NR > 1 { printf "%d %.1f Mbps\n", $1, ($2 - prev) * 8 / ($1 - t) / 1e6 } { prev = $2; t = $1 }' octets.txt

# rates.txt: one five-minute sample per line, in Mbps; nearest-rank 95th percentile
sort -n rates.txt | awk '{ v[NR] = $1 } END { r = int((NR * 95 + 99) / 100); print NR " samples, rank " r ", 95th percentile " v[r] " Mbps" }'

# output for the modelled month in the next section
8640 samples, rank 8208, 95th percentile 400 Mbps

03Worked example: when bursts are free and when they are not

Take a modelled month with stated assumptions: 150 Mbps for 21 hours a day, 400 Mbps for two evening hours and 600 Mbps for one peak hour, every day for 30 days. That gives 7,560 samples at 150 Mbps, 720 at 400 and 360 at 600. All 360 peak samples fall inside the discarded 432, so the 433rd highest sample sets the bill at 400 Mbps, and the daily peak hour costs nothing.

Now add a flood that measures 8,000 Mbps during otherwise quiet hours, and assume the provider bills the higher of the inbound and outbound 95th percentiles, which is also the default in the LibreNMS billing module. Multiply by any price per Mbps to turn the table into money; the ratios stay the same.

04Why a DDoS attack can inflate a 95th percentile bill

The provider's counters measure what crosses your port, not what you wanted. An inbound flood is delivered to the port before your own firewall can drop it, so it is counted even if the server discards every packet, and if the provider bills the higher of inbound and outbound it is billed exactly as if you had sent it.

Outbound can grow too. An application-layer flood makes the server send real responses, and a server abused for reflection, an open DNS resolver for example, sends more than it receives. Attacks can run for days, as how long DDoS attacks last shows, so the 36-hour allowance is not a safety margin to rely on. To tell an attack from organic growth in your graphs, see signs of a DDoS attack.

Some providers waive attack traffic or cap the billable rate, and some null-route an address under attack, which protects the bill by taking the service offline. Ask before you need the answer:

• Is the 95th percentile taken on inbound, outbound, the higher of the two, or their sum?
• Is traffic measured before or after DDoS filtering, and is attack traffic billed?
• Is the billable rate capped, or limited only by the port speed?
• What happens to an address under attack: filtered, rate-limited or null-routed?
• Is the commit per port, per aggregate or per site, and how are short months rounded?

05Flat, burstable and per-GB pricing compared

The same month costs very differently under each model. In the example above, 24 hours of attack raised the 95th percentile by half, but it raised the volume transferred from 61,425 GB to 146,205 GB, 2.4 times, because per-gigabyte billing counts every byte the flood delivered. Under a flat or unmetered price the invoice does not change at all.

Volume follows from rate and time: 1 Gbps sustained for an hour is 10^9 × 3,600 / 8 bytes, or 450 GB, so an 8 Gbps flood delivers 3.6 TB an hour. The figures here use decimal units (1 GB = 10^9 bytes), as transfer billing usually does.

06Does DDoS protection keep attack traffic off your bill?

It does when the filtering happens before the point where you are billed. If a protection service absorbs the flood on its own network and forwards only clean traffic, your provider's counters see only the clean traffic, and the 95th percentile reflects real use. If filtering happens on your server or your own firewall, the flood has already crossed the metered port. What DDoS mitigation is covers where the different methods sit.

Two gaps remain. A website behind a reverse proxy is protected only while attackers cannot reach the origin directly; once the origin address leaks, they can flood the metered port anyway, as how to hide your origin IP explains. And protection that is itself billed by volume or requests still charges for whatever it lets through, so check how the protection is priced as well as the transit.

07How to keep a 95th percentile bill under control

The bill is set by sustained load, so control comes from knowing your sample count early rather than at the end of the month.

• Graph your own five-minute samples from the same counters the provider uses, and compute the running 95th percentile during the month
• Alert when the month's count of samples above your commit approaches the discarded 5%
• Schedule bulk transfers such as backups for quiet hours, where they are less likely to lift the samples that set the bill
• Put DDoS filtering in front of the metered port, not behind it
• Agree in writing how attack traffic is treated before an incident, not during one