Meeting Service Traffic Requirements in SOA Keerthana Boloor (NCSU), Bob Callaway (IBM), Marcelo Dias de Amorim (UPMC) Adolfo Rodriguez (IBM), and Yannis Viniotis (NCSU)

Introduction / Motivation Enterprise networks host multiple services, located in potentially physically distinct servers. a Web Server farm using Web 2.0, SOA hosting static content. a group of enterprise application servers generating dynamic, business driven content Services can be governed by a “Client Service Contract (CSC).” CSC: “Limit the rate of requests to a service provider such that no more than X requests are processed by available servers over an observation/enforcement time interval of T seconds” Businesses are experiencing a paradigm shift owing to adoption of service oriented architectures for increased flexibility and integration with legacy systems. Deployment of SOA based applications is primarily enabled via XML based web services. (Read slide) (Show diagram) Since XML parsing is CPU intensive, dedicated hardware XML processing appliances are introduced in the infrastructure which also are controllers of the flow of requests to the service host. A service host typically enforces a service access requirement which is governed by a client service contract

Example: Enterprise Network For service a, X/B for T X/B X/B X/B For service a, X/B for T X/B CSC for Service A: No more than X requests over T seconds X/2B X/2B For service a, X/B for T 3X/2B X/B Server farm This is an example enterprise network with requests from internet users forwarded to the service provider through the middleware appliances. The middle ware appliances shown here are IBM Datapower appliances. A service enforces a service access requirement which is governed by the client service contract. (back to previous slide) The contract under consideration for the thesis says that “Limit the number of requests to a service to no more than X requests with an observation/enforcement period of T seconds”. The middleware appliances have to respect the CSC, collectively they should not allow more than X requests for a service a within the interval T. Typically static allocation is used in scenarios like this where the enterprise administrator will configure each box not to send more than X/B requests to service a within the enforcement period of X. This static allocation works fine if the rate of requests to the boxes were fairly static i.e uniformly distributed however in the real world this is not the case. Consider the example blah blah….. Hence static allocation is clearly not efficient and hence we need a measurement based dynamic allocation technique/algorithm for effective CSC enforcement. For service a, X/B for T X/B X/B Need measurement based dynamic allocation for effective CSC enforcement For service a, X/B for T Internet users Middleware appliances (B = 5)

Example: Enterprise Network X/B X/B X/B X/B CSC for Service A: No more than X requests over T seconds X/2B X/2B 3X/2B 3X/2B Server farm What if box 4 knew that box 3 has only X/B requests and it can send X/2B requests more of its own and still collectively respect the contract. Hence this approach where each appliance knows of the requests at the other boxes and Hence we need a reactive algorithm that adapts to the current state of the system on a per appliance basis. The term “per appliance” is extremely important because the shaping action or flow control occurs in each individual box locally but collectively respecting the contract. X/B X/B We propose a reactive algorithm that adapts to the current state of the system on a per appliance basis Internet users Middleware appliances

CASTS Credit based Algorithm for Service Traffic Shaping Decompose the observation/enforcement interval into K subintervals. Each subinterval is divided into measurement phase where the current number of queued requests are measured and adaptation phase where the output count to be allowed from the box is determined based on number of requests queued and current allowed count of the peers. At each middleware appliance, adaptation 1 2 K-1 K The algorithm developed as part of this study is called CASTS or credit based algorithm for service traffic shaping. T Input count during subinterval 1, X/2B

CASTS Mention D as credits remaining and R as cumulative counts allowed

Flooring effect Assumptions Since the CSC dictates the number of requests per observation interval, the local action at each box has to approximate the nearest integer number of allowed counts. We cannot use ceiling() as the CSC will not be respected and hence the algorithm is suboptimal as credits might be wasted, in the worst case when all queue sizes are same B - 1 credits are lost and have to be redistributed in the next subinterval. Assumptions The time required for the appliances to exchange status messages and compute the new allowed count is << T/K

High and low uniform input loads, Yin Results Number of appliances 32 (B=32) CSC: No more than 128 requests per second (X=128, T=1) Number of subintervals 20 (K = 20) High and low uniform input loads, Yin

Varying value of K Response under uniform load, Yin = 1000 Response under bursty traffic, Yin = 10000

Performance with varying input load rates, Yin When requests are evenly distributed among B appliances

Transit delay modes Taking transit delay into consideration, relaxed mode Yin = 10000 X = 9600 B = 32

Future work Simulate transit delays for various bandwidths for both strict and relaxed modes. Simulate varying initial conditions. Investigate varying K with input load rate. Compute overhead. Alleviate the flooring effect.