This section provides information and examples to help you configure the long-term SLA Cluster Enforcement policies at the requester level, service level, and operation level.
At the core of the long-term SLA implementation is the concept of a sliding window that is defined by a combination of two policies (message.sla.TimeWindow and message.sla.TimeUnit). The guiding principle is that in any given time window, the system will not allow more tokens to be consumed than what is allowed by the most granular rate policy defined for the request: either the message.sla.ClusterOperationRate, message.sla.ClusterServiceRate, or message.sla.ClusterRequesterRate policy (in that order).
All three examples apply only to the SLA Cluster Enforcement mediation primitive. They cannot be applied to the SLA Local Enforcement mediation primitive.
In this example, a telecom network operator has exposed Terminal Location (TL) and Terminal Status (TS) services to a client (Requester1) using TWSS. Assume that the network operator assigns a weight of 10 to each TL and TS operation, and wants to restrict Requester1 to send at most 10 requests (of either TL or TS) within a time window of 600 seconds.
<requesterID>Requester1</requesterID> <policies> <policy attribute="message.sla.ClusterEnabled" value="true"/> <policy attribute="message.sla.ClusterWeight" value="10"/> <policy attribute="message.sla.ClusterRequesterRate" value="100"/> <policy attribute="message.sla.TimeUnit" value="Second"/> <policy attribute="message.sla.TimeWindow" value="600"/> </policies>
With these policies in effect, here is an example of what would happen to a set of requests originating with Requester1. Some of the requests are rejected because the SLA policy is defined at the requester level for a time window of 600 seconds.
Time (seconds) | Request | Disposition |
---|---|---|
60 | TL (50) | Accepted |
180 | TS (50) | Accepted |
360 | TL (10) | Rejected, because the total number of tokens (100) has been exhausted for the 600 second window. |
540 | TS (10) | Rejected |
620 | TL (10) | Rejected |
680 | TS (30) | Accepted, because only 50 tokens have been consumed during the previous 600 seconds–therefore enough tokens are available to accommodate this request. |
820 | TS (50) | Accepted |
In this example, a telecom network operator has exposed short messaging (SMS), Terminal Location (TL), and Terminal Status (TS) services to a client (Requester1) using TWSS. Assume that the network operator assigns a weight of 1 to each SMS request and a weight of 10 to each TL and TS operation. Also assume that the network operator wants to restrict Requester1 to send at most 10 TL and 10 TS requests (each of them counted separately) and any number of SMS requests provided the total consumed capacity does not exceed 500 tokens, within a time window of 600 seconds.
For Requester1, message.sla.ClusterRequesterRate (at requester level) is defined to be 500. Note that this allows any request from Requester1 to consume up to 500 tokens collectively. The message.sla.ClusterServiceRate policy is defined for both TS and TL to be 100. This policy overrides the requesterRate policy and allows each TL and TS to consume 100 tokens each.
<requesterID>Requester1</requesterID> <policies> <policy attribute="message.sla.ClusterEnabled" value="true"/> <policy attribute="message.sla.ClusterWeight" value="10"/> <policy attribute="message.sla.ClusterRequesterRate" value="500"/> <policy attribute="message.sla.ClusterServiceRate" value="100"/> <policy attribute="message.sla.TimeUnit" value="Second"/> <policy attribute="message.sla.TimeWindow" value="600"/> </policies>
<requesterID>Requester1</requesterID> <policies> <policy attribute="message.sla.ClusterEnabled" value="true"/> <policy attribute="message.sla.ClusterWeight" value="1"/> <policy attribute="message.sla.ClusterRequesterRate" value="500"/> <policy attribute="message.sla.TimeUnit" value="Second"/> <policy attribute="message.sla.TimeWindow" value="600"/> </policies>
With these policies in effect, and assuming that message.sla.ClusterServiceRate is defined for both TL and TS services, here is an example of what would happen to a set of requests originating with Requester1.
Time (seconds) | Request | Disposition |
---|---|---|
60 | TL (50) | Accepted |
180 | TS (100) | Accepted, because both TL and TS are allowed to consume 100 tokens each over the interval. |
360 | TL (50) | Accepted; however, now the 100-token limit has been reached for both TL and TS. |
540 | TS (10) | Rejected, because TS has used its limit of 100 tokens within the past 600 seconds. |
620 | TL (10) | Rejected, because TL has also used its limit of 100 tokens within the past 600 seconds. |
680 | TL (30) | Accepted, because only 50 tokens have been consumed by TL during the previous 600 seconds–therefore enough tokens are available to accommodate this request. |
750 | TS (50) | Rejected, because TS is still at its threshold of 100 tokens within the past 600 seconds. |
810 | TS (50) | Accepted, because more than 600 seconds have elapsed since TS used up its limit of 100 tokens. |
This example demonstrates how to set up policies for different operations within a service. Consider a telecom network operator who has exposed TL service to a client (Requester1) using TWSS. Assume that the network operator assigns a weight of 10 to each TL operation. Also assume that the network operator wants to allow Requester1 to send at most 10 getLocation and 10 getLocationForGroup requests within a time window of 600 seconds.
For Requester1, service TL, and operation getLocation, the message.sla.ClusterOperationRate policy is defined to be 100. For Requester1, service TL, and operation getLocationForGroup, the message.sla.ClusterOperationRate policy is also defined to be 100. Note that if a message.sla.ClusterServiceRate policy is defined, then that policy is enforced for all operations other than getLocation and getLocationForGroup. Thus both getLocation and getLocationForGroup requests are allocated 100 tokens each. In a similar way, if a message.sla.ClusterRequesterRate policy is defined, that policy will apply for all services other than TL.
<requesterID>Requester1</requesterID> <policies> <policy attribute="message.sla.ClusterEnabled" value="true"/> <policy attribute="message.sla.ClusterWeight" value="10"/> <policy attribute="message.sla.ClusterRequesterRate" value="500"/> <policy attribute="message.sla.ClusterServiceRate" value="50"/> <policy attribute="message.sla.ClusterOperationRate" value="100"/> <policy attribute="message.sla.TimeUnit" value="Second"/> <policy attribute="message.sla.TimeWindow" value="600"/> </policies>In this case, the ClusterOperationRate (100) overrides both ClusterServiceRate (50) and ClusterRequesterRate (500). This allows Requester1 to send 100 getLocation requests. The ClusterServiceRate (50) value applies to all operations for which no ClusterOperationRate is defined. The ClusterRequesterRate (500) value applies to all other services for which ClusterServiceRate is not defined.
With these policies in effect, here is an example of what would happen to a set of requests originating with Requester1.
Time (seconds) | Request | Disposition |
---|---|---|
60 | getLoc (50) | Accepted |
180 | getLocGroup (100) | Accepted |
360 | getLoc (50) | Accepted; however, now the 100-token limit has been reached for both getLocation and getLocationForGroup. 300 tokens remain for other request types, based on the difference between the ClusterRequesterRate value (500) and the 200 tokens already consumed. |
540 | getLocGroup (10) | Rejected, because getLocationForGroup has used its limit of 100 tokens within the past 600 seconds. |
620 | getLoc (10) | Rejected, because getLocation has also used its limit of 100 tokens within the past 600 seconds. |
680 | getLoc (30) | Accepted, because only 50 tokens have been consumed by getLocation during the previous 600 seconds–therefore enough tokens are available to accommodate this request. |
750 | getLocGroup (50) | Rejected, because getLocationForGroup is still at its threshold of 100 tokens within the past 600 seconds. |
810 | getLocGroup (50) | Accepted, because more than 600 seconds have elapsed since getLocationForGroup used up its limit of 100 tokens. |