## 4 Discussions Alongside Numerical Experiments
### Classifier Based on Protocol Type and Status of the Connection  
The dataset we used is KDD-Cup'99, also known as KDD99. It consists of 41 features and 494,020 records and contains a wide variety of intrusions in network traffic. We used multi-label classification and LTN (Logic Tensor Networks) to classify our records according to the protocol used and the status of the connection. In this first example, real logic is used to ask complex queries to interpret the data. To avoid possible causes of errors based on the huge number of replicated records, we eliminated them and the number dropped from 494,020 to 145,585 records.  
Our protocol types and connection statuses used to write the grounding in real logic are displayed in the Table 1 below:  
Our input layer of the network has the same size as the number of classes mentioned above. The set of axioms in this example will include all the protocol types and connection statuses, but with no constraints. We split the samples into training and testing, 120,000 for training and the rest for testing.  
The set of axioms in this case:  
\[\forall x_{tcp}:P(x_{tcp},tcp) \forall x_{s0}:P(x_{s0},s0)\] \[\forall x_{icmp}:P(x_{icmp},icmp) \forall x_{s3}:P(x_{s3},s3)\] \[\forall x_{udp}:P(x_{udp},udp) \forall x_{stc}:P(x_{stc},rsto)\] \[\forall x_{sf}:P(x_{sf},sf) \forall x_{rstr}:P(x_{rstr},rstr)\] \[\forall x_{s1}:P(x_{s1},s1) \forall x_{rsto0}:P(x_{rsto0},rstos0)\] \[\forall x_{rje}:P(x_{rje},rej) \forall x_{oth}:P(x_{oth},oth)\] \[\forall x_{s2}:P(x_{s2},s2) \forall x_{oth}:P(x_{oth},oth)\]  
Training the model, we define some metrics. We measure:  
1. The level of satisfiability of the Knowledge Base of the training data.
2. The level of satisfiability of the Knowledge Base of the test data.
3. The training accuracy (we used Hamming loss function).
4. The test accuracy (same thing, but for the test samples).
5. The level of satisfiability of a formula \(\phi 1\). \(\forall x:p(x,udp)\rightarrow\
eg p(x,tcp)\) (every \(udp\) connection is not a \(tcp\) connection and vice-versa)
6. The level of satisfiability of a formula \(\phi 2\). \(\forall x:p(x,udp)\rightarrow\
eg p(x,icmp)\) (every \(udp\) connection is not a \(icmp\) one and vice-versa)
7. The level of satisfiability of a formula \(\phi 3\). \(\forall x:p(x,tcp)\rightarrow\
eg p(x,icmp)\) (every \(tcp\) connection is not a \(icmp\) one and vice-versa)  
Looking at our \(results.csv\) file that has all the metrics enumerated, we can see \(\phi 1\) and \(\phi 3\) have high satisfaction levels, almost perfect ones. This means that, every \(udp\) connection cannot be a \(tcp\) connection and every \(tcp\) connection cannot be a \(icmp\) one. For \(\phi 2\), we reached a satisfaction level of 0.10, denoting that between \(udp\) and \(icmp\) connections have features that are highly correlated.  
\begin{table}
\begin{tabular}{l l l l l} \hline
**0. TCP** & **1. ICMP** & **2. UDP** & **3. SF** & **4. S1** \\ \hline
5. REJ & 6. S2 & 7. S0 & 8. S3 & 9. RSTO \\
10. RSTR & 11. RSTOS0 & 12. OTH & 13. SH & \\ \hline \end{tabular}
\end{table}
Table 1: Protocol types and connection statuses used to create our grounding. The Knowledge Base will contain a set of rules based on these.