Fixing Figure references

trackingPaper.tex

@@ -186,7 +186,8 @@ Benchmarks allow for the stress testing of various aspects of a system (e.g. net
 
 We created a new tracing system to collect data from the \textcolor{green}{university}
 %\textcolor{red}{UConn}  
-storage network system.  The tracing system was built around the high-speed PF\_RING packet capture system and required the use of proper hardware and software to handle incoming data\textcolor{blue}{; however interaction with later third-party code did require re-design for processing of the information}.  We also created a new trace capture format derived on the DataSeries structured data format developed by HP~\cite{DataSeries}.
+storage network system.  The tracing system was built around the high-speed PF\_RING packet capture system and required the use of proper hardware and software to handle incoming data%\textcolor{blue}{; however interaction with later third-party code did require re-design for processing of the information}
+.  We also created a new trace capture format derived on the DataSeries structured data format developed by HP~\cite{DataSeries}.
 % PF\_RING section
 %The addition of PF\_RING lends to the tracing system by minimizing the copying of packets which, in turn, allows for more accurate timestamping of incoming traffic packets being captured ~\cite{Orosz2013,skopko2012loss,pfringWebsite,PFRINGMan}.  
 PF\_RING acts as a kernel module that aids in minimizing packet loss/timestamping issues by not passing packets through the kernel data structures~\cite{PFRINGMan}.  
@@ -463,7 +464,8 @@ Cancel & \multicolumn{2}{|c|}{0}	&	0.00\% \\
 %	\label{fig:IO-R+W}
 %\end{figure}
 Each SMB Read and Write command is associated with a data request size that indicates how many bytes are to be read or written as part of that command.
-Figures~\ref{fig:PDF-Bytes-Read} and~\ref{fig:PDF-Bytes-Write} show the probability density function (PDF) of the different sizes of bytes transferred for read and write I/O operations respectively.  The most noticeable aspect of these graphs are that the majority of bytes transferred for read and write operations is around 64 bytes.  It is worth noting that write I/O also have a larger number of very small transfer amounts.  This is unexpected in terms of the amount of data passed in a frame.  Our belief is that this is due to a large number of long term calculations/scripts being run that only require small but frequent updates. This assumption was later validated in part when examining the files transferred, as some were related to running scripts creating a large volume of files, however the more affirming finding was the behavior observed with common applications.  For example, it was seen that Microsoft Word would perform a large number of small reads at ever growing offsets.  This was interpreted as when a user is viewing a document over the network and Word would load the next few lines of text as the user scrolled down the document; causing ``loading times'' amid use.  A large degree of small writes were observed to be related to application cookies or other such smaller data communications.
+Figure~\ref{fig:SMB-Bytes-IO} %and~\ref{fig:PDF-Bytes-Write} 
+shows the probability density function (PDF) of the different sizes of bytes transferred for read and write I/O operations respectively.  The most noticeable aspect of these graphs are that the majority of bytes transferred for read and write operations is around 64 bytes.  It is worth noting that write I/O also have a larger number of very small transfer amounts.  This is unexpected in terms of the amount of data passed in a frame.  Our belief is that this is due to a large number of long term calculations/scripts being run that only require small but frequent updates. This assumption was later validated in part when examining the files transferred, as some were related to running scripts creating a large volume of files, however the more affirming finding was the behavior observed with common applications.  For example, it was seen that Microsoft Word would perform a large number of small reads at ever growing offsets.  This was interpreted as when a user is viewing a document over the network and Word would load the next few lines of text as the user scrolled down the document; causing ``loading times'' amid use.  A large degree of small writes were observed to be related to application cookies or other such smaller data communications.
 %This could also be attributed to simple reads relating to metadata\textcolor{red}{???}
 
 %\textcolor{blue}{Reviewing of the SMB and SMB2 leads to some confusion in understanding this behavior.  According to the specification the default ``MaxBuffSize'' for reads and writes should be between 4,356 bytes and 16,644 bytes depending on the use of either a client version of server version of Windows; respectively.  In the SMB2 protocol specification, specific version of Windows (e.g. Vista SP1, Server 2008, 7, Server 2008 R2, 8, Server 2012, 8.1, Server 2012 R2) disconnect if the ``MaxReadSize''/``MaxWriteSize'' value is less than 4096.  However, further examination of the specification states that for SMB2 the read length and write length can be zero.  Thus, this seems to conflict that the size has to be greater than 4096 but allows for it to also be zero.  It is due to this protocol specification of allowing zero that supports the smaller read/write sizes seen in the captured traffic.  The author's assumption here is that the university's configuration allows for smaller traffic to be exchanged without the disconnection for sizes smaller than 4096.}
@@ -520,7 +522,8 @@ Figures~\ref{fig:PDF-Bytes-Read} and~\ref{fig:PDF-Bytes-Write} show the probabil
 %	\caption{CDF of Bytes Transferred for Read+Write I/O}
 %	\label{fig:CDF-Bytes-RW}
 %\end{figure}
-Figures~\ref{fig:CDF-Bytes-Read} and~\ref{fig:CDF-Bytes-Write} show cumulative distribution functions (CDF) for bytes read and bytes written.  As can be seen, almost no read transfer sizes are less than 32 bytes, whereas 20\% writes below 32 bytes.  Table~\ref{fig:transferSizes} shows a tabular view of this data.  For reads, $34.97$\% are between 64 and 512 bytes, with another $28.86$\% at 64 byte request sizes.  There are a negligible percentage of read requests larger than 512.
+Figure~\ref{fig:SMB-Bytes-IO} %and~\ref{fig:CDF-Bytes-Write} 
+shows cumulative distribution functions (CDF) for bytes read and bytes written.  As can be seen, almost no read transfer sizes are less than 32 bytes, whereas 20\% writes below 32 bytes.  Table~\ref{fig:transferSizes} shows a tabular view of this data.  For reads, $34.97$\% are between 64 and 512 bytes, with another $28.86$\% at 64 byte request sizes.  There are a negligible percentage of read requests larger than 512.
 This read data differs from the size of reads observed by Leung et al. by a factor of four smaller.
 %This read data is similar to what was observed by Leung et al, however at an order of magnitude smaller.  
 Writes observed also differ from previous inspection of the protocol's usage.  % are very different.  
@@ -636,14 +639,14 @@ Other observations of the data show that the number of writes is very close to t
 \begin{figure}[t!]
 	\includegraphics[width=0.5\textwidth]{./images/smb_2019_iats_cdf.png}
 	\caption{CDF of Inter-Arrival Time for SMB I/O}
-	\label{fig:CDF-RT-SMB}
+	\label{fig:CDF-IAT-SMB}
 	%\vspace{-2em}
 \end{figure}
 
 \begin{figure}[t!]
 	\includegraphics[width=0.5\textwidth]{./images/smb_2019_iats_pdf.png}
 	\caption{PDF of Inter-Arrival Time for SMB I/O}
-	\label{fig:PDF-RT-SMB}
+	\label{fig:PDF-IAT-SMB}
 	%\vspace{-2em}
 \end{figure}
 
@@ -748,10 +751,10 @@ Avg IAT ($\mu$s) &    33220.8   & \multicolumn{1}{r|}{35260.4} & \multicolumn{1}
 %%	\end{itemize}
 %%\end{enumerate}
 %
-Figure~\ref{fig:CDF-IAT-General} shows the inter arrival times CDF for general I/O.  As can be seen, SMB commands happen very frequently - $85$\% of commands are issued less than 1024~$\mu s$ apart.  As was mentioned above, the SMB protocol is known to be very chatty, and it is clear that servers must spend a lot of time dealing with these commands.  For the most part, most of these commands are also serviced fairly quickly as 
-seen in Figure~\ref{fig:CDF-RT-General}.  Interestingly, the response/return time (RT) for the general metadata operations follows a similar curve to the inter-arrival times.
+Figure~\ref{fig:CDF-IAT-SMB} shows the inter arrival times CDF for general I/O.  As can be seen, SMB commands happen very frequently - $85$\% of commands are issued less than 1024~$\mu s$ apart.  As was mentioned above, the SMB protocol is known to be very chatty, and it is clear that servers must spend a lot of time dealing with these commands.  For the most part, most of these commands are also serviced fairly quickly as 
+seen in Figure~\ref{fig:CDF-RT-SMB}.  Interestingly, the response/return time (RT) for the general metadata operations follows a similar curve to the inter-arrival times.
 
-Next we examine the response time (RT) of the read, write, and create I/O operations that occur over the SMB network filesystem.  The response time for write operations (shown in Figure~\ref{fig:CDF-RT-Write}) does not follow the step function similar to the bytes written CDF in Figure~\ref{fig:CDF-Bytes-Write}.  This is understandable as the response time for a write would be expected to be a more standardized action and not necessarily proportional to the number of bytes written.  However, the read response time (Figure~\ref{fig:CDF-RT-Read}) is smoother than the bytes read CDF (Figure~\ref{fig:CDF-Bytes-Write}).  This is most likely due to the fact that some of the reads are satisfied by server caches, thus eliminating some long access times to persistent storage.  
+Next we examine the response time (RT) of the read, write, and create I/O operations that occur over the SMB network filesystem.  The response time for write operations (shown in Figure~\ref{fig:CDF-RT-SMB}) does not follow the step function similar to the bytes written CDF in Figure~\ref{fig:SMB-Bytes-IO}.  This is understandable as the response time for a write would be expected to be a more standardized action and not necessarily proportional to the number of bytes written.  However, the read response time (Figure~\ref{fig:CDF-RT-SMB}) is smoother than the bytes read CDF (Figure~\ref{fig:SMB-Bytes-IO}).  This is most likely due to the fact that some of the reads are satisfied by server caches, thus eliminating some long access times to persistent storage.  
 However, one should notice that the response time on read operations grows at a rate similar to that of write operations.  This, again, shows a form of standardization in the communication patterns although some read I/O take a far greater period of time; due to larger amounts of read data sent over several standardized size packets.
 %While the RT for Write operations are not included (due to their step function behavior) Figure~\ref{fig:CDF-RT-Read} and Figure~\ref{fig:CDF-RT-RW} show the response times for Read and Read+Write operations respectively.  T
 %\textcolor{red}{The write I/O step function behavior is somewhat visible in the CDF of both reads and writes in Figures~\ref{fig:CDF-RT-Read}~and~\ref{fig:CDF-RT-Write}.  Moreover, this shows that the majority ($80$\%) of read (and write) operations occur within 2~$ms$, the average access time for enterprise storage disks.  As would be expected, this is still an order of magnitude greater than the general I/O.}