WildMinnie: compression of software-defined networking (SDN) rules with wildcard patterns

Minnie limitations

It is not hard to conclude that Minnie fails to compress when there is only one flow for each pair of source and destination addresses. In this regard, Minnie is very traffic sensitive and has efficient compression when flows are initiated from limited sources or destined to a limited set of destinations.

Another serious limitation of Minnie is the inability to handle wildcard rules since it works based on exact equality of addresses and has no conflict resolution mechanism. As an example, consider a rule table shown in Fig. 2. In this rule table $p^{\ast }$ = 0, $p_{11\ast }^{\ast }=1$ and $p_{100\ast }^{\ast }=2$. Consequently, all rules with the output port of 0 are replaced with the default rule, and the other two groups are reduced to two rules. Now consider a packet with the source address of s = 11,100. This packet matches with (111 $\ast$, $\ast$, 0) rule in the uncompressed table, while in the compressed table matches with (11 $\ast$, $\ast$, 1, 1) rule. This happens because Minnie does not consider the conflict of rule spaces when addresses are in the wildcard form. According to this limitation, Minnie obligates using only non-wildcard, host addresses which means subnet addresses could not be used in rule tables, whereas using subnet addresses is very common, especially in the network core.

Our suggested solution is also based on the same grouping philosophy used in Minnie; however, instead of using exact values of addresses, we drive and use wildcard patterns for grouping, which helps put more rules in one group and get more compression ratio. Besides, using wildcard patterns makes compression performance noticeably independent of the traffic pattern.

OpenFlow wildcard rules

OpenFlow standard, like IPv4, allows expressing source and destination address of rules in the form of wildcards. Wildcard patterns make it possible defining of aggregate rules that match with several flows. In IPv4 standard (Fuller et al., 2008; Rekhter & Li, 1993), wildcard rules could only be in the prefix form (i.e. 0111 $\ast$). With this standard, we can define aggregate rules for flows with a common sequence of 0s and 1s at the start of their source or destination addresses. Usually, the length of the prefix is shown in pattern/len form, like 0111 $\ast$/4.

Wildcard definition in the OpenFlow Switch Specification ver. 1.4.1 (2015) is more general and allows wildcard bits to be defined in any number and anywhere in the address. For example, 011?101??0 $\ast$ pattern includes all addresses beginning with 011, then any 0 or 1 bits, followed by 101 bit sequence, then have two other wildcard bits lead to a 0 bit. ‘ ${}^{\ast }$’ indicates that the address’s remaining bits do not matter and can be any sequence of 0s and 1s. Naturally, more complicated patterns can be defined according to this scheme compared with prefix-only wildcards.

Generally, wildcard patterns may have rule conflicts or overlaps; that means it is possible an address matches with several wildcard patterns. Assuming 6-bit addresses for simplicity and having three rules: (110110, $\ast$, 6), (110100, $\ast$, 6) and (111100, $\ast$, 5), all three source addresses match with the wildcard pattern 11?1?0 while they have different output ports. When facing such conflicts, two questions should be addressed: which rules are the best set to be aggregated using the specified wildcard pattern, and how to place the other rules in the table to preserve the original forwarding policy.

For the first issue, we use the strategy of Minnie. The matching rules with the output port having the highest count are aggregated by the wildcard pattern to gain the best compression ratio.

The precedence of rules solves the second issue. In legacy IPv4 routers, the precedence of rules is determined implicitly by the Longest Prefix Matching (LPM) law. According to the LPM, if a packet matches several wildcard patterns, it will be forwarded using the rule that has the longest prefix. In the OpenFlow standard, it is possible to assign a 16-bit precedence value for each rule. Although OpenFlow does not explicitly specify any precedence assignment mechanism, it is possible to implement almost any precedence assignment system in the network controller. For instance, to have an LPM mechanism, it is sufficient to assign the precedence of rules according to the length of their source or destination wildcard prefix. The condition in which a packet matches several rules with the same precedence but different output ports is undefined in OpenFlow specification.

According to these explanations, we can compress the three example rules as: (110100, $\ast$, 5, 2) and (11?1?0, $\ast$, 6, 1). The more specific the address pattern, the higher the precedence. Thus, it is forwarded with the highest precedence rule (110100, $\ast$, 5, 2) rule when a packet matches both rules.

Using general wildcards creates more complicated conflict types like (11?1?0, $\ast$, 5, 1), (111??0, $\ast$, 5, 1), and (1111??, $\ast$, 6, 1), (11?00?1, $\ast$, 6, 1) where the old LPM mechanism does not help us to determine which pattern is more specific than the other. This necessitates defining a new set of operators and relations for wildcard patterns to help us assign priorities correctly.

Definitions and operators

We define ${\mathbf{B}}^{\ast }$ system in which variables can have three values of {0, 1, $\ast$}. A $\ast$ bit indicates that bit may have any of 0 and 1 values. Pure and wildcard addresses, shown by upper case letters, are vectors of ${\mathbf{B}}^{\ast }$ bits: $\mathrm{\forall }$i ∈ [0,k], a_i ∈ ${\mathbf{B}}^{\ast }$ A = [a_k, …,a₁, a₀]. We define Mask operator (⊛) as follows:

(1) $$\mathrm{\forall }i,j,k\in {\mathbf{B}}^{\ast },k=i⊛j=\{\begin{array}{cc}1,& i=j\\ \ast ,& i\ne j\end{array}$$

The mask vector always includes sequence of 1s and $\ast$s. The common wildcard is obtained by applying a mask vector to a wildcard address using Derivation op( $\odot$):

(2) $$\mathrm{\forall }i,m,k\in {\mathbf{B}}^{\ast },k=i\odot m=\{\begin{array}{cc}i,& m=1\\ \ast ,& m=\ast \end{array}$$

Two bits in ${\mathbf{B}}^{\ast }$ match if both bits are the same or one of the bits is $\ast$.

(3) $$\mathrm{\forall }a,b\in {\mathbf{B}}^{\mathbf{\ast }},a\approx b\mathrm{i}\mathrm{f}(a=b)\vee (a=\ast )\vee (b=\ast )$$

We say an address A matches with a wildcard pattern W if they match bit by bit:

(4) $$A\approx W=\underset{i=0}{\overset{k}{\mathrm{\forall }}}{a}_i\approx w_i$$

A wildcard pattern W is dominant ( $\succ$) of A if:

(5) $$W\succ A\mathrm{i}\mathrm{f}\underset{i=0}{\overset{k}{\mathrm{\forall }}}{w}_i=a_i\vee w_i=\ast$$

Based on the dominance relation, the parent pattern always has more $\ast$ bits than the child, and therefore, has more matching addresses. In contrast, the child pattern is more specific and matches with a limited set of addresses. As a result, if A_c and A_p are the set of addresses that match with the patterns W_c and W_p, respectively, and $W_p\succ W_c\Rightarrow {\mathbf{A}}_{\mathbf{c}}\subset {\mathbf{A}}_{\mathbf{p}}$.

Dominance relation can be considered as a generalization for the longest prefix in which wildcard bits can be anywhere, not just at the pattern’s tail. Employing this relation, we will build a tree structure for wildcard patterns to detect and solve conflict problems.

Step 1: finding initial common wildcard patterns

In the first step, WildMinnie finds common wildcard patterns between addresses using ⊛ (Eq. (1)) and $\odot$ (Eq. (2)) operators shown in lines 6–22 of Algorithm 2. As final patterns are formed by the output port number, it searches for common patterns among rules with equal output ports. Therefore, in the beginning, all rules are grouped by their output ports. Assuming m ports for a switch, we have:

(6) $$G_p=\{G_{p_1},G_{p_2},\dots ,G_{p_m}\}\mathrm{w}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{e}{G}_{p_i}=\{(s,t,p,l)|p=p_i\}$$

The group with the most rule count is handled by one default rule and needs no further processing. For the remaining groups, to get the best compression ratio, we should find a set of patterns that collectively match all initial addresses, while each pattern should have the minimum conflict with patterns of other groups.

Finding all common patterns needs checking of all address pairs, which is in the order of O(|Gp_i|²). For addresses of length 32 bits, this exhaustive process may produce 3³² patterns. In an experiment, about 4 million unique patterns were found for only 4,000 rules. Exhaustive searching for all patterns and optimizing the large quantity is unacceptable from both processing and timing aspects.

As an approximation, we derive the common patterns from the adjacent rule pairs in the rule list. Then, the combined list of initial and new patterns is shuffled, and the derivation process is done again. This process is repeated REPEAT_COUNT times which makes this step of order O(Gp_i). In our experiments, we set this parameter to 2. Although the random approach may not generate the optimum set of patterns, we observed that throughout the WildMinne procedure, a considerable percent of patterns are removed due to low rank, and new high-ranked patterns take precedence. Additionally, more repetition of this process often generates patterns with many star-bits having higher conflicts and minor ranks such that they do not affect the final pattern list. In this regard, the starting random phase provides only a limited set of patterns as initial seed, since new high-ranked patterns are generated during the second step of WildMinnie in a more targeted way. In “Simulations”, we investigate the effect of more repeat counts by a set of simulations.

Initial and derived wildcard patterns are saved as a tuple of (A, p, M) where the first element is the pattern, the second element is the output port number, and the last element is the set of merged initial patterns. The initial pattern set is the set of distinct addresses obtained from the ruleset, which is Minnie’s output, too. The central part of the WildMinnie algorithm operates on this set instead of individual rules. When a pair of patterns are combined and generate a new pattern, initial matching patterns are saved along with the new pattern. This practice accelerates the rules’ processing and helps WildMinnie consider the initial patterns only once. Intuitively, the third element of all initial addresses has only one member, which is the same as the first element (see Algorithm 2 line 10). All derived patterns from all output ports are saved in a global list of pattern tuples (see Algorithm 2 line 21).

Figure 3 illustrates the steps of finding common patterns for a group of rules with output port number 1. In this example, for completeness and showing conflicts, we also assume a group of rules with output port number 2. In each step, the merge set and conflict set of each pattern are presented under the pattern.

Step 2: building pattern tree

In the second step, WildMinnie builds a tree structure using patterns and ranks them. The pseudo-code of this step is shown in Algorithm 3. To compute rank and build the tree, WildMinnie processes all patterns to achieve more information about them. This is done at line 4. After processing, a three-element pattern tuple, w(A, p, M), is expanded into a seven-element tuple, K(A, p, M, I, V, S, r). K.I is the set of rules matching the pattern and having the same port as K.p. K.V is the set of conflicting rules that match K.A but have a different port number than K.p. The last two elements K.S and K.r are the set of sub-patterns and pattern rank, respectively. At this step, K.S is empty and K.r = 0. We will explain these two parameters later.

If a pattern has no conflicting rules (i.e. k.V = ϕ), its rank can be computed and it is also eligible to be inserted in the pattern tree (lines 5–7). Such patterns substitute all of their K.I set in the table. As we will explain, a pattern without conflicting rules is a leaf node.

If a pattern has conflicting rules, it can also replace all rules in K.I, but its conflicting rule set can not be compressed and must be written as-is to the switch table, adversely affecting the compression ratio. To decrease the number of generated rules, WildMinnie recursively finds common patterns between conflicting rule sets. The resulting sub-patterns are saved in K.S of the pattern tuple. Each sub-pattern substitutes a set of rules in the conflicting set (K.V), which results in a more compressed rule table. In the pattern tree, sub-patterns of K.S are inserted as the children of the initial pattern. Sub-patterns are not necessarily tied to their resulting patterns and are processed independently (lines 12–14). As we will discuss in “Step 3. Assigning Priorities”, the final set of patterns are selected based on a ranking function (Wildcard Pattern Ranking). Therefore, when a child node’s rank is higher than its parent, it is used alone in the final list of rules. However, if a parent pattern in the tree has a better rank than its children, all children must be written in the final rule list to resolve conflicts.

This recursive step to find sub-patterns is, in fact, a part of finding patterns, but instead of discovering the whole pattern set at the beginning, WildMinnie starts with an initial pattern seed and seeks for other patterns in a more targeted way. As another advantage, we should note that processing and selecting the best sub-patterns is done for a limited set of children of a pattern, and unselected ones are trimmed at that level. If the whole pattern set is discovered and found in the first phase, the memory footprint can be very high.

A pattern is ready to be ranked and inserted into the pattern tree if all of its sub-patterns are in the tree and ranked (line 8). At this stage, a pattern may have several overlapping sub-patterns. To accurately compute the rank of a pattern, the best set of its non-overlapping sub-patterns is selected based on their rank.

In the subsequent sections, we explain the details of the pattern tree data structure and ranking function. Since choose_best procedure is very similar to the Algorithm 5, it is not listed separately.

Pattern tree

For the correct operation of WildMinnie, we have to handle the rule conflicts. Three types of conflicts may occur when using general wildcard patterns. The first type of conflict is when similar patterns are found in different groups having different port numbers. For instance, 1 $\ast$ $\ast$ $\ast$ $\ast$ $\ast$ pattern is found in both groups of Gp₁ and Gp₂. In this case, the group with the largest rule count is selected for compression, and the other rules are used intact or may be compressed and saved in the sub-pattern set. In this way, the conflict is removed.

The second type of conflict occurs when addresses match with several patterns in different groups. As an instance, address 111000 matches with patterns 1 $\ast$ $\ast$ $\ast$ $\ast$ $\ast$ in Gp₁ and $\ast$11 $\ast$ $\ast$0 in Gp₂. We resolve this type of conflict with a precise precedence assignment procedure, explained in “Step 3. Assigning Priorities”.

The last type of conflict occurs when a pattern is a parent of other patterns with different outport numbers—as an instance, having two rules (101 $\ast$ $\ast$, $\ast$, 3) and (10 $\ast$ $\ast$ $\ast$, $\ast$, 2), a packet with the source address 10100 matches both rules. The detection and priority assignment of such conflicts in legacy IPv4 networks are far more straightforward than OpenFlow due to prefix-only wildcard patterns and the LPM mechanism. To resolve the third type of conflict, we introduce the Pattern Tree data structure. A Pattern tree, essentially, is an m-ary tree in which parent nodes have dominance relation ( $\succ$, Eq. (5)) with their children. The root of the tree is the all-star pattern. Sibling nodes in a pattern tree have no particular relation but may have conflicting rule sets.

Figure 4A shows the pattern tree for the table of patterns in Fig. 3. In this example, we assume the rules are compressed with the all-star pattern and inserted as the root node has port number 3 and has no conflict with the current patterns. Figure 4B shows the same pattern tree when patterns of rule group with outport of 2 is added to the tree after finding their common patterns. These nodes are colored in red. As it is clear from the figure, conflicts of patterns, especially with different outport numbers, are easily detected in this structure. The pattern tree structure also considerably simplifies the computation and update of patterns’ rank in the last phase of WildMinnie (Step 3. Assigning Priorities) since the rank of a pattern (Wildcard Pattern Ranking) strongly depends on its sub-patterns.

Algorithm 4 shows the procedure of inserting a new node in the pattern tree. Insert_tree encapsulates a pattern tuple in a tree node structure and starts searching a proper position for the new node from the tree root by calling the add_pattern. The add_pattern is a recursive function. In each recursion, it moves one level toward the leaves. In the first step, it is checked if the given pattern can be a parent for some of the current node’s children. If this condition is met, the new node is inserted as a child of the current node (line 10), and all matching children are removed from the current node and added as children of the new node. Otherwise, it is checked if any child of the current node can be a parent for the new node. In this condition, add_pattern function is called for every eligible child, which causes a pattern to be added as a child of one or several nodes (line 16). The last phase of WildMinnie ensures only one of these redundant nodes is used in the final rule list of the switch table (Step 3. Assigning Priorities). When the new node can neither be a child nor a parent for any of the current node’s children, it is appended as a child of the current node (line 18).

Algorithm 4:

Inserting a pattern in a pattern tree.

1: procedure Insert_Tree(B, k)

2:  if k.A is ALL_STAR then

3:    return

4:  end if

5:  n := node(k)

6:  add_pattern(B.root, n)

7: end procedure

8: procedure add_pattern(b, n)

9:   $Y:=\{y|y\in b.S\wedge n.A\succ y.A\}$

10:  if Y ≠ $\mathrm{\varnothing }$ then

11:    n.parent := b

12:    b.S −=Y

13:     $\underset{y\in Y}{\mathrm{\forall }}y.parent:=n$

14:  else

15:     $Z:=\{z|z\in b.S\wedge z.A\succ n.A\}$

16:  if Z ≠ $\mathrm{\varnothing }$ then

17:       $\underset{z\in Z}{\mathrm{\forall }}$ add_pattern(z, n)

18:    else

19:      b.S ∪ = n

20:      n.parent := b

21:    end if

22:  end if

23: end procedure

DOI: 10.7717/peerj-cs.809/table-4

In the worst case, the height of a pattern tree can be as much as the address length when all possible patterns are available, or patterns are linearly the child of each other. Since WildMinnie deliberately keeps a limited number of patterns, the worst-case condition barely happens in practice. Even with more than 200 K flows in our simulations, tree height does not exceed more than six levels. Therefore, the insertion or deletion operations on the pattern tree are efficient regardless of the rules or the selected patterns count in practice.

Step 3: assigning priorities

In the last step of WildMinnie, presented in Algorithm 5, rules of the pattern tree are written in the rule table of the switch in their rank order. Procedure copy_to_switch_table in a loop selects the highest rank pattern tuple from the tree. If the output port is the same as the most frequently used port number, it is discarded, as all of these rules will be replaced by the default rule. Then, wildcard patterns of the selected tuples are copied into the switch table, recursively using the add_rules procedure (line 14). Inside this procedure, sub-patterns are added to the table, first with higher priority, and then the node’s pattern is added. The priority of rules is decremented by the addition of each rule to prevent the second type of conflicts as explained in “Pattern Tree”.

All initial patterns in k.M of the copied pattern are marked (line 18) as covered. Having a coverage log helps WildMinnie to discard patterns that have a high rank, but their merging set has been covered previously (line 8).

WildMinnie analysis

WildMinnie finds common patterns in the first step. If we want to visit each address once, the time complexity of finding patterns will be from the order of O(|T_s|). If |T_s| unique patterns are found, their insertion in the pattern tree will be from the order of O(|T_s|²). Similarly, the last step of WildMinne involves sorting and searching the handled merge set, which is in the same order. Of course, the worst-case scenarios are absolutely rare cases and may not happen in practice. The following theorem defines a lower bound for the compression ratio of WildMinnie.

Theorem 1 WildMinnie in the worst case performs as Minnie.

Proof. WildMinnie, as illustrated in Algorithm 2, for each pattern keeps a merge list. The merge set have a set of patterns that are directly obtained from the ruleset without masking and derivation process. In this way, the initial patterns set are the same as the final grouping of Minnie. During masking and derivation process in procedure find_common_patterns (Algorithm 2 line 6), WildMinnie keeps track of initial pattern set, too. Therefore, for each pattern generated in any step of the algorithm, it is clear which initial patterns formed that pattern. We also should note that, in the last step of WildMinnie, in Algorithm 5 a pattern is discarded when all of its merge set members are covered by previous patterns. By the above explanation, we can conclude that each initial pattern is used at most once in the final rule set copied to the table. An initial pattern may be used in the original form or merged with other patterns and form a new pattern.

Now, suppose that for a rule set, Minnie compression ratio is better than WildMinnie. This necessitates that some initial patterns are used more than once in various derived or non-derived forms, which contradicts the WildMinnie algorithm.

Incremental updates

It should be noted that after the network initial start-up, generally, rules will be added to the network in small batches. If the address field of a new rule matches an existing wildcard rule and their output port is also equal, then no change is required in the rule table. Otherwise, a new non-wildcard rule should be inserted in the table with the highest precedence. For a not-too-large set of rules, this approach is fast and has zero overhead. As the WildMinnie compression ratio is good enough, one should not be concerned about several hundreds of new rules. However, the compression ratio will be decreased over time by using this approach.

The alternative approach runs the complete WildMinnie procedure for the limited set of rules that did not match the existing rules. We should keep a pattern tree for each switch and apply incremental updates on it in this method. For incremental deletions, we check the pattern tree’s corresponding nodes for the set of rules intended for deletion. All nodes and their corresponding rules with the condition |n.I| = 0 are removed from the tree and the rule table.

Simulation settings

We implemented WildMinnie with Java, which is the language for most of the well-known controllers. In simulations, we consider several factors to study the performance of WildMinnie from various aspects. In all simulations, we report the compression ratio on destination address; there was no remarkable difference between the results of sources and destination addresses. We also assume that all flows are active during the simulation time, so switches must have rules of all flows. This assumption is the worst condition for the rule placement.

As WildMinnie does not have an integrated routing method, we use the simple routing method introduced in Minnie, which we call it MinnieRouting. MinnieRouting defines a weight parameter for each link, updated after every rule placement according to the total load of passing flows and the filled ratio of its source switch’s rule table. MinnieRouting distributes flows’ load in the whole network to avoid overloading of some core switches.

Topologies

Similar to Rifai et al. (2017), simulations have been done on well-known data center topologies: Fat-tree (k = 4, 8, 12, 16) (Al-Fares, Loukissas & Vahdat, 2008), VL2(k = 2, 4, 8, 12) (Greenberg et al., 2009), DCell((2,1), (3,1), (4,1), (5,1), (6,1)) (Guo et al., 2008). These topologies include 9 to 320 switches where each switch has at most 24 ports. With this assumption, some topologies cannot be set up like VL2(k = 16). Figure 5 shows an example of these topologies. Fattree and VL2 belong to the family of architectures in which only switches participate in forwarding. In other families of architectures like DCell and BCube, servers also cooperate in forwarding. One purpose of experimenting on various topologies is to produce different mixes of flows to study the compression behavior. Datacenter topologies usually have a standard and efficient count of links and produce balanced mixes of flows. Meanwhile, data centers receive large diversity of source-destination pairs, making them a pretty perfect target for testing compression algorithms. To show the stability of WildMinnie’s performance in extreme scenarios, we also test the shortest path routing instead of MinnieRouting. The general shortest path routing does not balance the flows over links and switches and produces hot points in the network.

Performance metrics

For performance comparison, we use two measurements. The first measurement denoted by C_total is defined as follows:

$$\mathbb{T}=\sum _{s\in S}|T_s|$$

$$C_{total}=100\ast {\displaystyle \frac{{\mathbb{T}}_{old}-{\mathbb{T}}_{new}}{{\mathbb{T}}_{old}}}$$

$\mathbb{T}$ is the total number of rules installed in all switches of a network and C_total indicates what percent of total rules reduced by a compression method. This parameter is also a good indicator for the average compression ratio of individual switches. The second measurement, C_max, shows the effectiveness of a compression method in reducing the maximum size of rule tables.

$${\mathbb{T}}^{max}=\underset{s\in S}{MAX}|T_s|$$

$$C_{max}=100\ast {\displaystyle \frac{{\mathbb{T}}_{old}^{max}-{\mathbb{T}}_{new}^{max}}{{\mathbb{T}}_{old}^{max}}}$$

A compression method can reduce some rule tables, but it may fail to compress large or special tables. In this condition, average compression may be satisfactory; however, few tables remain with a large count of rules.

WildMinnie performance

This section provides a performance comparison of WildMinnie and Minnie based on topology, SPE, and stickness parameters.

By subnet-per-edge (SPE)

Figures 6A, 6D and 6G show the performance of algorithms with increasing number of subnets per-edge in thee topologies. In all of these experiments, we use 10K flow sets with stickiness of 0.5.

As expected, the performance of Minnie compression quickly drops with increasing SPE. Especially in VL2 and Fattree topologies, Minnie loses 20–70% of its performance with only 10 subnets per edge. Higher SPEs decrease its compression ratio by less than 30%, but it is not as sharp as the SPE = 10. The sharp beginning drop happens because the first compression ratio is achieved in an unreal condition of having only one subnet-per-edge. In the continue, compression ratio decreases with a reasonably monotone rate of 10–20%. This was pretty predictable since Minnie’s compression strongly depends on equal addresses, and with higher SPE values, the variety of destination addresses destined to the same switches grows.

WildMinnie also loses its compression performance with SPE, but the loss slope is slower than Minnie. The compression ratio gap between Minnie and WildMinnie grows as SPE increases, in a way that in SPE = 80, the compression ratio of WildMinnie is twice Minnie’s approximately.

The compression ratio also decreases when graphs get larger in all types of topologies. This performance loss is natural since the flow set size remains constant while the number of nodes is increased. Therefore, flows are distributed in more paths over a high count of nodes which causes less compression. For instance, in smaller graphs like Fattree k = 4, VL2 k = 4, and most of the DCELL topologies compression rate is around 99%, since a small number of switches bear a large percent of rules.

These facts are also approved by C_max charts in Figures 6B, 6E, and 6H. According to these figures, WildMinnie, independent of the topology or graph size, successfully reduces the max table size by 80–99%. These statistics confirm that the spread of the rule set in more nodes and smaller table sizes is the main reason for the performance reduction in large graphs. This is in contrast with the behavior of Minnie, which fails to keep the high C_max ratio in large graphs. A diverse set of addresses scattered in more nodes reduces the probability of address equality in switches which again confirms the strong dependency of Minnie to traffic distribution.

By topology

Figure 7 gives a detailed view of how WildMinnie and Minnie operate in each layer of architectures. Each chart displays the average difference between the total compression ratios of WildMinnie and Minnie based on different SPE values with a flow set size of 10 K and stickiness of 0.5.

In DCell architecture, since there are no aggregate or core layers, we categorized nodes to edge and non-edge nodes. WildMinnie and Minnie in this architecture have the lowest performance difference, as both of them achieve high compression ratios. In DCell, plenty of paths exists between each pair of nodes, and MinnieRouting performs a good load balance on links and switches. Thus, when the graph size grows, the distribution of rules is not changed significantly. However, with high SPEs, the diversity of addresses increases, and the difference of compression ratio between WildMinnie and Minnie grows slowly.

VL2 and Fattree architectures present a more clear view of Minnie and WildMinnie’s behavior. According to Figs. 7C–7H, the least difference of performance is achieved in edge nodes where the diversity of destination addresses is high, and the most significant performance gap is in the core nodes. In core and aggregate nodes, a good mix of flows with the same destination switch exists; however, WildMinnie gets the most out of this mix by finding the common patterns. In both architectures, graphs of size k = 8 show the rising threshold. In the beginning, with SPE = 1, both methods have similar results, but with the growth of SPE and reduction of address equality, WildMinnie takes advantage of its pattern weaving approach and achieves a better compression ratio. VL2, compared with Fattree, has more interconnections between its pods and has better potential for balancing. Therefore, in VL2, the performance gap is lower, and its rising threshold is higher than Fattree.

By deeper search

The next simulation set examines the performance of WildMinnie with the number of rounds it searches for the common patterns. For testing, the process of combining and shuffling of address patterns is repeated with different values of REPEAT_COUNT parameter in function find_common_patterns (Algorithm 2, line 6). Simulations were carried out with flow sets of size 10K, SPE = 40, and stickness = 0.5 on FatTree architecture as WildMinnie has its least performance on FatTree. We continued the simulations until we received the out-of-memory error. Figure 8A doesn’t show a meaningful relation between the final compression ratio and REPEAT_COUNT. The variation of C_total for this simulation is around 5%, which most probably happens due to the randomness in the process of generating and assigning subnets. We draw two important results from this simulation. First, increasing the search rounds increases the number of patterns exponentially. Second, due to the generation of a large number of low-ranked patterns, an exhaustive search to find a better set of patterns needs a tremendous number of rounds and a huge memory size.

Running time

The execution of WildMinnie includes two main time-consuming parts: finding common patterns and building the pattern tree. For measurement, we choose the FatTree (K = 4) network, which has a high rules-per-switch parameter. Measurements have been done on a commodity PC with Intel Core i5-4460 CPU² and 8 GB of RAM.

Figure 9A shows the minimum, average, and maximum running time of finding a certain number of unique patterns. Due to the random selection of address pairs, the number of explored pairs for finding a certain number of unique patterns is not constant. For instance, for 2,000 unique patterns, it may be necessary to visit 25,000 pairs, while in another switch with only 10,000 address pairs, the same count of patterns is found. Search time in WildMinnie with REPEAT_COUNT = 2 increases linearly with a slight slope. According to the Fig. 9A, in the worst case, it takes 3–5 ms by average to find 3,000 unique patterns that are quite a large count in our experiments. The next Fig. 9B shows the minimum, average, and maximum time for processing plus inserting a pattern in the pattern tree with the specified size. By average, it takes about 0.2–1 ms to process and insert a pattern in a tree with 1,200 nodes.

Based on these figures, the total execution time of WildMinnie for one switch takes only several milliseconds on a commodity PC, and it can be used in larger networks with a higher number of flow sets without any concern.