Solution

License the bandwidth you actually need

Combined RX and TX measured at the vService client-facing boundary — pre-vService network blocks and the application-server pass-through stay out of the tier you pick

Most ADC and gateway products measure throughput at the platform wire. Every byte through their infrastructure counts — the duplicate traffic on the application-server side and the traffic already blocked at the network layer. To cover the same real serving capacity, you have to license a larger tier. TR7 measures at the vService client-facing boundary: combined RX and TX of the traffic your virtual service actually serves. The tier you license matches your real serving capacity.

vService boundary
Where the meter sits — client-facing edge of the virtual service
RX + TX
Combined bi-directional throughput, industry-standard measurement
Live
Same figure shown to operators in the reporting layer

Why platform-wide metering pushes you into a bigger tier than you need

Traditional ADC products measure throughput at the platform wire — the aggregate of every byte flowing through the appliance, regardless of which boundary it crossed. A single HTTP request touches the platform multiple times: client to platform, platform to application server, application server back to platform, platform back to client. Many vendors count each of those segments, so the same request consumes throughput on the meter up to four times.

On top of that, the network-layer protection that fires before a request ever reaches the vService — L3/L4 DDoS protection, network-layer firewall rules, IP reputation drops — still consumes bytes that count against the same meter. The better the network-layer protection performs, the larger the silent overhead loading the throughput accounting.

Bandwidth on an ADC is licensed as a tier, not metered per byte. But the tier you pick has to be high enough to cover everything the meter sees — so platform-wire metering pushes you into a larger tier than your real serving capacity requires. The TR7 model draws the line at the vService client-facing boundary. The traffic your virtual service actually serves to and from the client side is what gets measured. The internal pass-through to application servers is not metered. The traffic stopped at the network layer before the vService sees it is not metered. The tier you license lines up with the bandwidth you actually use.

vService boundary, bi-directional, transparent

Throughput measurement runs continuously in the TR7 ADC reporting layer. The same number that determines whether you fit in your licensed tier is shown live to operators — no separate billing platform, no opaque vendor-side calculation.

Measured at the vService boundary

The meter sits at the vService client-facing edge. Traffic that reaches the vService and is processed by it counts. Traffic stopped before the vService — at the network firewall or by L3/L4 DDoS protection — does not.

Combined RX and TX

Both the client-to-vService request side (RX) and the vService-to-client response side (TX) are summed. This is the industry-standard way to express true bi-directional throughput and matches how serving capacity translates into user experience.

Application-server pass-through is out of scope

When the vService relays a request to an application server and the response comes back, that internal traffic is not counted. Only the client-facing side counts toward the licensed tier.

Live operator visibility

The same throughput figure used for the license tier is shown in real time in the ADC reporting layer. Operators can watch utilization, see how much of the tier is in use, and plan tier capacity changes before the renewal cycle.

What does not count toward the licensed tier

Measurement happens at the vService client-facing boundary. Three types of traffic never cross that boundary and therefore are not included in the licensed tier:

Network-layer firewall blocks

Packets dropped by network-layer firewall rules before the vService sees them are not in the measurement window. They never crossed the vService boundary.

L3/L4 DDoS blocked at the network layer

Volumetric flood traffic blocked by network-layer protection before reaching the vService is excluded. Being a frequent attack target does not push you into a larger licensed tier.

vService to application-server pass-through

When the vService relays a request to an application server and receives the response, that internal traffic is not metered. The same request is not counted a second time on the application-server side.

What this means in practice

Most competitor products measure throughput at the platform wire — every byte through their infrastructure counts, both client-facing and application-server-facing. TR7 only counts the client-facing side. The structural consequences:

01

No double-count of the same request

A request handled by your virtual service crosses two boundaries: client to vService, and vService to application server. Vendors that meter both add the second crossing to the same throughput figure for traffic that is structurally identical to the first. TR7 only counts the client-facing crossing.

02

Network-layer protection is not a tier tax

When network-layer protection blocks an L3/L4 DDoS or a network firewall rule drops a flood, those bytes do not propagate into the throughput accounting. Being a high-value target should not force you into a larger licensed tier than your real serving capacity requires.

03

Materially more effective capacity per licensed tier

Because the duplicated application-server-facing traffic is not metered, the same licensed tier on TR7 carries substantially more real serving capacity than the same nominal tier on platform-wire metering products. For typical enterprise workloads the difference can compound to multiples.

04

Transparent and operator-verifiable

The throughput figure your tier is sized against is the same figure surfaced in the reporting layer. Operators can audit it live, reconcile it against vService-by-vService activity, and plan tier capacity well before renewal.

05

Per-vService bandwidth control (QoS)

Independently of the global licensed tier, individual vServices can have per-vService bandwidth limits with automatic fair-share QoS enforcement. Service Provider deployments distribute licensed bandwidth across tenants automatically.

Where the model makes the biggest difference

Sites under sustained attack pressure

Banking, government, betting, public services — workloads that block constant L3/L4 attacks at the network layer. Network-layer protection does its job without forcing you into a larger licensed tier than your real users require.

E-commerce during peak campaigns

Black Friday, flash sales, ticket launches — windows when bot waves and legitimate traffic compete for the same capacity. The throughput your tier has to cover reflects what shoppers actually received, not the bot probes the network layer already filtered.

Streaming and media delivery

Outbound-heavy services where response payloads dominate the bandwidth profile. RX + TX measurement at the client-facing edge matches how serving capacity is usually expressed in this category.

Service Provider multi-tenant deployments

Licensed bandwidth shared across customer tenants with automatic fair-share QoS. Per-vService limits let providers offer differentiated service tiers; the global license measures only the client-facing total across all tenants.

Common questions

Is TR7 bandwidth licensed as a tier or metered per byte?
It is licensed as a tier picked up front, the same as most ADC products. You choose the tier when you license; throughput stays within that tier during the period. What makes TR7 different is not the licensing model but the measurement model — the throughput figure that has to fit in your tier counts only what your vService actually serves at the client-facing boundary, so the tier you pick matches real serving capacity rather than platform-wide overhead.
Are WAAP and bot management blocks really included in the measurement?
Yes. WAAP and bot management run inside the vService, so the traffic they inspect — both allowed and blocked — is part of what the vService processes and is included. The line is not 'allowed vs blocked', the line is 'reached the vService vs stopped before it'. Network-layer firewall and L3/L4 DDoS protection sit before the vService and are excluded; L7 controls sit inside it and are included.
How does this compare to competitor measurement?
Most ADC and gateway products meter at the platform wire — every byte through their infrastructure, including the duplicated traffic on the application-server side. Because TR7 only meters the client-facing edge of the vService, the same request that competitors count twice (once on each side) is counted once. For the same real serving capacity, the TR7 licensed tier you need is materially smaller — the difference can compound to multiples depending on workload profile.
Can I see the throughput measurement live?
Yes. The same figure used to size your license tier is shown in the ADC reporting layer in real time. Operators can watch utilization throughout the period, reconcile it against per-vService activity, and plan tier capacity well before renewal.
What happens if my traffic exceeds the licensed tier?
TR7 continues operating normally — there is no hard cut-off that stops service. Overage is surfaced on the licensing dashboard. Operators can upgrade the licensed tier on-demand with pro-rated pricing for the rest of the period, or wait for renewal.
Does per-vService bandwidth limiting change the global figure?
Per-vService limits are a fairness mechanism within the licensed tier. They distribute the licensed bandwidth equitably across vServices and tenants, but they do not change the global measurement — the license sees the aggregate client-facing throughput across all vServices.

See the throughput your tier is sized against — in real time

The TR7 ADC reporting layer shows the same vService-boundary figure that determines your licensed tier — visible, predictable, and free of pre-vService overhead.