Implementations of Single Packet Attacks With Concur-

Using concurrency and multiplicity options allow us to achieve higher performance. The understanding of the following definitions will help to understand the set of experiments in this section:

• Concurrency means part of the code (operator or referenced module (group of operators)) run in its own thread.

• Multiplicity refer to the number of instances of the code.

• Dispatch style is related to the multiplicity. The dispatch style specifies how each instance receives tuples in round robin, broadcast, or based on a data value. In broadcast each instance will receive a copy of the incoming tuple. In round robin the first tuple goes to the first instance and the second goes to the second and so on. Based on value is by checking the value against a test condition and then dispatch to the designated instance for that value.

Figure 7.9: Single Packet Attack Program Using Module

In StreamBase the concurrency can be set, the multiplicity, or both. According to the StreamBase manual, these options can be used for portions of the application that meet certain criteria:

• if the code portion is long-running or compute-intensive;

• can run without data dependencies on the rest of the application;

• it would not cause the containing module to be waiting or blocked.

To use these options in our program in Figure 7.6, we need to apply these guidelines. Also, in SSQL, it is allowed to use these options for modules only. In StreamBase, a module is a set of operators that include input and output streams, and is written in one SQL file. Figure 7.9 illustrates the change. The application contains two components: the input adapter and a referenced module (from here on we refer to them as input

Chapter 7. Experiments and Results 102

code and attack module). The attack module contains the filter, map, and output operators for a single attack written as a referenced module. For the input code, we can use the concurrency option but not the multiplicity as it has no input stream. For the attack module we can use both options. This means that there are eight possible implementations as can be seen in Figure 7.10. Table 7.4 shows the results of all the

Figure 7.10: All Possible Implementations For The Single Packet Attack With Pay- load

experiments of this category. In this table (CC) denotes “Concurrency”. (NCC) denotes “No Concurrency”, (1) denotes single instance or no multiplicity, and (n) denotes n multiplicity where n is an integer such that n > 1. For instance, the first row shows the results of running non concurrent input code (NCC) and non concurrent (NCC) 50 attack modules of (1) instance each (i.e., no multiplicity). The following are observations on these results:

• The first row result is almost the same result obtained previously with no concur- rency and no multiplicity (the third row in Table 7.2). The difference is that we implement the attack code as a module, but we did not use the concurrency or the multiplicity.

• Using input code with concurrency and no concurrency for the attack module gives better results in general (rows 7-11).

• Row number 9 has the result of best performance where three non concurrent in- stances of attack modules are used. In rows 7-8 less than three number of instances used and in rows 10-11 more than three instances used. Increasing the number of instances above three cause the performance to degrade. This is consistent with StreamBase rule of thumb that is for best performance the number of instances should be equal to the number of cores on the machine or less. So, we have three instances in addition to the input module running on four cores on the testing machine.

• Using input code with concurrency and multiplicity for the attack module gives us the best result that exceeded the results ofSNORT andBRO which are presented in Table 7.1.

Chapter 7. Experiments and Results 103

TeStID perform well with parallel input code and running multiple threads of the attack modules (rows 7-11). Simple graphical representation for this implementation is in Figure 7.11. When multiplicity option are set, the attack module threads receive input in round robin fashion, so each thread will process a tuple (packet) and the subsequent packet will be processed by another thread. This scenario occurs for all the 50 attack modules. These threads all exist in the main region (no concurrency) which gives the StreamBase engine less overhead when it was running in parallel (with concurrency) in the rows 5 and 6.

Finally, the the developer versionStreamBase Server was used to run all the exper- iments. The enterprise edition is an ultra low-latency application server optimized for high production level performance [92], but the results achieved by using the developer version was adequate to show the efficiency of using SDP.

Implementation X2 X4 X8 X16 X24 X48

1 NCC Input Code + 50 NCC Attack Module (1) 0 -3 -79 2 NCC Input Code + 50 NCC Attack Module (2) 0 -2 -67 3 NCC Input Code + 50 CC Attack Module (1) -293 4 NCC Input Code + 50 CC Attack Module (2) -299 5 CC Input Code + 50 CC Attack Module (1) -3 -126 6 CC Input Code + 50 CC Attack Module (2) -84 -128

7 CC Input Code + 50 NC Attack Module (1) 0 0 0 -5 8 CC Input Code + 50 NC Attack Module (2) 0 0 0 0 0 -2

9 CC Input Code + 50 NC Attack Module (3) 0 -1

10 CC Input Code + 50 NC Attack Module (5) 0 -2

11 CC Input Code + 50 NC Attack Module (10) 0 -5 Table 7.4: Results of Single Packet Attacks With Concurrency and Multiplicity