Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Update of Tracing Paper
	- Addition of buffer sizes seen image
	- Slight additions to Tracing Paper body

Signed-off-by: Paul Wortman <paul.mauddib28@gmail.com>
  • Loading branch information
paw10003 committed May 12, 2015
1 parent 1b68031 commit bf32a8a
Show file tree
Hide file tree
Showing 2 changed files with 7 additions and 1 deletion.
Binary file added Images/totalBufSeen.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
8 changes: 7 additions & 1 deletion TracingPaper.tex
Expand Up @@ -157,7 +157,7 @@ All comands sent over the network are coupled to an identifying MID/PID/TID/UID
\subsection{SMB}
\label{SMB}
Server Message Block (SMB) is the modern dialect of Common Internet File System (CIFS). The most important aspect of SAMBA (e.g. SMB) is that it is a stateful protocol , i.e. one where the information being sent via SMB has identifying fields that allow for process ID tracking.
\\The structure for sending message payloads in SMB is as follows: each SMB message is split into three blocks. The first block is a fixed-length SMB header. The second block is made up of two variable-length blocks called the SMB parameters. The third block is made up of the SMB data. Depending on the transaction occurring these different blocks are used in different manners. The purpose of the SMB header is particularly important because the header identifies the message as an SMB message payload~\cite{MS-CIFS}. The most important aspects of the SMB header, which the tracing system constantly examines, are the PID/MID tuple (for the purpose of identifying a client/server) and the commands value which is passed (notifying our tracing system of the actions taking place on the network). It is through this command field that the process ID tracking system is able to follow the different commands (read/write/general event) that occur and try to find patterns in these network communications.
\\The structure for sending message payloads in SMB is as follows: each SMB message is split into three blocks. The first block is a fixed-length SMB header. The second block is made up of two variable-length blocks called the SMB parameters. The third block is made up of the SMB data. Depending on the transaction occurring these different blocks are used in different manners. The purpose of the SMB header is particularly important because the header identifies the message as an SMB message payload~\cite{MS-CIFS} (as shown in Figure~\ref{fig:SMBSpec}). The most important aspects of the SMB header, which the tracing system constantly examines, are the PID/MID tuple (for the purpose of identifying a client/server) and the commands value which is passed (notifying our tracing system of the actions taking place on the network). It is through this command field that the process ID tracking system is able to follow the different commands (read/write/general event) that occur and try to find patterns in these network communications.

\subsection{System Limitations and Challenges}
\label{System Limitations and Challenges}
Expand Down Expand Up @@ -194,6 +194,12 @@ During the three weeks of data observation there was a moritorium on changes/alt

Expectation would dicatate that there will be spikes of activity the week leading up the beginning of the semester, the first few days after the semester starts, and during any moments of maintenance that make use of the network; valleys/low points of activity right before (2 days leading up to) the beginning of the semester, holidays (9/1 - labor day), and general progression of less traffic as the semester progresses. Spikes would be expected to be moments either when new files are being added onto the system (mainly writes), or when a large number of users are attempting to access files (mainly reads). Ditches would most likely show periods of low to no activity, although both the IO \& Bytes graphs should be examined to confirm inactivity rather than something else.

\begin{figure*}
\includegraphics[width=\textwidth,height=4cm]{./images/totalBufSeen.png}
\caption{Summation of Buffer Size Occurrences.}
\label{fig:totalBuf}
\end{figure*}

\subsection{Run Patterns}
\label{Run Patterns}
Interpreting the data collected is done by producing three separate graphs showing three important areas of interest for being able to understand the traffic being examined. These areas are: \textbf{1)} the total number of read/write IO events, \textbf{2)} the occurrrences of different file sizes being read/written, \textbf{3)} the total number of bytes (combined read \& write) that are communicated over the traffic captured by the trace1 system. The reason for needing these three areas of information is that combined together one is able to better interpret all the collected information. By comparing the byte traffic to the IO information this is how we are able to tell not only when the times of greatest traffic are but which types of IO interactions dominate these periods. It should be noted that unfortunately the analysis program does not include a granularity to allow knowledge on whether the read, or write, events are responsible for the most data transfer (via communication) but that is one of the many future additions to this work. From early examinations the data leads us to interpret that the majority of reads are due to client exploring the shared drives \& queries about directories and directory contents, along with users copying large directories of data (most likely for their own purposes). The file size information allows for interpretation of the size of the information that is being passed between the UITS servers and clients (e.g. buffer sizes). Although the granualrity for this information is far corser (24 hours versus the tracked 15 minute time window) it still shows which variations of data lengths were most encountered over the period of the given day. This information coupled with the byte and IO information reflects a priliminary protrait of how the UITS file server system is used, which can be compared to the internal network information that the UITS department keeps for their own maintenance and troubleshooting purposes. The hope is to essentially replicate the data that UITS keeps for their own records.
Expand Down

0 comments on commit bf32a8a

Please sign in to comment.