Establish the workload and billing baseline
Separate live and on-demand traffic, then group by platform, region, media protocol, and rendition. Record the time window, viewer concurrency, playback duration, and CDN contract terms. A busy live event is not directly comparable to a low-traffic VOD day.
- Review bitrate ladders, encoding efficiency, cache behavior, and unnecessary downloads before attributing all potential savings to P2P.
- Check whether the CDN bills by transferred bytes, peak bandwidth, a percentile method, or a minimum commitment.
- Capture startup time, rebuffering, errors, and playback completion alongside delivery bytes. Cost improvements must not hide a poorer playback experience.
Calculate CDN offload from download bytes
P = bytes downloaded from peers
C = bytes downloaded from the CDN
CDN offload = P / (P + C) × 100%Use the same application, content scope, and time window for P and C. Do not add peer upload bytes to the denominator: that would count shared traffic again. When P + C is zero, report the rate as unavailable instead of zero.
For a combined result, divide summed peer bytes by summed peer and CDN bytes. Do not average session percentages without weighting by bytes. Exclude unrelated API or tracker traffic and keep measurement boundaries consistent.
This is a delivery-byte metric, not a claim about the CDN invoice. Compare it with provider-side traffic and billing data; caching, retries, and accounting boundaries can produce differences. The statistics reference defines MeshStream's delivery measurements.
Estimate the bill impact, including P2P fees
For a simplified flat per-GB contract, let D be the comparable delivered traffic, r the measured offload fraction, c the CDN unit price, and p the effective MeshStream price per peer-downloaded GB:
CDN-only cost = D × c
Estimated CDN + P2P delivery cost = D × (1 − r) × c + D × r × p
Estimated difference = D × r × (c − p)Illustration only: with 10,000 GB, measured offload of 30%, CDN at $0.05/GB, and an assumed effective P2P price of $0.02/GB, the delivery-only estimate changes from $500 to $410, a $90 difference. These are hypothetical inputs, not MeshStream pricing, a customer result, or a savings forecast.
The model assumes equal delivered traffic and flat byte-based charges. It excludes taxes, commitments, request fees, TURN or relay charges where applicable, integration, and operating costs. Use your actual package or subscription cost rather than a fictional unit price; quota and minimum commitments can change the result. Byte offload alone does not determine savings under peak or percentile billing. Check current MeshStream pricing and your CDN contract separately.
Run a representative playback comparison
- Record a CDN-only baseline with P2P disabled, using your target devices and player settings.
- Enable P2P on a limited cohort. Keep comparable content, bitrate, platform, region, and network conditions; document any differences in audience concurrency.
- Separate warm-up, stable concurrency, and abnormal exits. Record peer bytes, CDN bytes, and playback quality for each window.
- Keep CDN connectivity available while disabling P2P to validate fallback. Release sessions after playback so final statistics can be completed.
- Repeat across representative traffic periods and reconcile estimates with actual billing. Report observed differences and confounders rather than claiming that a before/after change proves causation.
For live workloads, see the P2P CDN live streaming solution. For implementation, start with the Web SDK or the quickstart.
Common measurement mistakes
Can the session offload rate rise without reducing the total bill?
Yes. Delivered volume can grow, the CDN may have a minimum spend, or P2P and other charges can offset lower CDN byte usage. Compare complete costs for a comparable workload.
Why does a high peer count not prove savings?
Connected peers may lack the requested segment or enough upload capacity. Use delivered bytes and playback quality, not connection count alone.
Is an offload percentage from a small test a production forecast?
No. Device mix, viewer overlap, content popularity, and network reachability can change in production. Keep the test conditions and measured limits next to every estimate.