diff --git a/Thumbs.db b/Thumbs.db index 45536dc..15d7706 100644 Binary files a/Thumbs.db and b/Thumbs.db differ diff --git a/TracingPaper.aux b/TracingPaper.aux index 5d53de5..3ee5c29 100644 --- a/TracingPaper.aux +++ b/TracingPaper.aux @@ -42,62 +42,54 @@ \citation{PFRINGMan} \citation{PFRING} \citation{PFRINGMan} +\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Previous Advances Due to Testing}{2}} +\newlabel{Previous Advances Due to Testing}{{1.2}{2}} +\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Contributions}{2}} +\newlabel{Contributions}{{1.3}{2}} +\@writefile{toc}{\contentsline {section}{\numberline {2}Trace Collection}{2}} +\newlabel{Trace Collection}{{2}{2}} +\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Procedure}{2}} +\newlabel{Procedure}{{2.1}{2}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.1.1}Capture}{2}} +\newlabel{Capture}{{2.1.1}{2}} +\citation{MS-CIFS} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.1.2}Collection}{3}} +\newlabel{Collection}{{2.1.2}{3}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.1.3}Dissection/Analysis}{3}} +\newlabel{Dissection/Analysis}{{2.1.3}{3}} +\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}ID Tracking}{3}} +\newlabel{ID Tracking}{{2.2}{3}} +\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}SMB}{3}} +\newlabel{SMB}{{2.3}{3}} \citation{Orosz2013} \citation{Dabir2008} \citation{Skopko2012} \citation{Orosz2013} \citation{Ellard2003} \citation{Anderson2004} -\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Previous Advances Due to Testing}{2}} -\newlabel{Previous Advances Due to Testing}{{1.2}{2}} -\@writefile{toc}{\contentsline {section}{\numberline {2}Methodology}{2}} -\newlabel{Methodology}{{2}{2}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Interesting Aspects of Research}{2}} -\newlabel{Interesting Aspects of Research}{{2.1}{2}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}System Limitations}{2}} -\newlabel{System Limitations}{{2.2}{2}} \citation{Leung2008} \citation{Ellard2003} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}General Challenges}{3}} -\newlabel{General Challenges}{{2.3}{3}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}Interpretation of Data}{3}} -\newlabel{Interpretation of Data}{{2.4}{3}} -\@writefile{toc}{\contentsline {subsection}{\numberline {2.5}Scope of Interpretation}{3}} -\newlabel{Scope of Interpretation}{{2.5}{3}} -\@writefile{toc}{\contentsline {section}{\numberline {3}Tracing System}{3}} -\newlabel{Tracing System}{{3}{3}} -\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Stages of Trace}{3}} -\newlabel{Stages of Trace}{{3.1}{3}} -\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.1}Capture}{3}} -\newlabel{Capture}{{3.1.1}{3}} -\citation{MS-CIFS} -\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.2}Collection}{4}} -\newlabel{Collection}{{3.1.2}{4}} -\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.3}Dissection/Analysis}{4}} -\newlabel{Dissection/Analysis}{{3.1.3}{4}} -\@writefile{toc}{\contentsline {section}{\numberline {4}Trace Analysis}{4}} -\newlabel{Trace Analysis}{{4}{4}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}SMB}{4}} -\newlabel{SMB}{{4.1}{4}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}ID Tracking}{4}} -\newlabel{ID Tracking}{{4.2}{4}} +\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}System Limitations and Challenges}{4}} +\newlabel{System Limitations and Challenges}{{2.4}{4}} \citation{Traeger2008} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.3}System Information and Predictions}{5}} -\newlabel{System Information and Predictions}{{4.3}{5}} +\@writefile{toc}{\contentsline {section}{\numberline {3}Trace Analysis}{5}} +\newlabel{Trace Analysis}{{3}{5}} +\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}System Information and Predictions}{5}} +\newlabel{System Information and Predictions}{{3.1}{5}} \citation{Douceur1999} \citation{RuemmlerWilkes1993} \citation{Bolosky2007} \citation{EllardLedlie2003} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.4}Run Patterns}{6}} -\newlabel{Run Patterns}{{4.4}{6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {4.5}Locating Performance Bottlenecks}{6}} -\newlabel{Locating Performance Bottlenecks}{{4.5}{6}} -\@writefile{toc}{\contentsline {section}{\numberline {5}Intuition Confirm/Change}{6}} -\newlabel{Intuition Confirm/Change}{{5}{6}} -\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Characterizations of Different Packet Types}{6}} -\newlabel{Characterizations of Different Packet Types}{{5.1}{6}} -\@writefile{toc}{\contentsline {section}{\numberline {6}Conclusion}{6}} -\newlabel{Conclusion}{{6}{6}} +\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Run Patterns}{6}} +\newlabel{Run Patterns}{{3.2}{6}} +\@writefile{toc}{\contentsline {subsection}{\numberline {3.3}Locating Performance Bottlenecks}{6}} +\newlabel{Locating Performance Bottlenecks}{{3.3}{6}} +\@writefile{toc}{\contentsline {section}{\numberline {4}Intuition Confirm/Change}{6}} +\newlabel{Intuition Confirm/Change}{{4}{6}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Characterizations of Different Packet Types}{6}} +\newlabel{Characterizations of Different Packet Types}{{4.1}{6}} +\@writefile{toc}{\contentsline {section}{\numberline {5}Conclusion}{6}} +\newlabel{Conclusion}{{5}{6}} \bibcite{Leung2008}{1} \bibcite{Ellard2003}{2} \bibcite{EllardLedlie2003}{3} diff --git a/TracingPaper.log b/TracingPaper.log index ae26f73..56194f3 100644 --- a/TracingPaper.log +++ b/TracingPaper.log @@ -1,4 +1,4 @@ -This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.11.13) 16 MAR 2015 17:12 +This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.11.13) 17 MAR 2015 16:57 entering extended mode **C:/Users/rundeMT/Documents/UConn/TracingPaper/TracingPaper.tex (C:/Users/rundeMT/Documents/UConn/TracingPaper/TracingPaper.tex @@ -166,82 +166,104 @@ Underfull \vbox (badness 1436) has occurred while \output is active [] [1{C:/ProgramData/MiKTeX/2.9/pdftex/config/pdftex.map} -] [2] -Underfull \vbox (badness 3657) has occurred while \output is active [] +] - [3] +LaTeX Warning: Reference `Tracing System' on page 2 undefined on input line 110 +. + +[2] LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <10> not available -(Font) Font shape `OT1/ptm/b/it' tried instead on input line 176. +(Font) Font shape `OT1/ptm/b/it' tried instead on input line 146. + [3] +Underfull \hbox (badness 2042) in paragraph at lines 159--161 +\OT1/ptm/m/n/10 been fil-tered for spe-cific pro-to-col in-for-ma-tion and + [] + + +Underfull \hbox (badness 1552) in paragraph at lines 159--161 +\OT1/ptm/m/n/10 to how the packet cap-tur-ing drivers and pro-grams + [] -[4] -Underfull \vbox (badness 10000) has occurred while \output is active [] +Underfull \hbox (badness 10000) in paragraph at lines 159--161 -Underfull \hbox (badness 10000) in paragraph at lines 214--215 + [] + + +LaTeX Warning: Reference `Tracing System' on page 4 undefined on input line 164 +. + +[4] +Underfull \hbox (badness 10000) in paragraph at lines 207--208 [] -[5] -LaTeX Font Info: Try loading font information for OMS+ptm on input line 221. +LaTeX Font Info: Try loading font information for OMS+ptm on input line 214. - ("C:\Program Files\MiKTeX 2.9\tex\latex\psnfss\omsptm.fd" +("C:\Program Files\MiKTeX 2.9\tex\latex\psnfss\omsptm.fd" File: omsptm.fd ) LaTeX Font Info: Font shape `OMS/ptm/m/n' in size <10> not available -(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 221. +(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 214. + [5] +Underfull \vbox (badness 10000) has occurred while \output is active [] + -Underfull \hbox (badness 1077) in paragraph at lines 387--388 +Underfull \hbox (badness 1077) in paragraph at lines 242--243 \OT1/ptm/m/n/10 not only pull out in-for-ma-tion per-ta-nent to the [] [6] -Underfull \hbox (badness 10000) in paragraph at lines 429--430 +Underfull \hbox (badness 10000) in paragraph at lines 284--285 []\OT1/ptm/m/it/10 Common In-ter-net File Sys-tem (CIFS) Pro- [] -Underfull \hbox (badness 10000) in paragraph at lines 429--430 +Underfull \hbox (badness 10000) in paragraph at lines 284--285 \OT1/ptm/m/it/10 to-col\OT1/ptm/m/n/10 , urlhttp://msdn.microsoft.com/en- [] -Underfull \hbox (badness 10000) in paragraph at lines 431--432 +Underfull \hbox (badness 10000) in paragraph at lines 286--287 []\OT1/ptm/m/it/10 Server Mes-sage Block (SMB) Pro-to- [] -Underfull \hbox (badness 10000) in paragraph at lines 431--432 +Underfull \hbox (badness 10000) in paragraph at lines 286--287 \OT1/ptm/m/it/10 col\OT1/ptm/m/n/10 , urlhttp://msdn.microsoft.com/en- [] -Underfull \hbox (badness 10000) in paragraph at lines 446--448 +Underfull \hbox (badness 10000) in paragraph at lines 301--303 []\OT1/ptm/m/it/10 PF[]RING User Guide\OT1/ptm/m/n/10 , url- [] -Overfull \hbox (61.33023pt too wide) in paragraph at lines 446--448 +Overfull \hbox (61.33023pt too wide) in paragraph at lines 301--303 \OT1/ptm/m/n/10 https://svn.ntop.org/svn/ntop/trunk/PF[]RING/doc/UsersGuide.pdf [] -[7] (C:\Users\rundeMT\Documents\UConn\TracingPaper\TracingPaper.aux) ) +[7] (C:\Users\rundeMT\Documents\UConn\TracingPaper\TracingPaper.aux) + +LaTeX Warning: There were undefined references. + + ) Here is how much of TeX's memory you used: - 1480 strings out of 494049 - 19972 string characters out of 3146058 - 80689 words of memory out of 3000000 - 4772 multiletter control sequences out of 15000+200000 + 1477 strings out of 494049 + 19899 string characters out of 3146058 + 78651 words of memory out of 3000000 + 4769 multiletter control sequences out of 15000+200000 20443 words of font info for 42 fonts, out of 3000000 for 9000 715 hyphenation exceptions out of 8191 34i,8n,21p,2172b,435s stack positions out of 5000i,500n,10000p,200000b,50000s -{C:/Progr -am Files/MiKTeX 2.9/fonts/enc/dvips/fontname/8r.enc} -Output written on TracingPaper.pdf (7 pages, 114706 bytes). +{C:/Program Files/MiKTeX 2.9/fonts/enc/dvips/fontname/8r.enc} +Output written on TracingPaper.pdf (7 pages, 115073 bytes). PDF statistics: 51 PDF objects out of 1000 (max. 8388607) 0 named destinations out of 1000 (max. 500000) diff --git a/TracingPaper.pdf b/TracingPaper.pdf index 8e6ce16..38cbe3d 100644 Binary files a/TracingPaper.pdf and b/TracingPaper.pdf differ diff --git a/TracingPaper.synctex.gz b/TracingPaper.synctex.gz index 7ac500e..1d91e00 100644 Binary files a/TracingPaper.synctex.gz and b/TracingPaper.synctex.gz differ diff --git a/TracingPaper.tex b/TracingPaper.tex index d435a7f..48047ac 100644 --- a/TracingPaper.tex +++ b/TracingPaper.tex @@ -109,49 +109,25 @@ As has been pointed out by past work, the design of systems is usually guided by A detailed overview of the tracings and analysis system can be seen in section ~\ref{Tracing System}. The hope is to further the progress made with benchmarks \& tracing in the hope that it too will lend to improving and deepening the knowledge and understanding of these systems so that as a result the technology and methodology is bettered as a whole. -%\subsection{My Work} -%\label{My Work} -%Certain elements of this research are purposed to improve tracing knowledge along with general understanding of networked systems. One such element is the delevopment of tracking IO inter-arrival times along with processor times. This allows for more realistic replay of commands run due to more complete temporal considerations; time taken for computation and "travel" time. Another elements is the PID/MID/TID/UID tracking which allows for following command executions between a given client and server. This element paired with the previous development helps expand the understanding and replay-ability of temporal scaling. -%Things to make sure to say: Need trace of CIFS behavior. -%The following are issues that our work hopes to alleviate: there has been no large scale study done on networks for some time, there has been no study on CIFS(Common Internet File System)/SMB(Server Message Block) protocols for even longer, and most importantly these studies have not tackled lower level aspects of the trace, such as spacial \& temporal scaling idiosyncrasies of network communication. It is for these reasons that we have developed this tracing system and have developed new studies for lower level aspects of communication network. \\ - -\section{Methodology} -\label{Methodology} - -\subsection{Interesting Aspects of Research} -\label{Interesting Aspects of Research} -\textbf{RENAME THIS SECTION SOMETHING MORE INTELLIGENT} \\ +\subsection{Contributions} +\label{Contributions} Out of all the elements that make up the tracing system used for this research, there are a few key aspects that are worth covering due to their uniqueness within the system. These key components of the tracing system are the use of PF\_RING to mitigate timing and resource concerns, the use of proper hardware and software to handle incoming data, along with the tweaking of DataSeries code to create analysis tools for the captured data. % 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,Skopko2012,PFRING,PFRINGMan}. PF\_RING acts as a kernel module which allows for kernel-based capture and sampling that limits packet loss and timestamping overhead leading to faster packet capture while efficiently preserving CPU cycles ~\cite{PFRING}. This aids in minimizing packet loss/timestamping issues by not passing packets through the kernel data structures~\cite{PFRINGMan}. The other reason PF\_RING is instrumental is that it functions with the 10Gb/s hardware that was installed into the Trace1 server; allowing for full throughput from the network tap on the UITS system. \\ % DataSeries + Code section The tweaks and code additions to the existing DataSeries work are filtering for specific CIFS/SMB protocol fields along with the writing of analysis tools to parse and dissect the captured packets. Specific fields were chosen to be the interesting fields to be kept for analysis. It should be noted that this was done arbitrarily and changes/additions have been made as the value of certain fields are determined to be worth examining. \textbf{ADD BIT ABOUT FIELDS' VALUE AND WORTH/IMPACT}. The code written for analysis of the captured DataSeries format packets focuses on read/write events, ID tracking (PID/MID/TID/UID), and OpLock information. The future vision for this information is to combine ID tracking with the OpLock information in order to track resource sharing of the different clients on the network. -\subsection{System Limitations} -\label{System Limitations} -When initially designing the tracing system used in this paper, different aspects were taken into account, such as space limitations of the tracing system, packet capture limitations (e.g. file size), and speed limitations of the hardware. One limitation encountered in the packet capture system deals with the functional pcap (packet capture file) size. The concern being that the pcap files only need to be held until they have been filtered for specific protocol information and then compressed using the DataSeries format, but still allow for room for the DataSeries files being created to be stored. Other limitation concerns came from the software and packages used to collect the network traffic data~\cite{Orosz2013,Dabir2008,Skopko2012}. These ranged from timestamp resolution provided by the tracing system's kernel~\cite{Orosz2013} to how the packet capturing drivers and programs (such as dumpcap and tshark) operate along with how many copies are performed and how often. The speed limitations of the hardware are dictated by the hardware being used (e.g. GB capture interface) and the software that makes use of this hardware (e.g. PF\_RING). After all, our data can only be as accurate as the information being captured~\cite{Ellard2003,Anderson2004}. -An other concern was whether or not the system would be able to function optimally during periods of high network traffic. All apsects of the system, from the hardware to the software, have been altered to help combat these concerns and allow for the most accurate packet capturing possible. - -\subsection{General Challenges} -\label{General Challenges} -Challenges include: Interpretation of data, selective importance of information, arbitrary distribution of collected information. -One glaring challenge with building this tracing system was using code written by others; tshark \& DataSeries. While these programs are used within the tracing structure (which will be further examined in section ~\ref{Tracing System}) there are some issues when working with them. These issues ranged from data type limitations of the code to hash value \& checksum miscalculations due to encryption of specific fields/data. Attempt was made to dig and correct these issues, but they were so inherrent to the code being worked with that hacks and workaround were developed to minimize their effect. Other challenges centralize around selection, intrepretations and distribution scope of the data collected. Which fields should be filtered out from the original packet capture? What data is most prophetic to the form and function of the network being traced? What should be the scope, with respect to time, of the data being examined? Where will the most interesting information appear? As each obstacle was tackled, new information and ways of examining the data reveal themselves and with each development different alterations \& corrections are made. - -\subsection{Interpretation of Data} -\label{Interpretation of Data} -Unfortunately benchmarks require that the person(s) creating the benchmark determines the interpretation of the data collected. To some degree these interpretations are easy to make (e.g. file system behavior \& user behavior~\cite{Leung2008}) while others are more complicated (e.g. temporal scaling of occurances of read/write), but in all scenarios there is still the requirment for human interpretation of the data. While having humans do the interpretations can be adventageous, a lack of all the "background" information can also lead to incorrectly interpreting the information. The hope of this project is that, despite the possible pitfall of incorrect data interpretation, we will be able to not only find out more about the workings and uses of a network but also produce a meaningful benchmark that will more accurately represent the low level aspects of large communication networks. - -\subsection{Scope of Interpretation} -\label{Scope of Interpretation} -Expanding on the previous point about interpretation of data, another human factor of benchmark creation is selecting which information is important or which information will give the greatest insight to the workings on the network. As stated earlier too little information can lead to incorrect conclusions being drawn about the workings on the system, while too much information (and not knowing which information is pertinent) can lead to erroneous conclusions as well. Thus there is a need to strike a balance between what information is important enough to capture (so as not to slow down the capturing process through needless processing) while still obtaining enough information to acquire the bigger picture of what is going on. Unfortunately every step of the tracing process requires a degree of human input to decide what network information will end up providing the most complete picture of the network communication and how to interpret that data into meaningful graphs and tables. This can lead to either finds around the focus of the work being done, or even lead to discoveries of other phenomena that end up having far more impact on the overall performance of the system~\cite{Ellard2003}. - -Even when all the information is collected and the most important data has been selected, there is still the issue of what lens should be used to view this information. Because the data being collected is from an active network, there will be differing activity depending on the time of day, week, and scholastic year. For example, although the first week or so of the year may contain a lot of traffic, this does not mean that trends of that period of time will occur for every week of the year (except perhaps the final week of the semester). The trends and habits of the network will change based on the time of year, time of day, and even depend on the exam schedule. For these reasons one will see different trends depending on the distribution of the data used for analysis, and the truly interesting examination of data requires looking at all different periods of time to see how all these factors play into the communications of the network. +%\subsection{My Work} +%\label{My Work} +%Certain elements of this research are purposed to improve tracing knowledge along with general understanding of networked systems. One such element is the delevopment of tracking IO inter-arrival times along with processor times. This allows for more realistic replay of commands run due to more complete temporal considerations; time taken for computation and "travel" time. Another elements is the PID/MID/TID/UID tracking which allows for following command executions between a given client and server. This element paired with the previous development helps expand the understanding and replay-ability of temporal scaling. +%Things to make sure to say: Need trace of CIFS behavior. +%The following are issues that our work hopes to alleviate: there has been no large scale study done on networks for some time, there has been no study on CIFS(Common Internet File System)/SMB(Server Message Block) protocols for even longer, and most importantly these studies have not tackled lower level aspects of the trace, such as spacial \& temporal scaling idiosyncrasies of network communication. It is for these reasons that we have developed this tracing system and have developed new studies for lower level aspects of communication network. \\ -\section{Tracing System} -\label{Tracing System} +\section{Trace Collection} +\label{Trace Collection} -\subsection{Stages of Trace} -\label{Stages of Trace} +\subsection{Procedure} +\label{Procedure} \subsubsection{Capture} \label{Capture} @@ -165,9 +141,12 @@ The collection of these files is rather straight forward. Once the DataSeries f \label{Dissection/Analysis} The trace analysis in performed by an analysis module code that both processes the DataSeries files for extraction of information but also outputs meaningful information (such as IO patterns) to a file that can be used for further analysis. This section of the tracing system is always growing and changing as discoveries and limitations are found during the continuous execution of this code. Alterations range from edits to speed up the analysis process to adjustments to how communications are tracked and interpreted. This analysis will eventually incorporate oplocks and other aspects of resource sharing on the network to gain a more complete picture of the network's usage and bottlenecks. -\section{Trace Analysis} -\label{Trace Analysis} -The trace analysis is performed by an AnalysisModule code that both processes the ds-files for extraction of information to an event\_data structure and also outputs meaningful information (such as the IAT times between request and response packets) to a file that can be used for further analysis. +\subsection{ID Tracking} +\label{ID Tracking} +\textit{\textbf{Note:} It should be noted that this system is currently not implemented due to the poorly written way in which it was implemented. The new concept for this ID tracking is to combine the MID/PID/TID/UID tuple tracking along with FID tracking to know what files are opened, by whom (i.e. tuple identification), and tracking of file sizes for files that are created with an initial size of zero. The purpose for this tracking will be to track the habits of individual users. While initially simplistic (drawing a connection between FIDs and tuple IDs) this aspect of the research will be developed in future work to be move inclusive.} \\ +All comands sent over the network are coupled to an identifying MID/PID/TID/UID tuple. Since the only commands being examined are read or write commands, the identifying characteristic distinguishing a request command packet from a reponse command packet is the addition of an FID field with the sent packet. It is examination of the packets for this FID field that allows the analysis code to distinguish between request \& response command pakets. The pairing is done by examining the identifying tuple and assuming that each tuple-identified system will only send one command at a time (awaiting a response before sending the next command of that same type). +\\Following these process IDs is as a way to check for intercommunication between two or more processes. In particular, we examine the compute time \& I/O (input/output) time (i.e. time spent in communication; between information arrivals). This is done by examining the inter-arrival times (IAT) between the server \& the client. This is interesting because this information will give us a realistic sense of the data transit time of the network connections being used (e.g. ethernet, firewire, fibre, etc.). Other pertinent information would be how often the client makes requests \& how often this event occurs per client process ID, identifiable by their PID/MID tuple. One could also track the amount of sharing that is occurring between users. The PID is the process identifier and the MID is the multiplex identifier, which is set by the client and is to be used for identifying groups of commands belonging to the same logical thread of operation on the client node. +\\The per client process ID can be used to map the activity of given programs, thus allowing for finer granularity in the produced benchmark (e.g. control down to process types ran by individual client levels). Other features of interest are the time between an open \& close, or how many opens/closes occurred in a window (e.g. a period of time). This information could be used as a gauge of current day trends in filesystem usage \& its consequent taxation on the surrounding network. It would also allow for greater insight on the r/w habits of users on a network along with a rough comparison between other registered events that occur on the network. Lastly, though no less important, it would allow us to look at how many occurrences there are of shared files between different users. One must note that the type of sharing may differ and there can be an issue of resource locking (e.g. shared files) that needs to be taken into account. This is preliminarily addressed by monitoring any oplock flags that are sent for read \& writes. This information also helps provide a preliminary mapping of how the network is used and what sort of traffic populates the communication. \subsection{SMB} \label{SMB} @@ -175,12 +154,26 @@ Server Message Block (SMB) is the modern dialect of Common Internet File System \\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}. When used in a response message the header also includes status information that indicates whether and how the command succeeded or failed. 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. \\\textit{\textbf{Expectations}}: SMB will be heavily used by students to access their network accounts from any networked computer, along with network access to shared file systems and connected printers. Oplocks will be in heavy use and cause a slowdown of the system for multiuser shared storage space. Authentication of network computers could bottleneck during moments of high traffic (e.g. students all logging in for a class). -\subsection{ID Tracking} -\label{ID Tracking} -\textit{\textbf{Note:} It should be noted that this system is currently not implemented due to the poorly written way in which it was implemented. The new concept for this ID tracking is to combine the MID/PID/TID/UID tuple tracking along with FID tracking to know what files are opened, by whom (i.e. tuple identification), and tracking of file sizes for files that are created with an initial size of zero. The purpose for this tracking will be to track the habits of individual users. While initially simplistic (drawing a connection between FIDs and tuple IDs) this aspect of the research will be developed in future work to be move inclusive.} \\ -All comands sent over the network are coupled to an identifying MID/PID/TID/UID tuple. Since the only commands being examined are read or write commands, the identifying characteristic distinguishing a request command packet from a reponse command packet is the addition of an FID field with the sent packet. It is examination of the packets for this FID field that allows the analysis code to distinguish between request \& response command pakets. The pairing is done by examining the identifying tuple and assuming that each tuple-identified system will only send one command at a time (awaiting a response before sending the next command of that same type). -\\Following these process IDs is as a way to check for intercommunication between two or more processes. In particular, we examine the compute time \& I/O (input/output) time (i.e. time spent in communication; between information arrivals). This is done by examining the inter-arrival times (IAT) between the server \& the client. This is interesting because this information will give us a realistic sense of the data transit time of the network connections being used (e.g. ethernet, firewire, fibre, etc.). Other pertinent information would be how often the client makes requests \& how often this event occurs per client process ID, identifiable by their PID/MID tuple. One could also track the amount of sharing that is occurring between users. The PID is the process identifier and the MID is the multiplex identifier, which is set by the client and is to be used for identifying groups of commands belonging to the same logical thread of operation on the client node. -\\The per client process ID can be used to map the activity of given programs, thus allowing for finer granularity in the produced benchmark (e.g. control down to process types ran by individual client levels). Other features of interest are the time between an open \& close, or how many opens/closes occurred in a window (e.g. a period of time). This information could be used as a gauge of current day trends in filesystem usage \& its consequent taxation on the surrounding network. It would also allow for greater insight on the r/w habits of users on a network along with a rough comparison between other registered events that occur on the network. Lastly, though no less important, it would allow us to look at how many occurrences there are of shared files between different users. One must note that the type of sharing may differ and there can be an issue of resource locking (e.g. shared files) that needs to be taken into account. This is preliminarily addressed by monitoring any oplock flags that are sent for read \& writes. This information also helps provide a preliminary mapping of how the network is used and what sort of traffic populates the communication. +\subsection{System Limitations and Challenges} +\label{System Limitations and Challenges} +When initially designing the tracing system used in this paper, different aspects were taken into account, such as space limitations of the tracing system, packet capture limitations (e.g. file size), and speed limitations of the hardware. One limitation encountered in the packet capture system deals with the functional pcap (packet capture file) size. The concern being that the pcap files only need to be held until they have been filtered for specific protocol information and then compressed using the DataSeries format, but still allow for room for the DataSeries files being created to be stored. Other limitation concerns came from the software and packages used to collect the network traffic data~\cite{Orosz2013,Dabir2008,Skopko2012}. These ranged from timestamp resolution provided by the tracing system's kernel~\cite{Orosz2013} to how the packet capturing drivers and programs (such as dumpcap and tshark) operate along with how many copies are performed and how often. The speed limitations of the hardware are dictated by the hardware being used (e.g. GB capture interface) and the software that makes use of this hardware (e.g. PF\_RING). After all, our data can only be as accurate as the information being captured~\cite{Ellard2003,Anderson2004}. +An other concern was whether or not the system would be able to function optimally during periods of high network traffic. All apsects of the system, from the hardware to the software, have been altered to help combat these concerns and allow for the most accurate packet capturing possible. \\ + +%About Challenges of system +Challenges include: Interpretation of data, selective importance of information, arbitrary distribution of collected information. +One glaring challenge with building this tracing system was using code written by others; tshark \& DataSeries. While these programs are used within the tracing structure (which will be further examined in section ~\ref{Tracing System}) there are some issues when working with them. These issues ranged from data type limitations of the code to hash value \& checksum miscalculations due to encryption of specific fields/data. Attempt was made to dig and correct these issues, but they were so inherrent to the code being worked with that hacks and workaround were developed to minimize their effect. Other challenges centralize around selection, intrepretations and distribution scope of the data collected. Which fields should be filtered out from the original packet capture? What data is most prophetic to the form and function of the network being traced? What should be the scope, with respect to time, of the data being examined? Where will the most interesting information appear? As each obstacle was tackled, new information and ways of examining the data reveal themselves and with each development different alterations \& corrections are made. + +%About interpretation of data +Unfortunately benchmarks require that the person(s) creating the benchmark determines the interpretation of the data collected. To some degree these interpretations are easy to make (e.g. file system behavior \& user behavior~\cite{Leung2008}) while others are more complicated (e.g. temporal scaling of occurances of read/write), but in all scenarios there is still the requirment for human interpretation of the data. While having humans do the interpretations can be adventageous, a lack of all the "background" information can also lead to incorrectly interpreting the information. The hope of this project is that, despite the possible pitfall of incorrect data interpretation, we will be able to not only find out more about the workings and uses of a network but also produce a meaningful benchmark that will more accurately represent the low level aspects of large communication networks. + +%About scope of interpretation (affect of time on data seen) +Expanding on the previous point about interpretation of data, another human factor of benchmark creation is selecting which information is important or which information will give the greatest insight to the workings on the network. As stated earlier too little information can lead to incorrect conclusions being drawn about the workings on the system, while too much information (and not knowing which information is pertinent) can lead to erroneous conclusions as well. Thus there is a need to strike a balance between what information is important enough to capture (so as not to slow down the capturing process through needless processing) while still obtaining enough information to acquire the bigger picture of what is going on. Unfortunately every step of the tracing process requires a degree of human input to decide what network information will end up providing the most complete picture of the network communication and how to interpret that data into meaningful graphs and tables. This can lead to either finds around the focus of the work being done, or even lead to discoveries of other phenomena that end up having far more impact on the overall performance of the system~\cite{Ellard2003}. + +Even when all the information is collected and the most important data has been selected, there is still the issue of what lens should be used to view this information. Because the data being collected is from an active network, there will be differing activity depending on the time of day, week, and scholastic year. For example, although the first week or so of the year may contain a lot of traffic, this does not mean that trends of that period of time will occur for every week of the year (except perhaps the final week of the semester). The trends and habits of the network will change based on the time of year, time of day, and even depend on the exam schedule. For these reasons one will see different trends depending on the distribution of the data used for analysis, and the truly interesting examination of data requires looking at all different periods of time to see how all these factors play into the communications of the network. + +\section{Trace Analysis} +\label{Trace Analysis} +The trace analysis is performed by an AnalysisModule code that both processes the ds-files for extraction of information to an event\_data structure and also outputs meaningful information (such as the IAT times between request and response packets) to a file that can be used for further analysis. %\subsection{Other (e.g. HTML)} %\label{Other (e.g. HTML)} @@ -236,144 +229,6 @@ Interpreting the data collected is done by producing three separate graphs showi \subsection{Characterizations of Different Packet Types} \label{Characterizations of Different Packet Types} -%\section{Related Work} -%\label{Related Work} -% -%\subsection{Anderson 2004 Paper} -%\label{Anderson 2004 Paper} -%This paper tackles the temporal inaccuracy of current day benchmarks \& the impact and errors produced due to these naive benchmarking tools. Timing accuracy (issuing I/Os at the desired time) at high I/O rates is difficult to achieve on stock operating systems ~\cite{Anderson2004}. Due to this inaccuracy, these may be introduction of substantial errors into observed system metrics when benchmarking I/O systems; including the use of these inaccurate tools for replaying traces or for producing synthetic workloads with known inter-arrival times ~\cite{Anderson2004}. Anderson \textit{et al.} demonstrates the need for timing accuracy for I/O benchmarking in the context of replaying I/O traces. Anderson \textit{et al.} showed that the error in perceived I/O response times can be as much as +350\% or -15\% by using naive benchmarking tools that have timing inaccuracies ~\cite{Anderson2004}. Anderson \textit{et al.}'s measurements indicated that the accuracy achieved by using standard system calls is not adequate and that errors in issuing I/Os can lead to substantial errors in measurements of I/O statistics such as mean latency and number of outstanding I/Os. -%\begin{itemize} -% \item 1. Timing in accuracy of benchmakrs can lead to error of +350\% or -15\% in perceived I/O response times. Accuracy achieved using standard system calls \textbf{not} adequate and error in issuing I/Os leads to substantial I/O statistics errors -% \item 2. "We currently lack tools to easily and accurately generate complex I/O workloads on modern storage systems". \textit{\textbf{Result}}: May introduce substantial errors in observed system metrics when benchmark I/O systems use inaccurate tools -% \item 3. I/O benchmarking widespread practice in storage industry and serves as basis for purchasing decisions, performance tuning studies and marketing campains. "how does a given storage system perform for my workload?" Benchmarking done by comparing I/O systems by subjecting them to known workloads -% \item 4. Three general approaches based on trade-off between experimental complexity and resemblence to application -% \begin{itemize} -% \item 1. Connect system to production/test environment, run application, measure application metrics -% \item 2. Collect traces from running application and replay them (after possible modification) back on test I/O system -% \item 3. Generate sythetic workload and measure system performance -% \end{itemize} -% \item 5. Most studies assume issue accuracy using standard system calls adequate. Measures indicate not the case and errorsin issuing I/O can lead to substantial errors in issuing I/O can lead to substantial errors in I/O statistic measurements (e.g. mean latency and number of outstanding I/Os -% \item 6. Inaccuracies in scheduling I/Os may result in as much as a factor of 3.5 difference in measured response time and factor of 26 in measured queue sizes; Differences too large to ignore -% \item 7. Timing accuracy and high through-put involves three challenges -% \begin{itemize} -% \item 1. Designing for peak performance requirements -% \item 2. Coping with OS timing inaccuracy -% \item 3. Working around unpredictable OS behavior -% \begin{itemize} -% \item 1. Standard OS mechanisms to keep time and issue I/Os; accuracy determined by scheduling granularity of underlying OS -% \item 2. Accuracy of I/O scheduling contingent upon thread being scheduled at right time by OS scheduling boundaries \textit{or} flatten bursts -% \end{itemize} -% \item 4. Unpredictable performance effects due to interrupts; locking, resource contention, kernel scheduling intracacies -% \item 5. Examples of performance effects -% \begin{itemize} -% \item 1. \textit{gettimeofday}() function (SMP) from multiple threads may cause locking to preserve clock invarience -% \item 2. Thread moving from one CPU to another difficulty keeping track of wall clock time -% \end{itemize} -% \item 6. In higher load case the kernel gets more opportunities to schedule threads and hence more I/O issuing threads get scheduled at right time -% \end{itemize} -%\end{itemize} -% -%\subsection{Ellard Ledlie 2003} -%\label{Ellard Ledlie 2003} -%This paper examines two workloads (research and email) to see if they resemble previously studied workloads, as well as performs several new analyses on the NFS protocol. Trace-based analyses have guided and motivated contemporary file system design for the past two decades; where the original analysis of the 4.2BSD file system motivated many of the design decisions of the log-structured file system (LFS)~\cite{EllardLedlie2003}. This paper also takes the stance that since the use of technology has expanded and evolved, this fundamental change in workloads needs to be traced to observe and understand the behavior. "We believe that as the community of computer users has expanded and evolved there has been a fundamental change in the workloads seen by file servers, and that the research community must find ways to observe and measure these new workloads."~\cite{EllardLedlie2003} Some of the contributions of this paper include new techniques for analyzing NFS traces along with tools to gather new anonymized NFS traces. Leung \textit{et al.} (as well as Ellard \textit{et. al.}) also observed that much of the variance of load characterization statistics over time can be explained by high-level changes in the workload over time; despite, this correlation having been observed in many trace studies, its effects are usually ignored~\cite{EllardLedlie2003}. The most noticeable change in their traces was the difference between peak and off-peak hours of operation. This finding conveyed that time is a strong predictor of operation counts, amount of data transferred, and the read-write ratios for their CAMPUS (e.g. email) workload. -% -%\subsection{Ellard 2003} -%\label{Ellard 2003} -%This paper shows that the technology being actively researched gains improvement faster and that the technology that is not improved will end up being the bottleneck of the system. Ellard and Seltzer give the example of how file system performance is steadily losing ground relative to CPU, memory, and even network performance. Even though Ellard and Seltzer began their efforts to accurately measure the impact of changes to their system, they also discovered several other phenomena that interacted with the performance of the disk and file system in ways that had far more impact on the overall performance of the system than their improvements~\cite{Ellard2003}. This paper loosely groups all benchmarks into two categories: micro benchmarks and macro/workload benchmarks, the difference between these two being that micro benchmarks measure specific low-level aspects of system performance while workload benchmarks estimate the performance of the system running a particular workload. -% -%\subsection{Leung 2008 Paper} -%\label{Leung 2008 Paper} -%Comparison of file access patterns (RO, WO, RW) -%\begin{itemize} -% \item 1. Workloads more write-heavy than previously seen -% \item 2. RW access patterns much more frequent -% \item 3. Bytes transferred in much longer sequential runs -% \item 4. Bytes transferred from much larger files -% \item 5. Files live order of magnitude longer -% \item 6. Most files not reopened once closed; If file re-opened, temporally related to previous closing of file -%\end{itemize} -%Files are infrequently shared by more than one client; over 76\% files never opened by more than one client. -%File sharing rarely concurrent and usually read-only; 5\% of files opened by multiple client are concurrent and 90\% of sharing is read only -%\textit{Compared to Previous Studies} -%\begin{itemize} -% \item 1. Both of our workloads are more write-oriented. Read to write byte ratios have significantly decreased. -% \item 2. Read-write access patterns have increased 30-fold relative to read-only and write-only access patterns. -% \item 3. Most bytes are transferred in longer sequential runs. These runs are an order of magnitude larger. -% \item 4. Most bytes transferred are from larger files. File sizes are up to an order of magnitude larger. -% \item 5. Files live an order of magnitude longer. Fewer than 50\% are deleted within a day of creation. -%\end{itemize} -%\textit{New Observations} -%\begin{itemize} -% \item 6. Files are rarely re-opened. Over 66\% are re-opened once and 95\% fewer than five times. -% \item 7. Files re-opens are temporally related. Over 60\% of re-opens occur within a minute of the first. -% \item 8. A small fraction of clients account for a large fraction of file activity. Fewer than 1\% of clients account for 50\% of file requests. -% \item 9. Files are infrequently shared by more than one client. Over 76\% of files are never opened by more than one client. -% \item 10. File sharing is rarely concurrent and sharing is usually read-only. Only 5\% of files opened by multiple clients are concurrent and 90\% of sharing is read-only. -%\end{itemize} -%\textit{List of interesting data points (comes from 'Table 3: Summary of trace statistics')} -%\begin{itemize} -% \item Clients, Days, Data Read (GB), Data Written (GB), R:W I/O Ratio, R:W Byte Ratio, Total Operations -% \item Operation Names: Session Create, Open, Close, Read, Write, Flush, Lock, Delete, File Stat, Set Attribute, Directory Read, Rename, Pipe Transactions -%\end{itemize} -%\textit{Table 4: Comparison of file access patterns - This figure gives good show of Read-Only, Write-Only \& Read-Write} -%\\\textit{Observations:} -%\begin{itemize} -% \item 1) “Both of our workloads are more write-heavy than workloads studied previously” -% \item 2) “Read-write access patterns are much more frequent compared to past studies” -% \item 3) “Bytes are transferred in much longer sequential runs than in previous studies” -% \item 4) Bytes are transferred from much larger files than in previous studies -% \item 5) Files live an order of magnitude longer than in previous studies -% \item 6) Most files are not re-opened once they are closed -% \item 7) If a file is re-opened, it is temporally related to the previous close -%\end{itemize} -% -%\subsection{Orosz 2013 Paper} -%\label{Orosz 2013 Paper} -%\begin{itemize} -% \item 1. Primary bottleneck in current timestamp resolution provided by Kernel is large deviation of deneration (timestamp generation) overhead decreases timestamp precision -% \item 2. Simplifying the work of the kernel (i.e. time stamping process) will lead to lower packet loss -% \item 3. "In network measurement, the precision of timestamping is a criterion more important than the low clock offset, especially for measuring packet inter-arrival times and round-trip delays at one single point of the network (e.g., active probing)" -%\end{itemize} -% -%\subsection{Dabir 2008 Paper} -%\label{Dabir 2008 Paper} -%\begin{itemize} -% \item 1. "Since Dumpcap is a single threaded application, it was suspected that while it is busy writing to disk, because it is blocked by the I/O call, it is unable to handle newly arriving packets due to the small size of the kernel buffer which quickly fills up." -% \item 2. Increasing amount of kernel level buffer associated with capture socket could lead to better capture speeds with Dumpcap -%\end{itemize} -%\textit{Note}: While (item 1) could be a source of packet loss, until this is tested on a trace system do not assume this is a key limiting factor. It could be that by having Dumpcap write to RAM would alieviate this problem. If this is the case, Dabir \& Matrawy attempted to overcome this limitation by having synchronization between two threads (using two semaphores) where \textbf{one} thread would store/buffer incoming packets and the \textbf{second} thread would write the packet information to disk -% -%\subsection{Narayan 2010 Paper} -%\label{Narayan 2010 Paper} -%\begin{itemize} -% \item 1. Striping Data in parallel file system can bottleneck if file distribution parameters do not fit access patterns of applications -% \item 2. Parallel application have five major models of I/O -% \begin{itemize} -% \item 1. Single output file shared by multiple nodes by ranges -% \item 2. Large sequential read by single node at beginning of computation and large sequential write by single node at end of computation -% \item 3. Checkpointing of state -% \item 4. Metadata and read intensive - small data I/O, frequent directory lookups for reads -% \item 5. Each node outputs to its own file -% \end{itemize} -% \item 3. Distributing I/O across more nodes not decrease IATs because files striped across all nodes which causes any Read or Write to access all nodes -% \item 4. From Figure 5: As we see in the graphs and data provided, as the number of I/O nodes increases (as well as the number of processors/servers) the IATs decrease along with the number of I/O operations increase. This leads to a larger \% of IATs occuring at lower times (e.g. < 1ms) -% \item 5. From study on IATs, most parallel applications doing significant I/O increase the I/O frequency as the number of compute nodes increases. \textbf{However}, scaling I/O nodes alone causes issue because increased I/O load is transferred to each I/O storage node -% \item 6. "I/O access models that assume independence or randomness between requests are not valid" -%\end{itemize} -% -%\subsection{Skopko 2012 Paper} -%\label{Skopko 2012 Paper} -%\begin{itemize} -% \item 1. Software based capture solutions heavily rely on OS's packet processing mechanism -% \item 2. "Dumpcap itself uses relatively small system resources, however it is executed on a general purpose system that shares its resources between the running processes" -% \item 3. Drivers typically operate in two different modes: interrupt mode and polling mode; importance of modes is dual -% \begin{itemize} -% \item 1. timestamps generated at enqueueing process reflect that tiem instead of moment of arrival at physical layer -% \item 2. polling causes bursty packet forwarding, thus need for appropriate sized buffers to handle them -% \end{itemize} -% \item 4. Dumpcap has option called \textit{snaplength} to do truncation; compared to original measurement, smaller snaplength = fewer lost packets by Dumpcap -%\end{itemize} - \section{Conclusion} \label{Conclusion} \textit{Do the results show a continuation in the trend of traditional computer science workloads?}