Method and Apparatus for Controlling Utilization in a Horizontally Scaled Software Application

• US 20140143300A1
• Filed: 11/21/2012
• Published: 05/22/2014
• Est. Priority Date: 11/21/2012
• Status: Active Grant

• Current Assignee: Telefonaktiebolaget LM Ericsson
• Original Assignee: Telefonaktiebolaget LM Ericsson
• Inventors: Karlsson, Pr, Kaspersson, Mikael
• Granted Patent: US 9,112,809 B2
• Time in Patent Office: Days
• US Class Current: 709/203
• CPC Class Codes: H04L 41/5009 Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
• CPC Class Codes: H04L 41/5022 by giving priorities, e.g. assigning classes of service
• CPC Class Codes: H04L 43/026 using flow identification
• CPC Class Codes: H04L 43/0876 Network utilisation, e.g. volume of load or congestion level
• CPC Class Codes: H04L 47/10 Flow control; Congestion control
• CPC Class Codes: H04L 47/20 Traffic policing
• CPC Class Codes: H04L 67/101 based on network conditions
• CPC Class Codes: Y02D 30/50 in wire-line communication networks, e.g. low power modes or reduced link rate

Abstract

The present invention comprises an apparatus and method for distributed traffic control in a horizontally scaled application, in which a software-based application is implemented as a number of peer application instances that each provide a portion of the application'"'"'s overall capability or capacity. An apparatus that includes a distributed traffic controller is instantiated or otherwise implemented at each application instance, and these apparatuses collectively operate to limit the overall utilization of the application by individual clients or affiliated groups of clients according to, e.g., Service Level Agreements or SLAs, and further operate to prevent disproportionate utilization of any one of the application instances. Advantageously, such operations are accomplished according to the teachings herein using efficient information propagation protocols between the distributed traffic controllers.

Claims

1-20. -20. (canceled)

21. A method of controlling a utilization of a software application by an individual client, wherein the application is implemented as a number of peer application instances that receive application traffic from any one or more clients in a plurality of clients and wherein the method at each application instance comprises:

classifying the application traffic incoming to the application instance into flows corresponding to different ones of the clients and/or different types of application traffic;

estimating a local demand value for each flow with respect to the application instance;

exchanging local demand information with one or more other ones of the application instances, including sending the local demand values estimated for the flows at the application instance and receiving like estimated local demand values for all like flows at other ones of the application instances;

determining a global demand value for each flow with respect to the application, based on the exchanged local demand information;

calculating a local utilization limit for each flow as a function of the global demand value determined for the flow;

marking the application traffic in each flow as being out-of-policy traffic or as being in-policy traffic, in dependence on whether or not the local utilization limit for the flow is exceeded;

determining whether an aggregation of the application traffic for all flows at the application instance exceeds a local aggregated utilization limit; and

controlling a buffering of the aggregated application traffic toward the application instance on a per-flow and/or aggregated flow basis, based on whether the local aggregated utilization limit is exceeded and distinguishing between in-policy and out-of-policy traffic.

22. The method of claim 21, wherein exchanging the local demand information comprises communicating with the one or more other ones of the application instances via a gossip-based anti-entropy protocol that propagates the local demand values as estimated at any one of the application instances to all other ones of the application instances.

23. The method of claim 21, wherein estimating the local demand value for each flow comprises at least one of:

counting a number of protocol sessions active at the application instance for the flow;

estimating an expected flow rate of the flow based on whether any new application traffic in the flow has been received within a defined interval; and

estimating the expected flow rate of the flow based on measuring an arrival rate of the application traffic in the flow.

24. The method of claim 21, wherein determining the global demand value for the flow comprises summing the local demand value estimated for the flow at the application instance with the local demand values estimated for all like flows at the other ones of the application instances, as known from the exchanging of the local demand information.

25. The method of claim 21, wherein calculating the local utilization limit for each flow comprises calculating a local flow rate limit for the flow.

26. The method of claim 25, wherein calculating the local flow rate limit for the flow comprises calculating the local flow rate limit as an overall maximum flow rate limit known for the flow and all of its like flows with respect to the application, and scaling the overall maximum flow rate limit by a proportionality factor determined as a ratio of the local demand value of the flow to the global demand value of the flow.

27. The method of claim 25, wherein calculating the local utilization limit for each flow further comprises calculating a local burst size limit for the application traffic in the flow.

28. The method of claim 21, wherein controlling the buffering of the aggregated application traffic toward the application instance comprises prioritizing the in-policy traffic over the out-of-policy traffic, including emptying one or more delay buffers toward the application instance according to a prioritization scheme that in general imposes shorter buffering delays on the in-policy traffic as compared to the out-of-policy traffic.

29. The method of claim 28, further comprising further prioritizing the aggregated application traffic in the one or more delay buffers according to one or more service parameters defined in respective Service Level Agreements (SLAs) associated with individual ones of the flows, so as to meet one or more minimum application traffic parameters defined for the flows in one or more of the SLAs.

30. The method of claim 21, wherein said marking step further includes a policing step that includes throttling or selectively dropping application messages within the application traffic in each flow, as needed to maintain compliance with maximum service levels guaranteed in a corresponding Service Level Agreement (SLA) known for the flow.

31. An apparatus for controlling a utilization of a software application by an individual client, wherein the application is implemented as a number of peer application instances that receive application traffic from any one or more clients among a plurality of clients and wherein the apparatus is implemented at each application instance and comprises:

a distributed traffic controller configured to classify the application traffic incoming to the application instance into flows corresponding to different ones of the clients and/or different types of application traffic and estimate a local demand value for each flow with respect to the application instance; and

a communication controller configured to exchange local demand information with one or more other ones of the application instances, including sending the local demand values estimated at the application instance for the flows at the application instance and receiving like estimated local demand values for all like flows at the other application instances; and

wherein said distributed traffic controller is further configured to;

determine a global demand value for each flow with respect to the application, based on the exchanged local demand information;

calculate a local utilization limit for each flow as a function of the global demand value determined for the flow;

mark the application traffic in each flow as being out-of-policy traffic or as being in-policy traffic, in dependence on whether or not the local utilization limit for the flow is exceeded;

determine whether an aggregation of the application traffic of all the flows at the application instance exceeds a local aggregated utilization limit; and

control a buffering of the aggregated application traffic toward the application instance on a per-flow and/or aggregated flow basis, based on whether the local aggregated utilization limit is exceeded and distinguishing between in-policy and out-of-policy traffic.

32. The apparatus of claim 31, wherein the distributed traffic controller is configured to cooperate with the communication controller to exchange the local demand information by communicating with the one or more other ones of the application instances via a gossip-based anti-entropy protocol that propagates the local demand values as estimated at any one of the application instances to all other ones of the application instances.

33. The apparatus of claim 31, wherein the distributed traffic controller is configured to estimate the local demand value for each flow by at least one of:

counting a number of protocol sessions active at the application instance for the flow;

estimating an expected flow rate of the flow based on whether any new application traffic has been received in the flow within a defined interval; and

estimating the expected flow rate of the flow based on measuring an arrival rate of the application traffic in the flow.

34. The apparatus of claim 31, wherein the distributed traffic controller is configured to determine the global demand value for each flow by summing the local demand value estimated for the flow at the application instance with the local demand values estimated for all like flows at the other application instances, as known from the exchanging of the local demand information.

35. The apparatus of claim 31, wherein the distributed traffic controller is configured to calculate the local utilization limit for each flow by calculating a local flow rate limit for the flow.

36. The apparatus of claim 35, wherein the distributed traffic controller is configured to calculate the local flow rate limit for the flow by calculating the local flow rate limit as an overall maximum flow rate limit known for the flow with respect to the application, as scaled by a proportionality factor that is determined as a ratio of the local demand value of the flow to the global demand value of the flow.

37. The apparatus of claim 35, wherein the distributed traffic controller is configured to calculate the local utilization limit for each flow further by calculating a local burst size limit for the flow.

38. The apparatus of claim 31, wherein the distributed traffic controller is configured to control the buffering of the aggregated application traffic toward the application instance by buffering the aggregated application traffic in one or more delay buffers and emptying the one or more delay buffers toward the application instance according to a prioritization scheme that in general imposes shorter buffering delays on the in-policy traffic as compared to the out-of-policy traffic.

39. The apparatus of claim 38, wherein the distributed traffic controller is further configured to prioritize any aggregated application traffic in the one or more delay buffers according to one or more service parameters defined in respective Service Level Agreements (SLAs) associated with individual ones of the flows at the application instance, so as to meet one or more minimum application traffic parameters defined in one or more of the SLAs.

40. The apparatus of claim 31, wherein, in conjunction with marking the application traffic in each flow as being in-policy traffic or out-of-policy traffic, said distributed traffic controller is further configured to throttle or selectively drop application messages within each flow, as needed to maintain compliance with maximum service levels guaranteed in a corresponding Service Level Agreement (SLA) known for the flow.