STATEFUL DISTRIBUTED INTERPOSITION JOHN REUMANN and KANG G. SHIN

1. STATEFUL DISTRIBUTED INTERPOSITION JOHN REUMANN and KANG G. SHIN Presented by Sridurga Mavram

2. CONTENTS • Introduction • System Model • Architectural Overview • SDI Concepts • An Example using SDI • Performance • Conclusion

3. INTRODUCTION • Monolithic network services to modular multitier services. • Important system context is lost at system boundaries. • To manage resources, propagating information across multi-tier applications is problematic. • Virtual Services associate each service with a VS structure. • To Propagate VS resource descriptors need the OS to be changed at numerous places.

5. INTRODUCTION • Problems • telneting from login machine to remote client. • Information loss at tier boundaries is far more serious when system security is to be preserved. • Flask and DTE propose mechanisms for distributed security. • They have some common features

6. INTRODUCTION • SDI generalizes the common features and provides the following requirements. • Keep State : storing state variables in context object. • Generate State: automating generation of context. • Propagate Context: automates the propagation of context between cooperating services • Utilize Context: uses dynamic contextual information to trigger interposition on standard system interfaces.

7. SYSTEM MODEL • SDI is based on the following assumptions: • Multi-tier Systems are connected via a fast, reliable Server Area Network (SAN). • Each server provides a set of services, many of which act as front-end services. • Front-ends handle the requests from outside networks. • Front-end services depend on back-end which are also part of the server farm. • Back ends may be utilized by multiple front-end services simultaneously.

8. SYSTEM MODEL • To exchange request/replies, front-end and back-end services depend on OS communication primitives. • There are no communication channels hidden from the OS. • Contextual information can be shared among cooperating tiers without application support, only if the requests are executed by kernel-level threads. • It assumes a typical layered OS design, which helps in having interception points called taps. • A tap may be installed between the transition from a network layer to the IP layer.

9. ARCHITECTURAL OVERVIEW • Context Abstraction • SDI provides context abstraction that stores name-value pairs similar to POSIX environment variables. • The Difference : Unlike environment variables, context acts as an abstraction which can propagate along with the workload along multiple tiers. • A context object can be associated with multiple system objects at multiple hosts simultaneously, which is a necessity in distributed system. • Context is very important to facilitate co-ordination of distributed activities in a multitiered system.

10. ARCHITECTURAL OVERVIEW • Managing Context • Tagging of system objects to new/existing context object is needed • The initial context for messages received from outside network are tagged using classifiers. • Classifiers extract as much information as possible from incoming message and use for context determination. • The context may affect the processing of packet/process at various levels. • This is similar to the effect that environment variables have on the application.

11. State change at various levels as request progresses.

12. ARCHITECTURAL OVERVIEW • Managing Context • Taps intercept the control flow at the OS layer and can apply SDI rules to interception computations • SDI rules are dynamically installed by the system administrator. • SDI rules are triggered if the condition in the guard clause is met. • This may cause the modification of context attributes or tag system objects with reference to different context objects. • SDI rules have a means of policing intercepted multitier computations. • Apart from standard actions, SDI rules also permit GCF’s. For example they could be GCF’s for encryption and decryption.

13. Structure of SDI rule

14. ARCHITECTURAL OVERVIEW • Application-Level Integration • Applications may use the context variables in addition to environment variables. • SDI provides an interface for the applications to query and set the values of context attributes. • Application can rely on OS and no longer need to device their own mechanisms which could be incompatible across different distributed frameworks. • An additional benefit in this design could be to reduce the latency in messages that need not be error-free.

15. SDI CONCEPTS • Context • Context: Aggregate of attribute-value pairs, that could be associated with system objects as additional state. • Naming Attributes : Global namespace is controlled by University of Michigan, Real-Time Computational Laboratory. • Addressing context: Addressing is relative to the system abstraction whose state it extends. An absolute addressing is needed. • Context Propagation: To facilitate distributed priorities, access control, system services under different kernels need to exchange context. • The tagging rule should track the control and data flow of a composite process at tier boundaries.

16. SDI CONCEPTS • Initial Context Creation • Classifiers extract and interpret intercepted packet information in accordance with system administrator-specified context binding. • Classifier may evaluate an incoming packet’s source address, destination address, protocol and port number. • Based on the above values, the classifier either associates the incoming packet with existing context or creates a new context object. • Since there is no limit for the amount of information that could be specified inside the classifier, they proposed a grammar.

17. SDI CONCEPTS • Handling Distributed Context Efficiently • Problem1: If the context object that SDIs refer are located remotely, frequent invocations can incur higher latencies. • Solution: Caching is the best solution. Distributed access to context attributes proceeds through caching proxy object. • Problem2: Memory efficiency – when is it safe to discard a context object? • Solution: two way – one is to check whether the context is still needed locally, second is to check how many proxies refer to this context object and use a count-based garbage collector.

18. SDI CONCEPTS • Handling Distributed Context Efficiently • Problem3: Memory leakage due to host failures • Solution: The back-end being unresponsive is handled by heart beats, each host periodically announces its liveliness to the host holding the primary context objects for its proxies. • Context Security • The mechanisms in this framework have only addressed local access integrity leaving the rest to the IP layer. • To assure local access integrity, attribute operations are controlled by access rights. For binding privileged context, binding permissions are also enforced.

19. An Example using SDI • Context Propagation via Local IPC • Two system calls used to send and receive messages are msgsnd and msgrcv. • We need to deal with the message queue, sender and the receiver. • It is necessary to add a context reference pointer to the message queue data structure. • If the sender priority is high, SDI copies the sender’s context to the message. • When the context tagged message is received, SDI copies the received message’s context to the receiver’s context.

20. An Example using SDI

21. PERFORMANCE Objective: To to see if SDI is an efficient mechanism for system extension, which requires fast interpretation to context attributes and fast interpretation of rules. The Result: They have tested the framework both on micro and macro benchmarks which indicates that SDI can be used as an efficient mechanism.

22. CONCLUSION SDI is a low-overhead improvement for hosting multitier services, hence services can perform well in server farms, under constraints that were not anticipated during the design process. SDI is not intended to be a final standard for distributed context. It has just marked a beginning of the standardization. It will be necessary for future implementations to concentrate more on the main concepts seen in this paper.

23. THANK YOU