@ -5,7 +5,7 @@ In this chapter we evaluate tests that were run using our test framework in Mini
The evaluations are sorted by topology. For each topology we measured the bandwidth, bandwidth with a concurrent data flow, latency, TCP packet flow and UDP packet flow. We execute each test once with FRR active in the corresponding section \textit{With FRR} and once with FRR and our implementation of ShortCut active in the corresponding section \textit{With FRR and ShortCut}.
We start with our minimal network in section \ref{eva_minimal_network}, followed by the evaluation of two networks with longer "failure paths", measuring the influence of additional nodes in looped paths in section \ref{eva_failure_path_networks}.
We start with our minimal network in section \ref{eva_minimal_network}, followed by the evaluation of two networks with longer "failure paths", measuring the influence of additional nodes in looped paths in section \ref{eva_failure_path_network}.
@ -222,7 +222,7 @@ When the failure is introduced concurrent to a running test, the latency spikes
Our implementation of ShortCut using \textit{nftables} does not seem to add any additional delay to packet transfers as is evident when comparing the average delay produced before a failure in \cref{fig:evaluation_minimal_latency_wo_sc_a} and \cref{fig:evaluation_minimal_latency_sc_a}.
When introducing the failure the latency does not change when introducing a failure to the network as can be seen in \cref{fig:evaluation_minimal_latency_sc}. This is caused by the removal of the looped path and therefore the additional delay each packet would be subjected to.
When introducing the failure the latency does not change as can be seen in \cref{fig:evaluation_minimal_latency_sc}. This is caused by the removal of the looped path and therefore the additional delay each packet would be subjected to.
The spike in latency which can be seen in \cref{fig:evaluation_minimal_latency_concurrent_sc}, occurring when the failure is introduced can be attributed to the same possible scenario as explained in \cref{minimal_latency_with_frr}, which is most likely a timing issue with the introduction of the failure on the routers R2 and R4 and simultaneously sent ICMP packets.
@ -283,14 +283,14 @@ Reconfiguration of routers in Mininet does not reset the \textit{nftables} count
\caption{UDP packet flow on all routers measured with \textit{nftables} counters using ShortCut}
\end{figure}
When using ShortCut in a UDP packet flow measurement, the negative consequences of the failure disappear. While in \cref{fig:evaluation_minimal_packet_flow_udp_wo_sc_a} routers R1, R2 and R4 receive all packets on the original route, the load switches after a failure from R2 to R3. As expected, the ShortCut implementation has cut out the looped path and restored the original functionality on an alternative route.
@ -367,8 +369,8 @@ When using ShortCut in a UDP packet flow measurement, the negative consequences