Paper Discussion - Fall 2008 - CS 736

Summary
The paper proposes using "resource containers" as the domains for
resource management and policy decisions, instead of using the
isolation domains - process/threads as the resource principle. This
helps in better resource allocation and accounting for each
independent activity(handling a network request)

Problem
Networked(HTTP) servers and monolithic kernels form the majority of
the commercial systems in use. But these http applications have no
control over the resources used on its behalf or control QoS on a per
request or per user basis. This arises out of monolithic kernel's
design of using process as isolation domains as well as resource
principle.

Contributions
- By using resource containers, we can have multiple
threads(kernel/user) belong to multiple resource containers with a
many to many mapping.
- This flexibility allows the system to handle any kind of activity
ranging from single threaded server to multi-threaded server with
dynamic content, and associate a container with it.
- Each container can have different priorities/resources and can
control the policies and usage of any activity (for e.g. network
request) right from the point it enters the system. By using network
filters we can provide prioritization of premium requests at kernel
level.
- Rather than penalizing a dynamic process, we can penalize the
request that actually causes high cpu/memory usage.
- By associating resource containers with each thread that is
associated with an activity(request/user), we can maintain the
complete resource usage of that container and charge it to the user.

Flaws
- There is no mention about access control over the resource containers.
- For the sake of accountability, it adds the complexity of
maintaining the resource containers for each activity. This has a
performance cost too for each thread creation and deletion.

Techniques
It uses a resource container construct shared between the kernel and
user level and associated with an independent activity. Resource
containers provide higher accountability and better control over
resource usage at the cost of added complexity and performance. This
model can be used by any cloud computing system to accurately charge
the users for the services used.

Summary:
The paper proposes resource containers as a mechanism to associate the resource binding of each thread to the approapriate activity that the thread is doing. This decouples resource principal from the protection domain / process, and allows more accurate accounting of resource usage against the correct activity.

Problem:
Contemporary operating systems mix up the concepts of protection domain and resrouce principal into the process abstraction. There are many instances which the paper enumerates where the resource principal differs from the user-process. This causes errors in accounting of resource usage. Also, scheduling is affected because the data on past resource usage that the scheduler uses is inaccurate. (While the motivation for the whole paper is the case of web-servers, the scope of the solution is much more general).

Contributions:
- The most important contribution is the decoupling of resource principal from the protection domain / process. This allows for proper accounting of resource usage in many use-cases as pointed out by the paper.
- The paper suggests the idea of making the thread's resource binding explicit. This actually better than the OS trying to infer this binding and definitely better than blindly associating the binding to the process. Reason: the activity is really the entity which knows what resources / threads make it up.
- Resource containers further allow scheduling at the granularity of an activity. Guarantees can be requested for resources for an activity, and as the prototype implementation demonstrates, these were actually achieved.

Flaws:
- resource containers isn't a complete solution in itself. For eg., with the processing that the kernel does on behalf of an activity, providing a resource container alone does not allow accounting. In the paper, they use LRP to actually do the accounting correctly; modifying the LRP to work with containers rather than processors.
- A hierarchical organization like a tree might not always be sufficient. A case for multi-parented organization exists. For eg. with the CGI application case, if one wants to account the CGI processing against the correct network connection, one needs to use the RC of the connection. But if one needs to limit total processing for CGI, one uses a parent child structure which enforces a guarantee on the maximum time that CGI processing takes. But what if one wants to do both?
- The paper is strongly coupled to the webserver example. However, the ideas proposed have a greater applicability. (All the same, this coupling actually makes the paper awesomely lucid, unlike some of the papers we've read in class :D )

Technique used:
The technique used to achieve accurate resource binding/accounting here is delineation of the resource container entity and providing it an independent existence (and hierarchy). Contemporary operating system have the RC mired in the process abstraction which is quite insufficient as demonstrated by the paper.

Tradeoff made:
There is a tradeoff in performance here because now we have the overhead of another data structure to be maintained, and stuff like LRP to be done at the kernel to allow accurate resource binding. However, the evaluation in the paper shows that they manage to keep it low.

Another place where the technique applies:
Threads could be argued to be a manifestation of a similar delineation. Traditionally a process was a protection doman as well as an execution sequence. But when various insufficiencies of this model arose, people delineated the execution sequence from the protection doman and created threads. With threads, the problem of improving parallelism gets a better solution without having the overheads of circumventing the protection domain by setting up shared memory / IPC etc.

Summary
This paper discusses the idea that associating costs of the kernel usage is insufficient in current designs and leads to vulnerabilities with resource allocations. Resource containers extend the idea of LRP and present a way to charge threads for system utilization that they consume.

Problem Description
In prior general purpose operating systems, the application execution cost does not associate with the kernel code usage that the application consumes. This allows kernel code executed by low priority applications to possibly consume disproportionately with priority which leads to vulnerabilities such as denial of service. Quality of Service with kernel code utilization is not extended to application code for direct resource consumption such as networking.

Contributions
-The idea of extending the LPR from a process unit to a thread unit of resource consumption.
-Abstraction of a resource container which stores all resources and consumption for the system scheduler to utilize.
- Implementation of a sockaddr filter for specifying what external sources are allowed to use the resource for improved filtering and protection from SYN floods.

Flaws
The testing targets single case tests to show that the system does in fact control the resource consumption. However, it does not show the overall resource and processing overhead between a system without resource containers and with resource containers under real test conditions. For example, typical benchmarks not related to network consumption should be run because resource containers will affect performance of all threads in the system.

Techniques
The technique used to achieve performances is a structure containing resource utilization for used by the scheduler to make decisions. The trade off is an accurate representation of thread consumption for the additional cost of having the resource container primitives. This method of using resource containers at a thread level could be valuable in mobile technologies to control which processes are consuming the most power and under low power mode, schedule the threads in a way to minimize power usage.

Summary
The paper proposes a new operating system abstraction called a resource container, which differentiates between the notion of a protection domain from the notion of a resource principal (entities among which system resources are shared). The performance of this new abstraction is measured and found to add only a negligible overhead.

Problem attempted
The objective of this paper to allow an application to explicitly allocate resource consumption among the independent activities it manages.

Contributions

1. The paper identifies one of the following two different problems with the resource management in current operating systems :
a) Either an application has no control over system resources controlled by kernel on behalf of the application, as the current resource management primitives do not extend to kernel code

b) Even in systems where (a) is possible, there is no flexibility in what constitutes an independent activity. Invariably, a process is assumed to constitute an independent activity. In a single process server (which is true for many modern servers), the kernel sees just one resource principal

2. The paper addresses this problem by proposing a new abstraction called resource container, for the operating system's resource principal. A resource container contains all system resources being used by an application for a specific independent activity. Containers are associated with attributes like scheduling parameters, resource limits etc. The kernel is expected to account for usage of system resources on the resource container rather than a process.

3. The application has the choice of binding a thread to a specific resource container and the resource consumption of a thread charges the thread's container. If for a particular independent activity, we require multiple threads from different processes, then all these threads are bound to the same resource container.

4. A thread's scheduler binding is the set of all containers that will be used to determines the schduling of a thread. Though the scheduler binding of a thread is set implicitly by the operating system, the application is given explicit control over which containers should remain in the scheduler binding of a thread. Allocation of other system resources are handled in a manner similar to allocating CPU cycles.

Flaws

The paper does not clearly explain the resource management between different threads bound to the same container. Because all the charges are now assigned to the container, it is unclear as to how the different threads within a container are allocated resources.

What it makes easier

Resource containers form a hierarchical structure. This makes it possible to control resource consumption of an entire subsystem and at the same time, the system gives the freedom to the subsystem to allocate and schedule resources among its various independent activities.

What it makes harder

Implementing resource containers requires change of a large protion of both the kernel code and application code. The change to be effected on the application side is not really a burden as the application has the choice of doing container based resource allocation or going ahead with the current system.