Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
  • G06F9/5083—Techniques for rebalancing the load in a distributed system
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/11—Identifying congestion
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/29—Flow control; Congestion control using a combination of thresholds
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2209/00—Indexing scheme relating to G06F9/00
  • G06F2209/50—Indexing scheme relating to G06F9/50
  • G06F2209/5019—Workload prediction
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2209/00—Indexing scheme relating to G06F9/00
  • G06F2209/50—Indexing scheme relating to G06F9/50
  • G06F2209/5022—Workload threshold

Definitions

• the present invention relates to telecommunication networks, and more particularly to systems and methods for controlling network server message flow to prevent server overload.
• SCPs Service Control Points
• SCPs Service Control Points
• SCPs will soon support a range of intelligent network services, such as voice activated dialing, local number portability, calling name delivery and other screening features, automated telephone polling, and personal communications services.
• SCPs An analogue of the SCP for video dial tone services is a Level 1 Gateway.
• a Level 1 Gateway screens video session requests and instructs other network elements to set up connections.
• Level 1 Gateways also handle multiple transaction types, e.g., session requests for interactive TV and for pay-per-view events.
• Service demand volatility threatens the integrity of the services that such network servers provide.
• ordinary traffic engineering may not keep pace with the growth and fluctuations in load placed on network servers.
• the servers may experience occasional or even frequent overloads. Overload controls must therefore complement engineering practices.
• Prior art controllers implement a trial and error search to establish proper control values relating measurements taken by the controller to server workload capacity. Examples of such measurements include the number of messages that flow into the server, the number of messages that encounter excessive response times, and processor utilization.
• the prior art search algorithms suffer from two major limitations. First, the search algorithms update control parameters on a much longer time scale than arriving transactions (seconds vs.
• a server When a server determines that it is in overload, it must instruct traffic sources to reduce the number of new transactions to the server.
• a source is a logical grouping of transactions; one source is the smallest stream of translations subject to a single overload control request.
• Present controllers in SCPs tightly couple the way servers specify the amount of traffic reduction to a technique for reducing traffic.
• SCPs block incoming calls with Automatic Code Gapping ("ACG"), illustrated in Fig. 1.
• ACG Automatic Code Gapping
• the source blocks all new transactions 1 that occur during a gap interval 3. When the gap interval has finished, the next incoming new transaction, 5, 6, or 7, will be accepted. Immediately following the acceptance of the new transaction, the next gap interval begins.
• an ACG request to a source tells it to initiate at most one new transaction per "g" seconds, where g is the gap interval.
• Conventional gapping techniques store predetermined tables of gap intervals at the sources.
• the server transmits to the source an "overload level,” an index into the table. The source then applies the gap corresponding to the overload level.
• a limitation of this type of controller is that the fixed list of values may not contain the proper control values necessary to remedy a given server overload condition.
• a controller that is restricted to selecting a control value from a fixed list exhibits characteristic oscillations in transaction throughput as the server alternately selects overload levels that are too large and too small. The larger the mismatch between the values on the fixed list and the values actually needed to control the overload, the larger the swings in throughput.
• the frequency of the oscillations is governed by the length of the measurement interval, since the controller picks a new value from the list once per interval.
• network server overload controllers should reduce the load incoming to the server to the maximum level it can comfortably handle.
• a controller should also block demands for individual services provided by the network server.
• the present invention overcomes the limitations of conventional techniques by implementing a method for preventing overload of a network server by messages received from a source initiating a network server transaction.
• the method includes the steps, executed by a processor, of establishing a target incoming transaction workload per measurement interval, estimating from measurements obtained during the measurement interval the transaction workload offered by a source, and reducing a rate at which new transactions are initiated by the source to match the incoming transaction workload to the target workload when the offered transaction workload exceeds a threshold.
• the invention also comprises an apparatus for preventing overload of a network server by messages received from a source initiating a network server transaction.
• the apparatus includes structure for establishing a target incoming transaction workload per measurement interval, structure for estimating from measurements obtained during the measurement interval an incoming transaction workload offered by a source, and structure for reducing a rate at which new transactions are initiated by the source to match the target incoming transaction workload when the offered transaction workload exceeds a threshold.
• Fig. 1 is a diagram of transaction and gap intervals
• Fig. 2 is a block diagram of a video dial tone network
• Fig. 3 is a block diagram of a network application using a service control point
• Fig. 4 is a block diagram of an apparatus for preventing network server overload in accordance with one embodiment of the present invention.
• Fig. 5 is a block diagram of an apparatus for preventing network server overload in accordance with one embodiment of the present invention.
• Fig. 6 is a flow diagram of a method for controlling server overload
• Fig. 7 is a flow diagram of a "search-type" overload control method according to one embodiment of the present invention.
• Fig. 8 is a flow diagram of a "drop-type" overload control method according to one embodiment of the present invention.
• Fig. 9 is a flow diagram of a "usage" overload control method according to one embodiment of the present invention.
• Fig. 10 is a flow diagram of a "fair share" overload control method according to one embodiment of the present invention
• Fig. 1 1 is a flow diagram of an overload control method for reducing operating system conflicts according to one embodiment of the present invention.
• BEST MODE FOR CARRYING OUT THE INVENTION The present invention can be implemented in a variety of telecommunication networks including, for example, video dial-tone networks.
• Fig. 2 is a block diagram of such a video dial-tone network.
• a video dial-tone network typically includes a Level 1 gateway 200, video information providers ("VIPs") 202a-c, an ATM network 204, and access system and local distribution facilities 206a-b.
• VIPs video information providers
• Level 1 Gateway 200 plays the role of network server in a video dial tone network.
• the Level 1 Gateway manages network sessions. It determines whether a given video information user 208a-g may connect to video information providers 202a-c or vice- versa. An example of such a session may be a video on demand viewing or a pay-per-view event. If the user is authorized to make the desired connection, then Level 1 Gateway 200 confirms with user 208a and provider 202a that they agree to engage in a session. Level 1 Gateway 200 then issues orders to ATM network 204 to allocate logical paths and bandwidth for the connection.
• Level 1 Gateway 200 At each stage of session setup, Level 1 Gateway 200 records the status of the video service provided by the network and the network connections. Thus, to enable a video session setup, several messages must be communicated between network elements including a set top box, the video information provider, and ATM switches. Through ATM network 204 and access system and local distribution facilities 206a-b, Level 1 Gateway 200 mediates this exchange of messages. If any of the messages involved in session setup fails to reach its destination, the session will not be established.
• An embodiment of the controller of the present invention prevents network servers such as Level 1 gateway 200 from overload caused by messages sent to it for processing video dial-tone network services.
• the controller seeks a target rate for the aggregate transaction stream caused by users initiating video service requests and computes admission factors that specify the fraction of new transactions that sources such as access system and local distribution 206a-b should admit for processing.
• Fig. 3 is a block diagram of an intelligent network.
• the intelligent network of Fig. 3 includes SCPs 300a and 300b (paired for reliability), signaling transfer points ("STPs") 302a and 302b (also paired for reliability), and service switching points ("SSPs") 304a-304n capable of common channel switching.
• the SCPs serve as network servers.
• One common application using SCPs as network servers includes the translation of "800" telephone numbers. For this translation, an SSP 304a-n receives dialed "800" numbers and launches a common channel signaling query to SCP 300a or 300b through STP 302a or 302b. SCP 300a or 300b processes this query, translates the received "800" number, and returns the translated number to the originating SSP.
• Controller 400 includes mass storage 402, main memory 404, central processing unit (CPU) 406, and input/output (I/O) device 408.
• Main memory 404 contains overload control program 410 implementing overload methods for the present invention.
• Main memory 404 also includes computer program code that computes traffic measurements 412 associated with overload control at specified intervals.
• CPU 406 executes the computer program load stored in main memory 404.
• Input/output device 408 handles the controller's access to mass storage 402 and serves as a gateway to network traffic resources.
• controller 500 includes target establisher 502, incoming transaction workload estimator 504, and rate reducer 506. Controller 500 is connected to mass storage 508 in a network server.
• Target establisher 502 measures incoming server messages in each measurement interval and computes a target incoming transaction workload.
• incoming transaction workload estimator 504 estimates an incoming transaction workload offered by a source.
• Rate reducer 506 then reduces the rate at which new transactions are initiated by the source to match the incoming transaction workload when the offered transaction workload exceeds a threshold.
• an overload controller located in a network server or attached to a network server performs several tasks as illustrated by the flow diagram of Fig. 6.
• an overload controller establishes a target incoming workload per measurement interval to be used during overload (step 602).
• the overload controller computes the offered load of sources from measurements of arriving messages (step 604).
• the offered workload is greater than the threshold reducing the new transaction rate from each source to match the incoming workload target (step 606).
• steps 602 and 604 could be reversed.
• the target incoming workload may be determined and fixed ahead of time based on historical network traffic statistics.
• the controller can generate the target dynamically.
• the value for the target incoming workload may be fixed at a level that provides a desired maximum fraction of time for the server to spend on transaction processing (i.e., the server capacity).
• a controller counts messages whose response times exceed a threshold and computes dynamically an appropriate target incoming workload from this count.
• the target incoming workload is expressed in terms of messages per second and represents a workload target when the transaction mix does not vary widely.
• the output of a server overload controller is a computed value ("admission factor") representing the fraction of new transaction requests a source may send to the server during the coming measurement interval.
• the server communicates the admission factor to a source in response to new transactions from the source. It takes some time for the response message to reach the source and for the source to update the admission factor. If the controller allows a source to send the first message of a transaction, it also allows any network node to send subsequent messages corresponding to this transaction.
• a controller controls the number of transactions transmitted to a network server by updating the admission factor at the end of a measurement interval and applying it to sources during the next measurement interval. Before an overload, the admission factor equals one (other values may also be used to detect overload conditions). A controller detects an overload and then modifies the admission factor during later measurement intervals for as long as the overload condition is detected or until the admission factor is less than one.
• a ' denotes the number of messages that arrived at the server in the present interval.
• D denotes the number of dropped messages in the present interval.
• F denotes the number of messages that finished service in the present interval.
• the overload controller is a
• search-type controller i.e., the controller continually seeks to determine the maximum number of messages to admit to the server in a measurement interval.
• This embodiment of the controller illustrated in the flow diagram of Fig. 7, uses a binary feedback scheme that lowers or raises C by a multiplicative factor (selected at step 700) according to whether messages are or are not dropped in an interval.
• the controller updates the admission factor C at the end of every measurement interval.
• the admission factor in the present interval is updated in one of two ways depending on the number of dropped messages D during the present interval. If a server drops messages during the present measurement interval (determined at step 702), then the admission factor for the next measurement interval is computed by multiplying the admission factor for the present interval by a constant b, a number preferably between zero and one (step 704). If no messages were dropped during the present measurement interval, the admission factor for the next interval is the lesser of either the admission factor for the present interval divided by b or one (step 706). The computed admission factor is used to control the rate at which transactions are initiated by sources (step 708). This computation of the admission factor for the next measurement interval is expressed in the following computer program code segment: if ( D > 0) C - C*b else
• Another embodiment of the present invention updates admission factors in one step using dropped messages.
• An embodiment of a drop-type controller follows the steps shown in the flow diagram of Fig. 8. The steps shown in Fig. 8 are executed at the end of each measurement interval.
• the controller discovers a surrogate for the target incoming workload per measurement interval (step 802).
• the surrogate is A ' max , the maximum number of messages the server should receive in a measurement interval.
• a new episode of overload is signaled by the dropping of messages.
• a ' max is initially set to this value.
• the controller updates the admission factor as follows (Step 806). If the server has dropped messages or if the admission factor is less than one, the admission factor is set equal to the lesser of either the admission factor for the present interval multiplied by the ratio of A' max to A ' for the present interval or one. If messages are dropped during the present interval, A ' m ⁇ , for the next interval is the difference between the number of messages that arrived at the server during the present interval and the number of dropped messages during this interval. If there are no dropped messages, but the admission factor is still less than one, A' ⁇ mx remains unchanged.
• the following computer program code segment illustrates these steps: if (D > 0 or C ⁇ 1.0) ⁇ if (D > 0)
• the server can buffer messages. In the interval when the server first drops messages, the difference between incoming and dropped messages can overestimate the correct number to admit, since some of the incoming messages are buffered instead of dropped.
• messages dropped in one interval may have arrived in another. This is a significant factor causing the difference between incoming and dropped messages to underestimate the right number of messages to admit.
• a more subtle limitation in drop controllers is that once the server stops dropping messages, the value of A ' mm stays fixed. Unfortunately, the message capacity of the server may not stay fixed. For example, if the average real time cost per message drops, the old value of ⁇ ' mtt ⁇ may be unnecessarily low.
• An embodiment of the present invention accounting for the server message drop history fixes the problem of poorly chosen values of A' mu by maintaining a history of the value A' max in a circular array having H elements.
• the server overwrites the oldest member of the array with A' - D. If D > 0, the server sets A' m ⁇ f equal to the average of the values in the array. Otherwise, A' max remains unchanged.
• the new admission factor is set exactly as in a drop type controller. Defining A ' max as an average over several measurements when the server drops messages addresses the variability in a single measurement. Drop History Controller With Growth
• server control is based on the number of dropped messages and the potential to increase, or "grow," the target maximum number of messages that arrive for server processing during a time interval.
• this rule takes advantages of random fluctuations in the number of messages arriving to the server to explore whether the server actually can accept more messages per interval than A' B10 ⁇ . In this way, the limit A ' occurs,,, remedy is raised until the server again drops messages, at which time, its growth may be halted.
• the controller monitors server processor utilization instead of dropped messages.
• usage controllers provide an advantage over the drop type controllers because they need not translate the server processing capacity into messages per unit time. This embodiment follows the steps illustrated in the flow diagram of Fig. 9.
• the controller selects T, the target utilization level for transaction processing during overload (step 902). For example, a server operator may not want the transaction-related processor utilization to go above 92%. The operator may also want to build in a safety margin and therefore set T to represent a maximum value less than 0.92, like 0.90.
• the maximum incoming transaction workload per measurement interval is then given by TI, where I is the duration of the measurement interval.
• the usage controller updates the admission factor from the present interval to the next interval as follows. First the controller infers the offered transaction load in the next interval as follows. The average processing time per message in the present interval is p I/F; thus the arriving workload in that interval may be estimated as A' p I/F (step 904).
• the controller computes an updated admission factor according to the following expression (step 908): if ( p > T or C ⁇ 1.0)
• C typically is equal to 1.0, so the test p > T detects an overload. Once admission factors have been applied, the same test typically fails, so the second test C ⁇ 1.0 prevents controls from being removed abruptly and gradually raises C back to 1.0 when the overload subsides.
• the computed admission factor is used by the controller to control the transaction rate (step 910).
• a controller In an environment where a single network server provides multiple services, a controller must not only reduce the load coming to the server to the maximum level it can handle during overloads, the controller must also block excessive demands for services individually. For example, if a sudden increase in the demand for one service overloads the server (a focused overload occurs), the network operator might want to cut back traffic directed to the service causing the overload, but not traffic of other services. On the other hand, in a general overload (the loads of all services increase), the controller could cut back all traffic in proportion to demand. In general, a controller in a multiservice environment must allocate "fair shares" of the server capacity to competing services.
• An embodiment of a fair share controller executes the algorithm below at the end of each measurement interval: if (server is overloaded or control was active in current measurement interval) ⁇ for each service determine fair share [service]; for each service ⁇ if ( demand[service] > fair_share [service] ) accept at most fair_share[servicej ; else accept demand[service];
• the initial if statement both activates and removes controls. Assuming the server is initially not overloaded, it activates overload controls when the server becomes overloaded. Once controls are active, the measurements that detected an overload may (and should, if the control effectively reduces traffic) indicate that the server is no longer overloaded. However, the demand may still be too high. The algorithm continues to estimate demand as long as controls are active. Otherwise, controls might be removed abruptly, resulting in oscillations in and out of overload.
• the array fair_share specifies how much processing capacity the server allocates to each service in the coming measurement interval.
• the fair share is not necessarily the maximum amount of processing the service could consume; if a service's demand is less than the available capacity server processing capacity may be allocated to another service.
• the sum of all the fair shares must be less than the server capacity, as the sum is generally what the services are expected to use.
• Controls that dynamically compute the share of server processing capacity for each service typically require information about all services at once. Revenue-based controls might well have the same property if priorities are not absolute (i.e., do not shut off one service completely before cutting back a higher priority service).
• fair share could involve table lookups if priorities are static or comparisons of measurements under more dynamic allocation algorithms. Since the resource allocated is processing capacity, fair share must ultimately be converted into units of time or processor utilization.
• the quantity demand refers to the workload the sources offer. Since some of this offered load may be blocked at the sources by a controller, the server infers the offered load from internal measurements and prior admission factors.
• Both usage and drop controllers can be modified to produce fair share controllers for servers providing multiple services.
• the notation describing controller operation must be modified as follows:
• a '(.v) denotes the number of messages of service s that arrived at the server in the current interval.
• a ' ⁇ A ' (s) is the number of messages from all services. Omitting an argument from a measurement represents the sum over all services.
• C(s) is the admission factor for service .v (i.e., the admission factor that all sources belonging to service s use) for the current method. 0 ⁇ C (s) ⁇ 1.
• a ' ⁇ mx (s) is the maximum number of messages the server should accept from service s in the coming measurement interval.
• • p(s) denotes the processor utilization due to processing of service s work in the current interval.
• T(s) denotes the target transaction-related utilization level for service s work in the next interval.
• a fair share drop controller uses counts of dropped and arriving messages to detect overload and estimate demand including the history and growth modifications.
• An embodiment of a drop controller method that enforces fair shares for different services provided by the computer's process scheduler includes the steps of the following algorithm: for each s: ⁇ if ( D (s) >0 o ⁇ min C (s) ⁇ 1.0 ) ⁇
• the subscript i indexes measurement intervals, with 0 denoting the current one and higher numbers denoting intervals further in the past.
• the inside "if statement in the algorithm computes the fair share for processes that are dropping messages.
• the else statement raises the share once the service stops overloading the server.
• the min function serves to accept the smaller of the service's demand and the service's fair share.
• a fair share usage controller reduces incoming traffic until the server utilization is at the overall target T.
• a fair share usage controller is designed to reduce traffic from each service in proportion to how much the service's demand exceeds its recent usage. For example, if only one service is causing the overload, then a fair share controller cuts back traffic directed to that one service, without affecting other services.
• An embodiment of a fair share controller follows steps illustrated in the flow diagram of Fig. 10 when there is an overload.
• the controller divides up the target T into "fair shares" for the services on the server in proportion to the loads they offered before the overload (step 1002). Next, it sets the admission factor for each service (step 1004) to reduce the service's workload to the service's fair share (step 1006).
• the fair share or target for service s is defined as follows: if U(s) is an estimate of the utilization of service s prior to the overload and U - ⁇ U(_?), then
• a fair share controller updates the circular arrays of utilization histories for each service. Then it updates the admission factors for each service: if(p>T or mm C(s) ⁇ 1.0)
• a usage type controller keeps processor utilization at a safe, target level while maintaining maximum transaction throughput.
• a fair share usage controller achieves these objectives and it controls an overload by cutting back traffic from the service causing the overload and allowing the server to continue processing nearly all the traffic other services offer.
• Overload Controller Compensating for Server Process Scheduling Another embodiment of the present invention is suited for an environment where the servers offer multiple services whose demand is likely to be volatile, where at any time, demand for one of the services could increase and push the total load beyond what the server can handle. In such an event, the server must decrease the amount of traffic it accepts. A server controller must choose which traffic to accept and which to reject. Server controllers determine how much of the server processing capacity to allocate to competing services when the total demand exceeds the server capacity and limit the incoming demand of those services to their allocations.
• Allocation questions such as these also fall within the domain of the operating system's process scheduler.
• the process scheduler prioritizes competing services because it determines when and for how long each process runs.
• the overload controller also assigns services priorities because it governs how much work of each type gets admitted to the server. Overload controllers designed according to the present embodiment recognize and deal with these overlapping priority assignments.
• Controllers designed according to the present invention compensate for the interaction of server overload controls and process scheduling.
• the UNIX scheduler gives different processes time slices in a round robin fashion.
• a process may use part or all of its time slice, which roughly translates into a guaranteed share of processing capacity per process.
• Other processes may, in effect use the portion of the time slice that a given process does not need, thereby taking more than their guaranteed share of real time.
• a server has a single, multitasking processor; however, the present invention also has application in a multiprocessor environment.
• transaction handling processes and overhead processes There is a one-to-one correspondence between transaction-handling processes and services.
• the overhead process represents all the other tasks the server processor must perform including operating system chores, maintenance, measurements, and the overload control itself.
• Preferred embodiments of the fair share usage controller can be modified to handle interaction with server process scheduling.
• a usage controllei is designed to create fire walls between services when one service's demand suddenly increases while the other services' demands remain roughly constant
• a usage controller allocates server processing capacity to services roughly in proportion to their recent usage levels The intent is to give those services not responsible for the overload as much server processing capacity as they have recently been using and to cut back traffic from the offending service.
• the server control is activated.
• p mM represents the processor utilization due to overhead processes in the current interval , I e p mhd —p -
• a server overload controller that reduces operating systems conflicts includes the steps shown in the flow diagram of Fig. 1 1
• the overload controller estimates the recent processor utilization of each seivice (step 1 102)
• the controller compares the processor utilization valve to a threshold (step 1 104) and tests C(s) to determine if it is less than 1 0 (step 1 106)
• the controller subsequently allocates an amount of processor capacity for overhead processing (step 1 108), computes a fair share processor utilization level for the service using equations introduced below (step 1 110), and replaces the computed admission factor with a newly computed admission factor, computed using the fair share processor utilization level
• H-l be the last H measurements ot service s ⁇ utilization (0 indexes the current interval and the subscripts increase with age), and define
• the fair share T(s) of service s depends on all services through the sum U; it also depends upon overhead processes through (p max -p mhJ ) Consequently, the fair shares of all services are calculated jointly.
• the min function sets the new admission factor to accept all of service s's demand if the demand is forecast to be less than the amount T (s) I of time the processor can devote to service s. Otherwise it sets the admission factor to accept only T (s) I seconds of work from service s which is its fair share.
• Adaptive Gapping The preceding discussion did not specify how sources should implement admission factors because determining and implementing admission factors are separate, independent operations.
• One possible implementation of admission factors is by percent-blocking, in which the source chooses at random a specified fraction of new transactions for admission.
• the table-driven code gapping approach is another method of implementing admission factors.
• the present invention prefereably uses automatic code gapping to admit new transaction requests.
• the gap intervals are adaptively recalculated, based on the admission factor, each time that the SCP tells its source that its congestion level has changed.
• the source In response to a request from a server to reduce the number of new transactions transmitted to the server by the admission factor C, the source measures its input transaction rate, ⁇ , and calculates its new gap interval, g new , as:
• the source measures its input transaction rate, ⁇ , and calculates its new gap interval, using this same expression.
• this adaptive gap technique may alternatively be performed at the server level.
• the main difference between calculating the new gap interval, g new , at the server rather than the source is that the server does not know, and cannot directly measure ⁇ .
• the server infers ⁇ based on the source's output transaction rate, ⁇ out .
• the server measures ⁇ ullI and then estimates ⁇ as:
• the server calculates g new using the same method as the source. Finally, the server transmits the new gap interval to the source.
• the adaptive code gapping algorithm could be used in sources in combination with the admission factor algorithms described above or with any algorithm the server uses to set admission factors.
• a source can send to the server the fraction of transactions specified by the admission factor using any method of blocking transactions the source chooses.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Computer And Data Communications (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (5)

Publications (2)

Family

ID=26690966

Family Applications (1)

Country Status (4)

Families Citing this family (8)

Citations (1)

• 1997
  • 1997-04-11 WO PCT/US1997/006058 patent/WO1997045792A1/en not_active Application Discontinuation
  • 1997-04-11 EP EP97920351A patent/EP0901656A4/de not_active Withdrawn
  • 1997-04-11 JP JP9542354A patent/JPH11514177A/ja active Pending
  • 1997-04-11 CA CA002252792A patent/CA2252792A1/en not_active Abandoned

Patent Citations (1)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events