\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.
+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 hardware addresses, in this case, Ethernet MAC addresses.
Here we have a mesh network topology with 25 switches in the mesh, shown in Figure~\ref{fig-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, by using an ARP Request, causing a broadcast packet to be emitted.
\label{fig-mesh}
\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. As 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.
+MOOSE performs poorly when packets are broadcast. This is due to the selection of Reverse Path Forwarding to prevent broadcast storms. Broadcast storms are where, when packets are broadcast to the entire network, they loop around a series of links, causing ever increasing network utilisation. This in turn causes the network to become unusable until the problem is remedied by some external means.
-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.
+Reverse Path Forwarding works by detecting that a frame did not come from the most efficent route from source, and thus it is a duplicate, and thus it can be safely discarded. In MOOSE this works by looking at the source and port combination that a frame arrives at the switch with and checking that a frame sent to that switch would be sent on the same port. If it is, then the frame is flooded on all other ports, in the case of broadcast, otherwise it is dropped. This means that each frame is forwarded to one destination more than it would if a spanning tree existed, as it is only detected as a inefficent route on arrival at a switch, not before it is flooded.
-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.
+In a fully connected mesh network, this is causes very poor broadcast performance, as after the first switch floods the frame to all other ports, each switch which recieves it will have received it on the most efficent port and will flood the frame again. However, all of the switches to which it floods the frame will already have recieved the frame and thus it will be a duplicate.
+
+As a result of 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.
-. 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.
+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.
\subsection{State Table Size}
\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.
+Ethernet performs better when a limited number of hosts are connected by a series of switches. In this situation 15 switches have been connected in a row, with a single host connected to the first and last switch.
%\begin{figure}
%\includegraphics[height=10cm]{simulation-6}
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}
+\subsubsection{MOOSE}
+
+MOOSE performs much better than Ethernet when the hosts are distributed across a number of switches.
+
+To demonstrate this, in this scenario, I have used a tree topology. Each tree has three layers of switches, with one switch on the node, and then branching out to $n$ switches on the layer below, with $n^2$ on the final layer. Each of the final layer of switches has 24 hosts directly attached.
-%MOOSE performs best when there are a number of switches each with a
+The first host is designated as a sink, while each of the other hosts send two packets to the sink. This ensures that each host broadcasts an ARP query, which will ensure that all the state tables contain the relevant data.
+
+As $n$ increases, the size of the Ethernet state table grows at the same speed as $n$, while the MOOSE state table grows as the number of switches grow, which a much lower state of growth. In Figure~\ref{graph-1}, the rate of growth of the Ethernet state table is clearly demonstrated. Here the amount of memory required to realise the same topology is greatly increased.
+
+\begin{figure}
+\centering
+\includegraphics[width=10cm]{simulation-7-2.png}
+\caption{Rate of growth of state tables}
+\end{figure}
\section{Limitations of the Simulation}
\section{Possible Improvements}
-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.
+Testing against real world traces, and incorporating dynamic versions of the routing protocols, and implementing the SAMI protocol \cite{dwh} would increase the use of the data presented here.
\section{MOOSE}