WebSphere brand IBM WebSphere Telecom Web Services Server, Version 7.1

Guidelines for choosing limits for SLA Local Enforcement

This section provides information and examples to help you configure the long-term SLA Local Enforcement policies at the requester level, service level, and operation level.

Overview

At the core of the long-term SLA implementation is the concept of a fixed 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.LocalOperationRate, message.sla.LocalServiceRate, or message.sla.LocalRequesterRate policy (in that order).

All three examples apply only to the SLA Local Enforcement mediation primitive.

Requester level policies

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.

In this case, the policy set is coded as follows:
<requesterID>Requester1</requesterID>
	<policies>
		<policy attribute="message.sla.LocalEnabled" value="true"/>
		<policy attribute="message.sla.LocalWeight" value="10"/>
		<policy attribute="message.sla.LocalRequesterRate" 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.

(The notations indicate that the first request is a Terminal Location request consuming 50 tokens, for example a getLocation request with 5 targets. The request is sent 60 seconds after the start of the interval in question.)
Time line showing requests in the example using requester level policies. Refer to the accompanying table for details.
Table 1. Example using requester level policies
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) Accepted, because a new time window has begun and no tokens have been consumed–therefore, enough tokens are available to accommodate this request.
680 TS (30) Accepted, because only 10 tokens have been consumed during the present 600-second window–therefore enough tokens are available to accommodate this request.
820 TS (50) Accepted

Service level policies

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.LocalRequesterRate (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.LocalServiceRate 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.

In this case the policy set retrieved for any TL or TS request is coded as follows:
<requesterID>Requester1</requesterID>
	<policies>
		<policy attribute="message.sla.LocalEnabled" value="true"/>
		<policy attribute="message.sla.LocalWeight" value="10"/>
		<policy attribute="message.sla.LocalRequesterRate" value="500"/>
		<policy attribute="message.sla.LocalServiceRate" value="100"/>
		<policy attribute="message.sla.TimeUnit" value="Second"/>
		<policy attribute="message.sla.TimeWindow" value="600"/>
	</policies>  
The policy set retrieved for an SMS request is coded as follows:
<requesterID>Requester1</requesterID>
	<policies>
		<policy attribute="message.sla.LocalEnabled" value="true"/>
		<policy attribute="message.sla.LocalWeight" value="1"/>
		<policy attribute="message.sla.LocalRequesterRate" 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.LocalServiceRate is defined for both TL and TS services, here is an example of what would happen to a set of requests originating with Requester1.

(As in the previous example, the notations indicate that the first request is a Terminal Location request consuming 50 tokens, for example a getLocation request with 5 targets. The request is sent 60 seconds after the start of the interval in question.)
Time line showing requests in the example using service level policies. Refer to the accompanying table for details.
Table 2. Example using service level policies
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 present 600-second window.
620 TL (10) Accepted, because a new time window has begun and no TL tokens have been consumed.
680 TL (30) Accepted, because only 10 tokens have been consumed by TL during the present 600-second window–therefore enough tokens are available to accommodate this request.
750 TS (50) Accepted, because no tokens have been consumed by TS during the present 600-second window–therefore enough tokens are available to accommodate this request.
810 TS (50) Accepted, because only 50 tokens have been consumed by TL during the present 600-second window–therefore enough tokens are available to accommodate this request.

Service operation level policies

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.LocalOperationRate policy is defined to be 100. For Requester1, service TL, and operation getLocationForGroup, the message.sla.LocalOperationRate policy is also defined to be 100. Note that if a message.sla.LocalServiceRate 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.LocalRequesterRate policy is defined, that policy will apply for all services other than TL.

In this case the policy set retrieved for getLocation and getLocationForGroup requests from Requester1 is coded as follows:
<requesterID>Requester1</requesterID>
	<policies>
		<policy attribute="message.sla.LocalEnabled" value="true"/>
		<policy attribute="message.sla.LocalWeight" value="10"/>
		<policy attribute="message.sla.LocalRequesterRate" value="500"/>
		<policy attribute="message.sla.LocalServiceRate" value="50"/>
		<policy attribute="message.sla.LocalOperationRate" value="100"/>
		<policy attribute="message.sla.TimeUnit" value="Second"/>
		<policy attribute="message.sla.TimeWindow" value="600"/>
	</policies>  
In this case, the LocalOperationRate (100) overrides both LocalServiceRate (50) and LocalRequesterRate (500). This allows Requester1 to send 100 getLocation requests. The LocalServiceRate (50) value applies to all operations for which no LocalOperationRate is defined. The LocalRequesterRate (500) value applies to all other services for which LocalServiceRate is not defined.

With these policies in effect, here is an example of what would happen to a set of requests originating with Requester1.

(The notations indicate that the first request is a getLocation request consuming 50 tokens, for example a request with 5 targets. The request is sent 60 seconds after the start of the interval in question.)
Time line showing requests in the example using service operation level policies. Refer to the accompanying table for details.
Table 3. Example using service operation level policies
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 LocalRequesterRate value (500) and the 200 tokens already consumed.
540 getLocGroup (10) Rejected, because getLocationForGroup has used its limit of 100 tokens within the present 600-second window.
620 getLoc (10) Accepted, because a new time window has begun–therefore enough tokens are available to accommodate this request.
680 getLoc (30) Accepted, because only 10 tokens have been consumed by getLocation during the present 600-second window–therefore enough tokens are available to accommodate this request.
750 getLocGroup (50) Accepted, because no tokens have been consumed by getLocationForGroup during the present 600-second window–therefore enough tokens are available to accommodate this request.
810 getLocGroup (50) Accepted, because only 50 tokens have been consumed by getLocationForGroup during the present 600-second window–therefore enough tokens are available to accommodate this request.

General guidelines

In general, follow these guidelines when defining SLA policies:
  • Even though the Service Policy Manager allows you to define the policy values for message.sla.LocalRequesterRate, message.sla.LocalServiceRate and message.sla.LocalOperationRate at any level, you should define message.sla.LocalRequesterRate only at the requester level, message.sla.LocalServiceRate only at the service level, and message.sla.LocalOperationRate only at the operation level.
  • The time window should be defined at the same level where the rate policy is defined.
  • If you change the policies to modify the rate or duration of the time window, your changes will take effect as soon as the next request is sent. However, if you change the duration of the time window, requests that are already placed will expire according to the policy values that were in force when the requests were placed.



Terms of use
(C) Copyright IBM Corporation 2009. All Rights Reserved.