## 3 Materials and Methods
### Network Structure and Available Traffic
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Attribute** & **Capture location tap1** & **Capture location tap2** \\ \hline Duration of capture & 3,918 s & 4,561 s \\ No. of packets & 3,168,660 & 2,838,227 \\ Avg. size of packets & 135.10 bytes & 134.23 bytes \\ Avg. data rate & 109,257.90 bytes/s & 83,525.07 bytes/s \\ Capture size & 478,792,912 bytes & 426,382,869 bytes \\ Avg. packet rate & 808.70 packets/s & 622.26 packets/s \\ No. of connections & 613 & 930 \\ No. of TCP connections & 8 & 174 \\ No. of UDP flows & 598 & 713 \\ No. of ICMP flow & 0 & 36 \\ Portion of multicast packets & 92.38\% & 96.97\% \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Statistics of the packet captures, connection number without the RAID controller messages. For the traffic recorded from Tap2, the total number of packets was 2,838,227 of which 3031 packets represented RAID controller traffic. 3223 connections were reported by Bro NSM of which again 3031 were RAID messages. For the duration of the packet capture and the location of the Tap2, 0.1% of the packets found in the network represented this type of unneeded traffic. At a first glance, using Wireshark [19], some very suspicious protocols were reported by the tool, such as eDonkey, a peer-to-peer protocol. However, after a short investigation, it was revealed that these very sporadic and sparsely appearing protocols were also in fact messages by Promise RAID controllers present in the network. This particular behavior by Promise RAID controllers turned out to be causing the \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multicolumn{1}{c}{**t**} & \multicolumn{1}{c}{**Tap**} & \multicolumn{1}{c}{**Data byte rate (B/s)**} & \multicolumn{1}{c}{**Avg. packet size(B)**} & \multicolumn{1}{c}{**Avg. packet rate**} \\ \hline \multirow{2}{*}{0s} & Tap1: & 110,764.06 & 135.12 & 819.73 \\  & Tap2: & 81,069.95 & 132.19 & 613.29 \\ \hline \multirow{2}{*}{600 s} & Tap1: & 112,781.12 & 135.16 & 834.73 \\  & Tap2: & 81,336.13 & 132.15 & 615.48 \\ \hline \multirow{2}{*}{1200 s} & Tap1: & 109,876.51 & 135.06 & 813.55 \\  & Tap2: & 87,409.34 & 138.72 & 630.12 \\ \hline \multirow{2}{*}{1800 s} & Tap1: & 108,285.54 & 135.09 & 801.58 \\  & Tap2: & 83,917.03 & 133.33 & 629.39 \\ \hline \multirow{2}{*}{2400 s} & Tap1: & 107,414.70 & 135.09 & 795.11 \\  & Tap2: & 85,160.06 & 133.65 & 637.20 \\ \hline \multirow{2}{*}{3000 s} & Tap1: & 107,521.36 & 135.07 & 796.06 \\  & Tap2: & 83,499.59 & 133.01 & 627.75 \\ \hline \multirow{2}{*}{3600 s} & Tap1: & 107,203.58 & 135.14 & 793.27 \\  & Tap2: & 80,870.29 & 132.31 & 611.23 \\ \hline \multirow{2}{*}{4200 s} & Tap1: & - & - & - \\  & Tap2: & 85,885.34 & 141.26 & 608.00 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Statistics of the 600 s interval slices of the packet captures. Figure 2: Average packet sizes for the 600 s slices of packet capture from Tap1 and Tap2. false appearance of a number different protocols in Wireshark analysis. After weeding out the protocols caused by RAID controller messages, the list of protocols presented in Table 1 remained. No traffic in the network traces was found which would have been readily identified as being of a malicious origin. Hence all the traffic analyzed was assumed to be of benign origin, even if unnecessary or posing a risk. This assumption is critical for selection of possible features.