CS 443 Advanced OS Fabián E. Bustamante, Spring 2005 Resource Containers: A new Facility for Resource Management in Server Systems G. Banga, P. Druschel, J. Mogul Rice & Compaq Presented by: Aaron J Beach

Outline Background and Terms Previous Approaches and Problems A new Approach: Resource Containers Performance and Evaluation Conclusion

Background: Web Servers Many users' perceived computing performance is based on how well remote web servers perform. The OS and hardware are rarely on the critical path concerning web browsing Servers may accomplish many different tasks each consuming many different types of resources. Depending on the resource strategies of the system it can be very hard to achieve QOS, fairness, or protection for existing and new clients.

The Big Idea! The main big problem this paper seeks to convey and build upon is this: Independent activities or tasks are not coupled with the process or thread entity. However, the user-level (thread or process) is treated as the independent accountable entity for resource management. This mis-assumption is BAD!

Web servers Previous Approaches Problems Previous Solutions Mis-assumptions

Process per Connection An idle connection waits listens on the socket For each new connection a new process is spawned Drawbacks: Suffers from context switches Process creation IPC Possibly very vulnerable to Syn attacks

Event-Driven Single-Process Single process runs and calls handlers when it receives requests Avoids IPC and context switches Drawbacks: Not really concurrent, however, can spawn multiple processes if on multi-processor system

Multi-threaded Server Each connection gets its own thread Threads are scheduled by scheduler thread Idle threads listen for next connections This avoids context switches and scales better

Other Resources used by Servers Dynamic Resources such as pages created in response to user input may require third party software. This usually results in another process being spawned to handle each dynamic request.. CGI was developed for fast IPC Kernel Resources: The kernel does network processing in order to handle connections and send connections, It may have buffers for the connections. These resources are generally considered separately from the Server and charged to either no one or any unlucky process!

General Assumptions of Severs ● Process provides dual purpose ● Protection domain ● Resource Entity ● Basically the ideas of a protection domain and accountable resource entity are coupled by the process/thread

Kernel vs User Resources Server activity extends into the kernel This is not considered during Resource management Network intensive apps (i.e. Servers) may result in large percentages of overall resources being spent in the kernel!

Multi-threaded server and the Kernel ● The threads each require processing to be done within the kernel ● Lazy Receiver Processing ● Charge kernel processing to the associated connection ● Allows you to scale more gracefully and protect existing threads from incoming new threads (possibly syn attacks) ● Allows better QOS ● Still associates the protection domain and resource principle!

Process vs Independent Activity ● Single activity may spawn multiple processes to handle same connection (i.e. Dynamic Content) ● Single activity may want to protect different aspects of the same activity from eachother! ● Conclusion: ● Protection domains and resource principles are not semantically coupled!

A new approach... RESOURCE CONTAINERS! “An abstract operating system entity that logically contains all of the system resources being used by an application to achieve a particular independent activity” ● Resources ● CPU, memory, sockets, buffers ● Attributes ● Scheduling parameters (priority, QOS level, constraints ● Resource Container Aspects ● Hierarchy (parents -> children) ● Dynamic Resource Binding ● API and other practical implementation aspects

Resources Processes / Threads Dynamic Resource Binding Basically processes and threads can be associated and re-associated with the activity or purpose they are serving Charge resources within the kernel like LRP The key idea: The resource binding is the relation between resource/processing domains and the associated resource principles, effectively decoupling the two

Attributes Attributes are used by Resource Management to protect QOS of clients Can protect against SYN attacks by maintain QOS at all levels for existing clients Can Maintain Static Content requests separate of dynamic requests Attributes: Priority Type of Service Constraints

Scheduling threads Threads may serve one container or many, existing within the same protection domain To avoid rescheduling threads after every resource container binding, a list of containers is associated with a thread and the thread is scheduled based on combined attributes Threads initially inherit their parent's Container (Hierarchical)

PERFORMANCE AND EVALUATION Isolation of separate activities Dynamic requests vs Static requests Priority based scheduling QOS of differing priority clients Protecting against Syn Floods Continuing to Server existing clients

Experiment Added 6550 lines of code to Digital UNIX Modified: CPU scheduler To use Resource Containers as it's principle unit TCP/IP subsystem LRP style processing “4820 lines... to Integrate containers as the system's resource principles”... the details I guess Running a single-process Event driven server

Dynamic vs Static Requests Can Static requests maintain throughput in the face of many Dynamic requests? Constrain the resource usage of dynamic reqs

Differentiating QOS Assign resource container T-high to high priority connections. Assign resource container T-low to low priority How do T-high response time change with increase in low priority connections Reduce queue time of T-high

SYN-attack resilience Basically they had a set of known mis- behaving clients SYN attack the server, and measured the concurrent throughput to other clients.

Attributes Attributes are used by Resource Management to protect QOS of clients Can protect against SYN attacks by maintain QOS at all levels for existing clients Can Maintain Static Content requests separate of dynamic requests Attributes: Priority Type of Service Constraints

Conclusions... YO! Resource Container decouple resource principles from protection domains and extend them into the kernel and other processes Evaluation shows they are able to achieve fine-grained QOS differentiation enforce priorities of activities that may share the same process or pervade many processes This makes sense, no?