From: Richard Whitehouse Date: Mon, 16 May 2011 14:15:44 +0000 (+0100) Subject: Improvements for rkh X-Git-Url: https://git.richardwhiuk.com/?a=commitdiff_plain;h=a2d6c0ef17fe6c3c63bc5f8f600e03a15ce4a992;p=ii-diss.git Improvements for rkh --- diff --git a/evaluation.tex b/evaluation.tex index edc689c..4f3de18 100644 --- a/evaluation.tex +++ b/evaluation.tex @@ -4,7 +4,7 @@ The following experiments were carried out on the simulator with a Gigabit Ethernet network, with trials being done with both MOOSE and Ethernet as the Data Link Layer protocol. In each case UDP packets, encapsulated in IP datagrams are sent on Ethernet frames from the hosts. -\subsection{Inital Trials} +\subsection{Operational Validation} The first section of trials was done on the following network. These were done to check the protocols were performing correctly. @@ -14,36 +14,91 @@ The first section of trials was done on the following network. These were done t In this set of tests, the first sends a packet, and then a second later, the second host replies. +\subsubsection{Local Transmission} + The first test shows that the local packets, i.e. packets which only traverse their local switch. In this case between Host 0 and Host 1. In both the Ethernet and MOOSE case the packet traverse the switch and go to the host correctly. In the MOOSE case, the address is rewritten in both directions. This provides evidence that the switches are working correctly with the respect to the protocol descriptions. +\subsubsection{Remote Transmission} + Further evidence is provided in the second test, where a remote packet, i.e. a datagram which travels to a different switch, is shown. In this case, between Host 0 and Host Here we have evidence that the addressing and routing between switches is performing correctly and that the switch addressing is working correctly in the case of MOOSE. +\subsubsection{Routing protocol} + Evidence of the effect of the different routing systems can be found in the third test, where Host 4 sends a packet to Host 6. In the case of Ethernet, this is forced to travel via Switch 2, Switch 0, Switch 1 and then Switch 3, before arriving at Host 6, and the reverse for 6 to 4. In the case of MOOSE however, it travels from Host 4, to Switch 2 then Switch 3 then Host 6, and the reverse for 6 to 4. For the unicast packet this results in a large increase in the number of Ethernet datagrams required. \subsection{Efficency of Routing} In this test, we are looking at the efficency of the routing protocol. -An extreme example of this, is the effect of the routing protocol on the number of switches each datagram passes through - the more inefficent the routing protocol, the more Ethernet datagrams that are required. +We can measure this by the number of Ethernet frames for a packet to go between two hosts. With a ineffficent routing protocol it will require more frames than in an efficent routing protocol. + +We need to look at two different types of addressing as well. Packets in Ethernet can either be broadcast, or unicast, so both mechanisms will be studied. + +\subsubsection{Unicast} + +Here we have a ring network topology with 25 switches in the ring. Switch 12 and 13 each have a host attached, 0 and 1 respectively. Host 0 sends a packet to host 1, and then host 1 sends a packet back to host 0. \begin{figure} -\includegraphics[width=12cm]{simulation-4} +\includegraphics[width=6cm]{simulation-4} \end{figure} +The network has been designed to exploit the worst case of the Ethernet protocol. Namely the spanning tree is constructed such that the the nodes are at the bottom of different branches of the tree. As such, the direct link between switches 12 and 13 is disabled, and the packets must traverse the entire ring. + \begin{figure} \includegraphics[width=2cm]{simulation-4-tree} \end{figure} -Here we have a ring network topology. I have also designed it such that the Ethernet protocol choses a spanning tree such that the datagram is required to cross the entire structure to reach the destination. As such, here the Ethernet protocol performs badly, requiring far more frames to reach the other host, whereas MOOSE simply crosses the short distance between the two hosts. +Due to this, the Ethernet protocol performs very badly here, requiring 26 frames in each direction for the UDP packet and the ARP Response packet - giving a total of 52 unicast UDP packets, and 52 unicast ARP packets, combining to make a total of 104 unicast frames. + +MOOSE on the other hand, uses a routing protocol, which allows it to perform much better. As the unicast packets only need to traverse between switch 12 and switch 13, the number of frames which have to be unicast is vastly reduced. Only a total of 12 unicast frames are sent, with 3 for each UDP packet and 3 for each ARP Response. + +\subsubsection{Broadcast} + +Broadcast is the mechanism by which each host on the network is delivered a copy of the packet. It is primarily used for ARP, the Address Resolution Protocol, which resolves IP addresses to Ethernet MAC addresses. + +Here we have a mesh network topology with 25 switches in the mesh. Switch 12 and 13, like in the unicast example, have a host attached, 0 and 1 respectively. Host 0 sends a packet to host 1, and then host 1 sends a packet back to host 0. Before the transmission of a packet, the network must resolve the address of the host, causing a broadcast packet to be emitted. + +\begin{figure} +\includegraphics[width=6cm]{simulation-5} +\end{figure} + +Using broadcast in a mesh network is problematic for MOOSE, as it utilises Reverse Path Forwarding to prevent broadcast storms, whereas Ethernet uses the Rapid Spanning Tree Protocol. s such, each broadcast packet is sent to the next switch, before it is culled in MOOSE, while in Ethernet, it doesn't need to send it any further as it knows the entire topology. + +Due to this, the MOOSE protocol performs especially badly here, requiring 1156 broadcast frames to perform the simulation, 578 from each transmission. One frame is from the host to the switch, then 24 frames to each of the connected switches, followed by each of those switches sending another 24 frames, plus an additional frame from one switch to the host. + +In comparison, Ethernet, using the Rapid Spanning Tree Protocol (RSTP), uses only 52 broadcast frames, which is minimal. This is 26 frames for each broadcast of a ARP request, with one from the host to the nearest switch, 24 switch to switch and then one to destination host. + +. I have also designed it such that the Ethernet protocol choses a spanning tree such that the datagram is required to cross the entire structure to reach the destination. As such, here the Ethernet protocol performs badly, requiring far more frames to reach the other host, whereas MOOSE simply crosses the short distance between the two hosts. \subsection{State Table Size} -\section{Limitations} +One of the major advantage of the MOOSE protocol is that of reduced state table sizes. Here I will show two different cases which show the difference between MOOSE and Ethernet. + +\subsubsection{Ethernet} + +Ethernet performs better when a limited number of hosts are connected by a series of switches. In this situation I have 15 switches connected in a row, with a single host connected to the first and last switch. + +\begin{figure} +\includegraphics[width=6cm]{simulation-6} +\end{figure} + +Here the Ethernet protocol gives a state table size of 2 in the first and last switch, while MOOSE gives a host table with a size of 1 in both the first and last switches and, in addition, a switch table size of 14 in all of the switches. + +%\subsubsection{MOOSE} + +%MOOSE performs best when there are a number of switches each with a + +\section{Limitations of the Simulation} + +The topologies tested are not representative of existing data centres, or other networks. As such the figures gathered only represent the extreme end of the differences betwen the two protocols. + +The traces used to test the topologies are very simplistic. While it is expected that this shouldn't have an impact on the evaluation made here, it is worth bearing in mind that this only demonstrates a small snapshot of the possible scenarios. \section{Possible Improvements} -\section{Ethernet} +Testing against real world traces, and incorporating dynamic versions of the routing protocols, and implementing the SAMI protocol outlined in \cite{dwh} would increase the use of the data presented here. \section{MOOSE} +The developers of MOOSE should seriously consider adding a Spanning Tree Protocol instead of relying on Reverse Path Forwarding, as this simulation has shown that it performs poorly under broadcast, especially in well connected networks. diff --git a/implementation.tex b/implementation.tex index d79fa97..9ee413f 100644 --- a/implementation.tex +++ b/implementation.tex @@ -12,10 +12,14 @@ The core component of the generation phase of the Topology Helpers. These are ba The following types of topology are currently implemented: -* Tree -* Mesh -* Cube -* Torus +\begin{itemize} + +\item Tree +\item Mesh +\item Cube +\item Torus + +\end{itemize} Each topology type takes a number of parameters and outputs a topology as a result. This topology is then stored in a file. @@ -81,7 +85,7 @@ The topology file details the graph of the network. Specifically it lists the nu The data file details the data sent across the network. After the file header, it lists in order, the sets of packets to be transferred across the network, The first field contains the time to start, interpreted as a double. After this follows descriptors containing the hosts (zero indexed) to send to and from. Finally each section has the number of packets to send across the link. -\subsubsection{State} +%\subsubsection{State}% \subsubsection{Trace} @@ -131,7 +135,7 @@ The algorithm executes in the following way. The algorithm assumes that all the nodes are connected, and that all links are bidrectional, which is the case is the networks I am testing. In the case I am testing the priority queue is also replacable by a normal queue under the condition that all the links have equal cost traversal, which is also the case. -\subsection{Rapid Spanning Tree} +%\subsection{Rapid Spanning Tree} \subsection{Static Routing} diff --git a/toc.tex b/toc.tex index 797e377..2f2c54b 100644 --- a/toc.tex +++ b/toc.tex @@ -1,2 +1,4 @@ \tableofcontents +\listoffigures +