Ankit Agrawal

We are doing an analysis of the performance impacts of moving the network middleboxes to virtual machines and containers. The goal is to design a scalable and an optimized enterprise network with middlebox elements deployed on cloud. We will explore the opportunities to deploy the middlebox by keeping the following things in mind:

1. Minimize the data copying between middleboxes.
2. Optimize the data transfer time between the middleboxes.
3. Minimize the computation on a packet as it pass through the middlebox stack.
4. Load balancing of the computations for the network packets.
5. Data security by restricting the communication to only a set of authorized middleboxes.

SWAMP is a framework to perform analysis on the user source code and seek for potential security vulnerabilities. I am working to create a plugin for the Eclipse IDE. The plugin will allow the user to ship their project (C/C++, JAVA and Python) from the workspace to the SWAMP cloud infrastructure for analysis. The development effort is in Java.

Virtualization systems share several hardware resources that includes CPU, memory and the I/O devices and thus the challenge of performance isolation arise. Ideally, an application running inside one environment should not at all be affected from the activities of the other environments it shares hardware resources with. We quantify the extent of isolation provided by the two popular virtualization systems Xen and Linux containers (LXC) by performing a series of experiments on CPU, memory, network card and the block I/O. Findings:

Motivation: Source code size reduction for embedded systems due to the lack of memory resources.
​Procedural Abstraction: Code is searched for matching sequences and those sequences are then replaced by a single procedure resulting in lower program size.
Additional Compression: We observed that there is an opportunity for further compression by identifying the sequence of instructions that matches only partially (in the opcode part). We proposed a new compression algorithm to seek for repeating sequences of opcodes in the code section. Since the probability of finding a matching sequence of opcode is greater, it is possible to find sequences that are frequent and large in size. The repeating sequences are replaced by a marker instruction and are divided into the opcode and non-opcode parts. The code size reduction is obtained by saving only one copy of the opcode part of the repeating sequence and discarding others.
Opportunity: When tested on multiple small ARMv6 programs, we found out that there is an opportunity for compression in the range of 3-5%.
Roadblock: An implementation of the decompression algorithm on the hardware was proposed that required changes to the ARMv6 instruction pipeline. However, maintaining clock sync to correctly generate instructions from the subparts and stalling new instructions until the decompression completes were the biggest setbacks to the implementation