XcelleNet_Dynamic Bandwidth Throttling White Paper_Final

7/28/2019 XcelleNet_Dynamic Bandwidth Throttling White Paper_Final

1/11

Dynamic Bandwidth Throttling

A Technical White Paper

Chris FoleySenior Technical Product Manager

XcelleNet, Inc.


2/11

Background

The concept of bandwidth throttling is not new. For over a decade, network infrastructure

hardware and software vendors have offered a variety of products to allow Local AreaNetwork (LAN) and Wide Area Network (WAN) administrators to control and manage thetraffic traversing their networks. Such products have traditionally been implemented as partof the overall network infrastructure. These products usually operate at Layer 3 or Layer 4 ofthe ISO protocol stack. Either incorporated into the feature set ofrouters and switches, oras stand-alone devices or servers, these products have a scope/jurisdiction of the networksegments with which they share interfaces.

Being implemented at such a low level, these devices have limited capabilities when it comesto shaping the network traffic passing through them. A router or switch which allows traffictraveling on a specific port to be restricted to a specified percentage of the aggregatethroughput of the device is an example of this type of limitation. In situations where only asingle traffic class is routed over a specific port, or to a specific subnet, these products

provide adequate distribution of available bandwidth to the respective traffic types or hosts.

Traditional Bandwidth Throttling and Traffic/Packet Shaping

As network traffic patterns evolved, it became clear that a simplistic port-by-port or subnet-by-subnet approach was not sufficient. Many applications began to share the same ports andprotocols; HTTP and Port 80 are classic examples. Additionally, as users became moremobile and roving laptop computers started to displace anchored desktop machines, theability to mediate bandwidth demands by subnet became problematic in many environments.The need developed for a more intelligent means of identifying and throttling specific traffictypes, classes, and hosts.

These products, known today as Traffic or Packet Shapers, were introduced to meet thesechallenges. Traffic Shapers have the ability to better identify application-specific traffic byreading data higher up the protocol stack from within packet headers, and looking for tell-taleapplication signatures. Armed with this additional data, packet shapers provide WAN/LANadministrators with the ability to control the precise bandwidth percentage used by eachrespective application.

This top-down view method of bandwidth control is often accomplished by brute-forcemethods such as packet discardment. For example, if application A is generating 15% morepacket traffic than it has been allocated, an arbitrary number of its packets are dropped ordiscarded by the packet shaper. This produces the desired effect ofthrottlingthe application

back to target levels, but it does not inhibit the source applications from continuing to

generate excessive traffic. In fact, discarding packets usually results in elevated levels ofapplication traffic generation, as negative acknowledgements (NACKS) from remote hoststhat frequently generate re-transmissions.

Another limitation of the top-down packet shaping approach is that even under the best ofcircumstances, the balancing of network traffic only takes the server-host environment intoconsideration. The experience and performance of remote hosts (and users) is by definitionconsidered to have a lesser priority. The LAN/WAN administrator achieves his or her desiredresult, but at what cost to the end user?

Software-Specific Approaches and Static Bandwidth Throttling

In response to such network-level approaches, several software vendors have attempted toallow their applications to either play nicely in hardware-throttled environments, or to


3/11

independently control their traffic demands by providing throttlingmechanisms. These

mechanisms vary in terms of point/location of application, and the methods used. Typically,client applications, such as Web browsers, are at the whim of server throttling settings and fallin line accordingly. Client-server applications, on the other hand, usually allow throttlingsettings to be configured on the client, on the server, or on both.

As mentioned above, there are several methods of throttling employed by differing types ofsoftware applications. For the purpose of this discussion, our focus will be confinedexclusively to throttling methods used by client-server applications. Because of their dualoperating environments, client-server applications are uniquely qualified to overcome thelimitations imposed by top-down, server-side only approaches. Despite these inherentadvantages, many client-server applications base their throttling methods on arbitrary rulesand data. The vast majority of applications that incorporate such an approach can begenerally categorized as using a Static Bandwidth Throttlingmodel.

Static Bandwidth Throttling(SBWT) is similar conceptually to the hardware-based packet-shaping approach in that it targets a specific level of packet activity as its desired result. Atypical SBWT implementation would involve either a client-side or server-side setting thatgates the amount of packet traffic generated or accepted at pre-configured (static) levels.

Often these static levels are defined in terms of a percentage of available bandwidth (size ofthe pipe). In most cases, however, the pipe itself must be statically configured or declared. In

other words, there is no real-time discovery of available bandwidth, and consequently, noreaction based on availability.

Static Bandwidth Throttling does take into account the remote host (end user) experience to

the extent that it can be configured to stay within acceptable boundaries relative to otheranticipated traffic types on the host. The theoretical best case for this type of bandwidthsharing would be a scenario where each client-side application had a similar facility for gatingbandwidth, and the sum total of all applications would be 100% of the pre-determined pipesize (theoretical maximum throughput of the network interface). For example, a remotenotebook computer equipped with a 56 kbps modem would be configured to allot 50% (28k)to an e-mail application, 25% (14k) to Sales Force Automation application, and 25% (14k) to a

systems management application.

There are many flaws inherent in the SBWT model: (a) The theoretical maximum throughput(56k in this case) is rarely, if ever, achieved; (b) Application usage is frequently sporadic, andalmost never involves concurrent usage of all production applications; (c) Many remote andmobile computing devices are equipped with multiple network interfaces, such as 56kmodems, 10/100 Mb LAN and/or 11Mb WLAN network interfaces (not to mention the growingnumber of WAN wireless interfaces). Depending on which interface is in use, staticallyconfigured throttling parameters may or may not be appropriate; (d) Available bandwidth oftenfluctuates throughout the course of a communication session, once again rendering staticconfiguration settings inappropriate.

Another Static Software Throttling Approach Choice of Static Parameters

In an attempt to provide some flexibility in their approach, some software vendors provide achoice of multiple throttling levels. High, medium, and lowsettings are configurable on theclient, the server, or on both. While this scheme represents an improvement over the one-size-fits-all SBWT approach, it is still arbitrary in terms of when a given level is applied. Acommon implementation of this method would be to assign a high priority level (no or minimalthrottling) to important work, while assigning a lowpriority level (10% or less of the pipe) tonon-time-critical tasks. This model still suffers from most of the traditional SBWT flaws in thatit still gates throughput at static levels, regardless of the connection type/quality/speed, or theamount concurrent application traffic present at communication time.


4/11

The net effect ofanystatically configured ceiling is to lengthen the execution time of the

throttled application, while also preventing concurrent applications from achieving maximumthroughput. As shown in Figure 1.1 below, SBWT models are also incapable of recoveringunused bandwidth. This unused bandwidth is frequently the product of the ebbs and flows ofmost typical production applications, such as e-mail synchronization, databasesynchronization, Web browsing, and FTP downloads spawned from Web pages .

Figure 1.1 Static Bandwidth Throttling Behavior

Clearly, in order to take advantage of these periods of relative inactivity, a bandwidth-throttlingscheme must incorporate some form of activity level monitoring. Unlike traffic shapingappliances and servers, which are able to monitor network interfaces directly, mostapplication-level client-side applications do not have access to throughput and capacity levelsof these interfaces. In many cases, special monitoring agents must be resident to gain client-side access to such data, while the interfaces themselves must be configured to apromiscuous state. The additional CPU and monitoring overhead required to supplyconnection and interface data to production applications, such as e-mail, management, anddata synchronization is considered to be an undesirable by most enterprise administrators.

This type of diagnostic activity is usually reserved for isolated troubleshooting scenarios,where monitoring agents andpacket sniffers are typically employed.

Given these constraints, how can a production-class application address the need forintelligent bandwidth control? The answer to this, and many other related questions, is calledDynamic Bandwidth Throttling. XcelleNet, a mobile infrastructure provider, has developedits own patent-pending mechanism that detects and utilizes lulls in bandwidth, while alsoallowing high-priority applications and tasks to maximize their bandwidth usage as required.


5/11

Dynamic Bandwidth Throttling - An intelligent Software Throttling Approach

XcelleNet has developed a unique approach to solving the problems associated with thevariable and concurrent bandwidth demands of production-class enterprise applications.Dynamic Bandwidth Throttling (DBWT), introduced in itsXcelleNets Afaria product line in

February 2002, allows administrators to allocate bandwidth on a per-user, per-connection

basis. Attributes such as quality/speedof connection,priorityof current task, time/costofconnection, andpresence/absence of other applications are all taken into account indetermining when and how much bandwidth is consumed by XcelleNets Afariamanagement/data movement activities.

The patent-pending algorithm used in XcelleNets DBWT leverages several platform

attributes, which have been key XcelleNets Afaria differentiators since its initial launch in1998. Features such as checkpoint restart, byte-level differencing, data compression and filesegmentation have enabled XcelleNets Afaria to move data and perform management tasksefficiently over a myriad of connection types to wide array of remote and mobile devices.These efficiencies and tolerances form the foundation on which DBWTis built. With its real-time client and server state discovery capabilities, XcelleNets Afarias business rules engine,Session Manager, allows administrators to apply the appropriate bandwidth policies on the fly.

How Does XcelleNets Dynamic Bandwidth Throttling Work?

In order to achieve such flexibility and efficiency without introducing undesirable overhead intoits proven communications architecture, XcelleNet uses a pressure-sensing mechanism thatrelies on many existing components. XcelleNets Afarias Check SpeedEvent andConnection Speedvariable have long been accessible to administrators as a means ofvarying task execution and priority based on the current speed (or throughput) of aconnection. DBWT utilizes this measurement as its Current Throughputparameter in itsmonitoring and throttling calculations. Additionally, a running average,Average Throughput,

is maintained throughout each XcelleNets Afaria session. Armed with these two pieces ofdata, XcelleNets Afaria is able to sense pressure from outside applications by measuring thesustained Variance between these two measurements. As shown in Figure 1.2 below, asustained drop-off of in the Current Throughputrelative to theAverage Throughputis anindication that an outside application or process is exerting pressure on XcelleNets Afaria.

Figure 1.2 Dynamic Bandwidth Throttling: Sensing and Throttle-down Behavior


6/11

Also depicted in Figure 1.2 is the Wait Time value (in seconds), which determines theduration that the variance must be sustained in order trigger a Throttle-down reaction. Whenthe target Variance is initially achieved, XcelleNets Afaria sessions are in a Pendingstatusuntil either (a) the Wait Time is reached and the Variance sustained (Throttle-down condition);or (b) the Variance is not sustained through the Wait Time (resume monitoring condition).

Additionally, the Throttle-down Percentage is shown. This attributedeterminesthe magnitude

of throttle-down behavior. In the example shown, a variance of 20% is sustained for seven(7) seconds. This results in a Throttle-down condition, where a 90% reduction in XcelleNets

Afaria throughput results. The Variance, Wait Time, and the Throttle-down Percentage are alladministratively configurable, as shown below in Figure 1.3. The remaining DBWTadministrative settings and monitoring tools are discussed in the Dynamic BandwidthThrottling Calibration and Monitoring Tools section of this document.

Figure 1.3 Dynamic Bandwidth Throttling Server Properties Interface


7/11

Once a Throttle-down action has taken place, XcelleNets Afaria immediately returns to a

monitoring mode. This is the default mode under normal conditions where, over time,XcelleNets Afaria would eventually drift back to higher throughput levels and eventually fillthe pipe (in the absence of outside pressure). However, following a Throttle-down condition,

XcelleNets Afaria attempts to accelerate its return to pre-throttle-down throughput levels. Itdoes so by testing the waters at three stair-step intervals, which are approximately 10

seconds apart. If throttle-down conditions are once again attained at any of these plateaus,throughput will immediately be throttled-down and the whole cycle will be repeated. Thiscontrolled recovery behavior works in a similar fashion to the TCP/IP slow startalgorithm, andenables XcelleNets Afaria to take advantage of voids in network traffic. The new state ofequilibrium (maximum efficiency) is achieved much faster than if left to natural network drift.This recovery behavior is demonstrated below in Figure 1.4.

Figure 1.4 Dynamic Bandwidth Throttling: Recovery Monitoring and Acceleration Behavior

Tangible Benefits of Dynamic Bandwidth Throttling

By providing a dynamic means of both reducing throughput at times of high contention andaggressively detecting and leveraging lulls in activity, XcelleNets Afaria is able to reducecommunication costs while also reducing end-user pain. LAN and WAN administrators willimmediately recognize the efficiency gain realized by the application of Dynamic BandwidthThrottling, as average connection times will be reduced. In organizations where the length ofconnections corresponds to the cost of the connections, the evidence will be show up in theirISP, Telco, and Wireless Carrier invoices. The indirect end-user benefits will show up in aseveral areas that are not as apparent, yet are just as valuable. By reducing the amount oftime that a user spends on-line the organization gains a productivity dividend by allowing theuser to get back to what he or she is paid to do. Quicker, more-efficient connections alsoresult in greater employee satisfaction levels and fewer Help desk calls. Enterpriseemployees frequently list waiting for the organizational stuff to happen as one of their chiefcomplaints. After all, its the e-mail, the Web browsing or the sales report that prompted themto initiate the connection, not that management stuff.


8/11

Figure 1.5below graphically demonstrates the net savings and pain reductionrealized with XcelleNets DBWT. In this depiction, the same amount of work isaccomplished in significantly less time due to the inherent efficiencies.

Figure 1.5 Time, Cost, Productivity, and Support Savings Realizedwith Dynamic Bandwidth Throttling

How Does Dynamic Bandwidth Throttling Deal with Differing Connection Typesand Speeds and Performance Levels?

While XcelleNets DBWT implementation includes the ability to accelerate and deceleratethroughput within a given communication session, the ability to adapt to the type, speed andconnection quality of a session is also required. The default throttling settings configured byan administrator may not be appropriate for users connecting over a variety of methodsranging from 9.6 kbps wireless WAN links through 100 Mbps LAN connections. To addressthese requirements, XcelleNets Afaria provides several pre-defined sets of throttlingparameters appropriate for the most common connection types found in enterpriseenvironments. These canned settings can be supplemented with an unlimited number of

custom settings. Using the real-time-state awareness of XcelleNets Afarias SessionManager (is Session Manager trade-marked?), administrators can then create rules to selectthe appropriate setting on the fly. This capability also supports the ability to change throttlingsettings multiple times within a single session. By sliding different settings in and out within asession, administrators are able to prioritize critical work, such as delivery of anti-virusupdates, while also having the ability to react to fluctuations in connection quality/speed.

The Configurations group box shown below in Figure 1.6 provides a drop-down controllisting all pre-defined and custom throttling configuration sets. From this interface,administrators can create new sets, as well as designate the default set.


9/11

Figure 1.6 Bandwidth Configurations Administrative User Interface

Once Dynamic Bandwidth Throttling parameters are set within the administrative userinterface, configuration sets are then applied to XcelleNets Afaria Sessions by means of aSession Manager Event named Set Bandwidth Throttling Config. This event is usually usedin conjunction with procedural logic utilizing system-defined XcelleNets Afaria sessionvariables such as ConnectionSpeed. Figure 1.7(below) depicts a typical scenario where thethroughput of the current connection determines which of several possible throttling profiles isto be applied.

Figure 1.7 Usage Example ofSet Bandwidth Throttling Config Session Event

Dynamic Bandwidth Throttling Calibration and Monitoring Tools

In order to apply throttling configuration sets to actual client environments, the right mix ofsettings choices must be available. While the pre-built sets provide an excellent startingpoint, there is no substitute for testing in the production environment. XcelleNet providesseveral tools to help administrators define, fine tune and monitor their bandwidth throttlingconfigurations. These tools include a set of bandwidth-relatedAlerts Console Events, aCalibration Mode, and real-time Session Monitoring Statistics.


10/11

Two profile-specific settings, Maximum and MinimumThroughput (see Diagram 1.8 below),support auditing capabilities that are enabled through the use of the bandwidth throttlingAlerts Console Events. On the surface, these two profile settings are meant to establish theceiling and floor between which a given set of throttling parameters operates. Unless theintent is to combine the predictability ofSBWT with the reactive behavior ofDBWT within atarget range, the value of these settings lies primarily in their ability to test throughput

boundaries. Once set at preferred or acceptable recorded levels for each communicationtype/method, aberrations in performance can then be audited through the XcelleNets Afaria

Alerts Console by definingAlarms that are triggered when a designated number of dropsbelow the floor or collisions with the ceiling occur. Another bandwidth-related AlertsConsole Event flags Throttle-down instances, which can be aggregated across a specifiedtime period for the purpose of alerting administrators when expected thresholds areexceeded. Checking the Enable Event Logging checkbox as shown in Diagram 1.8 belowenables all bandwidth-related Alerts Console Events.

Figure 1.8 Bandwidth Throttling Calibration, Monitoring, and Range Configuration Settings

Also shown inDiagram 1.8 (above)is Enable Calibration checkbox. When this box ischecked/enabled, two separate calibration facilities are activated. Firstly, entering CalibrationMode enables administrators to manually or programmatically alter the values contained incustom bandwidth throttling configuration sets without the need to stop and restarttheXcelleNets Afaria service. The second behavior that is activated in Calibration Mode is thegeneration of an XcelleNets Afaria Messages Log entry for each client connection, whichcontains detailed summary information regarding each sessions throttling activity. The

summary information includes the number of times a Throttle-down occurred, the number oftimes a Pendingstate was reached, and the Throughputof the session.


11/11

By combining theses two Calibration Mode features, administrators can interactively fine tunecustom profile settings while monitoring the results in the Messages Log. This is thefunctional equivalent to turning the squelch knob on a Citizens Band (CB) radio until allstatic noise is suppressed. In other words, administrators can keep tuning their settings untilthey reach a state where no throttling occurs in the absence of other competing traffic orprocesses. These settings should provide a valid threshold where any additional contention

should force a Pendingcondition.

Another monitoring mechanism that provides administrators with real-time feedback regardingDBWT performance is the Session Status utility. Session Status provides a live view of everyXcelleNets Afaria Session occurring on a given server. In addition to the basic connectionsummary information, such as User, Machine Name, Address, Status, Channel andPercentage Complete, this utility provides bandwidth-specific attributes such as ThrottlingState, Current Throughput, Average Throughput, Target Throughput, and Threshold.As with

all Session Status attributes, a detailed, Event-by-Event view of the live client connection canbe viewed by double-clicking on any selected summary line.

Summarizing the Benefits of XcelleNets Dynamic Bandwidth Throttling

By combining the ability to dynamically react to throughput conditions, dynamically changethrottling schemes, and dynamically configure and monitor these schemes, XcelleNetspatent-pending Dynamic Bandwidth Throttlingimplementation provides organizations with apowerful means to reduce costs and minimize end user pain normally associated withmulti-purpose connections. Coupled with XcelleNets industry-leading support for enterpriseusers communicating over slow, intermittent, and unreliable connections, Dynamic BandwidthThrottlingtakes the control and management of remote and mobile users and devices tounparalleled levels of efficiency and cost reduction.

Documents

XcelleNet_Dynamic Bandwidth Throttling White Paper_Final