228 lines
9.6 KiB
TeX
228 lines
9.6 KiB
TeX
\documentclass[a4paper,11pt]{article}
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage{lmodern}
|
|
% \usepackage[portuguese]{babel}
|
|
\usepackage[margin=2cm]{geometry}
|
|
\usepackage{fancyhdr}
|
|
\usepackage[backend=bibtex,style=numeric,citestyle=numeric,maxcitenames=3]{biblatex}
|
|
\usepackage{hyperref}
|
|
\usepackage{float}
|
|
\usepackage{multicol}
|
|
\usepackage{graphicx}
|
|
\usepackage{color, colortbl, xcolor}
|
|
|
|
\pagestyle{myheadings}
|
|
\setlength{\parindent}{0pt}
|
|
\setlength{\parskip}{0.85em}
|
|
|
|
\title{Comparative performance evaluation of Low Delay Routing on emulated environment}
|
|
\author{Ádler Oliveira Silva Neves \\ \href{mailto:adler.neves@aluno.ufes.br}{\texttt{adler.neves@aluno.ufes.br}}}
|
|
\date{}
|
|
|
|
\bibliography{gvozdiev2018onlowlatency}
|
|
\bibliography{awslambdapricing}
|
|
\bibliography{lantz2010network}
|
|
\bibliography{ryusdnframework}
|
|
\bibliography{bui2015rethinking}
|
|
\bibliography{kelton2017improving}
|
|
\bibliography{pries2011power}
|
|
|
|
\begin{document}
|
|
\maketitle
|
|
|
|
\begin{abstract}
|
|
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
|
|
\end{abstract}
|
|
|
|
\begin{multicols}{2}
|
|
\section{Introduction} % You will find background information and a statement of the author's hypothesis in the introduction
|
|
|
|
On a world with web services billed by the millisecond, such as AWS Lambda\cite{awslambdapricing}, time is money.
|
|
Accessing a remote database from such environment means that the time spent waiting the connection to establish is money lost.
|
|
On the web, such delay in the response from the server side increases power consumption on mobile devices\cite{bui2015rethinking} and decreases user experience\cite{kelton2017improving}.
|
|
Therefore, reducing such latency is crucial and would bring clear benefits.
|
|
|
|
\citeauthor{gvozdiev2018onlowlatency} proposes Low Delay Routing\cite{gvozdiev2018onlowlatency} (LDR) as a solution for this problem, which is a network routing algorithm that got impressive results on the metrics that reflect its purpose.
|
|
Despite its attractive results on latency, there's no in-depth evaluation of bandwidth and jitter.
|
|
Storage and processing components usually requires that the owner chooses up to two attributes from high speed, high capacity and low cost, and, extending such dilemma to the network area, LDR had to give up somewhere.
|
|
But where? Are there other limits which were not mentioned?
|
|
|
|
\section{Materials and Methods} % The methods section will help you determine exactly how the authors performed the experiment.
|
|
To answer that question, we set up a testing environment with Mininet, Ryu and some own code on a PC equipped with an i7 4790 (4 cores, 8 threads, 4GHz) and 16GB RAM DDR3@1600MHz, running Arch Linux.
|
|
``Mininet is a system for rapidly prototyping large networks on the constrained resources of a single laptop''\cite[p. 1]{lantz2010network}, which was used to create the emulated network and run commands on the hosts it created.
|
|
``Ryu is a component-based software defined networking framework''\cite{ryusdnframework}, which was used to define the behavior that the switches would have using OpenFlow.
|
|
Our own code is a collection of Python scripts and a Makefile, including our re-implementation of \citeauthor{gvozdiev2018onlowlatency}'s as a Ryu controller, which were responsible for routing, monitoring, visualization, automatic testing and both table and chart generation.
|
|
These tools generated the data that will be discussed on section \ref{sec:res}, but, first, we will explain more on how our tool set does what it does on the next subsections.
|
|
|
|
\subsection{Dividing the network for tests}
|
|
Suppose we have an array of hosts, such as:
|
|
|
|
\begin{center}
|
|
\begin{tabular}{|c|c|c|c|c|c|c|c|c|}
|
|
\hline
|
|
h1 & h2 & h3 & h4 & h5 & h6 & h7 & h8 & h9 \\
|
|
\hline
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
An easy way to get pairs to test is split such array in path, discarding the extra member:
|
|
|
|
\begin{center}
|
|
\begin{tabular}{c|c|c|c|c|c}
|
|
\cline{2-5}
|
|
\textcolor{white}{hx} & h1 & h2 & h3 & h4 & \textcolor{gray}{h5} \\
|
|
\cline{2-5}
|
|
\textcolor{white}{hx} & h6 & h7 & h8 & h9 & \textcolor{white}{hx} \\
|
|
\cline{2-5}
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
As {\tt h1} and {\tt h6} were, on some topologies, closer to each other than to {\tt h9} (the last element), and the first pair would be a latency test, it was chosen to reverse the second part.
|
|
The final combination would be:
|
|
|
|
\begin{center}
|
|
\begin{tabular}{|c||c|c|c|}
|
|
\hline
|
|
h1 & h2 & h3 & h4 \\
|
|
\hline
|
|
h9 & h8 & h7 & h6 \\
|
|
\hline
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
That said, {\tt h1} and {\tt h9} are latency tests and all other 3 pairs are bandwidth tests. All tests are run sequentially and then concurrently, in order to measure all links in its idle and overloaded state.
|
|
Between every test there's a wait time that is exactly 2 times the monitoring interval, which is the minimal interval to make the routing algorithm see the entire network as unused.
|
|
Latency is {\tt avg} from {\tt ping} command; jitter, {\tt mdev} from the same command; bandwidth, the bottom line of the {\tt iperf} command running as client, using TCP.
|
|
|
|
\subsection{Representing the topologies}
|
|
The topologies are stored as JSON files.
|
|
Such file contains an array that contains 3 arrays.
|
|
The first array is a list of strings that represents the list of hosts.
|
|
The second array is a list of strings that represents the list of switches.
|
|
The last array is a list of arrays that represents the list of links.
|
|
Every array that represents a link contain an two strings that represents either a host or a switch, and the third element is a number that represents the maximum bandwidth of such link.
|
|
Then, it comes the time to present the topologies.
|
|
|
|
\subsection{The topologies}
|
|
We tested 9 topologies.
|
|
Switches (starts with ``s'', such as ``s3'') were represented by blue circles.
|
|
Hosts (starts with ``h'', such as ``h7'') were represented by green circles.
|
|
When there is no indication of speed on the edge, the speed is 1 mbps.
|
|
The topologies are:
|
|
|
|
\begin{description}
|
|
\item[Triangle:] This topology is a triangle that has a longer and slower path that only becomes a viable path when the shorter and faster is congested.
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/principle.pdf}
|
|
\caption{``Triangle'' topology}
|
|
\label{fig:triangle}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
\item[Binary tree:] asd
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/simpletree.pdf}
|
|
\caption{``Binary tree'' topology}
|
|
\label{fig:bintree}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
\item[Fat tree:] asd
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/fattree.pdf}
|
|
\caption{``Fat tree'' topology}
|
|
\label{fig:fattree}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
\item[3-layered CLOS:] asd
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/clos.pdf}
|
|
\caption{``3-layered CLOS'' topology}
|
|
\label{fig:clos}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
\item[Bipartite:] A CLOS with an extra
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/bipartite.pdf}
|
|
\caption{``Bipartite'' topology}
|
|
\label{fig:bipartite}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
\item[5-layered CLOS:] asd
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/clos5.pdf}
|
|
\caption{``5-layered CLOS'' topology}
|
|
\label{fig:clos5}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
\item[Grid:] asd
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/grid.pdf}
|
|
\caption{``Grid'' topology}
|
|
\label{fig:grid}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
\item[DCell:] This topology, as presented in \citeauthor{pries2011power}'s work \cite{pries2011power},
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/dcell.pdf}
|
|
\caption{``DCell'' topology}
|
|
\label{fig:dcellunused}
|
|
\end{center}
|
|
\end{figure}
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/dcellswitched.pdf}
|
|
\caption{``DCell'' topology with extra switches}
|
|
\label{fig:dcell}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
\item[BCube:] This topology, as presented in \citeauthor{pries2011power}'s work \cite{pries2011power},
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/bcube.pdf}
|
|
\caption{``BCube'' topology}
|
|
\label{fig:bcubeunused}
|
|
\end{center}
|
|
\end{figure}
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\includegraphics[width=0.6\linewidth]{topos/bcubeswitched.pdf}
|
|
\caption{``BCube'' topology with extra switches}
|
|
\label{fig:bcube}
|
|
\end{center}
|
|
\end{figure}
|
|
\end{description}
|
|
|
|
|
|
\subsection{The OpenFlow controller}
|
|
Our Ryu controller got the shortcut of knowing the topology
|
|
|
|
\section{Results} % The results section contains the data collected during experimentation.
|
|
\label{sec:res}
|
|
|
|
|
|
\section{Discussion} % The discussion section will explain the authors interpret their data and how they connect it to other work
|
|
|
|
|
|
\section{Acknowledgments} % The acknowledgments tell you what people or institutions (in addition to the authors) contributed to the work.
|
|
|
|
|
|
\printbibliography
|
|
\end{multicols}
|
|
\end{document}
|