STATEFUL DISTRIBUTED INTERPOSITION

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.

4
(No Transcript)
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 GCFs. For example they could be GCFs 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 packets
  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
  senders context to the message.
• When the context tagged message is received, SDI
  copies the received messages context to the
  receivers 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