Compilation and Automatic Optimization of Network Protocol Implementations
Grant Status
1 Sept 1998

Compiling Web Servers for Faster Web Access

PI: George Varghese
Graduate Student: Girish Chandranmenon

With the emergence of faster Web servers, faster modems and faster links, round-trip delays can dominate access latency for web traffic. We have invented a new technique called REFERENCE POINT CACHING, in which a server tells its client that it has cached pages referenced in a page the client just retrieved; this allows the client to retrieve the pages from its current connection, instead of creating a new connection to the referenced point. If the server does not have a cached copy, it sends the IP ADDRESS of the host in the URL, saving the client the need to do a DNS query. Reference point caching broadens the scope of HTTP caching to allow regional server caches specialized by topic, and allows search engines to return IP addresses along with the result of a query.

Our analyses based on web traces from Boston University show that 17.8 percent of user clicks on remote sites result in DNS lookups, and these can be avoided using REFERENCE POINT CACHING of IP ADDRESSES. Although the average DNS lookup time for a set of site names collected from the yahoo site was 835ms, many remote sites result in lookup times of the order of seconds. We are also collecting search traces from individual users, to show that the set of IP addresses followed during a search session are unlikely to be cached in the local DNS server since they are likely to be random.

Our simulated experiments using a set of Yahoo pages on travel resorts show that using a local server and reference point caching of pages, we could reduce the access latency by 72 percent. We are also setting up a local Newspaper server that will prefetch the newspapers registered by its users. Using this server, we intend to show the feasibility and usefulness of setting up regional servers. In order to build this server, we have written a web robot that periodically fetches series of pages from remote sites and a web compiler that selectively rewrites the references in the pages to refer to their local copy. We are also conducting experiments over a modem line to measure the benefits that home users will experience from these techniques.

This web system and associated ideas constitute roughly one half of Girish's thesis. A paper with these ideas (without the latest measurements) was submitted to SIGCOMM 98, but rejected (though it had favorable reviews) with the suggestion to add more extensive performance tests. Girish is currently working on additional measurements and completing the system.

Automatic packet filtering

Efficient Network Packet Filters Using
Tomita Parsers
Dan Rosenstein

The point of our research was to create an efficient network packet filter that is easily extensiable. Since work was done to show that context free grammars could be joined together quickly without hurting parsing proformance, we decided to experiment and see if grammars could be used for packet filtering. They of course can. The problem with using grammars for packet filtering is that they can not utilize predetermined knowledge of what they are parsing to improve preformance. For instance if you had a firewall grammar specification, and you knew that the first 128 bits were unimportant, a hand coded solution could skip these bits and parse only the bits after the first 128. A grammar based solution could not. At least until now.

We have developed a method for analyzing a grammar and determining what parts of that grammar are skipabable. A grammar is composed of production rules, a start symbol, non terminals and terminals. By determining which non terminals are skipable, we can determine which parts of the grammar we do not need to parse.

A non terminal is defined as skipable if the first k terminals that the non terminal derives are exactly equivilent to the cross product of the alphabet for k length. An example:

S --> A B
A --> 0 
    | 1
B --> 1
    | 0
in this grammar A is determined as skipable since it derives all of the alphabet. B is skipable also. to be precise A and B are 1 skipable. S therefor, S is determined as 2 skipable, since it can derive all of the strings of length 2 from the alphabet 0 and 1.

To determine the k that a non terminal is skipable by we used the classic first calculation. The problem with this calculation is that to determine first-1 sets we would need to calculate these sets, and then to determine the first 2 set we would need to calculate the first 1 set again and then the first 2 set, and so on.

We felt as though this was redundant (not to mention slow and costly), and so in order to achieve our ultimate goal we set off to develop an INCREMENTAL FIRST K calculation.

This is basicly the same as a standard first-k calculation, except now you save what has been computed as you recurse. for a given value of k it returns the first K of a non terminal, and it takes in the first K-1 for that non terminal.

Armed with an incremental first calculation we were able to determine what non terminals in a grammar were skipable, and by how much. We then proceeded to create an LR(1) parser, and when that was done we added a new action to the typical SHIFT, REDUCE, ACCEPT, ERROR parser which we called a SKIP action. Since we knew that a non terminal derived k terminals that could be skipped, we set up the parser to just end up in the state it would have of ended in if it had to SHIFT and REDUCE those values.

Once this was working we set out to Make a tomita parser that could handle non deterministic grammars. We did this because our ultimate goal was to create an efficient network packet filter, and the packet specifications could indeed be non deterministic.

We finaly added skipping to the Tomita parser in the same manner we added it to the LR(1) parser.

what we have now is a skipping tomita parser that can do a non deterministic parse of a specified grammar, and signal wether any, some or all the parses accepted.

What is left to be done (and what I am trying to currently do) is make only one pass over the input stream.

When our parser will be able to do this we will have a better network packet filter then what currently exists that runs faster, passes over the input only once, and is extensable quickly.

Optimizing High-performance, Real-time ORB Middleware

Doug has worked with student Andy Gokhale optimizing the efficiency and predictability of a high-performance, real-time Object Request Broker (ORB) called TAO. TAO is a real-time ORB endsystem designed to meet end-to-end application quality of service (QoS) requirements by vertically integrating CORBA middleware with OS I/O subsystems, communication protocols, and network interfaces. It is the first real-time ORB endsystem to support end-to-end QoS guarantees over ATM networks.

The goals of our research on TAO include the following:

  1. Identify the enhancements required to standard ORB specifications (such as OMG CORBA) that will enable applications to specify their QoS requirements to ORB endsystems.

  2. Empirically determine the features required to build real-time ORB endsystems that can enforce deterministic and statistical end-to-end QoS guarantees required by applications.

  3. Combine the strategies for real-time I/O subsystem architectures and optimizations with ORBs to provide vertically integrated ORB endsystems that support end-to-end bandwidth, latency, and reliability QoS guarantees.

  4. Capture and document the key software patterns necessary to develop extensible ORBs.

Since our previous grant status report, our work on the NSF grant has provided the following research contributions to the TAO project:

During the fall of '98, we are adding new optimizations to TAO's IDL compiler. These optimizations will use advanced compiler techniques to generate both (1) highly efficient compiled stubs and skeletons and (2) hybrid compiled/interpreted stubs and skeletons that permit fine-grained time/space tradeoffs. We plan to have results of these optimizations by the end of 1998.

Prepared by Ron Cytron, cytron@cs.wustl.edu
Prepared 9/98, Last Modified 9/98.