All-Optical Multi-Link Aggregation: Why Network Is Still Slow Even After Upgrading Bandwidth — The Overlooked Resource: Concurrent Sessions

The multi-link quotation sheet on the meeting table looks detailed: three commercial WAN lines with specified bandwidth and total aggregated Mbps. Divided by the number of terminals, the per-user bandwidth seems abundant. The bandwidth calculator also returns favorable figures. But once evening peak hits, the front desk reports failure to load new webpages, and POS payment timeouts happen intermittently. Speed tests still show normal results. Cabling construction is correct, and all lines are physically active. The root cause lies much earlier — one critical item was omitted from the design at the very beginning.

I. The Item Listed on the Sheet: Bandwidth

Bandwidth calculation itself is correct. Bandwidth is analogous to water pipes, measuring the maximum throughput at a given moment. It improves experience for multi-user, multi-task concurrent scenarios instead of accelerating single-file downloads. Quotation sheets, tariff documents and bandwidth calculators all revolve around this metric: how many lines, how much Mbps per line, and whether peak throughput is sufficient.

Bandwidth is easy to calculate, quote and verify. That is why discussions often stop here. However, judging network adequacy solely by total Mbps will lead to unexpected trouble later.

II. The Missing Item on the Sheet: Concurrent Sessions

The second key metric is concurrent sessions, comparable to waiters, which represents the maximum number of simultaneous connections the network can maintain. Each WAN link comes with its own NAT session table and public egress resources. N WAN links provide N sets of concurrent session capacity.

A single terminal maintains dozens of persistent sessions. Hundreds of terminals can easily generate tens of thousands of sessions. Once the session table is saturated, new connections cannot be established, while existing connections keep running. The egress bandwidth utilization usually remains low. This explains the paradox: bandwidth is underutilized, yet there are not enough “waiters” to process new requests.

Two resources need to be aggregated together: bandwidth (Mbps) and concurrent sessions. If you only calculate bandwidth, you are only counting water pipes while ignoring the serving staff.

表格

III. Key Questions to Raise During Site Survey

Network design cannot be finished in the office. These questions must be confirmed on site:
What is the session limit of each broadband line? How many terminals are online? What is the peak concurrent volume and average sessions per terminal?

Residential and commercial broadband are restricted by ONTs, home routers and carrier-side per-user session caps. The actual available margin is far smaller than theoretical data. Also confirm available operators, fiber entry points and whether multiple circuits share the same physical fiber. Without these records in the survey form, “even session distribution” has no basis, and congestion will persist even after adding lines.

AINOPOL all-optical multi-link aggregation integrates bandwidth aggregation, session aggregation and intelligent scheduling into one solution. New connections are distributed evenly across WAN links based on remaining session slots. Choose converged routers or Dream Gateways according to site scale, with expandable WAN ports and pre-built one-click scenario templates.
Use the AINOPOL bandwidth calculator to estimate bandwidth demand first, then cross-verify with session capacity. The final plan is confirmed only after both calculations match.

IV. Another Easy-to-Miss Bottleneck: The Gateway Itself

All sessions from multiple links converge on the egress gateway. The gateway’s native NAT session capacity, DNS processing performance and authentication throughput must be validated during site survey and hardware selection.
Even if sufficient WAN lines are deployed, an underpowered gateway will become the new bottleneck.

For multi-store deployments, management traffic for centralized dashboard access and policy push also needs to be counted. Portal authentication requests during mass online access at peak hours also consume gateway session and computing resources. Focusing only on WAN bandwidth ignores these loads.
AINOPOL converged gateways factor in these performance requirements at the design stage, preventing bottlenecks from simply shifting from the ISP circuit to the gateway.

Slow speeds after bandwidth upgrades are usually not caused by insufficient lines. The quotation sheet misses the concurrent session calculation. Bandwidth is the pipe, and concurrent sessions are the waiters. N WAN links deliver N independent NAT session tables. Confirm per-link session limits on site, validate gateway performance for NAT, DNS and authentication, and aggregate both resources. Only then is the design complete. Next time you review a quotation, check whether concurrent sessions are listed.

FAQ

Q: Why is the result from the bandwidth calculator still insufficient?
A: The bandwidth calculator only computes required Mbps. Concurrent session capacity is a separate calculation based on terminal count, peak concurrency and per-link session limits. Both calculations must be checked together.

Q: Is adding a “concurrent session” column on the quotation enough?
A: Session-aware scheduling is also required. Distribute sessions evenly and reserve headroom for every link. Do not forward traffic to low-cost links purely based on idle bandwidth, otherwise individual egress links will still saturate.

Q: Can the gateway itself become a bottleneck?
A: Yes. If WAN links are upgraded without matching gateway NAT session, DNS and authentication capacity, the bottleneck merely moves to the gateway. Hardware selection must follow site survey and specification evaluation.