Update

main.tex

@@ -20,7 +20,7 @@
 \maketitle
 
 \begin{abstract}
-Packet losses are known to affect the performance of latency sensitive applications in the Internet such as media streaming and gaming. Transport protocols recover from packet loss in order to provide reliable end to end communication and improving the quality of user experience. The efficiency of loss recovery greatly influences the completion time of flows. In this paper we focus on the state of the art loss recovery mechanisms for TCP and Multipath TCP. We use controlled tail loss scenarios to evaluate the performance of loss recovery mechanisms. Based on the observations, we propose an enhancement to the tail loss recovery in Multipath TCP to improve the loss recovery time. Our experiment results show consistent end to end latency performance improvement in considered scenarios. 
+Packet losses are known to affect the performance of latency sensitive applications in the Internet such as media streaming and gaming. Transport protocols recover from packet loss in order to provide reliable end to end communication and improving the quality of user experience. The efficiency of loss recovery greatly influences the completion time of flows. In this paper we focus on state of the art loss recovery mechanisms for TCP and Multipath TCP. We use controlled tail loss scenarios to evaluate the performance of loss recovery mechanisms. Based on the observations, we propose an enhancement to the tail loss recovery in Multipath TCP to improve the loss recovery time. Our experiment results show consistent end to end latency performance improvement in considered scenarios. 
 \end{abstract}
 
 \section{Introduction}
@@ -50,11 +50,14 @@ \section{Background and Related Work}\label{relwork}
 
 %\subsection{Scope}\label{scope}
 
-This paper analyzes the performance of state of the art loss recovery mechanism of MPTCP and presents a case for improvement in the tail loss scenario. 
-For understanding the loss recovery and retransmission policies in MPTCP Linux implementation version 0.91, we consider several specific cases of tail losses.  
-We use the standard settings of the Linux kernel.
-The Linux implementation of TCP is considered as the baseline TCP retransmission for implementation flexibility and availability of TLP support.
+This paper analyzes the performance of state of the art loss recovery mechanism of MPTCP and presents a case for improvement in the tail loss scenario.For understanding the loss recovery and retransmission policies in MPTCP Linux implementation version 0.91, we consider several specific cases of tail losses. We use the standard settings of the Linux kernel. The Linux implementation of TCP is considered as the baseline TCP retransmission for implementation flexibility and availability of TLP support.
 
+\begin{figure}[!ht]
+\begin{center}
+\includegraphics[angle=0, width=0.45\textwidth]{images/fortest.pdf}
+\caption{Topology used for Emulation}\label{fig1}
+\end{center}
+\end{figure}
 %\kern-1em
 \section{Experimental Setup}\label{exsetup}
 
@@ -65,12 +68,6 @@ \section{Experimental Setup}\label{exsetup}
 There is no attempt in this study to focus on the effect of link detailed characteristics in retransmission performance.
 
 
-\begin{figure}[!ht]
-\begin{center}
-\includegraphics[angle=0, width=0.45\textwidth]{images/fortest.pdf}
-\caption{Topology used for Emulation}\label{fig1}
-\end{center}
-\end{figure}
 \begin{center}
 
 \begin{table}
@@ -103,8 +100,7 @@ \section{Experimental Setup}\label{exsetup}
 
 %\kern-1em
 \subsection{Testing retransmission with deterministic loss patterns}
-In order to understand the retransmission behavior of the Linux MPTCP implementation and to reproduce the observed retransmissions, we use a deterministic drop pattern.
-Losses are generated by associating netem with corresponding interfaces and dropping select packets. This process is simplified by using the KAUNetem tool~\cite{Garcia2016}, which allows experimenter to e.g., drop packets based on their positions in a flow. A MPTCP connection starts with a single TCP subflow and subsequently, one or more subflows are added following an agreement between the client and the server. So one has to wait both in time and packets for the second subflow establishment. We send two bursts of 80 packets each and drop tail packets in the second burst at one of the interfaces. This is to ensure that the necessary and sufficient conditions for probe triggering are met and tail loss probe is generated on that subflow. We calculate the burst completion time for the second burst that has specified tail losses. The objective of this experiment is to evaluate retransmission mechanisms with tail loss (single packet loss and multiple tail loss) and temporary path loss. Three test cases are considered for experiments: single packet tail loss and two packet tail loss for tail loss evaluation and single packet along with probe~(in TLP) or retransmission~(in RTO) loss for path loss evaluation. 
+In order to understand the retransmission behavior of the Linux MPTCP implementation and to reproduce the observed retransmissions, we use a deterministic drop pattern. Losses are generated by associating netem with corresponding interfaces and dropping select packets. This process is simplified by using the KAUNetem tool~\cite{Garcia2016}, which allows experimenter to e.g., drop packets based on their positions in a flow. A MPTCP connection starts with a single TCP subflow and subsequently, one or more subflows are added following an agreement between the client and the server. So one has to wait both in time and packets for the second subflow establishment. We send two bursts of 80 packets each and drop tail packets in the second burst at one of the interfaces. This is to ensure that the necessary and sufficient conditions for probe triggering are met and tail loss probe is generated on that subflow. We calculate the burst completion time for the second burst that has specified tail losses. The objective of this experiment is to evaluate retransmission mechanisms with tail loss (single packet loss and multiple tail loss) and temporary path loss. Three test cases are considered for experiments: single packet tail loss and two packet tail loss for tail loss evaluation and single packet along with probe~(in TLP) or retransmission~(in RTO) loss for path loss evaluation. 
 
 In Linux, TCP supports multiple retransmission mechanisms that can be controlled by a system setting. The default setting in Linux enables both
 ER and TLP, which may not be the case with other operating systems. In this paper, we use TLP to denote the default Linux setting and RTO to denote the use of retransmission timeout only.
@@ -115,20 +111,6 @@ \subsection{Testing retransmission with deterministic loss patterns}
 \section{Observations and Discussion}\label{disc}
 This section provides the performance analysis of TCP and MPTCP for the considered cases of single packet tail loss, two packet tail loss and retransmission or probe loss.
 \kern-5em
-\subsection{TCP}
-Retransmission behavior of TCP provides a base case for MPTCP performance as each individual MPTCP subflow is a TCP flow in itself. Our analysis
-starts with the results using TCP and compare it with that of MPTCP. Figure~\ref{tcpf} represent the comparison of TCP 
-burst completion times. Path asymmetry is irrelevant in this case as TCP uses a single path.
-
-In the case of single packet tail loss as shown in Figure~\ref{t1p}, there is no difference in burst completion times of RTO and TLP settings. The retransmission
-timeout and the probe timeout are the same as there is only one outstanding packet. This is a special case in the TLP
-specification that adds 200\,ms to the PTO accommodating the case of delayed ACKs. The TLP implementation in Linux accounts
-for the delayed ACK and waits 200\,ms before sending a probe. The minimum of PTO and RTO is considered for PTO. In the case of two packet tail loss as shown in Figure~\ref{t2p},
-TLP performs better than the RTO retransmission for lower delay values. As the delay on the loss path increases RTO retransmission performs slightly better than TLP. In 120\,ms case, PTO is very close to RTO expiration and the second packet is recovered using ER which incurs additional delay in case of TLP. In RTO retransmission, all unacknowledged packets are retransmitted on a RTO expiration. 
-
-Hence retransmission timeout is the mode of loss recovery in both RTO and TLP. This can be avoided by tuning
-the ACKs as discussed in~\cite{Rajiullah:2015}. In the case of two packet tail loss, TLP performs better than RTO retransmission as it employs a combination of TLP and ER to recover from losses. If the probe or retransmission is lost, then TLP still performs better than RTO retransmission as it waits for one probe timeout and one RTO experiation instead of two RTO expirations, thus avoiding the exponential backoff of the RTO.
-
 \begin{figure*}[!tbp]
  \begin{subfigure}[b]{0.32\textwidth}
 	\includegraphics[angle=0, width=\textwidth,natwidth=578.16,natheight=433.62]{plots/T1P.pdf}
@@ -146,6 +128,20 @@ \subsection{TCP}
  \end{subfigure}
  \caption{Tail loss scenarios using TCP}\label{tcpf}
 \end{figure*}
+\subsection{TCP}
+Retransmission behavior of TCP provides a base case for MPTCP performance as each individual MPTCP subflow is a TCP flow in itself. Our analysis
+starts with the results using TCP and compare it with that of MPTCP. Figure~\ref{tcpf} represent the comparison of TCP 
+burst completion times. Path asymmetry is irrelevant in this case as TCP uses a single path.
+
+In the case of single packet tail loss as shown in Figure~\ref{t1p}, there is no difference in burst completion times of RTO and TLP settings. The retransmission
+timeout and the probe timeout are the same as there is only one outstanding packet. This is a special case in the TLP
+specification that adds 200\,ms to the PTO accommodating the case of delayed ACKs. The TLP implementation in Linux accounts
+for the delayed ACK and waits 200\,ms before sending a probe. The minimum of PTO and RTO is considered for PTO. In the case of two packet tail loss as shown in Figure~\ref{t2p},
+TLP performs better than the RTO retransmission for lower delay values. As the delay on the loss path increases RTO retransmission performs slightly better than TLP. In 120\,ms case, PTO is very close to RTO expiration and the second packet is recovered using ER which incurs additional delay in case of TLP. In RTO retransmission, all unacknowledged packets are retransmitted on a RTO expiration. 
+
+Hence retransmission timeout is the mode of loss recovery in both RTO and TLP. This can be avoided by tuning
+the ACKs as discussed in~\cite{Rajiullah:2015}. In the case of two packet tail loss, TLP performs better than RTO retransmission as it employs a combination of TLP and ER to recover from losses. If the probe or retransmission is lost, then TLP still performs better than RTO retransmission as it waits for one probe timeout and one RTO experiation instead of two RTO expirations, thus avoiding the exponential backoff of the RTO.
+
 %\kern-1em
 \subsection{MPTCP}
 
@@ -171,15 +167,6 @@ \subsection{MPTCP}
  \caption{Timing diagrams of MPTCP behavior on tail losses with a) RTO b) TLP }\label{mptiming}	
 \end{figure*}
 
-
-MPTCP uses an RTT based scheduler by default, that uses the lowest RTT path among the available paths to transmit
-the data until its congestion window is full. Subsequently, the next lowest RTT path is chosen. MPTCP performance
-is sensitive to asymmetry in paths. The burst completion times on single packet tail loss calculated for each delay 
-configuration and retransmission setting is depicted in Figure~\ref{1p}. There is no difference in performance of RTO retransmission and TLP for 
-cases when both paths are symmetric or the first path has lowest RTT. RTO performs better than TLP when the first path is not the lowest RTT path. In such
-scenarios~(30\,ms-20\,ms,120\,ms-20\,ms), the RTO retransmission happens in the second path with lowest RTT following the behavior depicted
-in Figure~\ref{timing1P}.
-
 \renewcommand{\thesubfigure}{\alph{subfigure}}
 \begin{figure*}[!tbp]
  \begin{subfigure}[b]{0.32\textwidth}
@@ -199,6 +186,15 @@ \subsection{MPTCP}
  \caption{Tail loss scenarios using MPTCP}
 \end{figure*}
 
+MPTCP uses an RTT based scheduler by default, that uses the lowest RTT path among the available paths to transmit
+the data until its congestion window is full. Subsequently, the next lowest RTT path is chosen. MPTCP performance
+is sensitive to asymmetry in paths. The burst completion times on single packet tail loss calculated for each delay 
+configuration and retransmission setting is depicted in Figure~\ref{1p}. There is no difference in performance of RTO retransmission and TLP for 
+cases when both paths are symmetric or the first path has lowest RTT. RTO performs better than TLP when the first path is not the lowest RTT path. In such
+scenarios~(30\,ms-20\,ms,120\,ms-20\,ms), the RTO retransmission happens in the second path with lowest RTT following the behavior depicted
+in Figure~\ref{timing1P}.
+
+
 
 
 
@@ -207,9 +203,7 @@ \subsection{MPTCP}
 the latest packet is sent as probe to trigger fast retransmit of the packets in between. In order to observe
 the performance of n-degree tail loss, we consider dropping the last two packets. 
 The results of two packet tail loss are shown in Figure~\ref{2p}. In this case, TLP performs better than the other 
-two settings in all scenarios except when the packets are lost on a high delay interface. In this scenario, the MPTCP retransmission follows the 
-behavior depicted in Figure~\ref{timing2P} and the delay difference is large enough that the retransmission of the last packet on the alternate path is 
-faster than the probe on the primary path. 
+two settings in all scenarios except when the packets are lost on a high delay interface. In this scenario, the MPTCP retransmission follows the behavior depicted in Figure~\ref{timing2P} and the delay difference is large enough that the retransmission of the last packet on the alternate path is faster than the probe on the primary path. 
 
 
 To further study the performance of TLP in the case when there is longer path interruption on one path, we tried to drop the probe packet along with the last packet. In this scenario, the RTO