Packet Classi cation using Tuple Space Search V. Srinivasan  S. Suri Abstract Routers must perform packet classi cation at high speeds to eciently implement functions such as rewalls and QoS routing. Packet classi cation requires matching each packet against a database of lters (or rules), and forwarding the packet according to the highest priority lter. Existing lter schemes with fast lookup time do not scale to large lter databases. Other more scalable schemes work for 2-dimensional lters, but their lookup times degrade quickly with each additional dimension. While there exist good hardware solutions, our new schemes are geared towards software implementation. We introduce a generic packet classi cation algorithm, called Tuple Space Search (TSS). Because real databases typically use only a small number of distinct eld lengths, by mapping lters to tuples even a simple linear search of the tuple space can provide signi cant speedup over naive linear search over the lters. Each tuple is maintained as a hash table that can be searched in one memory access. Building on this idea, we introduce several techniques for further re ning the search of the tuple space, and demonstrate their e ectiveness on some industrial rewall databases. For example, a real database of 278 lters had a tuple space of 41 which our algorithm prunes to 11 tuples. Our experiments show (using a random two-dimensional lter generation model) that as we increase the lter database size from 1K to 100K, the size of the tuple space grows from 53 to only 186, and the pruned tuples only grow from 1 to 4. Our Pruned Tuple Space search is also the only scheme known to us that allows fast updates and fast search times.  Computer Science Department, Washington University, St. Louis. Research supported in part by NSF Grant NCR-9628145. y Computer Science Department, Washington University, St. Louis. Research supported in part by NSF Grant 9813723 z Computer Science Department, Washington University, St. Louis. Research supported in part by NSF Grant NCR 9813723. y G. Varghese z We also show a lower bound on the general tuple space search problem, and describe an optimal algorithm, called Rectangle Search, for two-dimensional lters. 1 Introduction As the Internet begins to be used for commercial applications, service providers would like routers to provide \service di erentiation". Traditional routers do not provide service di erentiation because they treat all trac going to the same Internet destination address identically. Routers with a packet classi cation [8, 13] capability, however, can distinguish trac based on destination, source, and application type. Such classi cation allows various forms of service di erentiation: blocking trac sent by insecure sites ( rewalls), preferential treatment for premium trac (resource reservation), and routing based on trac type and source (QoS routing). While more general applications like resource reservation [2]) and QoS routing are likely to be part of future routers, many routers today implement rewalls [3] at trust boundaries, such as the entry and exit points of a corporate network. A rewall database consists of a series of packet lters (or rules based on packet header elds) that implement security policies. Despite the progress made in the last year on solutions to the packet classi cation problem [8, 13], existing rewall software is still slow. While the general solution in [8] can handle thousands of lters at very high speeds, it is geared towards hardware and uses hardware parallelism and high speed memories. The solutions in [13] have a high worst case gure for the general packet lter problem. Thus there is room for further research especially in the area of software packet classi cation. Existing solutions are also optimized for the case when updates are infrequent. However, many rewall vendors now o er stateful lters [4]. For example, the sending of a UDP request may trigger the addition of a lter addition that allows the response to ow past the rewall. This may require lter insertion in the order of microseconds. Other applications that may require fast lter updates include resource reservation protocols like RSVP [2]. Thus faster software packet classi cation with fast update times can bene t screening routers and many commercial rewall software packages. It can also be useful for other applications of packet classi cation implemented in say endnodes, which are unlikely to use FPGA or ASIC based solutions. A general lter consists of arbitrary pre x or range speci cations on the destination, source, protocol, port number and possibly other elds. There is evidence that the general lter problem is a hard problem [8, 13] and requires either memory of N K or time of O(N ), where N is the number of lters and K is the number of dimensions. We con rm this growing body of evidence in our paper with some new lower bounds in a hashing model, which complement the earlier lower bounds on multidimensional range matching quoted in [8, 13]. The lower bounds indicate that to do better one has to exploit the semantics of actual databases. Since rewall databases are commonly used, we decided to examine actual rewall databases to see if there were some regularities we could exploit. On examination we found that there were only a few combinations of eld lengths used in rewall lters. Intuitively, this follows because most address pre xes are based on Class C (24 bit) and Class B (16 bits) pre xes. Similarly port elds are typically either fully speci ed port numbers (e.g., port 23), the wildcard range (*), or the single range (> 1024 or  1023).1 This motivated us to examine what we call Tuple Search. In its simplest form, Tuple Search examines the space of tuples in a lter database, where a tuple is a combination of eld lengths. Each check for a tuple can be eciently done by hashing. Next, we develop some additional heuristics for speeding up Tuple Search, and use them to construct ecient and practical implementations, some of which have fast update times. We also develop the theory behind Tuple Search. We show that the general lter case is indeed hard in the Tuple Search paradigm as well, con rming the intuition in [8, 13]. For the special case of two-dimensional lters, we describe an optimal Tuple Search scheme called Rectangle Search, whose performance is comparable to the two-dimensional algorithms presented in [8, 13]. This paper is organized as follows. We provide background on rewalls in Section 2, and formally describe the packet classi cation problem in Section 3. We survey related work in Section 4. We start our discussion of tuple space search in Section 5 with the simplest tuple search. In Section 6, we describe a simple heuristic variant of the basic tuple search called Tuple Pruning , that has fast search and update times. While Tuple Pruning appears to be our most practical algorithm (based on our experience with real databases), its worst case case search time for arbitrary databases can be bad. In Section 7, we show how to improve the worst case search time of tuple search using markers and precomputation. In Section 8, we also describe an optimal algorithm for 2-dimensional lters. Next, we describe lower bounds on the general tuple search problem in Section 9. 1 Because BSD UNIX reserves ports 0 to 1023 for local use only by root, these ports are only used by servers, not clients. Other operating systems have followed this custom. This allows packets sent by servers to be distinguished from packets sent by clients. Filters for X servers are another non-trivial example of a port range (e.g., 60000-61000) but these are less common. In Section 10 we describe another balancing heuristic for computing a good probe sequence for general tuple spaces while exploiting markers and precomputation. We conclude in Section 11. 2 A Brief Introduction to Firewalls While the techniques in our paper are applicable to any application that requires packet classi cation, we provide some background on rewalls. Firewalls provide a concrete application of packet classi cation where fast software implementations are currently desired. Firewalls are implemented using various combinations of two basic techniques [4]: packet ltering and application level gateways (also known as proxy services). In packet ltering, a so-called screening router (also known as a choke router) sits between the external and internal worlds, and allows or blocks certain types of packets. Unlike conventional routers, screening routers make their decision based on Layer 3 headers as well as Layer 4 and even application headers. For example, this exibility allows a screening router to block Telnet (by blocking packets sent to TCP port 23) or to disallow incoming TCP connections from some ports (by inspecting TCP ags). Application level gateways are specialized server programs that run on rewall hosts that take user requests (e.g., for Telnet and FTP) and forward them according to the site policy. An advantage of proxy services is that they are specialized for each service and can thus implement more sophisticated policies than a screening router by itself. For example, an FTP proxy can allow some users to import les only from some sites. Because they understand the protocol, Proxy Services can also provide more intelligent logging (useful to detect the onset of an attack). On the other hand, one has to construct a proxy service for each possible service one supports and keep it current as implementations change; proxy services usually require some modi cations to clients and servers; and proxies don't work with all services [4]. Further, proxy services are only e ective with one or more screening routers that restrict communication with the host that implements the proxy service. Thus in practice, various combinations of the two techniques are used. For example, Telnet and SMTP are handled well using packet ltering. Web services seem best handled using proxies [4] because web proxies are easily available and can improve performance by caching. Passive mode FTP can be handled using packet ltering, but normal model FTP can use port numbers higher than 1023, which can allow access to other services. Thus normal mode FTP is often handled using a proxy. The most important point to gather from our brief introduction to rewalls is that software packet ltering routers are an important part of real rewall con gurations today. There are clearly other important components such as proxy and logging services, but packet ltering is important by itself. Our paper is about improving the performance of software packet classi cation and allowing fast updates. This in turn can allow fast software implementations of screening routers, but can also be used for other packet classi cation applications such as resource reservation. 3 Problem Statement Suppose there are K header elds in each packet that are relevant to ltering. Then, each lter F is a K tuple (F [1], F [2], : : :, F [k]), where each F [i] is either a variable length pre x bit string or a range. The most common elds are the IP destination address (32 bits), IP source address (32 bits), protocol type (8 bits), and port numbers (16 bits) of destination and source applications, and protocol ags. Since the number of distinct protocol ags, such as TCP ack, are limited, we can combine them into the protocol eld itself. (TCP ags are important for packet ltering because the rst packet in a connection does not have the ACK bit set while the others do; this allows a simple lter to block TCP connections initiated from the outside while allowing responses to internally initiated connections.) The lter F = (128:112:; ; TCP; 23; ), as an example, speci es a rule for trac ow addressed to subnet 128:112 using TCP destination port 23, which is used for incoming Telnet; a rewall database may disallow Telnet into its network. A lter database consists of N lters F1 ; F2 ; : : : ; FN . Each lter F is an array of K distinct elds, where F [i] is a speci cation on the i-th eld. We often refer to the i-th eld as the i-th dimension. Each eld i in a lter is allowed three kinds of matches: exact, pre x, and range. Each lter Fj has an associated directive: for example, rewall database could specify whether to accept or block a packet. Each lter also has an associated cost; in rewall databases, lters are linearly ranked, and the position of a lter is used as its cost. We say that a packet P matches lter F if for all packet elds i, P [i] matches F [i]. The packet classi cation problem is to nd the lowest cost lter matching a given packet P . While our examples only use simple elds in the IP and TCP headers, so called \third-generation" ltering products [4] are emerging that can use application header elds, and also other parameters such as the input link and time-of-day. We note that our techniques apply to the use of other elds as well. For the particular case of lters that depend on the input link (useful for preventing forged source addresses), the simplest technique is to use a separate database per input link. While the cost of inserting a rule may seem less important than search, this is not true for dynamic or stateful packet lters. This capability is useful, for example, for handling UDP trac. Because UDP headers do not contain an ACK bit that can be used to determine whether a packet is the bellwether packet of a connection, the screening router cannot tell the di erence between the rst packet sent from the outside to an internal server (which it may want to block) and a response sent to a UDP request to an internal client (which it may want to pass). The solution used in some products is to have the outgoing request packet dynamically trigger the insertion of a lter (that has addresses and ports that match the request) that allows the inbound response to be passed. This requires very fast update times. 4 Related Work For several years, packet lters have been used for demultiplexing of incoming packets directly to user processes [10, 1, 6]. The rst packet ltering scheme (to our knowledge) that avoids a linear search through the set of lters is PathFinder [1]. However, PathFinder only allows lters that have wild card elds at the end of the lter (for instance, (D; S; ; ; ) is allowed, but not (D; ; P rot; ; SrcP ort)). For such a restricted case, all lters can be merged into a generalized trie (with hash tables replacing array nodes) and lter lookup can be done in time proportional to the number of packet elds. DPF [6] uses the PathFinder idea of merging lters into a trie but adds the idea of using dynamic code generation for extra performance. However, it is unclear how to handle intermixed wildcards and speci ed elds, such as (D; ; P rot; ; SrcP ort), using these schemes. Because our problem allows more general lters, the PathFinder idea of using a trie does not work. There does exist a simple trie scheme to perform a lookup in time O(K ), where K is the number of packet elds. The basic idea is to consider a trie as a deterministic state machine and to realize that a general lter can be recognized by a non-deterministic automaton (NDA). Such a NDA can be converted to a trie but with an exponential blowup in the storage cost. Such schemes are described (using DAGs instead of trees) in [5, 9]. To the best of our knowledge, such schemes require (N K ) storage where K is the number of packet elds and N is the number of lters. Thus such schemes are not scalable for large databases. By contrast, our new schemes require only O (N K ) storage. Another simple way to solve the lter problem is to do a linear search of the set of lters against a header and then to cache the result of the search keyed against the whole header. There are two problems with this scheme. First, the cache hit rate of full IP addresses in the backbones is typically at most 80-90 percent [12, 11]. The poor cache hit rate is caused in part by web trac, where each ow consists of just a few packets; if a web session sends just 5 packets to the same address, then the cache hit rate is 80 percent. Since caching full headers takes a lot more memory, the cache hit rate should be even worse for the packet classi cation problem (for the same amount of cache memory). Second, Amdahl's Law shows that even with a 90 percent rate cache, a slow linear search of the lter space will result in poor performance. For example, suppose that a search of the cache costs 100 nsec (one memory access) and linear search of 10,000 lters costs 1000,000 nsec = 1 msec (one memory access per lter). Then the average search time with a cache hit rate of 90 percent is still 0.1 msec, which is rather slow. Linear Search and Caching: One of the solutions presented last year for the lter matching problem [13] decomposes the multidimensional problem into several 2-dimensional planes, and uses a data structure, grid-of-tries, to solve the 2-dimensional problem. This solution does not scale well as the number of required Grid-of-Tries and Crossproducting: planes increase. For practical rewall databases, it requires up to 8 planes, with each plane requiring upto 8 memory accesses. This results in a worst case of 64 memory accesses. Another limitation of this scheme is that it does not allow arbitrary ranges. A second solution in [13] is called crossproducting. In this scheme, a longest matching lookup or a range lookup is rst performed in each of the dimensions. The results are then concatenated to form a crossproduct, which is then mapped to a best matching lter. While crossproducting has good lookup times, it either requires O(N K ) memory or does not provide deterministic search time guarantees. Hardware solutions can potentially use parallelism to gain lookup speed. For exact matches, this is done using Content Addressable Memories (CAMs) in which every memory location, in parallel, compares the input key value to the contents of that memory location. This can be generalized if the CAMs allow certain eld positions to be masked out. However, it is dicult to manufacture CAMs with the width required to solve lter problems. Second, hardware solutions run the risk of being made obsolete, in a few years, by software technology running on faster processors and memory. A clever hardware approach is presented in [8]. While this scheme is optimized for hardware, it can work quite well in software for moderate sized databases. It involves reading a bitmap of size N bits for each of K dimensions. The scheme starts by computing the best matching prex (or closest enclosing range) for each dimension. With each such pre x (or range) P is associated an N bit vector BP . Bit i of BP is set if P is compatible with the i-th lter in the database. Finally, the intersection of the K bitmaps is computed, and the lter corresponding to the rst bit set in the intersection is returned as the result. If we consider 5-dimensional lters and N = 1000, this involves reading 5000 bits. With a cache line size of 32 bytes, this is only about 19 memory accesses to main memory. However, in its simplest form, the memory requirement for this scheme is O(N 2 ). Thus it does not scale well to large databases. The update times are also slow because of the potential need to update all bitmaps when a new lter is added. Some techniques presented in [8] allow these bitmaps to be compressed to O(N log N ), but these schemes involve reading N log N bits per dimension during search, instead of N . Hardware solutions: 5 Tuple Space Search Our scheme is motivated by the observation that while lter databases contain many di erent pre xes or ranges, the number of distinct pre x lengths tends to be small. Thus, the number of distinct combinations of pre x lengths is also small. This observation seems to be validated by our empirical study of some industrial rewall databases. We can de ne a tuple for each combination of eld length, and call the resulting set tuple space . Since each tuple has a known set of bits in each eld, by concatenating these bits in order we can create a hash key, which can then be used to map lters of that tuple into a hash table. Suppose we have a lter database FD with N lters, and these lters result in m distinct tuples. Since m tends to be much smaller than N in practice, even a linear search through the tuple set is likely to greatly outperform the linear search through the lter database. Starting with this simple observation, we then develop several optimizations that reduce the search cost further. With this motivation, we rst de ne the notion of tuple space more formally. 5.1 De ning Tuple Space Consider a lter database FD that contains N lters, each specifying K elds. We will call these K -dimensional lters. While our results are general, we will explicitly consider 5-dimensional lters in our examples and experiments, whose elds are IP source, IP destination, protocol type, source port number, and the destination port number. IP source and destination pre xes have at most 32 bits; the protocol is speci ed by 8 bits; and the port numbers are 16 bit addresses. A tuple T is vector of K lengths. Thus, for example, [8; 16; 8; 0; 16] is a 5-dimensional tuple, whose IP source eld is a 8-bit pre x, IP destination eld is a 16-bit pre x, and so on. We say that a lter F belongs or maps to tuple T if the ith eld of F is speci ed to exactly T [i] bits. For example, considering 2-dimensional lters, both F1 = (01; 111) and F2 = (11; 010) map to the tuple [2; 3]. Filters always specify IP source or destination addresses using pre xes, so the number of bits speci ed is clear. The port numbers, however, are often speci ed using ranges, and the number of bits speci ed is not clear. To get around this, we de ne the length of a port range to be its nesting level. For instance, the full port number range [0; 65535] has nesting level and length 0. The ranges [0; 1023] and [1024; 65535] are considered to be nesting level 1, and so on. If we had additional ranges [30000; 34000] and [31000; 32000], then the former will have nesting level 2 and the latter level 3. (We assume that port number ranges speci ed in a database are nonoverlapping.) While the nesting level of a range helps de ne the tuple (or hash table) it will be placed in, we also need a key to identify the lter within the hash table. To this end, we use a RangeId, which is a unique id given to each range in any particular nesting level. So the full range always has the id 0. The two ranges at depth 1, namely,  1023 and > 1024, receive the ids 0 and 1 respectively. Suppose we had ranges 200 : : : 333, 32000 : : : 34230 and 60000 : : : 65500 at level 2, then they would be given ids 0,1 and 2 respectively. With range ids, we can now map any 5-dimensional lter to a 5-dimensional tuple. To understand how the RangeId works, let us draw an analogy between pre xes and ranges. An address D can have some m pre xes P1 : : : Pm in the database that match it, such that Pi?1 is a pre x of Pi . In the case of a range match, each of these pre x lengths correspond to a nesting depth. Notice that a given port in a packet header can map to a di erent ID at each nesting level. For example, with the above ranges, a port number 33000 will map on to three RangeId values, one for each nesting depth: Id 0 for nesting depth 0, Id 1 for nesting depth 1, and Id 1 for nesting depth 2. Thus a port number eld in a packet header must be translated to its corresponding RangeId values before tuple search is performed. In summary, the nesting level is used to determine the tuple, and the RangeId for each nesting level is used to form the hash key. 5.2 Searching the Tuple Space All lters that map to a particular tuple have the same mask: some number of bits in the IP source and destination elds, either a wild card in the protocol eld or a speci c protocol id, and port number elds that contain either a wild card or a RangeId. Thus, we can concatenate the required number of bits from each lter to construct a hash key for that lter. We store all lters mapped to T in a hash table Hashtable(T ). A probe in a tuple T involves concatenating the required number of bits from the packet as speci ed by T (after converting port numbers to RangeIds), and then doing a hash in Hashtable(T ). Thus, given a packet P , we can linearly probe all the tuples in the tuple set, and determine the least cost lter matching P . While this is a very naive search strategy, the search cost is proportional to m, the number of distinct tuples. On the other hand, the current practice of performing a linear search through the lter database has cost N , which tends to be much larger than m. We ran tests on 4 industrial rewall databases which we refer to generically as Fwal-1 to Fwal-4. We found that while the number of lters ranged from 68 to 278, the number of tuples ranged from 15 to 41. The following table shows this empirical statistic. Database Size Fwal-1 Fwal-2 Fwal-3 Fwal-4 Dest Src Tuples Pre xes Pre xes 278 57 66 41 158 38 36 28 183 31 29 24 68 32 22 15 Table 1: Four Firewall databases. Thus, even without any additional improvements, tuple space search seems better than linear search. Furthermore, since each lter belongs to a unique tuple, the update cost (inserting or deleting a lter) is small; just one memory access for a hash, assuming a perfect hash function that is chosen to avoid hash collisions. 6 Tuple Pruning Algorithm We now describe our rst heuristic for improving tuple space search, which is not only very simple but also gives the best search and update performance of all our heuristics. The main motivation behind this new heuristic, called Tuple Pruning, is that in real lter databases there seem to be very few pre xes of a given address. For example, when we examined the Mae-East pre x database [7], we found that no address D has more than 6 matching pre xes. Suppose this were true. If we consider Destination-Source lters, then naive Tuple Search may require searching 32  32 = 1024 (possible combinations of pairs of lengths for the destination and source pre x lengths) tuples. However, if both destination and source pre xes are taken from Mae-East, then if we rst nd the longest destination match and the longest source match, there are only at most 6  6 = 36 possible tuples that are compatible with the individual destination and source matches. Thus we have reduced the number of tuples to be searched from 1024 to 36 at the cost of an extra destination and source pre x match. In essence, tuple pruning seeks to generalize this empirical observation to arbitrary lters by rst doing individual longest pre x (or range matches) in each dimension and then searching only the tuples that are compatible with the individual matches. Tuple pruning will bene t if the reduction in the tuple space a orded by pruning o sets the extra individual pre x (or range) matches on each eld. In some sense, this is similar to the Lucent [8] scheme except for the following major di erence: while both schemes rst do independent matches in each dimension, the Lucent scheme searches through lters that are compatible with the individual matches while we search through tuples that are compatible with individual matches. Since, as we have said earlier, the number of tuples grows much slower than the number of tuples, we expect tuple pruning to scale better than the Lucent scheme. To set up Tuple Pruning, for each destination pre x D in the database, we compute a tuple list (or bitmap) containing the names of tuples that have a lter with destination equal to D or a pre x of D. Similarly, for each source address S in the database, we compute a list containing the names of tuples that have a lter with source equal to S or a pre x of S . We can do this for the protocol and port number elds as well, but our implementation results seem to indicate that (at least for the databases we had) the results do not improve much by using additional elds. For instance, suppose D = 1010. Suppose all the lters whose destination is a pre x of D belong to tuples [1; 4], [1; 1], and [2; 3]. Then, the tuple list of D contains these 3 tuples. Similarly suppose S = 0010. Suppose all the lters whose source is a pre x of S belong to tuples [2; 4], [1; 1], and [2; 5]. Now, our search algorithm works as follows. Given a packet header P , we rst compute the longest matching pre x PD of the destination address P [1], and the longest matching pre x PS of the source address P [2]. We now take the tuples lists stored with PD and SD, and nd their common intersection. For instance, if PD = D and PS = S in the above example, the intersection list only includes tuple [1; 1]. We now probe the tuples in this intersected list. The update algorithm is also quite simple. First, we re ne our description of the search process to describe how the the tuple list associated with a pre x D is computed. Rather than store the tuple list of D and all its pre xes with D, we store only the tuples associated with D. We can obtain the tuple lists associated with pre xes of D if we do a trie search for D because such a search must necessarily encounter all the pre xes of D. When a new lter is added into the database, we add its destination and source pre xes (say D and S ) to the destination and source tries. Next, for each pre x we add (for example D), we maintain an augmented list of tuples corresponding to lters that contain D. The augmented list is a list of tuples (as before) but each tuple T also contains a reference count of the number of distinct lters that have destination D and map to T . The reference count is useful for deletion of lters which decrements the reference count in an analogous way. When the reference count reaches zero, the corresponding tuple is removed from the tuple list of the associated pre x. Note that the augmented tuple lists containing counts need not be part of the search data structure but must be maintained by the update process. Thus the update time requires 2 best matching pre x operations plus a constant time to update the augmented tuple lists for each of three elds. Table 2 shows the e ect of Tuple Space Pruning on our rewall databases. We calculated the size of the worst case set of pruned tuples for all possible combinations of source, destination, and protocol matches. This pruned size is shown in the Pruned Tuples column. Note that this simple heuristic prunes the tuple space by a factor of at least three. We tried pruning on port elds as well, but found that we did not get better numbers. However, when we used the two port elds instead of the address elds for pruning, we obtained similar results. Thus for the small databases we examined pruning based either on destination and source addresses or destination and source ports produced the best results. However, for larger databases, we expect that pruning on all elds will be bene cial. Database Fwal-1 Fwal-2 Fwal-3 Fwal-4 Size Tuples Pruned Tuples 278 41 11 158 28 6 183 24 7 68 15 5 Table 2: The worst-case number of hash probes produced by the Pruned Tuple Search Method. 6.1 Experiments with random lters We believe that as the lter database grows larger the additive cost of doing a separate best matching pre x on the destination and source elds will remain a constant, but the relative gains of Pruned Tuple search will remain. Since there does not seem to be any publicly available large lter database, we experimented by creating random lters to see how well the tuple pruning algorithm scales. We generated N source-destination lters, where the source and the destination pre x of each lter was chosen uniformly at random from the MaeEast database [7]. We tried pruning on the destination eld, the source eld, and then on both the elds. We present our experimental results in Table 3. When the number of lters is large (> 10000), we could not strictly test the worst case pruned tuple size for all possible crossproducts. Thus for those two cases, we did a statistical sampling test by considering a million randomly chosen crossproducts, and nding the worst case size of the pruned tuples across all the random samples. Size Tuples 1000 5000 10000 50000 100000 53 92 104 151 186 DestSrcBothPruned Pruned Pruned 1 1 1 2 2 2 3 3 2 4 6 3 6 8 4 Table 3: Number of tuples found in a randomly generated lter database, and the e ect of pruning. Pre xes were randomly chosen from the MaeEast database. While this test does not in any way guarantee that Tuple Pruning will scale as well for large databases in practice, reducing the tuple space from say 104 (naive tuple search) to 2 (pruned tuple) at the cost of say 8 more memory accesses, does suggest good scaling behavior. More importantly, the Pruned Tuple Search algorithm has a very fast update time unlike the Balancing Heuristic algorithm we describe later (and all the other techniques in the literature). Thus Pruned Tuple Search is the only scheme we know of that provides fast search times and yet can be used for applications like Stateful Packet lters and RSVP lters. 7 Improved Tuple Space Search via Precomputation Naive Tuple search can have a large search time; pruned tuple search can improve the search time dramatically but it depends on assumptions on the structure of existing databases. Can we improve the performance of tuple search and provide some worst case guarantees without making such assumptions? The remainder of this paper is devoted to answering this question. In essence, our results will show that we can do fairly well for the case of two dimensional lters by using precomputation (which increases lter update time), but the worst case improvement is only marginal for the general lter problem. The ideas described below can be considered to be a generalization of the ideas in [14] for nding longest matching pre x. For example, simple tuple space search will take O(W ) time for nding the longest matching pre x of a W length destination address eld, but the techniques of markers and precomputation can be used to reduce the search time to O(log W ) at the cost of slower insertion times [14]. We will show that for twodimensional lters we can reduce the search time from W 2 memory accesses to 2W accesses using similar techniques. We will also describe lower bounds to show that this algorithm is optimal. We now consider such strategies for reducing the search space. The main idea is that a probe into a tuple Ti can be used to eliminate a subset of the tuple space. In particular, if a probe succeeds, then we can eliminate all the tuples that are coordinate-wise shorter than Ti , because we can precompute the best matching lter from those tuples and store the answers with lters in Ti . Similarly, if a probe fails in Ti , then we can eliminate all the tuples that are coordinate-wise longer than Ti , because each lter in those tuples can leave a marker lter in Ti . This is a time-space tradeo , because markers require additional memory, but the search cost can be reduced. We now describe the marker and precomputation ideas in more detail. 7.1 Markers and Precomputation Consider a tuple Ti = [l1 ; l2 ; : : : ; lK ]. We can partition the remaining tuple space into 3 disjoint parts, Short(Ti ), Long (Ti ) and I C (Ti ) (where IC stands for incomparable). The set Short(Ti ) contains all those tuples whose length vector is coordinate-wise shorter than Ti . That is, a tuple Tj = [h1 ; h2 ; : : : ; hK ] belongs to set Short(Ti ) if and only if hi  li , for all i = 1; 2; : : : ; K , and Tj 6= Ti . Similarly, Long(Ti ) contains all those tuples whose length vector is coordinate-wise longer than Ti . Speci cally, a tuple Tj = [h1 ; h2 ; : : : ; hK ] belongs to set Long(Ti ) if and only if hi  li , for all i = 1; 2; : : : ; K , and Tj 6= Ti . A tuple Tj , where Tj 6= Ti , that is neither in Short(Ti ) nor in Long(Ti ) belongs to the incomparable set I C (Ti ). Figure 1 shows this partitioning of the tuple space into the three sets. As an example, consider the tuple T = [2; 3; 2]. Then tuple [1; 1; 1] belongs to Short(T ); the tuple [5; 3; 3] belongs to Long(T ); and tuple [1; 4; 1] belongs to I C (T ). Fail (Ti) Short (Ti) vector for T . Since each lter in Long(T ) has at least li bits speci ed in eld i, this is possible. (As an example, a lter F = (1010; 110) of tuple [4; 3] leaves the marker F = (10; 11) in the tuple [2; 2].) Now, if we probe T and do not get a match, we can easily eliminate the set Long (T )|if any lter in that set matched the packet header, its marker entry in T would have produced a match. Thus, when the probe in T fails, we can restrict our search to the tuples in I C (T ) and Short(T ). Their union is the set F ail(T ) illustrated in Figure 1. While this general strategy seems promising, we need to nd a speci c instantiation of the strategy (which would specify the sequence of tuples to be probed) that can provide an improvement in the worst-case. We start by showing a speci c search strategy that works well for the two-dimensional case. Later we show some lower bound results that shed some light on the diculty of the general problem. Finally, we return to the general problem and show a heuristic search strategy that attempts to compute an optimal probe sequence for a given lter database, using precomputation and markers. 0 8 Rectangle Search: An Optimal Algorithm for 2-D Filters One can argue that two-dimensional lters (especially, destination-source lters) are interesting in their own right for multicast forwarding or virtual private networks (VPNs) [8]. A very simple application of a two dimensional lter database (suggested by Jon Turner) is a network monitor that computes trac statistics between all source and destination subnetworks. In this section, we will restrict ourselves to two dimensional lters. Filters 0 Tuple Set IC (Ti) 1 Z1 F = 101*, 1110* Z = 1*, 1* Z 2 Probe Tuple Ti Long (Ti) Succ (Ti) 3 4 5 Figure 1: Figure showing the three sets obtained when a probe is done at tuple Ti . The three sets are mutually exclusive and every tuple other than Ti falls into one of the three sets. The sets F ail(Ti ) and Succ(Ti ) are de ned later. Since each tuple in Short(T ) is less speci c than T on all elds, it is possible to precompute the best matching lter information for the set Short(T ) and store it with the lters in T . Speci cally, let F be a lter in T . We can precompute the best lter matching F in the set of lters than belong to Short(T ). Thus, if we get a match with lter F during the probe in T , we no longer need to search Short(T ). In other words, if the probe at T returns a match, we can restrict our search to the tuples in I C (T ) and Long(T ). Their union is the set Succ(T ) illustrated in Figure 1. Similarly, we have each lter F in Long(T ) leave a marker, which is the lter obtained by using only li bits of the ith eld of F , where [l1 ; l2 ; : : : ; lK ] is the length Markers F1 F2 F3 F4 F F4 F3 F2 F1 Z1 101*, 111* 101*, 11* 101*, 1* 101*, * 1*, * Figure 2: Illustration of markers and precomputation. Several ecient packet classi cation algorithms exist for the two-dimensional problem, such as range matching based on fractional cascading [8] or grid-of-tries for pre x matching [13]. Is there a similar ecient algorithm for the 2D case in the tuple space model? We show below that the answer is yes. We give a simple algorithm than computes the best matching lter in a W  W tuple space using 2W ? 1 probes, which is optimal in view of a lower bound we show later. The algorithm uses markers and precomputation to eliminate subsets of the tuple space after each probe. We call this algorithm Rectangle Search, and it uses a di erent marker and probing strategy than the heuristics of Section 7.1. We now describe the algorithm. A lter leaves a marker at all the tuples to its left in its row. So, a lter F that belongs in tuple [i; j ] leaves a marker in tuples [i; j ?1]; [i; j ?2]; : : : ; [i; 1]. Each lter (or marker) also precomputes the least cost lter matching it from among the tuples above it in its column. That is, a lter (or marker) in tuple [i; j ] precomputes the least cost lter matching it from the tuples [i ? 1; j ]; [i ? 2; j ]; : : : ; [1; j ]. Figure 2 shows an example of precomputation and markers, using two lters F and Z . The marker F2 precomputes the best matching lter among the entries in the column above it, which in this example is Z . c+1 r T T’ c ch at M r T No Ma c tch r-1 T’ T O(N log N ) memory, since W  log N . We can tradeo memory for speed by using fewer markers. For a lter in column i, we can leave markers in every column to the left of i that is a multiple of some k, and in each column after the largest multiple of k smaller than i. This increases the required number of hashes in the worst case from 2W to 3W , pbut reduces the memory to O(NW=k). Choosing k = W gives us an O(W ) worst-case p algorithm for the 2-dimensional lters with O(N W )memory. Rectangle Search is designed for square tuple spaces. What can be done for non-square tuple spaces? If we have a R  C rectangular tuple space, then Rectangle Search gives a worst-case bound of R + C ? 1. However, notice that if R  C , then binary search in each row can achieve O(R log C ), which may be much better. We can extend our Rectangle Search with a new idea, called doubling search, which allows us to search a R  C tuples space in O(R log(C=R)) probes. We do not describe doubling search here for lack of space. The bound for doubling search nicely interpolates the optimal bounds at the two extremes: O(log W ) for the linear tuple space, and O(W ) for the square tuple space. In table 4 we compare several 2-dimensional lookup algorithms and their worst case search and memory complexities. Figure 3: If a probe in tuple T results in a match, then the entries in the column above T are eliminated; if the probe results in no match, then the entries in the row to the right of T are eliminated. In both cases, the next probe is done in tuple T . Scheme Memory Search Linear Search O(N ) O(N ) Binary search O(N ) O(W + log N ) Grid-of-tries O(NW O(W ) p ) O(W ) Rectangle Search O(N W ) Given these markers and precomputation, we can now describe a search strategy that outputs the best matching lter after 2W ?1 worst-case probes. We start by probing the lower-left tuple, namely, [W; 1]. At each tuple, if the probe returns a match, we move to the next tuple in the same row. If the search returns no match, we move up one row, in the same column. See Figure 3. When we get a match in a tuple, the matching lter's precomputed information makes searching the tuples above it in its column unnecessary, and so we can eliminate them from the search. This allows us to move to the next column. If we fail to get a match, the marker rule tells us that there is no lter to the right of the current tuple; because otherwise that lter's marker would have produced a match. In this case we can eliminate the tuples to the right of the current tuple, and move to the row above. Thus, each probe eliminates a row or a column. The search terminates when the we reach the rightmost column or the rst row. Since there are W rows and W columns, the number of probes needed is at most 2W ? 1. Table 4: Complexity of 2-dimensional lookup algorithms. 0 8.1 Time-Space Tradeo s and Generalized Rectangle Search Rectangle search requires O(NW ) memory, since each lter leaves at most W markers. This performance is comparable to other O(log N ) search algorithms using 9 Some Lower Bounds The preceding sections have described several algorithms for the best matching lter problem in the tuple space search paradigm. The attractiveness of our algorithms is based on the premise that the tuple space of practical databases is quite sparse. Several researchers have also investigated packet classi cation algorithms with good worst-case guarantees [8, 13]. Although some nice results are known for the two-dimensional lters, none of the known algorithms scale well to multi-dimensional lters. As the dimension increases, either the search time degrades quickly, or the memory requirement grows exponentially. In this section, we argue that the packet classi cation problem indeed su ers from the curse of dimensionality, and formally establish a lower bound on the number of hash probes needed to nd the lowest cost matching lter in the tuple space model. Let us rst consider the simple case of 2-dimensional (source-destination pair) lters. What is the best possible bound for searching the W  W tuple space? Is O(log W ) possible? We establish a lower bound showing that at least 2W ? 1 probes must be made in the worst case. In fact, we prove a more general result: if the tuple space has R rows and C columns, then roughly R log(1+ CR ) probes are necessary in the worst case, where C  R. This shows that our rectangle search algorithm is essentially optimal in the tuple search paradigm. We will use the \decision tree model" of computation for our lower bound argument. The decision tree model is an abstraction of branching programs, in which each internal node represents a decision, which has a binary outcome. (For instance, in sorting the node corresponds to a comparison test between two elements. In our case, the test involves checking whether the header of a packet matches any of the lters in a tuple, which takes one hashed memory access.) The algorithm starts by performing the test at the root of the decision tree. Based on the outcome, the program branches to one of the children, and continues until a leaf node is reached, at which point the algorithm produces its output. The execution of the algorithm on a speci c instance corresponds to a path in the decision tree from the root to some leaf. The worst-case running time of the algorithm, therefore, corresponds to the height of the decision tree. Showing a lower bound of L on a problem'sLcomplexity requires one to show that there are at least 2 \con gurations" of the input where no two con gurations correspond to the same leaf node in the decision tree. We show that the problem of searching a R  C tuple space, where C  R, has roughly ( CR+R )R distinct con gurations, which will lead to a (R log RC ) lower bound. Consider a xed packet header with say source address S and destination address D. Our argument establishes a lower bound for the search cost of any decision tree algorithm for this xed header (S; D) over all possible input instances, where the input is a set of lters. Given an instance of the lter database, imagine coloring all those tuples red that contain a lter matching the header (S; D). Starting from the lower-left corner, we can draw a unique leftmost staircase that contains all the red tuples on or above it. Figure 4 (i) illustrates this concept. In this manner, each instance of the lter database can be associated with a staircase. The key point is that, for each instance, none of the tuples below the staircase contain a lter matching the pair (S; D). We now show that if two instances of the lter database have distinct staircases, then the decision tree algorithm must follow di erent paths on these inputs. Indeed, suppose we have two instances corresponding to staircases Z1 and Z2 . Then, there is a tuple T that lies on or above one staircase but below the other. Without loss of generality, suppose T lies above Z1 , and below Z2 . (See Figure 4 (ii), where the staircase Z1 is shown in dashed lines.) Clearly, if the algorithm probes the tuple T during its course, then the search path for Z1 and Z2 would diverge at that node|since we get a match for Z1 and no match for Z2 . Thus, the search algorithm must not have probed T . A common decision path for Z1 and Z2 means that the algorithm probes the same set of tuples, makes the same branching decision at each node, and therefore outputs the same tuple as its answer. A simple consequence of this observation is that on this particular search path, the algorithm cannot output tuple T as the best matching lter tuple|since the search path is common to both T (i) (ii) Figure 4: (i) A staircase. The tuples that match the header (S; D) are shown with solid disks. The staircase is shown in thick lines. (ii) Shows two staircases. Tuple T lies above the staircase shown with dashed lines and below the one with solid lines. 1 or Z2 , the output tuple must be a red tuple for both. But then if we simply put the least cost lter in T for a Z1 instance, the algorithm's output will be incorrect. Thus, every staircase must correspond to a distinct leaf node in the decision tree. Next, we establish a lower bound on the number of distinct staircases. This requires a simple combinatorial argument. If we have a grid of dimensions R  C , where C  R  2, then the number of staircases connecting the leftmost and rightmost corner is at least Z  +R?1 R ?1 C  One simple way to see this is as follows: each staircase can be uniquely identi ed by the positions of the vertical (unit) steps. There are R ? 1 are vertical unit steps needed to go from bottom row to the top row. Now, we are ready to prove our lower bound. The worst-case search cost of the algorithm is at least as large as the height of the decision tree. If a binary tree has M leaves, it has height at least log 2 M . Thus, the height H of the decision tree has the following lower bound: H   +R?1 R ?1  C + R ? 1 R?1  log R ? 1    (R ? 1) log R C? 1 + 1  log = C   R C log 1 + R  : This completes our proof of the lower bound for the two-dimensional tuple space. While the technique presented above is quite general, it does not yield the best possible lower bounds. For instance, when the tuple space is a W  W square, the proof above gives a lower bound of about W ? 1, though it is possible to obtain a tighter bound of 2W ? 1 using an adversary based argument, which we now present. However, the staircase lower bound provides a bound for a rectangular tuple space. 9.1 An adversary-based lower bound Consider the following set of tuples: M = f(l ; l ) j l + l = W g: Since 0  l ; l  W , there are precisely W tuples in M , namely, (0; W ); (1; W ? 1); : : : ; (W; 0). These tuples in fact correspond to the diagonal entries of the square tuple space. Using the de nition of Section 7.1, the tuples of M are pairwise incomparable. That is, if T = (l ; l ) and T = (l ; l ), where l + l = l + l = W , then l < l implies l > l . Thus, probing one tuple does not yield information about the other|neither markers or precomputation help, since each tuple has a longer coordinate than the other. Similarly, we can de ne a second set of tuples M = f(l ; l ) j l + l = W + 1g; which corresponds to the tuples along the second diagonal of the tuple space. The set M has precisely W ? 1 tuples. See Figure 5 for illustration. 1 1 1 0 2 1 2 2 0 1 0 1 1 1 1 0 2 0 2 2 2 1 1 2 0 1 2 1 0 2 1 2 2 2 Second Diagonal Main Diagonal in it, and foil the algorithm. Thus, in order for the algorithm to correctly determine the least cost lter matching (S; D), at least 2W ? 1 probes must be made. Note that this argument cannot be extended to a third diagonal|probing a cell of the middle diagonal will either eliminate some entries on the diagonal above (if a match is found) or it would eliminate some entries on the lower diagonal (if no match is found). 9.2 Extension to multi-dimensional lters The adversary lower bound argument can be extended to k-dimensional lters, as follows. Consider the set of tuples M = f(l ; l ; : : : ; lk ) j l + l +


+ lk = W g: Clearly, the tuples in set M are pairwise incomparable| if T is shorter than T in some dimension, then T must be longer than T in some other dimension to keep the sum constant. Now, given a packet header (H ; H ; : : : ; Hk ), we can create a lter for tuple (l ; l ; : : : ; lk ) by taking the l -bit pre x of H , the l -bit pre x of H and so on. Each of these jM j lters match the packet, and since these lters are pairwise incomparable, an adversary can force the algorithm to search all jM j tuples in order to nd the least cost lter. So, how many tuples are in the set M ? An easy inductive proof shows that jM j  W (kk?1) . Thus, in the hashing model of tuple space search, packet classication among arbitrary lters requires at least W (kk?1) tuple probes in the worst case. 1 2 1 2 0 0 1 1 1 1 2 2 2 2 ! ! Figure 5: Adversary lower bound. Now, consider an arbitrary packet header (S; D). We create W lters, one per tuple of M . Speci cally, the lter F (i; j ) corresponding to the tuple (i; j ) is constructed by taking the i-bit pre x of S and j -bit pre x of D. For instance, assuming W = 3, S = 101, and D = 011, the lter for tuple (1; 2) is (1; 01). Each of these lters may be assigned an arbitrary cost. The adversary's strategy is as follows: if the algorithm probes a tuple in M , the adversary returns the matching lter; if the algorithm probes any other tuple, the adversary returns \no match." Notice that this strategy is consistent|the matches along the main diagonal only eliminate the upper triangular tuple space (precomputation), while the lack of matches along the second diagonal only eliminates the lower triangular tuple space (markers). We claim that any tuple space algorithm must probe at least 2W ? 1 tuples to correctly nd the best matching lter for the header (S; D). Clearly, the algorithm must probe the W tuples of M |otherwise, since we can arbitrarily choose the lter costs, the lter in the unprobed tuple can be made the cheapest lter, thus foiling the algorithm. The key observation here is that since the tuples of M are pairwise incomparable, probing one does not reveal any information about any other tuple in M . In addition to the tuples of M , the algorithm must also probe all tuples in M . The adversary returns \no match" on any tuple of M probed. But if the algorithm fails to probe a tuple, say, (i; j + 1), where i + j + 1 = W +1, then we can put a least cost lter matching (S; D ) 1 1 1 1 1 1 2 2 10 Applying Markers and Precomputation for General Tuple Search So far, we have introduced the notion of using markers and precomputation to improve worst case search time in tuple search (Section 7), we have shown an optimal two-dimensional algorithm (Section 8), and we have shown lower bounds showing that markers and precomputation cannot improve the worst case signi cantly for general lter databases (Section 9). However, just as Tuple Pruning (Section 6) can improve the performance of naive tuple search for speci c databases, the question still remains: can we nd an optimal search strategy using markers and precomputation for speci c databases. We already know how to do this for 2D databases, but this certainly does not apply to the real rewall databases Fwal-1 to Fwal-4 that we used earlier. We now address this question. 10.1 A Dynamic Programming Algorithm Before reading on, the reader may wish to review the general strategy in Section 7.1 and the terminology used there. Given a tuple space T S , we wish to determine the optimal sequence of probes for computing the best matching lter, using markers and precomputation to eliminate tuples after each probe. This essentially corresponds to constructing a decision tree in which each node is labeled with a probe, and the algorithm branches to one or the other subtree based on the probe outcome. Suppose we probe tuple Ti in the rst step; then a match in Ti results in searching the set Succ(Ti ), while a fail in Ti results in searching Fail(Ti ). The optimal cost of searching the tuple space TS can then be written recursively as follows: TS Opt(TS ) = 1 + min maxfOpt(Succ(Ti )); Opt(Fail(Ti ))g: i=1 j Tuple Set Short (Ti) IC (Ti) Long (Ti) j The recurrence is based on the fact that after the probe done in the rst step, one of the two tuple subsets, Succ(Ti ) or Fail(Ti ), needs to be solved optimally, and the best rst probe is the one that minimizes the maximum of the two costs. Unfortunately, since the subsets Succ(Ti ) and Fail(Ti ) are not disjoint, and can have signi cant overlap, computing Opt(TS ) takes exponential time in the worst case. Speci cally, in the worst-case, the recurrence for computing Opt(TS ) can be written as f (m) = 2mf (m ? 1) + m ; 2 where m is the number of tuples in the tuple space and m2 is the complexity of forming the sets Succ(Ti ) and Fail(Ti ). This gives f (m)  2m , which is exponential. 10.2 Tuple Search using a Balancing Heuristic Given the prohibitive complexity of computing Opt(TS ), we use some heuristic algorithms. Rather than computing Opt(Succ(Ti )) and Opt(Fail(Ti )) recursively, we simply use some estimates on their costs. One simple estimate is the number of tuples in the set. That is, as the rst probe we pick the tuple Ti that minimizes the larger of jSucc(Ti )j and jFail(Ti )j, and then recursively work on the sets Succ(Ti ) and Fail(Ti ) using the same heuristic. Unfortunately, even this heuristic ends up being exponential! Indeed, the recurrence for this heuristic is f (m) = 2f (m ? 1) + m2 , which is better than the previous one, but still leads to exponential time. The main diculty remains that the total size of the two subproblems, Succ(Ti ) and Fail(Ti ), is still large. In our nal heuristic, we treat the common elements of the two sets, namely, Succ(Ti ) \ Fail(Ti ), separately. In other words, when we choose a tuple Ti to probe, we divide the set into three parts as shown in Figure 6. We then use a simple balancing heuristic for the cost function: Cost(Ti ) = jIC (Ti )j + max fjShort(Ti )j; jLong(Ti )jg: The tuple Ti with smallest Cost is used as the rst probe. We then recursively solve the problem for the three subsets IC (Ti ), Short(Ti ) and Long(Ti ). This heuristic runs in polynomial time, and can be analyzed as follows. Initially, we start with m tuples. (See Figure 6.) After O(m2 ) computation, we decide the tuple that will be probed rst in the search sequence. This leaves us with m ? 1 tuples in the next level. We do O(m2 ) computation at each level to choose the tuples to be probed at the next level. The maximum number of levels is m, since we can choose each of the tuples only once. This gives us a total time complexity of O(m3 ). Figure 6: Each level has at most m tuples, and there are at most m levels. Processing each level takes O(m2 ) time, for a total of O(m3 ). 10.3 Implementation and Measurements We demonstrate the performance of our heuristic on the 4 industrial rewall databases shown in Table 1. In Table 5, we show for each of the rewall databases the worst-case number of probes, as found by the heuristic. Database Fwal-1 Fwal-2 Fwal-3 Fwal-4 Size Tuples Probes Time 278 41 23 0.4 158 28 17 0.3 183 24 14 0.2 68 15 10 0.1 Table 5: Number of probes is the worst-case search length found by the balancing heuristic. The time is the time needed by the heuristic in seconds to compute the probe decision tree. As the table shows, the heuristic seems to reduce the number of probes by about 40%. When comparing the results of Pruned Tuple Search (Table 2) to that of the Balancing Heuristic (Table 5), we may at rst conclude that the Balancing Heuristic is much worse (for example 23 tuples versus 11 for the largest database). However, we have not accounted for the cost of computing the best matching pre x on the Destination and Source elds in Pruned Tuple Search. Using good algorithms, this can add 4 hashes for Destination, 4 for Source, and 1 for Protocol. This would yield more comparable numbers. 11 Conclusion In this paper, we have presented a new packet classi cation algorithm that we call tuple space search. Simple tuple space algorithm searches through the eld length combinations found in the lter set. It is motivated by the observation that the number of tuples in real databases is much smaller than the number of lters. Our experimental results were limited by the moderately size databases we had access to, the largest of which had 278 lters and 41 tuples. However, we believe that even for very large lter database (say a million lters), the tuple space is unlikely to grow beyond a few hundred. This is because most databases use only a few pre x lengths corresponding to Class A, Class B, and Class C addresses and a small number of port ranges. Even if the total tuple space were to grow into the thousands (using 32 possible destination and source prex lengths), we argue that pruned tuple search will produce a much smaller set of pruned tuples. We have examined the Mae-East IP pre x database and have found that no pre x D has more than 6 pre xes that are prexes of D in the worst case. Thus even the number of D-S tuples is probably bounded by 36 instead of 3232 = 1024. Because our empirical evidence shows a substantial reduction in the pruned set of tuples, we expect this behavior to be valid for larger databases. Pruned Tuple Search is also the only scheme we know of that has fast update times. It seems appropriate for software rewall implementations that require dynamic updates. Despite the apparent utility of Pruned Tuple Search, Pruned Tuple search does not guarantee a good worst case search time for arbitrary databases. Thus we spent a signi cant portion of this paper investigating whether techniques based on precomputation and markers could improve the worst case search time of tuple space search at the cost of increased update times. As shown in [14], for the IP address lookup, which can be thought of as the one-dimensional packet classi cation problem, markers and precomputation improve the worst case search cost from W to log W . Our paper shows that similar techniques improve the search cost from W 2 to 2W ? 1 in the two-dimensional packet classi cation. Our lower bounds demonstrate that for K -dimensional lters, where K > 2, the search time is O(W K ?1 ). Thus there is a point of diminishing returns beyond two dimensions where the use of markers and precomputation does not improve worst-case search times signi cantly. While the lower bounds preclude the ability to nd an algorithm based on tuple search that has a fast search time on all databases, it does not preclude algorithms that work well on speci c databases. Thus to complete the investigation, we also examined a Balancing Heuristic for generalized tuple search based on markers and precomputation. Our experimental results for the Balancing Heuristic were not encouraging, and the Balancing Heuristic does not seem to scale as well to large databases as does the Tuple Pruning Heuristic. However, the Balancing Heuristic may outperform Tuple Pruning search if the tuple space becomes suciently dense to allow more tuples to be eliminated by precomputation and markers. Another alternative for a dense tuple space is to break up the space into multiple rectangles, and perform Rectangle search. While our paper has emphasized software implementation, we note that tuple pruning search has a simple parallel implementation where each tuple can be probed in parallel. Thus, in conclusion, we believe that tuple pruning search is simple and scalable, has fast update times and has a simple parallel implementation. Finally, rectangle search provides an optimal algorithm for twodimensional lters. Acknowledgement We thank Jonathan Turner for an observation that led us to the tuple pruning algorithm. Marcel Waldvogel in- dependently invented a specialized form of tuple search, called line search. We also thank Paul Vixie for providing us with rewall databases. References [1] M. L. Bailey, B. Gopal, M. Pagels, L. L. Peterson, and P. Sarkar. PATHFINDER: A patternbased packet classi er. Proc. of the First Symposium on Operating Systems Design and Implementation, 1994. [2] J. Boyle. Internet Draft: RSVP Extensions for CIDR aggregated data ows. Internic, 1997. [3] W. Cheswick and S. Bellovin. Firewalls and Internet Security. Addison-Wesley, 1995. [4] D.B. Chapman and E.D. Zwicky. Building Internet Firewalls. O-Reilly & Associates, Inc., 1995. [5] D. Decasper, Z. Dittia, G. Parulkar, and B. Plattner. Router Plugins: A Software Architecture for Next Generation Routers. Proc. of ACM Sigcomm, 1998. [6] D. Engler and M. F. Kaashoek. DPF: Fast, Flexible Message Demultiplexing using Dynamic Code Generation. Proc. of ACM Sigcomm, 1996. [7] Merit Inc. IPMA Statistics. http://nic.merit.edu/ipma. [8] T. V. Lakshman and D. Stidialis. High Speed Policy-based Packet Forwarding Using Ecient Multi-dimensional Range Matching. Proc. of ACM Sigcomm, 1998. [9] G. Malan and F. Jahanian. An Extensible Probe Architecture for Network Protocol Measurement. Proc. of ACM Sigcomm, 1998. [10] S. McCanne and V. Jacobson. The BSD packet lter: A new architecture for user-level packet capture. USENIX Technical Conference Proceedings, 1993. [11] P. Newman, G. Minshall, and L. Huston. IP Switching and Gigabit Routers. IEEE Communications Magazine, 1997. [12] C. Partridge. Locality and Route Caches. NSF Workshop on Internet Statistics Measurement and Analysis, 1996. [13] V. Srinivasan, G. Varghese, S. Suri, and M. Waldvogel. Fast Scalable Level Four Switching. Proc. of Sigcomm, 1998. [14] M. Waldvogel, G. Varghese, J. Turner, and B. Plattner. Scalable High Speed IP Routing Lookups. Proc. of Sigcomm, 1997.