Bandwidth Tuning Monitoring and Control
NOTE: It is worth noting that while High and Low Bandwidth tuning is presently a major part of network optimisation it is being complemented more and more by LEDBAT technology. We are getting closer to LEDBAT becoming a main part of the solution for Enterprise bandwidth control and you should refer to the 2Pint Website various support and community resources for the latest in this regard. It is an important part of the Microsoft roadmap and is well worth a bit of research.
This section explains the configuration options available for Bandwidth monitoring and how the limits set are then used to adjust parameters for maximum download performance. With each of these detection methods, when an override happens, a warning will be written to the Event Log.
Bandwidth Tuning is turned on and overall site settings configured on the Server through the StifelR.Service.exe.config file. This file also contains the parameters that govern the various site wide settings that control the monitoring intervals and the tuning adjustment values. Please refer to the StifleR Server Settings Knowledge Base article for a full explanation of the settings available in this file.
StifleR can manage the bandwidth usage based on throughput, either too little or too much being used and adjust settings accordingly.
These are enabled on a Location (WMI) by setting the BandwidthTuning property, which sets what is to be monitored, the Latency Threshold value which sets when Tuning should be used and the TargetBandwidth value which is the sweet spot for the link.
The following BandwidthTuning options are available:
Latency
LowBandwidth
HighBandwidth
LEDBAT
MeasureBandwidth
StifleR can monitor and adjust a number of bandwidth related metrics. The bandwidth management system uses a bit flag system so multiple detectors can be used at the same time. i.e. a value of BandwidthTuning that equals 5 enables 1 and 4 but disables item 2 (see below). The server has flags defined it the actual code of the product as follows:
Therefore the value of 7 in the Server StifleRService.exe.config file:
<add key="BandwidthTuning" value="7" />
Enables the following tuning capabilities on the server (site wide): Latency (1) + LowBandwidth (2) + HighBandwidth (4) = 1+ 2+ 4 = 7.
If you wanted to only use Latency and HighBandwidth monitoring for the site you would set 1+4 = 5.
The same values are used to enable these settings per subnet and are set on the subnets object.
Latency Detection (BandwidthTuning = 1)
This configuration determines latency to the target server using a simple ICMP Ping. The round trip time is recorded and stored which can then be used to calculate the average latency for ongoing comparison.
To use the feature it must be enabled on the Server in the StifleRService.exe.config file (On by default) and then set the Bandwidth tuning Detection flag and LatencyThreshold value for each Subnet that you want to control.
Low Bandwidth Usage Detection (BandwidthTuning = 2)
This detects if the bandwidth being used is lower than a set value
To use the feature it must be enabled on the Server in the StifleRService.exe.config file (On by default) and then set the Bandwidth tuning Detection flag and LowBandwidthThreshold value for a Location that you want to control.
If this occurs without the latency detection being triggered, it’s most likely a configuration issue, server throttling or other QoS policy in place that artificially limits the allowed bandwidth.
BITS has a tendency to be overly cautious on how much bandwidth can be consumed. Please note that it is recommended that this feature be fully tested before use in production as it can consume excess bandwidth unless tightly monitored and controlled.
High Bandwidth Usage Detection (BandwidthTuning = 4)
This feature allows you to detect if the bandwidth being used by BITS is greater than the configured values. The reason for this violation would typically be due to a failure in assigning the desired BITS policy, or an issue with the BITS policy on its own. This may happen for a number of reasons.
Conflicting GPO settings e.g. Active Directory/Policy differences
Invalid security settings (StifleR client not running as Admin or System)
BITS policy corruption
BITS bugs due to inconsistent hotfixes
To use the feature it must be enabled on the server in the StifleRService.exe.config file (On by default) and then set the Bandwidth tuning Detection flag and HighBandwidthThreshold value for the Locations at which you want to use the feature.
LEDBAT (BandwidthTuning=8)
Low Extra Delay Background Transport (LEDBaT) is a way to transfer data in the background quickly, and without clogging the network. In order to control LEDBAT settings through StifleR you need to set this flag on the server and then make the configuration changes covered in the next section.
StifleR LEDBAT Configuration
StifleR lets you set a higher/different TargetBandwidth policy when LEDBAT is in play. LEDBAT itself ensures that only available bandwidth is used and if other traffic comes along BITS will automatically back off. True auto-throttling in action!
Setting up LEDBAT++ with Content Distribution
Enable LEDBAT++ on the content server that will be serving the BITS content (SCCM Distribution Point for example)
Set up the LEDBATTargetBandwidth (WMI) for a location/subnet in StifleR (This can be set in the Location Details dashboard or via WMI/PowerShell)
swmi -path 'root\Stifler:Subnets.subnetID="192.168.4.0"' -Arguments @{LEDBATTargetBandwidth = 20480}Set an IIS custom header to “LEDBAT:true” on the LEDBAT enabled Content Server. (see How to add a custom HTTP response header to a Web site that is hosted by IIS ) The custom header is picked up by StifleR on the client
If LEDBAT is detected on the client, then StifleR will use LEDBATTargetBandwidth value for that location that has been set on the Server
The higher LEDBATTargetBandwidth value is then set as that job has the LEDBAT: true header
If a different (non-LEDBAT aware) job starts, then StifleR will set the regular TargetBandwidth for the location
LEDBAT then takes care of the Throttling, and BITS runs at MAX of LEDBATTargetBandwidth
Bandwidth Measurement – Beacon Server (BandwidthTuning=16)
With this bit set it is possible to specify a Percentage of Maximum Bandwidth for a location/subnet as opposed to a hard limit (Target Bandwidth). It is important to note that this is a percentage of the Maximum measured download Bandwidth for that location. This value is automatically calculated by the StifleR client agent or may be set manually if required. (MaxBandwidthDownstream)
Once this value is set, a second value, PercentOfMaxDownstream is used to set limits for the Red Leader of that subnet/location.
How is it calculated?
The best (and most accurate) way of working out the bandwidth between two points is to send some content up to a location and record how long it takes. This involves some fancy footwork on the client-side which communicates with the StifleR Beacon Server component. In order to achieve this measurement we use the Open Source iperf tool - https://iperf.fr/ - which is ideally suited for this measurement.
Beacon Server Component
The server-side component (iperf3.exe) can run on any (modern) Windows OS (talk to us if you want to run it on Linux) It acts as the end point to which the StifleR Client Red Leaders send test packets. This allows the Red Leaders to determine the maximum bandwidth available between the a Subnet/Location and the content source. Typically, you will install this component on a server in a central location (such as an SCCM Distribution Point) from which your clients obtain the bulk of their content. If you have a central data center for instance you can simply install the StifleR Beacon service onto any server at that location. The StifleR Beacon Service may be installed on the StifleR Server if required but there is no dependency on this configuration.
Client Component
The client initiates the transfer of known chunks of content up to the StifleR Beacon Server and back again. This enables StifleR to build up an accurate picture of the maximum bandwidth (both up and down) that is available at that location. That data is then stored with the subnet information on the server.
This function only runs on the Red Leader at a location
It is run at service startup on the first Red Leader at a new location
It is then run periodically to test and update the setting at various times on a schedule (every six days subject to some other conditions)
Only increases in bandwidth are reported as it’s the Maximum Download Bandwidth that needs to be determined. i.e if the first client at a location measures that bandwidth to be 5Mbit then that will be set as the Maximum Download Bandwidth. If the client then runs a new test and determines that the bandwidth available is now 10Mbit then the Maximum Download Bandwidth will be increased to that value. If a third test is performed at that location and returns a bandwidth of only 8Mbit (the network may be busy for instance), nothing will change.
Once the Maximum Download Bandwidth is determined and set for that subnet, the second property comes into play – namely the PercentOfMaxDownstream parameter. For example, if the Maximum Download Bandwidth is calculated to be 10Mbs and the PercentOfMaxDownstream parameter is set at 50%, then the Target Bandwidth for that subnet is adjusted to 5Mbs.
Beacon Server Setup and Configuration
Client
The client needs to be configured with the Beacon Server address and and optional custom port number (port number only needed when using a different port than default). The Beacon Server Address is simply the FQDN or IP Address of the Beacon server to which the StifleR Client will connect.
The client gets the beacon server configuration from it's subnet, and this is set per subnet using the BeaconAddress parameter in WMI. The beacon address can be hostname:port or just hostname, in which case the default port of 5201 is used. The beacon address can be set via WMIC or PowerShell on the subnet(s).
Configure the Beacon Server for a single subnet using WMIC:
Configure the Beacon Server for a single subnet using PowerShell:
Configure the Beacon Server for all subnets using PowerShell:
Forcing a Beacon measurement
For testing purposes you can use the UpdateMaxBandwidth WMI method to force a client to update the MaxBandwidthDownStream property, which in will turn update the target bandwidth for that subnet.
Forcing an update using WMIC:
Forcing an update using PowerShell:
Server Configuration
The fifth bit must be set (16 (Decimal) = EstimateMaxBandwidth) in the StifleR.Service.exe.config file on the server. If you are already using other Bandwidth Tuning methods (and you wish to keep using them) then you must add this value to the existing setting.
<add key="BandwidthTuning" value="16"/>
Set using WMIC for a single subnet:
Or PowerShell (this example sets the BandwidthTuning bitflag for all locations)
Logging
In order to enable Beacon Server Service logging set the following key to a value of “1” in the StifleR.Service.Beacon.exe.config file:
<add key="EnableDebugLog" value="1" />
The Service Logs are written by default to “%PROGRAMDATA%\2Pint Software\StifleR\BeaconLogs”
The iPerf executable logs to the “%PROGRAMDATA%\2Pint Software\StifleR” folder.
NOTES:
Does not run at ‘Well Connected’ locations
Does not run at VPN locations
Does not run on Roaming Clients
Latency Auto-Tuning Management (No Beacon Server)
StifleR can be configured to auto adjust the download speed depending on latency from the Client to the StifleR server OR the download source. If the source is Internal (i.e. on a private network) the source will be used for latency calculations. If the source is External, i.e. the Internet, the StifleR server will be used for Latency calculations.
Sample WMI Commands to Enable Auto Latency Tuning
The following WMI Command will set the TargetBandwidth to 700 Kbit/s, enable the Latency monitoring flag in BandwidthTuning and set the latency threshold to 70 milliseconds for the subnet 192.168.138.0.
The above commands will achieve the following;
Set a TargetBandwidth of 700
Typically, all subnets have a TargetBandwidth value set as this is how StifleR knows how much bandwidth each Subnet or Location is allowed to use
Enable the first option of bandwidth management
The BandwidthTuning is a bit flag. Setting it to 1 enables the first option, Latency. Setting it to 3 would enable the first (1) and the second (2) options etc. Setting the first and third options would be done by setting the value to 5 (1 + 4). Note, this doesn’t actually turn on the tuning itself, as we need a value to tune against first
The last action is to set the value to tune against
In this case it is set to 70msec. If the latency to this Location exceeds 70msec StifleR will lower the bandwidth or if it drops below this threshold then StifleR will try to increase usage
Bandwidth Tuning Adjustment options
The information above is mainly related to how to actually turn on the various Bandwidth Tuning options and set the target counters to maximize network performance. The StifleRService.exe.config file also contains a number of configuration options to control how aggressively the tuning is controlled and changes to bandwidth usage applied.
There is a full list of the options with notes available on the 2Pint Support Knowledge Base - StifleR Server Settings – but for this section we shall discuss one example – Latency.
Therefore, if the Tuned Bandwidth is 500 Kbit/s and the target Bandwidth is 2000 Kbit/s StifleR would increase the Bandwidth by 2000 / 5 = 400, so the new TunedBandwidth figure would be 900Kbit/s with a new increase each 10sec by default
Latency will be measured and adjustment made every 10 second period by default. Should the Latency fall below or above the target level set for the Location, Bandwidth usage will be adjusted up or down according to the Increase/Decrease factors in order to bring things back into tolerance.
WMI Events on Thresholds
StifleR Creates events in WMI for the following items:
Latency Threshold Exceeded
Latency Threshold Resumed
High Bandwidth Threshold Exceeded
Low Bandwidth Threshold Exceeded
Last updated