In most Corporate Environments clients will connect in any number of different ways and locations. Bandwidth control must make allowances for these different scenarios with clients Roaming and connecting over VPN. Clients may be on well connected networks or slow links with and without Peers. StifleR must also recognise and cater for situations where the StifleR server cannot be contacted.
The StifleR client can be configured to recognise these different situations and adjust bandwidth allowances accordingly.
The following gives an overview of these various schedule settings:-
At start up the StifleR client will automatically set the DefaultDisconnected Bandwidth limits (DO and BITS) which are applied in the event that the StifleR client is unable to connect to the StifleR server.
If the StifleR Client can contact the StifleR server then it will firstly apply the DefaultNonRedLeader Policies (DO and BITS) values from the local client settings.
The Server will then instruct the client according to its situation:
If the client is roaming, ie. not assigned to a managed subnet, it will set the Server value of DefaultRoamingBandwidth (50/50 DO and BITS)
Bandwidth settings are set as follows:
If the StifleR agent detects that the system is connected via a corporate VPN connection, the client will take the configuration settings for the subnet (as configured on the server) and set:
- TargetBandwidth value / number of active clients
This is updated every 15mins.
For example. If the VPN Subnet is configured with a
TargetBandwidthvalue of 102400 (100Mbs), and there are 5 clients connected via VPN, they will each receive 5/100Mbs – so 20Mbs
This is recalculated every 15 minutes so as clients connect/disconnect via VPN the bandwidth is shared proportionately.
Note: VPN Clients on a VPN subnet are never selected to be a ‘Red Leader’ as that is not required for VPN clients.
Well Connected locations are networks where the bandwidth available to clients is generous and no throttling is required. In this scenario StifleR can still assist with improving Peer-to-Peer and caching efficiencies, which help to offload both network and memory/CPU load from source servers (Distribution Points etc)
How it Works:
A Red Leader will still be selected, but the bandwidth allocated to 'Non-Red Leaders' is exactly the same. This allows for faster P2P transfers and faster deployments in general.
The Default Setting is False - (Not Well Connected)
Note: You can change a subnet to Well Connected and the clients at that location will receive the new Well-Connected bandwidth settings from the server at the next client check-in. If you change back to Not Well Connected, the clients will revert to the original Subnet Target Bandwidth.
The Client will set:
- WellConnectedBITSBandwidth (for BITS) and WellConnectedDOBandwidth (for Windows 10 Delivery Optimization)
The client will initially set the Server DefaultNonRedLeader values. A Red Leader is then selected and configured with the TargetBandwidth setting for that subnet.
Red /Blue Leaders on Roaming networks are not assigned
Red /Blue Leaders on VPN networks are not assigned
On well connected subnets Red and Blue Leaders are still set but as local policy may be very high this is more to keep the role for other actions such as WOL etc.