@ -36,15 +36,21 @@ Longer failure paths would of course increase this additional delay. Because Sho
As such ShortCut provides a reliable way to optimize alternative routes, especially for time sensitive data like VOIP.
\subsection{TCP packet flow}
\label{discussion_packet_flow_tcp}
Our packet flow measurements using a TCP data transfer showed the amount of packets forwarded on each router. A naive assumption would be that the routers on a looped path would have to forward each packet twice and therefore have a 100\% increased load on them. This is, however, not true for TCP as only packets sent to the receiving device are forwarded through our loop in our topologies. ACKs returning from the \textit{iperf} server are not sent through the looped path. Because of this the routers on the looped path actually only forward half of all packets, except for the router at the entry point of the loop. It has to be noted that these packets all contain data and therefore do have full impact on the bandwidth of links involved in the looped path as discussed previously in \cref{discussion_bandwidth_link_usage}.
\subsection{Packet flow}
\label{discussion_packet_flow}
Our packet flow measurements using a TCP data transfer showed the amount of packets forwarded on each router. A naive assumption would be that the routers on a looped path would have to forward each packet twice and therefore have a 100\% increased load on them. This is, however, not true for TCP as only packets sent to the receiving device are forwarded through our loop in our topologies. ACKs returning from the \textit{iperf} server are not sent through the looped path. Because of this the routers on the looped path actually only forward half of all packets.
All routers on the failure path, except for the router at the end, will forward all packets sent into the loop twice. While the actual amount of packets does not change for these routers, as ACKs are not sent into the loop, they add onto the overall load of the network. The router directly attached to the broken link will just forward packets once.
The entry point of the loop, which in our topologies is always router R1, forwards each packet containing data twice and acknowledgements once, increasing the workload for the router by 50\%.
Longer failure paths do not influence this behaviour.
It has to be noted that these packets all contain data and therefore do have full impact on the bandwidth of links involved in the looped path as discussed previously in \cref{discussion_bandwidth_link_usage}.
ShortCut is able to cut the looped path and therefore restores the network to a state in which all routers on the path of routing forward the same amount of packets, with routers on the looped path not forwarding any packets anymore.
The entry point of the loop, which in our topologies is always router R1, forwards each packet containing data twice and in addition to this the acknowledgements once, increasing the workload for the router by 50\%.
Longer failure paths do not influence this behaviour, they do however add more devices which will be affected by the failure and therefore also the amount of packets forwarded on the network in total.
This adds up to 33\% more packets forwarded in our minimal network, 50\% more packets forwarded in our first failure path network and a 60\% increase in forwarded packets in our longer second failure path network.
When using UDP for our data transfer and measuring the packets forwarded on routers, the differences between TCP and UDP become quite obvious. As UDP does not send ACKs on successful transmission, all looped routers except for the router directly attached to the failure, e.g. router R4 for the second failure path network, will forward all packets twice.
For our minimal network this meant an increase in packets forwarded on the network by 50\%. With increasing length of the failure path the impact on the network grew worse, with a 100\% increase of packets forwarded for our first failure path network and a 120\% increase for our longer second failure path network.
For all transfers, be it using TCP or UDP, ShortCut is able to cut the looped path and therefore restore the network to a state in which only a minimum amount of routers forward the same amount of packets. No more additional packets are forwarded, alleviating the burden placed on the network. ShortCut proves to be a reliable way to reduce traffic caused by failures.
\subsection{UDP packet flow}
\label{discussion_packet_flow_udp}
When using UDP for our data transfer and measuring the packets forwarded on routers, the differences between TCP and UDP become quite obvious. As UDP does not send ACKs on successful transmission there a
@ -43,7 +43,7 @@ The second measurement however always uses H1 as an \textit{iperf} server, shift
\subsection{TCP packet flow}
The test uses the "measure\_packet\_flow" function described in \textit{measure\_packet\_flow} in \cref{implementation_commands}.
Depending on the topology
For each topology we chose four routers for which the packet counters should be implemented. For our minimal topology this choice was easy - we just implemented packet counters on all routers. In our failure path networks however we
Frederik Maaßen
2 years ago
