Rate limit balance

Greetings,

Our use case is to limit bandwidth to individual remote locations (on different subnets). We have devices running at a couple hundred remote locations that we would like to have come back to our central datacenter to download updates from an FTP server. All devices simultaneously coming back to the datacenter for a large update could overwhelm the circuit. Applying an individual per-session limit would not protect us against link saturation and applying an aggregate limit to the whole server would not be effective either.

We would like solve this issue by creating multiple, aggregate bandwidth limits to numerous subnets. I.e. "Site-A" gets 30Mbps, "Site-B" gets 30Mbps, "Site-C" gets 30mbps, etc… Each site (subnet) gets their own limit that does not count against other sites.

I am testing Bandwidth Manager with a 30Mbps limit and it does limit bandwidth to 30Mbps on the host server. However, bandwidth is not balanced evenly across the client connections. The clients are averaging 10Mbps, 9Mbps, 8Mbps and 3Mbps respectively. My server and all clients are on Virtual Servers in our datacenter with 10Gpbs connections to the backbone, so this should be a best-case scenario. I'll note that all clients systems are able to transfer at 2Gbps+ when the rule is disabled.

Your product does a far better job than NetQosPolicy rules, but I am fearful that some devices could be starved for bandwidth and timeout when a dozen are more devices are connected.

Please advise.

Your planned setup is exactly what Bandwidth Manager is designed for. Creating one rule per site subnet, each with its own aggregate limit, works as you expect: each rule has an independent limit that does not count against the others, and you can create as many such rules as you have sites.

Regarding the uneven distribution: within a single aggregate rule, Bandwidth Manager enforces the total precisely, but it deliberately does not schedule individual TCP connections inside that limit. All connections share one queue, and the split between simultaneous transfers is determined by TCP's own congestion control - the same behaviour you would see from a router enforcing a 30 Mbps policy. Differences in round-trip time and connection start order produce exactly the 10/9/8/3 pattern you observed, and the shares shift over time rather than staying fixed.

Importantly, this does not lead to starvation or timeouts. The queue depth is bounded, so a slower connection experiences ordinary packet drops that TCP recovers from automatically: every connection keeps making progress, and as faster transfers complete, the remaining ones immediately take up the freed bandwidth. With N devices downloading a large update, each will average roughly total/N over the life of the transfer even if instantaneous rates differ.

If you would like firmer per-device guarantees, there are two options:

1. In the rule properties, set Tracking mode to "source IP address" (or destination, depending on direction). Each device then receives its own independent limit (e.g. 3 Mbps each) guaranteeing no device can be crowded out. The trade-off is that the limit is fixed per device, so a single device downloading alone is also capped at that figure rather than using the full 30 Mbps. Note: a packet is processed by the first matching rule only, so a per-device and an aggregate limit cannot be stacked on the same traffic.

2. Keep the aggregate rules as you have them, and additionally enable "Transmit short TCP ACK without queueing" in Settings, which improves TCP feedback for competing transfers and typically evens out the distribution.

In practice, for a fleet downloading the same large update, the aggregate limit per site is usually the right choice: it protects the circuit, and TCP's convergence over a long transfer means no device is left behind.