Skip to content
Permalink
Newer
Older
100644 962 lines (860 sloc) 79.1 KB
1
% This is "sig-alternate.tex" V2.1 April 2013
2
% This file should be compiled with V2.5 of "sig-alternate.cls" May 2012
3
%
4
% This example file demonstrates the use of the 'sig-alternate.cls'
5
% V2.5 LaTeX2e document class file. It is for those submitting
6
% articles to ACM Conference Proceedings WHO DO NOT WISH TO
7
% STRICTLY ADHERE TO THE SIGS (PUBS-BOARD-ENDORSED) STYLE.
8
% The 'sig-alternate.cls' file will produce a similar-looking,
9
% albeit, 'tighter' paper resulting in, invariably, fewer pages.
10
%
11
% ----------------------------------------------------------------------------------------------------------------
12
% This .tex file (and associated .cls V2.5) produces:
13
% 1) The Permission Statement
14
% 2) The Conference (location) Info information
15
% 3) The Copyright Line with ACM data
16
% 4) NO page numbers
17
%
18
% as against the acm_proc_article-sp.cls file which
19
% DOES NOT produce 1) thru' 3) above.
20
%
21
% Using 'sig-alternate.cls' you have control, however, from within
22
% the source .tex file, over both the CopyrightYear
23
% (defaulted to 200X) and the ACM Copyright Data
24
% (defaulted to X-XXXXX-XX-X/XX/XX).
25
% e.g.
26
% \CopyrightYear{2007} will cause 2007 to appear in the copyright line.
27
% \crdata{0-12345-67-8/90/12} will cause 0-12345-67-8/90/12 to appear in the copyright line.
28
%
29
% ---------------------------------------------------------------------------------------------------------------
30
% This .tex source is an example which *does* use
31
% the .bib file (from which the .bbl file % is produced).
32
% REMEMBER HOWEVER: After having produced the .bbl file,
33
% and prior to final submission, you *NEED* to 'insert'
34
% your .bbl file into your source .tex file so as to provide
35
% ONE 'self-contained' source file.
36
%
37
% ================= IF YOU HAVE QUESTIONS =======================
38
% Questions regarding the SIGS styles, SIGS policies and
39
% procedures, Conferences etc. should be sent to
40
% Adrienne Griscti (griscti@acm.org)
41
%
42
% Technical questions _only_ to
43
% Gerald Murray (murray@hq.acm.org)
44
% ===============================================================
45
%
46
% For tracking purposes - this is V2.0 - May 2012
47
48
\documentclass[conference]{IEEEtran}
49
50
\usepackage{listings} % Include the listings-package
51
\usepackage{color}
52
\usepackage{balance}
53
\usepackage{graphicx}
54
\usepackage{url}
55
\usepackage{tabularx,booktabs}
56
\usepackage{multirow}
57
\usepackage[normalem]{ulem}
58
\useunder{\uline}{\ul}{}
59
60
\definecolor{darkgreen}{rgb}{0,0.5,0}
61
\definecolor{mygreen}{rgb}{0,0.6,0}
62
\definecolor{mygray}{rgb}{0.5,0.5,0.5}
63
\definecolor{mymauve}{rgb}{0.58,0,0.82}
64
\lstset{ %
65
backgroundcolor=\color{white}, % choose the background color; you must add \usepackage{color} or \usepackage{xcolor}
66
basicstyle=\ttfamily\scriptsize, % the size of the fonts that are used for the code
67
breakatwhitespace=false, % sets if automatic breaks should only happen at whitespace
68
breaklines=true, % sets automatic line breaking
69
captionpos=b, % sets the caption-position to bottom
70
commentstyle=\color{mygreen}, % comment style
71
deletekeywords={...}, % if you want to delete keywords from the given language
72
escapeinside={\%*}{*)}, % if you want to add LaTeX within your code
73
extendedchars=true, % lets you use non-ASCII characters; for 8-bits encodings only, does not work with UTF-8
74
frame=single, % adds a frame around the code
75
keepspaces=true, % keeps spaces in text, useful for keeping indentation of code (possibly needs columns=flexible)
76
keywordstyle=\color{blue}, % keyword style
77
% language=C, % the language of the code
78
morecomment=[l]{--},
79
morekeywords={property,set,is,type, constant, enumeration, end, applies, to, inherit, of, *,...}, % if you want to add more keywords to the set
80
numbers=left, % where to put the line-numbers; possible values are (none, left, right)
81
numbersep=5pt, % how far the line-numbers are from the code
82
numberstyle=\tiny\color{mygray}, % the style that is used for the line-numbers
83
rulecolor=\color{black}, % if not set, the frame-color may be changed on line-breaks within not-black text (e.g. comments (green here))
84
showspaces=false, % show spaces everywhere adding particular underscores; it overrides 'showstringspaces'
85
showstringspaces=false, % underline spaces within strings only
86
showtabs=false, % show tabs within strings adding particular underscores
87
stepnumber=1, % the step between two line-numbers. If it's 1, each line will be numbered
88
stringstyle=\color{mymauve}, % string literal style
89
tabsize=2, % sets default tabsize to 2 spaces
90
title=\lstname % show the filename of files included with \lstinputlisting; also try caption instead of title
91
}
92
93
\ifCLASSINFOpdf
94
% \usepackage[pdftex]{graphicx}
95
% declare the path(s) where your graphic files are
96
% \graphicspath{{../pdf/}{../jpeg/}}
97
% and their extensions so you won't have to specify these with
98
% every instance of \includegraphics
99
% \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
100
\else
101
% or other class option (dvipsone, dvipdf, if not using dvips). graphicx
102
% will default to the driver specified in the system graphics.cfg if no
103
% driver is specified.
104
% \usepackage[dvips]{graphicx}
105
% declare the path(s) where your graphic files are
106
% \graphicspath{{../eps/}}
107
% and their extensions so you won't have to specify these with
108
% every instance of \includegraphics
109
% \DeclareGraphicsExtensions{.eps}
110
\fi
111
112
\begin{document}
113
%
114
% paper title
115
% can use linebreaks \\ within to get better formatting as desired
116
\title{A Trace-Based Study of SMB Network File System Workloads in an Academic Enterprise}
117
118
%\author{\IEEEauthorblockN{Paul Wortman and John Chandy}
119
%\IEEEauthorblockA{Department of Electrical and Computer Engineering\\
120
%University of Connecticut, USA\\
121
%(paul.wortman, john.chandy)@uconn.edu
122
%}}
123
124
125
% make the title area
126
\maketitle
127
128
\begin{abstract}
129
Storage system traces are important for examining real-world applications, studying potential bottlenecks, as well as driving benchmarks in the evaluation of new system designs.
130
While file system traces have been well-studied in earlier work, it has been some time since the last examination of the SMB network file system.
131
The purpose of this work is to continue previous SMB studies to better understand the use of the protocol in a real-world production system in use at the University of Connecticut.
132
The main contribution of our work is the exploration of I/O behavior in modern file system workloads as well as new examinations of the inter-arrival times and run times for I/O events.
133
We further investigate if the recent standard models for traffic remain accurate.
134
\textcolor{red}{Our findings reveal interesting data relating to the number of read and write events. We notice that while the number of read events far exceeds writes, the average of bytes transferred over the wire is greater for writes. Furthermore we find an increase in the use of metadata for overall network communication that can be taken advantage of through the use of smart storage devices.}
135
\end{abstract}
136
137
\section{Introduction}
138
%Mention:
139
%\begin{itemize}
140
% \item Why is it important to re-examine the SMB protocol?
141
% \item Why does examination of network use matter?
142
% \item Need to ensure hash of data and not saving any of the original traffic packets.
143
%\end{itemize}
144
Over the last twenty years, data storage provisioning has been centralized through the
145
use of network file systems. The architectures of these storage systems can vary from
146
storage area networks (SAN), network attached storage (NAS), clustered file systems,
147
hybrid storage, amongst others. However, the front-end client-facing network file
148
system protocol in most enterprise IT settings tends to be, for the most part, solely
149
SMB (Server Message Block) because of the preponderance of MS Windows clients.
150
While there are other network file systems such as Network File System (NFS) and
151
clustered file systems such as Ceph, PanFS, and OrangeFS, they tend to be used less
152
extensively in most non-research networks.
153
154
In spite of the prevalence of SMB usage within most enterprise networks, there has
155
been very little analysis of SMB workloads in prior academic research. The last major study
156
of SMB was nearly a decade ago~\cite{leung2008measurement}, and the nature of storage
157
usage has changed dramatically over the last decade.
158
It is always important to revisit commonly used protocols to examine their use in comparison to the expected use case(s). This is doubly so for network communications because the nuances of networked data exchange can greatly influence the effectiveness and efficiency of a chosen protocol. \textcolor{red}{Since an examination of SMB has not occurred in the past decade, we took a look at its current implementation and use in a large university network.}
159
%Due to the sensitivity of the captured information, we ensure that all sensitive information is hashed and that the original network captures are not saved.
160
161
Our study is based on network packet traces collected on the University of Connecticut's centralized storage facility over \textcolor{red}{a period of a week of in March 2017.} This trace-driven analysis can help in the design of future storage products as well as providing data for future performance benchmarks.
162
%Benchmarks are important for the purpose of developing technologies as well as taking accurate metrics. The reasoning behind this tracing capture work is to eventually better develop accurate benchmarks for network protocol evaluation.
163
Benchmarks allow for the stress testing of various aspects of a system (e.g. network, single system). Aggregate data analysis collected from traces can lead to the development of synthetic benchmarks. Traces can expose systems patterns that can also be reflected in synthetic benchmark. Finally, the traces themselves can drive system simulations that can be used to evaluate prospective storage architectures.
164
165
%\begin{itemize}
166
% \item \textbf{Why?:} Benchmarks allow for the stress testing of different/all aspects of a system (e.g. network, single system).
167
% \item \textbf{How:} There are three ``steps'' to creating a benchmark.
168
% \begin{enumerate}
169
% \item Take a trace of an existing system
170
% \begin{itemize}
171
% \item This is important because this information is how one is able to compare the expected actions of a system (theory) against the traced actions (practice) of the system. Leads to the development of later synthetic benchmarks.
172
% \end{itemize}
173
% \item Determine which aspects of the trace of said system (in an educated arbitrary way) are most representative of ``what occurred'' during the tracing of the system. Leads to discovery of habits/patterns of the system; which is later used for synthetic benchmark.
174
% \item Use discovered information to produce benchmark
175
% \begin{itemize}
176
% \item Done by either running a repeat of the trace of synthetic benchmark created using trends from trace.
177
% \end{itemize}
178
% \end{enumerate}
179
%\end{itemize}
180
181
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 customization of 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.
182
% PF\_RING section
183
%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}.
184
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}.
185
%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. \\
186
% DataSeries + Code section
187
The tweaks and code additions to the existing DataSeries work are filtering for specific 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 kept for analysis. It should be noted that this was done originally arbitrarily and changes/additions have been made as the value of certain fields were determined to be worth examining; e.g. multiple runs were required to refine the captured data for later analysis. The code written for analysis of the captured DataSeries format packets focuses on I/O events and ID tracking (TID/UID). 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. As well as using IP information to recreate communication in a larger network trace to establish a better benchmark.
188
189
%Focus should be aboiut analysis and new traces
190
The contributions of this work are the new traces of SMB traffic over a larger university network as well as new analysis of this traffic. Our new examination of the captured data reveals that \textcolor{red}{despite the streamlining of the CIFS/SMB protocol to be less chatty, the majority of SMB communication in metadata based I/O. We found that while read operations occur in greater numbers and cause a larger overall number of bytes to pass over the network. However, the average number of bytes transferred for each write I/O is an order of magnitude greater than that of the average read operation. We also find that the current standard for modeling network I/O holds for the majority of operations, while a more representative model needs to be developed for writes.}
191
192
\subsection{Related Work}
193
In this section we discuss previous studies examining traces and testing that has advanced benchmark development. We summarize major works in trace study in Table~\ref{tbl:studySummary}. In addition we examine issues that occur with traces and the assumptions in their study.
194
\begin{table*}[]
195
\centering
196
\begin{tabular}{|r|c|c|c|c|c|}
197
\hline
198
Study & Date of Traces & FS/Protocol & Network FS & Trace Approach & Workload \\ \hline
199
Ousterhout, \textit{et al.}~\cite{ousterhout1985trace} & 1985 & BSD & & Dynamic & Engineering \\ \hline
200
Ramakrishnan, \textit{et al.}~\cite{ramakrishnan1992analysis} & 1988-89 & VAX/VMS & x & Dynamic & Engineering, HPC, Corporate \\ \hline
201
Baker, \textit{et al.}~\cite{baker1991measurements} & 1991 & Sprite & x & Dynamic & Engineering \\ \hline
202
Gribble, \textit{et al.}~\cite{gribble1996self} & 1991-97 & Sprite, NFS, VxFS & x & Both & Engineering, Backup \\ \hline
203
Douceur and Bolosky~\cite{douceur1999large} & 1998 & FAT, FAT32, NTFS & & Snapshots & Engineering \\ \hline
204
Vogels~\cite{vogels1999file} & 1998 & FAT, NTFS & & Both & Engineering, HPC \\ \hline
205
Zhou and Smith~\cite{zhou1999analysis} & 1999 & VFAT & & Dynamic & PC \\ \hline
206
Roselli, \textit{et al.}~\cite{roselli2000comparison} & 1997-00 & VxFS, NTFS & & Dynamic & Engineering, Server \\ \hline
207
Malkani, \textit{et al.}~\cite{malkani2003passive} & 2001 & NFS & x & Dynamic & Engineering, Email \\ \hline
208
Agrawal, \textit{et al.}~\cite{agrawal2007five} & 2000-2004 & FAT, FAT32, NTFS & & Snapshots & Engineering \\ \hline
209
Leung, \textit{et al.}~\cite{leung2008measurement} & 2007 & CIFS & x & Dynamic & Corporate, Engineering \\ \hline
210
%Traeger, \textit{et al.}~\cite{traeger2008nine} & 2008 & FUSE & x & Snapshots & Backup \\ \hline
211
Vrable, \textit{et al.}~\cite{vrable2009cumulus} & 2009 & FUSE & x & Snapshots & Backup \\ \hline
212
Benson, \textit{et al.}~\cite{benson2010network} & 2010 & AFS, MapReduce, NCP, SMB & x & Dynamic & Academic, Corporate \\ \hline
213
Chen, \textit{et al.}~\cite{chen2012interactive} & 2012 & MapReduce & x & Dynamic & Corporate \\ \hline
214
This paper & 2017 & SMB & x & Dynamic & Academic, Engineering, Backup \\ \hline
215
\end{tabular}
216
\caption{Summary of major file system studies over the past decades. For each study the tables shows the dates of the trace data, the file system or protocol studied, whether it involved network file systems, the trace methodology used, and the workloads studied. Dynamic trace studies are those that involve traces of live requests. Snapshot studies involve snapshots of file system contents.}
217
\label{tbl:studySummary}
218
\vspace{-2em}
219
\end{table*}Since
220
\label{Previous Advances Due to Testing}
221
Tracing collection and analysis has proved its worth in time from previous studies where one can see important lessons pulled from the research; change in behavior of read/write events, overhead concerns originating in system implementation, bottlenecks in communication, and other revelations found in the traces. \\
222
Previous tracing work has shown that one of the largest \& broadest hurdles to tackle is that traces (and benchmarks) must be tailored to the system being tested. There are always some generalizations taken into account but these generalizations can also be a major source of error~\cite{vogels1999file,malkani2003passive,seltzer2003nfs,anderson2004buttress,Orosz2013,dabir2007bottleneck,skopko2012loss,traeger2008nine,ruemmler1992unix}. To produce a benchmark with high fidelity one needs to understand not only the technology being used but how it is being implemented within the system~\cite{roselli2000comparison,traeger2008nine,ruemmler1992unix}. All of these aspects will lend to the behavior of the system; from timing \& resource elements to how the managing software governs actions~\cite{douceur1999large,malkani2003passive,seltzer2003nfs}. Furthermore, in pursuing this work one may find unexpected results and learn new things through examination~\cite{leung2008measurement,roselli2000comparison,seltzer2003nfs}. \\
223
These studies are required in order to evaluate the development of technologies and methodologies along with furthering knowledge of different system aspects and capabilities. As has been pointed out by past work, the design of systems is usually guided by an understanding of the file system workloads and user behavior~\cite{leung2008measurement}. It is for that reason that new studies are constantly performed by the science community, from large scale studies to individual protocol studies~\cite{leung2008measurement,vogels1999file,roselli2000comparison,seltzer2003nfs,anderson2004buttress}. Even within these studies, the information gleaned is only as meaningful as the considerations of how the data is handled. \\
224
225
The work done by Leung et. al.~\cite{leung2008measurement} found observations related to the infrequency of files to be shared by more than one client. Over 67\% of files were never open by more than one client.
226
Leung's \textit{et. al.} work led to a series of observations, from the fact that files are rarely re-opened to finding that read-write access patterns are more frequent ~\cite{leung2008measurement}.
227
%If files were shared it was rarely concurrently and usually as read-only; where 5\% of files were opened by multiple clients concurrently and 90\% of the file sharing was read only.
228
%Concerns of the accuracy achieved of the trace data was due to using standard system calls as well as errors in issuing I/Os leading to substantial I/O statistical errors.
229
% Anderson Paper
230
The 2004 paper by Anderson et. al.~~\cite{anderson2004buttress} has the following observations. A source of decreased precision came from the Kernel overhead for providing timestamp resolution. This would introduce substantial errors in the observed system metrics due to the use inaccurate tools when benchmarking I/O systems. These errors in perceived I/O response times can range from +350\% to -15\%.
231
%I/O benchmarking widespread practice in storage industry and serves as basis for purchasing decisions, performance tuning studies and marketing campaigns.
232
Issues of inaccuracies in scheduling I/O can result in as much as a factor 3.5 difference in measured response time and factor of 26 in measured queue sizes. These inaccuracies pose too much of an issue to ignore.
233
234
Orosz and Skopko examined the effect of the kernel on packet loss in their 2013 paper~\cite{Orosz2013}. Their work showed that when taking network measurements the precision of the timestamping of packets is a more important criterion than low clock offset, especially when measuring packet inter-arrival times and round-trip delays at a single point of the network. One concern is that Dumpcap is a single threaded application and was suspected to be unable to handle new arriving packets due to a small size of the kernel buffer. Work by Dabir and Matrawy, in 2008~\cite{dabir2007bottleneck}, attempted to overcome this limitation by using two semaphores to buffer incoming strings and improve the writing of packet information to disk.
235
236
Narayan and Chandy examined the concerns of distributed I/O and the different models of parallel application I/O.
237
%There are five major models of parallel application I/O. (1) Single output file shared by multiple nodes. (2) Large sequential reads by a single node at the beginning of computation and large sequential writes by a single node at the end of computation. (3) Checkpointing of states. (4) Metadata and read intensive (e.g. small data I/O and frequent directory lookups for reads).
238
Due to the striping of files across multiple nodes, this can cause any read or write to access all the nodes; which does not decrease the IATs seen. As the number of I/O operations increase and the number of nodes increase, the IAT times decreased.
239
Observations from Skopko in a 2012 paper~\cite{skopko2012loss} examined the nuance concerns of software based capture solutions. The main observation was software solutions relied heavily on OS packet processing mechanisms. Further more, depending on the mode of operation (e.g. interrupt or polling), the timestamping of packets would change.
240
241
As seen in previous trace work done~\cite{leung2008measurement,roselli2000comparison,seltzer2003nfs}, the general perceptions of how computer systems are being used versus their initial purpose have allowed for great strides in eliminating actual bottlenecks rather than spending unnecessary time working on imagined bottlenecks. Without illumination of these underlying actions (e.g. read-write ratios, file death rates, file access rates) these issues can not be readily tackled.
242
\\
243
244
\section{Background}
245
The Server Message Block (SMB) is an application-layer network protocol mainly used for providing shared access to files, shared access to printers, shared access to serial ports, miscellaneous communications between nodes on the network, as well as providing an authenticated inter-process communication mechanism.
246
%The majority of usage for the SMB protocol involves Microsfot Windows. Almost all implementations of SMB servers use NT Domain authentication to validate user-access to resources
247
The SMB 1.0 protocol has been found to have high/significant impact due to latency issues. Monitoring revealed a high degree of ``chattiness'' and disregard of network latency between hosts. Solutions to this problem were included in the updated SMB 2.0 protocol which decreases ``chattiness'' by reducing commands and sub-commands from over a hundred to nineteen. Additional changes, most significantly being increased security, were implemented in SMB 3.0 protocol (previously named SMB 2.2).
248
%\textcolor{red}{\textbf{Add information about SMB 2.X/3?}}
249
250
The rough order of communication for SMB session file interaction contains about five steps. First is a negotiation where a Microsoft SMB Protocol dialect is determined. Next a session is established to determine the share-level security. After this the Tree ID (TID) is determined for the share to be connected to as well as a file ID (FID) for a file requested by the client. From this establishment, I/O operations are performed using the FID given in the previous step.
251
252
% Information relating to the capturing of SMB information
253
The only data that needs to be tracked from the SMB traces are the UID and TID for each session. The MID value is used for tracking individual packets in each established session. The PID tracks the process running the command or series of commands on a host.
254
255
Some nuances of SMB protocol I/O are:
256
\begin{itemize}
257
\item SMB/SMB2 write request is the command that pushes bytes over the wire. \textbf{Note:} the response packet only confirms their arrival and use (e.g. writing).
258
\item SMB/SMB2 read response is the command that pushes bytes over the wire. \textbf{Note:} The request packet only asks for the data.
259
\end{itemize}
260
% Make sure to detail here how exactly IAT/RT are each calculated
261
262
\begin{figure}
263
\includegraphics[width=0.5\textwidth]{./images/smbPacket.jpg}
264
\caption{Visualization of SMB Packet}
265
\label{fig:smbPacket}
266
\end{figure}
267
268
\subsection{Issues with Tracing}
269
\label{Issues with Tracing}
270
There are three general approaches to creating a benchmark based on a trade-off between experimental complexity and resemblance to the original application. (1) Connect the system to a production test environment, run the application, and measure the application metrics. (2) Collect traces from running the application and replay them (after possible modification) back on the test I/O system. (3) Generate a synthetic workload and measure the system performance.
271
272
The majority of benchmarks are attempts to represent a known system and structure on which some ``original'' design/system was tested. While this is all well and good, there are many issues with this sort of approach; temporal \& spatial scaling concerns, timestamping and buffer copying, as well as driver operation for capturing packets~\cite{Orosz2013,dabir2007bottleneck,skopko2012loss}. Each of these aspects contribute to the initial problems with dissection and analysis of the captured information. For example, inaccuracies in scheduling I/Os may result in as much as a factor of 3.5 differences in measured response time and factor of 26 in measured queue sizes; differences that are too large to ignore~\cite{anderson2004buttress}.
273
Dealing with timing accuracy and high throughput involves three challenges. (1) Designing for dealing with peak performance requirements. (2) Coping with OS timing inaccuracies. (3) Working around unpredictable OS behavior; e.g. mechanisms to keep time and issue I/Os or performance effects due to interrupts.
274
275
Temporal scaling refers to the need to account for the nuances of timing with respect to the run time of commands; consisting of computation, communication \& service. A temporally scalable benchmarking system would take these subtleties into account when expanding its operation across multiple machines in a network. While these temporal issues have been tackled for a single processor (and even somewhat for cases of multi-processor), these same timing issues are not properly handled when dealing with inter-network communication. Inaccuracies in packet timestamping can be caused due to overhead in generic kernel-time based solutions, as well as use of the kernel data structures ~\cite{PFRINGMan,Orosz2013}. \\
276
Spatial scaling refers to the need to account for the nuances of expanding a benchmark to incorporate a number of (\textbf{n}) machines over a network. A system that properly incorporates spatial scaling is one that would be able to incorporate communication (even in varying intensities) between all the machines on a system, thus stress testing all communicative actions and aspects (e.g. resource locks, queueing) on the network.
277
278
\section{Packet Capturing System}
279
In this section, we examine the packet capturing system as well as decisions made that influence its capabilities. We illustrate the existing university network filesystem as well as our methods for ensuring high-speed packet capture. Then, we discuss the analysis code we developed for examining the captured data.
280
% and on the python dissection code we wrote for performing traffic analysis.
281
282
\subsection{UITS System Overview}
283
We collected traces from the University of Connecticut University Information Technology Services (UITS) centralized storage server. The UITS system consists of five Microsoft file server cluster nodes. These blade servers are used to host SMB file shares for various departments at UConn as well as personal drive share space for faculty, staff and students, along with at least one small group of users. Each server is capable of handling 1~Gb/s of traffic in each direction (e.g. outbound and inbound traffic). All together the five blade server system can in theory handle 10~Gb/s of receiving and transmitting data.
284
%Some of these blade servers have local storage but the majority do not have any.
285
The blade servers serve SMB but the actual storage is served by SAN storage nodes that sit behind them. This system does not currently implement load balancing. Instead, the servers are set up to spread the traffic load among four of the active cluster nodes while the fifth node is passive and purposed to take over in the case that any of the other nodes go down (e.g. become inoperable or crash).
286
287
The topology for the packet duplicating element is shown in Figure~\ref{fig:captureTopology}. For our tracing, we installed a 10~Gb network tap on the file server switch, allowing our storage server to obtain a copy of all network traffic going to the 5 file servers. The reason for using 10Gb hardware is to help ensure that the system is able to capture and all information on the network at peak theoretical throughput.
288
289
290
\subsection{High-speed Packet Capture}
291
\label{Capture}
292
%The packet capturing aspect of the tracing system is fairly straight forward.
293
%On top of the previously mentioned alterations to the system (e.g. PF\_RING), the capture of packets is done through the use of \textit{tshark}, \textit{pcap2ds}, and \textit{inotify} programs.
294
%The broad strokes are that incoming SMB/CIFS information comes from the university's network. All packet and transaction information is passed through a duplicating switch that then allows for the tracing system to capture these packet transactions over a 10 Gb port. These packets are
295
%passed along to the \textit{tshark} packet collection program which records these packets into a cyclical capturing ring. A watchdog program (\textit{inotify}) watches the directory where all of these packet-capture (pcap) files are being stored. As a new pcap file is completed \textit{inotify} passes the file to \textit{pcap2ds} along with what protocol is being examined (i.e. SMB). The \textit{pcap2ds} program reads through the given pcap files,
296
297
In order to maximize our faithful capture of the constant rate of traffic, we implement an ntop~\cite{ntopWebsite} solution called PF\_RING~\cite{pfringWebsite} to dramatically improve the storage server's packet capture speed.
298
%A license was obtained for scholastic use of PF\_RING. PF\_RING implements a ring buffer to provide fast and efficient packet capturing. Having implemented PF\_RING, the next step was to
299
We had to tune an implementation of \texttt{tshark} (wireshark's terminal pcap implementation) to maximize the packet capture and dissection into the DataSeries format~\cite{dataseriesGit}.
300
%The assumption being made is that PF\_RING tackles and takes care of the concerns of packets loss due to buffer size, storage, and writing. \textit{tshark} need only read in those packets and generate the necessary DataSeries (ds) files.
301
To optimize this step a capture ring buffer flag is used to minimize the amount of space used to write pcap files, while optimizing the amount of time to
302
%\textit{pcap2ds} can
303
filter data from the pcap files.
304
The filesize used was in a ring buffer where each file captured was 64000 kB.
305
% This causes tshark to switch to the next file after it reaches a determined size.
306
%To simplify this aspect of the capturing process, the entirety of the capturing, dissection, and permanent storage was all automated through watch-dog scripts.
307
\begin{figure*}
308
\includegraphics[width=\textwidth]{./images/packetcapturetopology.png}
309
\caption{Visualization of Packet Capturing System}
310
\label{fig:captureTopology}
311
\end{figure*}
312
The system for taking captured \texttt{.pcap} files and writing them into the DataSeries format (i.e. \texttt{.ds}) does so by first creating a structure (based on a pre-written determination of the data desired to capture). Once the code builds this structure, it then reads through the capture traffic packets while dissecting and filling in the prepared structure with the desired information and format.
313
Due to the fundamental nature of this work, there is no need to track every piece of information that is exchanged, only that information which illuminates the behavior of the clients \& servers that function over the network (e.g. I/O transactions). It should also be noted that all sensitive information being captured by the tracing system is hashed to protect the users whose information is examined by the tracing system. Further more, we now only receive the SMB header information since that contains the I/O information we seek, while the body of the SMB traffic is not passed through to better ensure security of the university's network communications.
314
315
\subsection{DataSeries Analysis}
316
317
Building upon existing code for the interpretation and dissection of the captured \texttt{.ds} files, we developed C/C++ code for examining the captured traffic information. From this analysis, a larger text file is created that contains read, write, create and general I/O information at both a global scale and individual tracking ID (UID/TID) level. In addition, read and write buffer size information is tracked, as well as the inter-arrival and response times. Also included in this data is oplock information and IP addresses. The main contribution of this step is to aggregate seen information for later interpretation of the results.
318
This step also creates an easily digestible output that can be used to re-create all tuple information for SMB/SMB2 sessions that are witnessed over the entire time period.
319
Sessions are any communication where a valid UID and TID is used.
320
321
%\subsection{Python Dissection}
322
%The final step of our SMB/SMB2 traffic analysis system is the dissection of the \texttt{AnalysisModule} output using the pandas data analysis library~\cite{pandasPythonWebsite}. The pandas library is a python implementation similar to R. In this section of the analysis structure, the generated text file is tokenized and placed into specific DataFrames representing the data seen for each 15 minute period. The python code is used for the analysis and further dissection of the data. This is where the cumulative distribution frequency and graphing of collected data is performed. Basic analysis and aggregation is also performed in this part of the code. This analysis includes the summation of individual session I/O (e.g. reads, writes, creates) as well as the collection of inter arrival time data and response time data.
323
324
\section{Data Analysis}
325
\label{sec:data-analysis}
326
327
\begin{table}[]
328
\centering
329
\begin{tabular}{|l|l|}
330
\hline
331
% & Academic Engineering \\ \hline
332
%Maximum Tuples in 15-min Window & 36 \\ %\hline
333
%Total Tuples Seen & 2721 \\ \hline
334
%\textcolor{red}{Maximum Sessions in 15-min Window} & 35 \\ %\hline
335
%Maximum Non-Session in 15-min Window & 2 \\ \hline
336
Total Days & 41 \\ %\hline
337
Total Sessions & 2270 \\ %\hline
338
%Total Non-Sessions & 451 \\ \hline
339
Number of SMB Operations & 2596081187 \\ %\hline
340
Number of Read I/Os & 42948043
341
\\ %\hline
342
Number of Write I/Os & 75465684 \\ %\hline
343
R:W I/O Ratio & 0.569 \\ %\hline
344
Number of Creates & 386934029 \\ %\hline
345
Number of General SMB Operations & 2090733431 \\ \hline
346
Total Data Read (GB) & 5.858 \\ %\hline
347
Total Data Written (GB) & 4.747 \\ %\hline
348
Average Read Size (B) & 144 \\ %\hline
349
Average Write Size (B) & 63 \\ \hline
350
%Percentage of Read Bytes of Total Data & 99.4\% \\ %\hline
351
%Percentage of Written Bytes of Total Data & 0.6\% \\ %\hline
352
%Total R:W Byte Ratio & 166.446693744549 \\ %\hline
353
%Average R:W Byte Ratio & 0.253996031053668 \\ \hline
354
\end{tabular}
355
\label{tbl:TraceSummaryTotal}
356
\caption{Summary of Trace I/O Statistics for the time of February 3rd, 2019 to March 15th, 2019}
357
\vspace{-2em}
358
\end{table}
359
% NOTE: Not sure but this reference keeps referencing the WRONG table
360
361
Table~\ref{tbl:TraceSummaryTotal}
362
shows a summary of the I/O operations, response times, and inter arrival times observed for the network filesystem. This table illustrates that the majority of I/O operations are \textcolor{red}{general; showing that $95.39$\% of the network file system I/O are metadata operations.}
363
364
Our examination of the collected network filesystem data revealed interesting patterns for the current use of CIFS/SMB in a large engineering academic setting. \textcolor{red}{The first is that there is a major shift away from read and write operations towards more metadata-based ones. This matches the last CIFS observations made by Leung et.~al.~that files were being generated and accessed infrequently. The change in operations are due to a movement of use activity from reading and writing data to simply checking file and directory metadata.
365
However, since the earlier study, SMB has transitioned to the SMB2 protocol which was supposed to be less "chatty" and thus we would expect fewer general SMB operations.
366
Table~\ref{tbl:SMBCommands} shows a breakdown of SMB and SMB2 usage on just March 15th. From this table, one can see that despite the fact that the SMB2 protocol makes up $99.96$\% of total network operations compared to just 0.04\% for SMB, indicating that most clients have upgraded to SMB2. However, $92.79$\% of SMB2 I/O are still general operations. Contrary to purpose of implementing the SMB2 protocol, there is still a large amount of general I/O. }
367
%While CIFS/SMB protocol has less metadata operations, this is due to a depreciation of the SMB protocol commands, therefore we would expect to see less total operations (e.g. $0.04$\% of total operations).
368
%The infrequency of file activity is further strengthened by our finding that within a week long window of time there are no Read or Write inter arrival times that can be calculated.
369
%\textcolor{red}{XXX we are going to get questioned on this. its not likely that there are no IATs for reads and writes}
370
\textcolor{red}{General operations happen at very high frequency with inter arrival times that were found to be relatively short (36$\mu$s on average). }
371
372
\textcolor{red}{Taking a deeper look at the SMB2 operations, shown in the bottom half of Table~\ref{tbl:SMBCommands}, we see that $85.41$\% of the general operations are negotiate commands. These are commands sent by the client to notify the server which dialects of the SMB2 protocol the client can understand. The three next most common commands are close, query info, and query directory. The latter two relate to metadata information of shares and files accessed, however the close operation relates to the create operations relayed over the network. Note that the create command is also used as an open file. The first thing one will notice is that the number of closes is greater than the total number of create operations; by $16.44$\%. These extra close operations are most likely due to applications doing multiple closes that do not need to be done.}
373
374
\begin{table}
375
\centering
376
\begin{tabular}{|l|c|c|c|}
377
\hline
378
I/O Operation & SMB & SMB2 & Both \\ \hline
379
Read Operations & 23416 & 42924627 & 42948043 \\
380
Read \% & 0.016\% & 1.75\%& 1.65\%\\
381
Write Operations & 4047 & 75461637 & 75465684 \\
382
Write \% & 0.028\% & 3.01\% & 2.91\% \\
383
Create Operations & 0 & 386934029 & 386934029 \\
384
Create \% & 0.00\% & 15.78\% & 14.9\% \\
385
General Operations & 144177220 & 1946556211 & 2090733431 \\
386
General \% & 99.98\% & 79.39\% & 80.53\% \\ \hline
387
Combine Protocol Operations & 144204683 & 2451876504 & 2596081187 \\
388
Combined Protocols \% & 5.55\% & 94.45\% & 100\% \\ \hline
389
%\end{tabular}
390
%\caption{\label{tbl:SMBCommands}Percentage of SMB and SMB2 Protocol Commands on March 15th}
391
%\end{table}
392
%\begin{table}
393
%\centering
394
%\begin{tabular}{|l|c|c|}
395
\hline \hline
396
SMB2 General Operation & \multicolumn{2}{|c|}{Occurrences} & Percentage of Total \\ \hline
397
Negotiate & \multicolumn{2}{|c|}{139513151} & 5.69\% \\
398
Session Setup & \multicolumn{2}{|c|}{24028626} & 0.98\%\\
399
Logoff & \multicolumn{2}{|c|}{1160528} & 0.05\% \\
400
Tree Connect & \multicolumn{2}{|c|}{867601720} & 35.39\% \\
401
Tree Disconnect & \multicolumn{2}{|c|}{13509426} & 0.55\% \\
402
Close & \multicolumn{2}{|c|}{563355572} & 22.97\% \\
403
Flush & \multicolumn{2}{|c|}{7224088} & 0.29\% \\
404
Lock & \multicolumn{2}{|c|}{11712449} & 0.48\% \\
405
IOCtl & \multicolumn{2}{|c|}{35813324} & 1.46\% \\
406
Cancel & \multicolumn{2}{|c|}{0} & 0.00\% \\
407
Echo & \multicolumn{2}{|c|}{64369} & 0.003\% \\
408
Query Directory & \multicolumn{2}{|c|}{25574851} & 1.04\% \\
409
Change Notify & \multicolumn{2}{|c|}{4160183} & 0.17\% \\
410
Query Info & \multicolumn{2}{|c|}{213781466} & 8.72\% \\
411
Set Info & \multicolumn{2}{|c|}{38941015} & 1.59\% \\
412
Oplock Break & \multicolumn{2}{|c|}{118120} & 0.005\% \\ \hline
413
\end{tabular}
414
\caption{\label{tbl:SMBCommands}Percentage of SMB and SMB2 Protocol Commands on March 15th. Breakdown of General Operations for SMB2}
415
\vspace{-2em}
416
\end{table}
417
418
\subsection{I/O Data Request Sizes}
419
\textcolor{red}{Figures~\ref{fig:IO-All} and~\ref{fig:IO-R+W} show the amount of I/O in 15-minute periods during the week of March 12-18, 2017.
420
The general I/O (GIO) value is representative of I/O that does not include read, write, or create actions. For the most part, these general I/O are mostly metadata operations. As one can see in Figure~\ref{fig:IO-All}, the general I/O dominates any of the read or write operations. Figure~\ref{fig:IO-R+W} is a magnification of the read and write I/O from Figure~\ref{fig:IO-All}. Here we see that the majority of I/O operations belong to reads. There are some spikes where more write I/O occur, but these events are in the minority. One should also notice that, as would be expected, the spikes of I/O activity occur around the center of the day (e.g. 8am to 8pm), and during the week (March 12 was a Sunday and March 18 was a Saturday).} \textbf{EVERYTHING HERE FORWARD NEEDS TO BE RE-READ AND RE-WRITTEN}
421
%\begin{figure}
422
% \includegraphics[width=0.5\textwidth]{./images/AIO.pdf}
423
% \caption{All I/O}
424
% \label{fig:IO-All}
425
%\end{figure}
426
%\begin{figure}
427
% \includegraphics[width=0.5\textwidth]{./images/RWIO-win.pdf}
428
% \caption{Read and Write I/O}
429
% \label{fig:IO-R+W}
430
%\end{figure}
431
\textcolor{red}{Figure~\ref{fig:Agg-AvgBytes} shows the average bytes transferred per read and write I/O operation. The most noticeable aspect of this graph is that the average number of bytes for write operations is much larger than that for reads. In other words, in spite of reads being more frequent than writes, each write transfer significantly more data.
432
%This is contrary to the number of I/O operations shown in Figure~\ref{fig:IO-R+W}, where one would expect that read operations cause the largest number of bytes.
433
Writes occur in the expected window of the center of each day, however there are reads that spike in-between these times. These large reads are due to backup processes reading from the fileservers for archiving to an offsite backup system. }
434
%This could also be attributed to simple reads relating to metadata\textcolor{red}{???}
435
436
%\begin{figure}
437
% \includegraphics[width=0.5\textwidth]{./images/aggAvgBytes.pdf}
438
% \caption{Average Bytes by I/O}
439
% \label{fig:Agg-AvgBytes}
440
%\end{figure}
441
%
442
%\begin{figure}
443
% \includegraphics[width=0.5\textwidth]{./images/bytesCompare.pdf}
444
% \caption{Total Bytes by I/O}
445
% \label{fig:bytesCompare}
446
%\end{figure}
447
448
\begin{figure}
449
\includegraphics[width=0.5\textwidth]{./images/smb_read_bytes_cdf.pdf}
450
\caption{CDF of Bytes Transferred for Read I/O}
451
\label{fig:CDF-Bytes-Read}
452
\end{figure}
453
454
\begin{figure}
455
\includegraphics[width=0.5\textwidth]{./images/smb_write_bytes_cdf.pdf}
456
\caption{CDF of Bytes Transferred for Write I/O}
457
\label{fig:CDF-Bytes-Write}
458
\end{figure}
459
460
%\begin{figure}
461
% \includegraphics[width=0.5\textwidth]{./images/CDF-ioBuff-win.pdf}
462
% \caption{CDF of Bytes Transferred for Read+Write I/O}
463
% \label{fig:CDF-Bytes-RW}
464
%\end{figure}
465
466
\textcolor{red}{Figure~\ref{fig:bytesCompare} shows that the overall total number of bytes is dominated by read I/O. We translate the difference between Figures~\ref{fig:Agg-AvgBytes} and~\ref{fig:bytesCompare} data to mean that while reads still dominate I/O over the network filesystem, the write I/O cause the largest generation of network traffic on average.
467
Figures~\ref{fig:CDF-Bytes-Read},~\ref{fig:CDF-Bytes-Write}, and~\ref{fig:CDF-Bytes-RW} show cumulative distribution functions (CDF) for bytes read, bytes written, and total bytes transferred respectively. As can be seen, the CDFs are step functions showing clearly that data transfers are on powers-of-2 boundaries. Table~\ref{fig:transferSizes} shows a tabular view of this data. For reads, 49\% are 4K or less, with another 23\% at 64K request sizes. There are no read requests larger than 64K. This data is similar to what was observed by Leung et al. Writes, on the other hand, are very different. Leung et al. showed that writes were 60-70\% less than 4K and 90\% less than 64K. In our data, however, we see that only 4\% of writes are less than 4K, 50\% are 64K requests, and 20\% of requests are very large 1M writes. In the 10 years since the last study, it is clear that writes have become significantly larger. This may be explained by the fact that files are much larger and being written as larger blocks.}
468
469
\begin{table}
470
\centering
471
\begin{tabular}{|l|c|c|}
472
\hline
473
Transfer size & Reads & Writes \\ \hline
474
$< 4$ & 0.17\% & 14.14\% \\
475
$= 4$ & 2.16\% & 4.36\% \\
476
$>4, < 64$ & 19.8\% & 42.57\% \\
477
$= 64$ & 35.12\% & 34.12\% \\
478
$>64, < 512$ & 42.68\% & 4.8\% \\
479
$= 512$ & 0.008\% & 1.06e-5\% \\
480
$= 1024$ & 1.48e-5\% & 3.31e-5\% \\ \hline
481
\end{tabular}
482
\caption{\label{fig:transferSizes}Percentage of transfer sizes for reads and writes}
483
\vspace{-2em}
484
\end{table}
485
486
\textcolor{red}{In comparison of the read, write, and create operations we founds that the vast majority of these type of I/O belong to reads. Furthermore, read operations account for the largest aggregate of bytes transferred over the network. However, non-intuitively, it is write operations that cause the largest average number of bytes to be transferred per operations; a magnitude more expensive. The observed byte data appears as a step function following in powers of 2 (e.g. 32K, 64K). }
487
488
% XXX I think we should get rid of this figure - not sure it conveys anything important that is not better conveyed than the CDF
489
%Figure~\ref{fig:Agg-AvgRT} shows the average response time (RT) for the different I/O operations. The revealing information is that write I/Os take the longest average time. This is expected since writes transfer more data on average. There is an odd spike for create I/O which can be due to a batch of files or nested directories being made. There are points where read I/O RT can be seen, but this only occurs in areas where large RT for write I/O occur. This is attributed to a need to verify the written data.
490
491
%\begin{figure}
492
% \includegraphics[width=0.5\textwidth]{./images/aggAvgRTs-windowed.pdf}
493
% \caption{Average Response Time by I/O Operation}
494
% \label{fig:Agg-AvgRT}
495
%\end{figure}
496
497
% XXX I think we should get rid of this figure - not sure it conveys anything important that is not better conveyed than the CDF
498
%Figure~\ref{fig:Agg-AvgBytes} shows the average inter arrival time (IAT) for the different I/O operations. \textcolor{red}{Issue: Data only exists for general operations, NOT for other operations. In other words, data for all other operations was IAT of zero.} \textcolor{blue}{Idea: This is due to single operation by a single user and then no operation being performed again. This would aligns with the ideas of Lueng et.~al.~who noticed that files were being interacted with only once or twice and then not again.}
499
500
%\begin{figure}
501
% \includegraphics[width=0.5\textwidth]{./images/aggAvgIATs-windowed.pdf}
502
% \caption{Average Inter Arrival Time by I/O Operation}
503
% \label{fig:Agg-AvgIAT}
504
%\end{figure}
505
506
%The following is a list of data collected and why:
507
%\begin{itemize}
508
% \item TID-to-IP map: with the hashing, the only way to maintain mapping of `share-types' (i.e. share-paths) to TIDs is via IP (reverse DNS).
509
% \item FID Data: holds the number of reads, writes, and size of the FID (tracked) for which this information is tracked (per FID).
510
% \item Tuple Data: holds the reads and writes performed by a seen tuple (per tuple) along with by the tuple and FID's data.
511
% \item TID Data: holds the number of reads, writes, creates, and total I/O events along with the last time each/any command was seen. Maps are kept of the buffs seen, general IAT, read IAT, write IAT, create IATs.
512
% \item Tuple Info: Tracking the tuples seen along with a map to that tuple's (per tuple) data.
513
% \item Oplock Data: Tracks the different types of oplocks that are seen per 15 minutes.
514
% \item Read/Write Buff: Maps that are used to track the different sized buffers used for Read/Write commands.
515
% \item `filesizeMap': Used for track the different sized buffers to pass data along the network (generic and all inclusive; ie. tuple level data).
516
% \item I/O Events: Track the number of I/O events seen in 15 minute periods. I/Os include - read, write, create, general.
517
%\end{itemize}
518
519
\subsection{I/O Response Times}
520
521
\begin{table}[]
522
\centering
523
\begin{tabular}{|l|l|l|l|l|}
524
\hline
525
& Reads & Writes & Creates & General \\ \hline
526
I/O \% & 1.65 & \multicolumn{1}{l|}{2.91} & \multicolumn{1}{l|}{14.9} & \multicolumn{1}{l|}{80.53} \\ \hline
527
Avg RT (ms) & 131773.717697 & \multicolumn{1}{l|}{495.248564} & \multicolumn{1}{l|}{730.298784} & \multicolumn{1}{l|}{9187.611725} \\ \hline
528
Avg IAT (ms) & 78299.580708 & \multicolumn{1}{l|}{44560.891349} & \multicolumn{1}{l|}{8690.900040} & \multicolumn{1}{l|}{1608.438123} \\ \hline
529
%\hline
530
%Total RT (s) & 224248 & \multicolumn{1}{l|}{41100} & \multicolumn{1}{l|}{342251} & \multicolumn{1}{l|}{131495} \\ \hline
531
%\% Total RT & 30.34\% & \multicolumn{1}{l|}{5.56\%} & \multicolumn{1}{l|}{46.3\%} & \multicolumn{1}{l|}{17.79\%} \\ \hline
532
\end{tabular}
533
\caption{Summary of Trace Statistics: Average Response Time (RT) and Inter Arrival Time (IAT)}
534
\label{tbl:PercentageTraceSummary}
535
\vspace{-2em}
536
\end{table}
537
538
%\begin{table}[]
539
%\centering
540
%\begin{tabular}{|l|l|l|l|l|l|}
541
%\hline
542
% & Reads & Writes & Creates & General R-W \\ \hline
543
%Total RT (ms) & 224248442 & \multicolumn{1}{l|}{41100075} & \multicolumn{1}{l|}{342251439} & \multicolumn{1}{l|}{131495153} & \multicolumn{1}{l|}{258573201} \\ \hline
544
%\% Total RT & 30.34\% & \multicolumn{1}{l|}{5.56\%} & \multicolumn{1}{l|}{46.3\%} & \multicolumn{1}{l|}{17.79\%} & \multicolumn{1}{l|}{34.99\%} \\ \hline
545
%\end{tabular}
546
%\caption{Summary of Response Time (RT) Statistics: Total RT and Percentage RT per Operation}
547
%\label{tbl:PercentageRTSummary}
548
%\end{table}
549
550
%~!~ Addition since Chandy writing ~!~%
551
Most previous tracing work has not provided data on I/O response times or command latency which serves as an approximation of server load. In
552
Table~\ref{tbl:PercentageTraceSummary} we show a summary of the response times for read, write, create, and general commands. We that most general operations have short average response times (24.17 $\mu$s). This exemplifies that these general operations occur in great numbers, run very quickly, and happen at high frequency.
553
Other observations of the data show that the number of writes are very few, although the response time for their operations is the longest. Creates happen more often, but have a quicker response time, because most of the create commands are actually opens. Although read operations are only a few percentage of the total operations they have a greater average response time than creates.
554
555
To get an indication of how much of an effect these general commands take on overall latency, we also calculated the total aggregate response time for read, write, create, and general operations. We see that even though general commands account for 95\% of all commands, they only account for only 17.8\% of the total response time. Thus, while the volume of general operations does not present an extraordinary burden on server load, reducing these operations can present a clear performance benefit. We also see that creates take the most amount of time ($46.3$\%) of the total response time for all operations. As seen in Table~\ref{tbl:SMBCommands}, the majority of general operations are negotiations while $6.38$\% are closes; which relate to create operations. This shows that while creates are only $5.08$\% on March 15th (and $2.5$\% of the week's operations shown in Table~\ref{tbl:PercentageTraceSummary}) of the total operations performed, they are responsible for $46.3$\% of the time spent performing network I/O.
556
%
557
%% Not Needed to Say Since we have no data
558
%%One key observation is that there were no inter arrival time calculations for read, write, or create operations. We interpret this data to reflect the observations of Leung et.~al.~that noticed that files are interacted with only a few times and then not interacted with again. Extrapolating this concept, we interpret the data to illustrate that files may be read or written once, but then are not examined or interacted with again.
559
%%\textcolor{blue}{This was entirely unexpected and was discovered as a result of our original assumptions made based on what scope we believed to be the best interpretation of user activity on the network filesystem.}
560
%
561
%%\begin{table}[]
562
%%\centering
563
%%\begin{tabular}{|l|l|}
564
%%\hline
565
%% & Count \\ \hline
566
%%Sessions & 122 \\ \hline
567
%%Non-Sessions & 2 \\ \hline
568
%%\end{tabular}
569
%%\caption{Summary of Maximum Session and Non-Session Seen}
570
%%\label{tbl:Counts}
571
%%\end{table}
572
%%
573
%%\textcolor{red}{Not sure if presenting a count of the number of sessions seen is important or worth showing.}
574
%
575
%%\begin{table}[]
576
%%\centering
577
%%\begin{tabular}{|l|l|l|}
578
%%\hline
579
%% & Reads & Writes \\ \hline
580
%%Average & 27167.76 B & 106961.36 B \\ \hline
581
%%Percentage & 99.4\% & 0.6\% \\ \hline
582
%%\end{tabular}
583
%%\caption{Summary of Bytes Transferred Over the Network}
584
%%\label{tbl:Bytes}
585
%%\end{table}
586
%
587
%%\textcolor{red}{Reference the large single table instead}
588
%%Table~\ref{tbl:TraceSummary} shows our findings relating to the total number of bytes transferred over the network due to Read and Write operations. Mimicing the findings from Figure~\ref{fig:Agg-AvgBytes}, the table shows that while the percentage of total bytes passed over the network is dominated by Read operations the average bytes pushed by Write operations is of a magnitude greater.
589
%
590
%%Tables to be included:
591
%%\begin{enumerate}
592
%% \item Return Times:
593
%% \begin{itemize}
594
%% \item General
595
%% \item Read
596
%% \item Write
597
%% \item Create
598
%% \item Read+Write
599
%% \end{itemize}
600
%% \item Inter Arrival Times
601
%% \begin{itemize}
602
%% \item General
603
%% \item Read
604
%% \item Write
605
%% \item Create
606
%% \item Read+Write
607
%% \end{itemize}
608
%% \item Bytes per Request (Bytes Over Network)
609
%% \begin{itemize}
610
%% \item Read
611
%% \item Write
612
%% \item Read+Write
613
%% \end{itemize}
614
%%\end{enumerate}
615
%%Modeling to include:
616
%%\begin{enumerate}
617
%% \item Inter Arrival Time CDF
618
%% \begin{itemize}
619
%% \item Read
620
%% \item Write
621
%% \item Read+Write
622
%% \end{itemize}
623
%%\end{enumerate}
624
%
625
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 20~$\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 well as seen in Figure~\ref{fig:CDF-RT-General}. Interestingly, the response/return time (RT) for the general metadata operations follows a linear growth.
626
627
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}) follows a 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 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.
628
%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
629
The write I/O step function behavior is somewhat visible in the CDF of both reads and writes in Figure~\ref{fig:CDF-RT-RW}. 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.
630
631
% Note: RT + IAT time CDFs exist in data output
632
633
% IAT information
634
635
\begin{figure}
636
\includegraphics[width=0.5\textwidth]{./images/smb_general_iats_cdf.pdf}
637
\caption{CDF of Inter Arrival Time for General I/O}
638
\label{fig:CDF-IAT-General}
639
\end{figure}
640
641
\begin{figure}
642
\includegraphics[width=0.5\textwidth]{./images/smb_general_iats_pdf.pdf}
643
\caption{PDF of Inter Arrival Time for General I/O}
644
\label{fig:PDF-IAT-General}
645
\end{figure}
646
647
\begin{figure}
648
\includegraphics[width=0.5\textwidth]{./images/smb_read_iats_cdf.pdf}
649
\caption{CDF of Inter Arrival Time for Read I/O}
650
\label{fig:CDF-IAT-Read}
651
\end{figure}
652
653
\begin{figure}
654
\includegraphics[width=0.5\textwidth]{./images/smb_read_iats_pdf.pdf}
655
\caption{PDF of Inter Arrival Time for Read I/O}
656
\label{fig:PDF-IAT-Read}
657
\end{figure}
658
659
\begin{figure}
660
\includegraphics[width=0.5\textwidth]{./images/smb_write_iats_cdf.pdf}
661
\caption{CDF of Inter Arrival Time for Write I/O}
662
\label{fig:CDF-IAT-Write}
663
\end{figure}
664
665
\begin{figure}
666
\includegraphics[width=0.5\textwidth]{./images/smb_write_iats_pdf.pdf}
667
\caption{PDF of Inter Arrival Time for Write I/O}
668
\label{fig:PDF-IAT-Write}
669
\end{figure}
670
671
\begin{figure}
672
\includegraphics[width=0.5\textwidth]{./images/smb_create_iats_cdf.pdf}
673
\caption{CDF of Inter Arrival Time for Create I/O}
674
\label{fig:CDF-IAT-Create}
675
\end{figure}
676
677
\begin{figure}
678
\includegraphics[width=0.5\textwidth]{./images/smb_create_iats_pdf.pdf}
679
\caption{PDF of Inter Arrival Time for Create I/O}
680
\label{fig:PDF-IAT-Create}
681
\end{figure}
682
683
% RTs information
684
685
\begin{figure}
686
\includegraphics[width=0.5\textwidth]{./images/smb_general_rts_cdf.pdf}
687
\caption{CDF of Response Time for General I/O}
688
\label{fig:CDF-RT-General}
689
\vspace{-2em}
690
\end{figure}
691
692
\begin{figure}
693
\includegraphics[width=0.5\textwidth]{./images/smb_general_rts_pdf.pdf}
694
\caption{PDF of Response Time for General I/O}
695
\label{fig:PDF-RT-General}
696
\vspace{-2em}
697
\end{figure}
698
699
\begin{figure}
700
\includegraphics[width=0.5\textwidth]{./images/smb_read_rts_cdf.pdf}
701
\caption{CDF of Response Time for Read I/O}
702
\label{fig:CDF-RT-Read}
703
\vspace{-2em}
704
\end{figure}
705
706
\begin{figure}
707
\includegraphics[width=0.5\textwidth]{./images/smb_read_rts_pdf.pdf}
708
\caption{PDF of Response Time for Read I/O}
709
\label{fig:PDF-RT-Read}
710
\vspace{-2em}
711
\end{figure}
712
713
\begin{figure}
714
\includegraphics[width=0.5\textwidth]{./images/smb_write_rts_cdf.pdf}
715
\caption{CDF of Return Time for Write IO}
716
\label{fig:CDF-RT-Write}
717
\vspace{-2em}
718
\end{figure}
719
720
\begin{figure}
721
\includegraphics[width=0.5\textwidth]{./images/smb_write_rts_pdf.pdf}
722
\caption{PDF of Return Time for Write IO}
723
\label{fig:PDF-RT-Write}
724
\vspace{-2em}
725
\end{figure}
726
727
\begin{figure}
728
\includegraphics[width=0.5\textwidth]{./images/smb_create_rts_cdf.pdf}
729
\caption{CDF of Response Time for Create I/O}
730
\label{fig:CDF-RT-Create}
731
\vspace{-2em}
732
\end{figure}
733
734
\begin{figure}
735
\includegraphics[width=0.5\textwidth]{./images/smb_create_rts_pdf.pdf}
736
\caption{PDF of Response Time for Create I/O}
737
\label{fig:PDF-RT-Create}
738
\vspace{-2em}
739
\end{figure}
740
741
%\begin{figure}
742
% \includegraphics[width=0.5\textwidth]{./images/CDF-ioRT-win.pdf}
743
% \caption{CDF of Response Time for Read+Write I/ O}
744
% \label{fig:CDF-RT-RW}
745
%\end{figure}
746
747
%\begin{figure}
748
% \includegraphics[width=0.5\textwidth]{./images/CDF-rBuff-win.pdf}
749
% \caption{CDF of Bytes Transferred for Read IO}
750
% \label{fig:CDF-Bytes-Read}
751
%\end{figure}
752
753
%\begin{figure}
754
% \includegraphics[width=0.5\textwidth]{./images/CDF-wBuff-win.pdf}
755
% \caption{CDF of Bytes Transferred for Write IO}
756
% \label{fig:CDF-Bytes-Write}
757
%\end{figure}
758
759
%\begin{figure}
760
% \includegraphics[width=0.5\textwidth]{./images/CDF-ioBuff-win.pdf}
761
% \caption{CDF of Bytes Transferred for Read+Write IO}
762
% \label{fig:CDF-Bytes-RW}
763
%\end{figure}
764
765
%Points worth mentioning:
766
%\begin{itemize}
767
% \item Scale of time is only to the microsecond due to the original pcap file capturing process. \texttt{tshark} only captures to a microsecond scale in our implementation.
768
% \item Due to a complication of how DataSeries stores information, there are potentially more SMB2 packets than actually occurred since $0$ is an acceptable command for SMB2 (although not used for SMB).
769
%\end{itemize}
770
771
\subsection{Distribution Models}
772
773
For simulations and analytic modeling, it is often useful to have models that describe the behavior of storage systems I/O. In this section, we attempt to map traditional probabilistic distributions to the data that we have observed.
774
Specifically, taking the developed CDF graphs, we perform curve fitting to determine the applicability of Gaussian and Weibull distributions to the the network filesystem I/O behavior. Note that an exponential distribution, typically used to model interarrival times and response times, is a special case of a Weibull distribution where $k=1$.
775
Table~\ref{tbl:curveFitting} shows best-fit parametrized distributions for the measured. % along with $R^2$ fitness values.
776
777
%Based on the collected IAT and RT data, the following are the best fit curve representation equations with supporting $R^{2}$ values. In the case of each, it was found that the equation used to model the I/O behavior was a Gaussian equation with a single term.
778
%\begin{equation} f(x) = a_1 * e^{-((x-b_1)/c_1)^2)} \end{equation}
779
%The $R^2$ values for each CDF graph were found to be the following:
780
%\begin{itemize}
781
% \item General Command IAT CDF, shown in Figure~\ref{fig:CDF-IAT-General}, had $R^2$ Value of $0.6704$.
782
% \item General Command RT CDF, shown in Figure~\ref{fig:CDF-RT-General}, had $R^2$ Value of $0.9728$.
783
% \item Read command RT CDF, shown in Figure~\ref{fig:CDF-RT-Read}, had $R^2$ Value of $0.7754$.
784
% \item Write command RT CDF, shown in Figure~\ref{fig:CDF-RT-Write}, had $R^2$ Value of $0.7797$
785
% \item Create command RT CDF, shown in Figure~\ref{fig:CDF-RT-Create}, had $R^2$ Value of $0.07146$
786
% \item Read + Write command RT CDF, shown in Figure~\ref{fig:CDF-RT-RW}, has $R^2$ Value of $0.7837$.
787
%\end{itemize}
788
789
\begin{table}
790
\centering
791
\begin{tabular}{|l|c|c|c||c|c|c|}
792
\hline
793
Model & \multicolumn{3}{|c|}{Gaussian}
794
& \multicolumn{3}{|c|}{Weibull} \\ \hline
795
CDF & \multicolumn{3}{|c|}{$\frac{1}{\sqrt{2\pi}}\int_{-\infty}^{\frac{x-\mu}{\sigma}}e^{\frac{-t^2}{2}}dt$}
796
& \multicolumn{3}{|c|}{$1 - e^{(-x/\lambda)^k}$} \\ \hline \hline
797
I/O Operation & $\mu$ & \multicolumn{2}{|c|}{$\sigma$} & $k$ & \multicolumn{2}{|c|}{$\lambda$} \\ \hline
798
General IAT & 0.8508 & \multicolumn{2}{|c|}{0.2429} & 4.593 & \multicolumn{2}{|c|}{0.976} \\
799
General RT & 0.5945 & \multicolumn{2}{|c|}{0.2694} & 2.2993 & \multicolumn{2}{|c|}{0.6665} \\
800
Read RT & 0.8322 & \multicolumn{2}{|c|}{0.194} & 6.147 & \multicolumn{2}{|c|}{0.8963} \\
801
Write RT & 0.6918 & \multicolumn{2}{|c|}{0.2898} & 2.455 & \multicolumn{2}{|c|}{0.7675} \\
802
Create RT & 0.8539 & \multicolumn{2}{|c|}{0.1906} & 6.379 & \multicolumn{2}{|c|}{0.9103} \\
803
R+W RT & 0.8045 & \multicolumn{2}{|c|}{0.2122} & 5.103 & \multicolumn{2}{|c|}{0.3937} \\ \hline
804
R+W Byte Transfer & 0.3744 & \multicolumn{2}{|c|}{0.2983} & 1.153 & \multicolumn{2}{|c|}{0.3937} \\
805
Read Buff Transfer & 0.3737 & \multicolumn{2}{|c|}{0.2982} & 1.152 & \multicolumn{2}{|c|}{0.3928} \\
806
Write Buff Transfer & 0.5742 & \multicolumn{2}{|c|}{0.2428} & 1.806 & \multicolumn{2}{|c|}{0.6172} \\ \hline
807
\end{tabular}
808
\caption{\label{tbl:curveFitting}Comparison of %$R^2$
809
$\mu$, $\sigma$, $k$, and $\lambda$ Values for Curve Fitting Equations on CDF Graphs}
810
\vspace{-3em}
811
\end{table}
812
813
%The graphs created by the dissection script are:
814
%\begin{itemize}
815
% \item Average IAT (G/R/W/C) - By DateTime.
816
% \item Average Bytes (R/W) - By DateTime.
817
% \item Session I/Os (G/R/W/C) - By DateTime.
818
% \item Non-Session I/Os (G/R/W/C) - By DateTime.
819
% \item Tuple Counts - By DateTime.
820
% \item Total Bytes (R+W/R/W) - By DateTime.
821
% \item Total I/Os (G/R/W) - By DateTime.
822
%\end{itemize}
823
824
%Observations on graphs:
825
%\begin{itemize}
826
% \item Avergage IAT - majority write/general.
827
% \item Total I/O - majority are general I/O.
828
% \item Average Bytes - majority are writes.
829
% \item Bytes Total - majority reads.
830
% \item Tuple counts are close to same as session counts.
831
%\end{itemize}
832
833
%Examination of the Response Time (RT) and Inter Arrival Times (IAT) revealed the speed and frequency with which metadata operations are performed, as well as the infrequency of individual users and sessions to interact with a given share.
834
835
Our comparison of the existing standard use of a exponential distribution to model network interarrival and response times is still valid. One should notice that the Gaussian distributions
836
% had better $R^2$ result than the exponential equivalent for write operations. This is not surprising due to the step-function shape of the Figure~\ref{fig:CDF-RT-Write} CDF. Examining the $R^2$ results for the read + write I/O operations we find that the exponential distribution is far more accurate at modeling this combined behavior.
837
for read and create operations are similar, while those for write operations are not. Further more there is less similarity between the modeled behavior of general operation inter arrival times and their response times, showing the need for a more refined model for each aspects of the network filesystem interactions. One should also notice that the read + write operation model is more closely similar to that of the reads.
838
This makes sense since the influence of read operations are found to dominate the I/O behavior of the network filesystem, which improves the ability of a exponential distribution to model the combined behavior.
839
%Observations:
840
%\begin{itemize}
841
% \item Byte data appears in powers of 2 (e.g. 32K, 64K)
842
% \item IAT times most occur in the 0-10000 microsecond range, expect to general I/O which is in a much smaller range. The expectation is that this is because some commands and actions in SMB do not require the establishment of a session, thus allowing for a faster response.
843
% \item The timestamps provided by SMB are only accurate to the microseconds.
844
%\end{itemize}
845
%University information:
846
%\begin{itemize}
847
% \item Central backup server where each has a client.
848
% \item Client notifies 50 servers at once to do backup and as finished move onto the next.
849
% \item Only begin during midnight to 4am while servers must be ready to back-up and clients must respond to back-up.
850
% \item The 50 servers are randomized and incremental back-up takes ~1-2 hours
851
%\end{itemize}
852
%\textbf{Note:} Not sure that we would see this traffic since that would be between the servers and the back-up clients, (not the student clients?).
853
%The collected data shows the following observations about the observed network filesystem.
854
%\begin{itemize}
855
% \item The majority of network operations relate to metadata. This is due to a movement for user activity from reading and writing data to simply checking file and directory metadata.
856
% \item Writes cause the largest amount of data to be passed over the network. While Read operations occur at the largest number and cause the larger total number of bytes to be transferred, write operations are more expensive by an order of magnitude.
857
% \item \textcolor{red}{Here will be observation on the modeling of poisson fit.}
858
%\end{itemize}
859
Due to the large number of metadata operations, the use of smart storage solutions could be used to minimize the impact of these I/O. Smart storage elements can aid by performing metadata operations without the need to access persistent storage, thus causing shorter response times. In this manner, the use of smart storage can also help reduce bottlenecks with larger network filesystems and minimize the effect of traffic on overall network performance.
860
861
\subsection{System Limitations and Challenges}
862
\label{System Limitations and Challenges}
863
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,dabir2007bottleneck,skopko2012loss}. 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{seltzer2003nfs,anderson2004buttress}.
864
An other concern was whether or not the system would be able to function optimally during periods of high network traffic. All aspects 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.
865
866
%About Challenges of system
867
While the limitations of the system were concerns, there were other challenges that were tackled in the development of this research.
868
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 there are some issues when working with them. These issues ranged from data type limitations of the code to hash value and checksum miscalculations due to encryption of specific fields/data. Attempt was made to dig and correct these issues, but they were so inherent to the code being worked with that hacks and workarounds were developed to minimize their effect. Other challenges centralize around selection, interpretations 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.
869
870
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. 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.
871
% DataSeries Challenge
872
A complication of this process is that the DataSeries code makes use of a push-pop stack for iterating through packet information. This means that if information can not be re-read then errors occur. This can manifest in the scenario where a produced \texttt{.ds} file is corrupted or incomplete, despite the fact that the original \texttt{.pcap} being fine.
873
%This manifested as an approximate loss of \textbf{????} out of every 100,000 files.
874
Normally, one could simply re-perform the conversion process to a DataSeries file, but due to the rate of the packets being captured and security concerns of the data being captured, we are unable to re-run any captured information.
875
876
\section{Conclusions and Future Work}
877
Our analysis of this university network filesystem illustrated the current implementation and use of the CIFS/SMB protocol in a large academic setting. We notice the effect of caches on the ability of the filesystem to limit the number of accesses to persistant storage. The effect of enterprise storage disks access time can seen in the response time for read and write I/O. The majority of network communication is dominated by metadata operation, which is of less surprise since SMB is a known chatty protocol. We do notice that the CIFS/SMB protocol continues to be chatty with metadata I/O operations regardless of the version of SMB being implemented; $92.79$\% of I/O being metadata operations for SMB2.
878
We also find that while read operations happen in far greater number than write operations (at a ratio of 4.35), the size of the transfers are far less. In fact, the size of the average write operation is an order of magnitude greater than that of reads. Examination of the return times for these different I/O operations shows that exponential distribution curve fitting equation is most accurate at modeling the CDF of the various I/O operations. This shows that the current model is still effective for the majority of I/O, but that for write operations there needs to be further research in modeling the step behavior.
879
%Our work finds that a single term Gaussian distribution has an $R^2$ value of $0.7797$, but further work needs to be made in order to refine the model.
880
Our work finds that read and create response times can be modeled similarly, but that the write response times require the alteration of the general model.
881
However, a combination of read and write I/O can be modeled using the same standard; which has similar shape and scale to that of the read and create operations.
882
883
\subsection{Future Work}
884
The analysis work 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.
885
Network filesystem usage from an individual user scope has become simple and does not contain a greater deal of read, write, and create operations.
886
Further analysis will be made in examining how the determined metircs change when examined at the scope of a per share (i.e. TID) or per user (i.e. UID). At this level of examination we will be able to obtain a better idea of how each share is interacted with, as well as how files and directories are shared and access control is implemented.
887
888
%\end{document} % This is where a 'short' article might terminate
889
890
%ACKNOWLEDGMENTS are optional
891
%\section{Acknowledgments}
892
%This section is optional; it is a location for you
893
%to acknowledge grants, funding, editing assistance and
894
%what have you. In the present case, for example, the
895
%authors would like to thank Gerald Murray of ACM for
896
%his help in codifying this \textit{Author's Guide}
897
%and the \textbf{.cls} and \textbf{.tex} files that it describes.
898
899
%
900
% The following two commands are all you need in the
901
% initial runs of your .tex file to
902
% produce the bibliography for the citations in your paper.
903
\balance
904
\bibliographystyle{IEEEtran}
905
\bibliography{sigproc} % sigproc.bib is the name of the Bibliography in this case
906
% You must have a proper ".bib" file
907
% and remember to run:
908
% latex bibtex latex latex
909
% to resolve all references
910
%
911
% ACM needs 'a single self-contained file'!
912
%
913
%APPENDICES are optional
914
%\balancecolumns
915
%\appendix
916
%%Appendix A
917
%\section{Headings in Appendices}
918
%The rules about hierarchical headings discussed above for
919
%the body of the article are different in the appendices.
920
%In the \textbf{appendix} environment, the command
921
%\textbf{section} is used to
922
%indicate the start of each Appendix, with alphabetic order
923
%designation (i.e. the first is A, the second B, etc.) and
924
%a title (if you include one). So, if you need
925
%hierarchical structure
926
%\textit{within} an Appendix, start with \textbf{subsection} as the
927
%highest level. Here is an outline of the body of this
928
%document in Appendix-appropriate form:
929
%\subsection{Introduction}
930
%\subsection{The Body of the Paper}
931
%\subsubsection{Type Changes and Special Characters}
932
%\subsubsection{Math Equations}
933
%\paragraph{Inline (In-text) Equations}
934
%\paragraph{Display Equations}
935
%\subsubsection{Citations}
936
%\subsubsection{Tables}
937
%\subsubsection{Figures}
938
%\subsubsection{Theorem-like Constructs}
939
%\subsubsection*{A Caveat for the \TeX\ Expert}
940
%\subsection{Conclusions}
941
%\subsection{Acknowledgments}
942
%\subsection{Additional Authors}
943
%This section is inserted by \LaTeX; you do not insert it.
944
%You just add the names and information in the
945
%\texttt{{\char'134}additionalauthors} command at the start
946
%of the document.
947
%\subsection{References}
948
%Generated by bibtex from your ~.bib file. Run latex,
949
%then bibtex, then latex twice (to resolve references)
950
%to create the ~.bbl file. Insert that ~.bbl file into
951
%the .tex source file and comment out
952
%the command \texttt{{\char'134}thebibliography}.
953
%% This next section command marks the start of
954
%% Appendix B, and does not continue the present hierarchy
955
%\section{More Help for the Hardy}
956
%The sig-alternate.cls file itself is chock-full of succinct
957
%and helpful comments. If you consider yourself a moderately
958
%experienced to expert user of \LaTeX, you may find reading
959
%it useful but please remember not to change it.
960
%\balancecolumns % GM June 2007
961
% That's all folks!
962
\end{document}
You can’t perform that action at this time.