1. A
study
of
Bit-­‐Torrent
Characteristics
Project
Report
Srikanth
Vanama
svanama@clemson.edu
Introduction
Network analysis is the process of capturing network traffic and inspecting it closely to
determine what is happening on the network. A network analyzer decodes the data
packets of common protocols and displays the network traffic in readable format. A
network analyzer can be a standalone hardware device with specialized software, or
software that is installed on a desktop or laptop computer. The differences between
network analyzers depend on features such as the number of supported protocols it can
decode, the user interface, and its graphing and statistical capabilities.
Packet analysis, often referred to as packet sniffing or protocol analysis, describes the
process of capturing and interpreting live data as it flows across a network in order to
better understand what is happening on that network. A packet sniffer, a tool used to
capture raw network data going across the wire, typically performs packet analysis.
Packet analysis can help us understand network characteristics, learn who is on a
network, determine who or what is utilizing available bandwidth and identify peak
network usage times.
For
the
project
we
captured
Packet
traces
of
few
Bit-­‐Torrent
files,
each
from
a
different
scenario
and
analyze
their
characteristics
by
plotting
different
graphs
and
studying
them.
Background.
BitTorrent
BitTorrent
is
a
p2p
protocol
for
content
replication
and
distribution
designed
to
quickly,
efficiently
and
fairly
replicate
data.
It
enables
an
efficient
and
faster
distribution
of
large
files
by
leveraging
the
upload
bandwidth
of
the
downloading
peers.
This
allowed
BitTorrent
to
use
bandwidth
between
peers
which
is
known
as
perpendicular
bandwidth.
The
basic
idea
is
that
files
are
split
up
into
chunks
and
the
downloaders
of
the
file
exchange
content
either
by
uploading
or
by
downloading
them.
It
works
on
the
tit-­‐for-­‐tat
(TFT)
basis
of
exchanging
file
contents.
The
chunks
of
file
are
downloaded
in
an
unordered
fashion
from
the
source,
which
enables
the
peers
to
maximize
the
use
of
peer
connection
to
other
downloaders
to
obtain
file
pieces,
which
they
do
not
possess.
This
protocol
makes
use
of
the
technique
named
“swarming”
i.e.,
which
explains
that
peers
are
allowed
to
download
pieces
of
a
file
from
several
peers
simultaneously.
This
results
in
a
great
advantage
of
efficient
network
utilization.
Based
on
the
per–resource
availability,
the
size
of
the
pieces
is
fixed.
Each
participating
peer
can
maximize
its
download
rate
by
exchanging

2. content
with
suitable
peers
and
peers
with
high
upload
rates
will
be
able
to
obtain
high
download
rates.
A
peer
interested
in
downloading
some
content
by
using
BitTorrent
must
first
obtain
a
set
of
metadata,
called
.torrent
file.
A
.torrent
file
is
an
encoded
file
that
contains
information
about
the
file
pieces
that
makes
up
the
original
file.
Users
who
wish
to
share
file(s)
in
the
BitTorrent
network
are
required
to
create
a.
torrent
file
and
then
upload
it
to
to
a
torrent
server
which
enables
other
peers
to
obtain
the
.torrent
file.
Generally,
a
moderator
system
is
used
to
the
check
the
file
integrity
and
remove
out
the
fake
contents
from
the
file.
[9]
Fig
2.
Torrent
Server
in
BitTorrent
networks.
[10]
To
find
a
torrent
file,
users
can
have
access
to
many
websites
found
in
the
Internet.
Some
of
the
example
websites
where
torrent
files
can
be
found
are
www.thepiratebay.org,
www.torrentz.com,
www.mininova.org;
a
torrent
file
can
be
downloaded
from
any
of
the
websites
a
user
is
interested
in.
The
basic
structure
of
a
torrent
file
can
be
represented
as
:

3.
Fig.
3.
The
structure
of
a
torrent
file
[10]
The
metadata
required
to
join
a
BitTorrent
network
consists
of
the
address
information
of
the
network,
announce
URL
of
the
tracker
and
information
of
the
file
size
and
piece
size.
It
also
incorporates
hash
values
[SHA-­‐1],
used
to
test
the
correctness
of
reception
of
a
file
piece.
A
peer,
who
downloads
a
.torrent
file,
will
be
able
to
join
a
pool
of
peers
who
are
involved
in
the
distribution
of
specific
content.
A
BitTorrent
distribution
swarm
can
be
partitioned
into
three
network
entities
and
two
protocols
[9].
• Tracker
• Set
of
active
peers
–
seeders
and
lechers
• Server
These
3
entities
are
discussed
separately
later
in
the
following
sections.
Terminology
used
in
BitTorrent
networks:
Seed
(seeder):
A
peer
who
owns
a
complete
copy
of
the
file
and
offers
it
for
seeding
(uploading).
Leech
(Leecher):
A
peer
who
has
a
partial
copy
of
the
file
and
communicates
with
other
peers
to
download
the
file
chunks.
Swarm:
the
pool
of
all
peers
downloading
a
file
or
resource.
Choke:
a
preventive
mechanism,
which
makes
a
client
to
stop
downloading
a
file
from
other
peers.
Share
ratio
(availability):
ratio
of
number
of
peers
with
complete
copies
of
the
file
to
the
total
no.
of
peers
in
the
swarm.
It
is
defined
as
a
percentage
ratio.
In
the
BitTorrent
network,
initially,
a
peer
who
wants
to
download
a
file
gets
connected
to
the
tracker
of
the
file,
which
keeps
track
of
all
the
downloaders
and
seeds
of
the
corresponding
file
in
the
system
maintained
in
a
global
registry.
The
tracker,
accepts
the
requests
and
then
replies
back
to
the
peer
with
a
random
list
of
peers
(both
seeders
and
leechers)
that
have
the
file.
The
information
the
tracker
replies
back
consists
of
other
peer
addresses
and
ports
as
well
as
records
simple
statistics
about
the
evolution
of
the
swarm.[9]
the
downloader
then
attempts
to
establish
a
connection
to
these
other
peers,
which
then
becomes
its
neighbors.
It
then
finds
out
what
pieces
each
of
its
neighbors
possess.
Each
peer
attempts
to
download
blocks
from
and
upload
blocks
to
its
corresponding
neighbors
to
which
it

4. is
connected.
A
node
at
this
point
of
time
has
various
choices
of
several
blocks
that
it
could
choose
to
download
from.
To
employ
this,
it
uses
a
local
rarest
first
policy
(LRF)
in
selecting
which
block
to
download.
It
then
tries
to
download
a
block
which
is
least
replicated
among
its
neighbors.
The
objective
is
to
maximize
the
diversity
of
content
in
the
system,
which
thus
prevents
the
system
from
hanging
up
due
to
the
“rare”
blocks
that
are
difficult
to
find.
This
ensures
a
uniform
distribution
of
pieces
among
peers
and
protocols.
An
exception
to
the
local
rarest
first
policy
occurs
when
a
new
node
enters
the
system
that
has
not
downloaded
any
blocks
yet.
It
chooses
a
random
block
and
starts
downloading
the
file.
From
that
point
on,
it
then
switches
and
adopts
the
local
rarest
policy.
[5]
A
tit-­‐for-­‐tat
(TFT)
policy
is
implemented
to
prevent
free
-­‐
riding,
which
is
defined
as;
a
node
uploads
only
to
its
neighbors,
which
offer
it
the
highest
download
rates.
Thus
each
node
should
upload
at
a
good
rate
to
its
corresponding
neighbors.
To
avoid
all
these
complexities,
each
node
is
limited
to
upload
only
to
5
no.
of
peers
that
have
the
highest
download
rates
even
thought
it
may
have
received
requests
from
more
than
5
peers
(downloaders).
.
Even
in
the
case
of
seeds,
the
similar
policy
is
adopted.
Choking,
is
a
mechanism
to
limit
the
number
of
parallel
uploads,
which
is
defined
as
the
temporary
refusal
of
a
node
to
upload
to
a
neighbor.
A
node
for
every
10
sec,
tries
to
find
out
whether
a
currently
unchoked
neighbor
should
be
choked
or
not
and
replace
with
a
neighboring
peer
which
offers
the
highest
download
rate.
To
implement
this
in
a
correct
manner,
i.e.
BitTorrent
uses
a
new
mechanism
called
the
optimistic
unchoking,
which
is
attempted
every
30
sec,
allows
a
peer
to
upload
to
the
peers
which
offers
the
highest
download
rates
and
drop
out
the
peer
with
the
least
download
rate.
Connections
between
peers
single
TCP
sessions,
carrying
both
data
and
signaling
traffic
[9]
.
Once
a
connection
is
established
between
peers,
the
peer,
which
initiates
the
connection,
sends
a
handshake
message,
which
contains
the
peer,
id
and
info
field
hash.
Figure
4.
BitTorrent
Handshake
procedure

5.
If
the
initiated
peer
gets
a
reply
back
with
the
information
requested
earlier,
the
BitTorrent
session
is
considered
to
be
open
and
the
peers
start
exchanging
messages
across
the
TCP
streams.
[9].
Otherwise,
the
TCP
connection
gets
closed.
Next,
each
peer
exchanges
about
the
information
about
the
resources
it
possesses.
This
is
implemented
only
once,
i.e.,
after
the
handshake
message.
The
information
is
sent
in
a
bit
field
message,
consisting
of
a
stream
of
bits,
with
each
bit
corresponding
to
a
piece
index
[9].
Wireshark
Introduction:
Wireshark
is
a
free
packet
sniffer
computer
application.
It
is
used
for
network
troubleshooting,
analysis,
software
and
communications
protocol
development,
and
education.
Wireshark
provides
insight
into
what
is
occurring
on
a
network,
which
is
useful
When
implementing
protocols,
debugging
network
applications,
testing
networks,
and
debugging
live
networks.
In
situations
involving
interaction
with
a
network
at
a
technical
level,
most
problems
can
be
resolved
using
Wireshark.
The
functionality
Wireshark
provides
is
very
similar
to
tcpdump,
but
it
has
a
graphical
front-­‐end,
and
many
more
information
sorting
and
filtering
options.
It
allows
the
user
to
see
all
traffic
being
passed
over
the
network
by
putting
the
network
interface
into
promiscuous
mode.
Wireshark
is
a
cross-­‐platform
application
running
on
various
computer
operating
systems
including
Mac
OS
X,
Linux
and
Microsoft
Windows.
Characteristics
of
Wireshark:
Wireshark
is
software
that
"understands"
the
structure
of
different
networking
protocols.
Thus,
it
is
able
to
display
the
encapsulation
and
the
fields
along
with
their
meanings
of
different
packets
specified
by
different
networking
protocols.
Wireshark
uses
pcap
to
capture
packets,
so
it
can
only
capture
the
packets
on
the
networks
supported
by
pcap.
• Data
can
be
captured
"from
the
wire"
from
a
live
network
connection
or
read
from
a
file
that
records
the
already-­‐captured
packets.

6. • Live
data
can
be
read
from
a
number
of
types
of
network,
including
Ethernet,
IEEE
802.11,
PPP,
and
loopback.
• Captured
network
data
can
be
browsed
via
a
GUI,
or
via
the
terminal
(command
line)
version
of
the
utility,
tshark.
• Captured
files
can
be
programmatically
edited
or
converted
via
command-­‐line
switches
to
the
"editcap"
program.
• Display
filters
can
also
be
used
to
selectively
highlight
and
color
packet
summary
information.
• Data
display
can
be
refined
using
a
display
filter.
• Hundreds
of
protocols
can
be
understood
and
can
be
analyzed.
Capturing
Live
Network
data
In
order
to
get
packet
data
into
Wireshark,
we
perform
the
packet
capture,
either
a
live
capture
or
we
open
a
existing
trace
file.
The
procedure
is
as
follows:
Open
WireShark.
1.
From
the
main
drop-­‐down
menu,
select
“Capture”
menu
and
then
Interfaces.
You
should
see
a
dialog
listing
the
various
interfaces
that
can
be
used
to
Capture
packets,
along
with
their
IP
addresses.
Choose
the
interface
you
Wish
to
use,
and
click
Capture
(figure
1)

7.
fig.
1
capture
interface
window
2.
Your
packet
capture
should
begin
and
Wireshark
should
show
the
active
packet
capture
window.
This
window
displays
a
brief
summary
of
the
type
of
traffic
being
captured,
as
well
as
the
duration
of
the
current
capture
3.
when
you
are
ready
to
stop
the
capture
and
view
your
data,
click
Stop.
Once
you
have
completed
these
steps
and
finished
the
capture
process,
the
WireShark
main
window
will
display
all
the
captured
data.
The
main
components
of
the
Wireshark
Graphical
User
Interface
(GUI)
are
:
• Main
window
Wireshark's
main
window
consists
of
parts
that
are
commonly
known
from
many
other
GUI
programs
such
as
menu,
main
toolbar,
filter
toolbar,
packet
list
pane,
packet
details
pane.
• Menu
bar
Menu
bar
consists
the
following
drop-­‐down
menus
:
File,
Edit,
View,
Go,
Capture,
Analyze,
Statistics
,
Tools
and
Help.

8.
• Tool
bar
Contains
buttons
for
some
commonly
used
functions
of
Wireshark.
The
Tool
Bar
icons
have
tool
tips
that
are
displayed
when
you
place
the
mouse
pointer
over
them.
• Summary
window
Provides
a
one-­‐line
summary
for
each
packet
in
the
capture.
One
or
more
columns
of
summary
data
are
displayed
for
each
packet.
The
columns
can
be
No.,
Time,
Sourcr,
Destination,
Protocol,
Info.
• Filter
Bar
Applies
filters
to
the
Summary
window
to
restrict
which
packets
in
the
capture
are
displayed,
based
on
their
attributes.
The
example
filters
can
be
Tcp,
Udp,
Bittorret
etc.
• Protocol
Tree
window
Provides
a
detailed
decode
of
the
packet
selected
in
the
Summary
window.

9.
• Data
View
window
Provides
a
view
of
the
raw
data
in
the
packet
selected
in
the
Summary
window.
This
window
contains
a
series
of
rows
that
each
begin
with
a
four-­‐digit
number
that
represents
the
number
of
bytes
in
an
octet.
• Information
field
The
Information
field
displays
the
name
of
the
capture
file,
or
information
about
the
protocol
field
selected
in
the
Protocol
Tree
window.
• Display
information
The
Display
Information
field
displays
the
number
of
packets
displayed
in
or
filtered
from
the
Summary
window
.
P
indicates
the
number
of
total
packets,
D
indicates
the
total
displayed
packets
and
M
indicates
the
total
marked
packets.
Motivations
and
Objectives:
With
the
ever-­‐increasing
popularity
of
Bit-­‐Torrent,
We
wanted
to
analyze
what
was
it
behind
the
most
popular
p2p
protocol,
which
made
it
tick.
While
writing
the
research
paper,
we
learnt
a
great
deal
about
how
the
torrent
file
system
actually
works.
We
study
different
characteristics,
based
on
the
kind
of
BitTorrent
trace
chosen.
The
differences
come
to
light
during
the
analysis
phase
of
the
project.
Therefore,
for
this
project
we
took
thr
ee
traces.
Two
of
them
from
the
home
network
and
one
of
them
in
the
Clemson
University
Wireless
Network.
Also,
all
the
three
torrent
files
are
completely
different
in
terms
of
their
popularity,
size
,etc.
We
would
talk
about
this
in
depth
during
the
analysis
phase.
Methodology
To
start
with,
we
have
used
a
popular
BitTorrent
client
“Vuze”
to
download
the
torrent
files.
We
chose
Vuze
because
of
its
multimedia
download
client.
We
have
downloaded
3
different
torrents
in
total.
Out
of
which,
2
of
them
were
downloaded
on
the
home
network
and
the
other
being
on
the
college
network.
We
tried
to
focus

10. on
these
3
different
torrent
files,
which
were
downloaded
at
varying
speeds,
and
study
the
characteristics
of
each
of
the
files
Out
of
the
2
torrents
downloaded
on
the
home
network,
one
was
a
sponsored
file
from
vuze,
with
very
high-­‐speed
download
rate.
The
other
one
is
a
torrent
file
named
“linux
distribution”
downloaded
from
a
popular
website
which
hosts
torrent
files.
This
torrent
file
was
downloaded
at
considerable
high
speed.
The
3rd
torrent
file,
which
was
downloaded
from
the
college
network,
was
downloaded
at
very
low-­‐speed
at
very
slow
download
rate.
To
capture
the
network
traffic
on
our
systems,
we
have
used
a
popular
network
sniffer-­‐tool
named
WireShark
to
trace
out
all
the
tcpdump
files
and
to
analyze
the
characteristics
of
different
torrent
files
by
generating
various
graphs.
Analysis:
We
have
taken
the
tcpdump
of
three
different
kinds
of
torrent
files.
One
of
them
was
an
Internet
based
electronics
show,
from
a
torrent
client
called
Vuze.
We
chose
this
because
of
the
peculiar
characteristics
of
their
sponsored
downloads.
This
torrent
client
has
a
list
of
sponsored
shows
available
for
download,
and
when
you
select
any
of
them
for
download
they
download
at
a
rapid
rate,
taking
over
most
of
the
network
bandwidth.
The
second
trace
we
took
was
that
of
a
popular
Linux
distribution.
The
third
trace
we
took
was
a
dictionary
torrent
file,
hosted
on
a
popular
website.
To
start
with,
We
processed
the
tcpdump
files
and
analyzed
the
characteristics
of
each
torrent
file
and
also
generated
various
graphs
which
explicitly
depict
the
characteristics
of
each
of
the
torrent
traces.
We
then
compared
each
of
these
graphs
for
each
of
the
different
torrent
file
traces.
The
various
download
speeds
of
each
of
the
torrent
files
are:
Fig.1
the
download
speed
of
vuze
sponsored
torrent
file
Fig.2
the
download
speed
of
linux
distribution
torrent
file

11.
Fig.3
the
download
speed
of
dictionary
torrent
file
From,
• fig.1,
the
avg.
download
speed
was
recorded
as
340
kbps
• Fig.2,
the
avg
download
speed
was
recorded
as
300
kbps
• Fig,
3,
the
avg.
download
speed
was
recorded
as
30
kbps
Flow
Graph:
The
Flow
Graph
provides
a
sequential
analysis
of
TCP
connections.
Here,
we
created
a
displayed
filter
to
target
only
traffic
related
to
download
of
a
file
thru
BitTorrent.
In
the
flow
graphs,
The
rows
represent
the
time
at
which
a
BitTorrent
handshake
was
occurred
or
When
a
handshake
continuation
data
takes
place
through
a
particular
port.
The
columns
represent
various
ip
addresses
of
different
seeders
who
had
participated
in
the
download
process
of
a
torrent
file
and
the
following
fig.(s)
show
the
sample
from
the
Flow
graph
for
3
different
trace
files,
(since
the
flow
graphs
came
upto
22
pages
we
have
included
a
part
of
it
here).
The
flow
graph
for
3
diff.
trace
files
are
shown
below

12.
fig.4
Flowgraph
for
the
vuze
sponsored
torrent
file

13.
fig.5
flowgraph
for
the
linux
distribution
torrent
file

14.
fig.6
flow
graph
for
the
dictionary
torrent
file
RTT
graphs:
The
Packet
Round-­‐Trip
Time
graph
shows
the
history
of
a
transaction's
round-­‐trip
time
(RTT).
RTT
is
the
average
number
of
milliseconds
spent
in
transit
when
a
client
and
server
exchange
the
SYN
(synchronize
sequence
numbers
flag)
and
its
corresponding
ACK
(acknowledge
flag).
A
transaction
involving
a
large
amount
of
data
requires
the
data
to
be
divided
into
multiple
packets.
Whereas
a
transaction's
network
delay
reflects
the
total
transit
time
for
all
required
packets,
the
RTT
reflects
the
time
for
a
single
packet
to
make
its
way
from
client
to
server
and
another
packet
to
make
the
return
trip.
An
ideal
RTT
for
data
transfer
across
the
Internet
is
no
more
that
0.04
seconds
(40
milliseconds).
If
we
consider
a
slow
download,
we
will
notice
near
the
beginning
of
the
capture,
an
RTT
of
up
to
one
full
second.
This
is
completely
unacceptable
for
downloading
a
file.
Even
when
downloading
a
file
off
of
the
Internet
you
should
see
times
at
no
more
than
0.1
seconds.
The
RTT
graphs
for
3
different
trace
files
are
shown
below:

15. Fig.
7
RTT
graph
for
the
vuze
sponsored
torrent
file
Fig.
8
RTT
graph
for
the
linux
distribution
file

16.
Fig.9
RTT
graph
for
the
dictionary
torrent
file.
From
all
the
above
RTT
graphs,
we
can
clearly
see
the
differences
in
the
values
of
round
trip
time
of
all
the
packets.
Now,
Comparing
all
the
3
graphs,
from
the
1st
graph,
the
average
RTT
was
calculated
from
fig.7
was
around
0.1s
(almost
0),
which
suggests
that
the
torrent
file
was
downloaded
at
high-­‐speed
download
rate.
Similarly,
from
the
2nd
graph,
the
average
RTT
was
calculated
from
fig.8
was
almost
<
0.1
s,
which
suggests
that
this
torrent
file
was
downloaded
at
very
high
speed
download
rate.
Now,
from
the
3rd
graph,
the
average
RTT
was
calculated
from
fig.9
was
around
0.3
s,
which
suggests
that
the
file
was
downloaded
at
very
slow
download
rate.
Time-­‐Sequence
Graphs
(Stevens)
The
time-­‐sequence
graph
(Stevens)
produces
a
simple
graph
of
TCP
sequence
numbers
vs
time
at
which
it
was
sent
for
the
TCP
stream
containing
the
packet
that
was
selected
in
the
Summary
window.

17. The
first
derivative
of
this
graph
is
the
TCP
traffic
throughput.
In
an
ideal
situation
where
there
is
a
constant
throughput,
the
graph
would
be
a
straight
rising
line
with
its
slope
equaling
the
throughput.
One
can
learn
about
where
the
source
of
throughput
issues
is
coming
from
by
looking
at
the
time-­‐sequence
graph.
fig.10
Time-­‐
Sequence
Graph
for
vuze
sponsored
torrent
file

18.
fig
11.
Time-­‐sequence
graph
for
the
linux
distribution
torrent
file

19.
fig.12
time-­‐sequence
graph
for
the
dictionary
torrent
file
To
understand
each
of
the
characteristics
from
the
above
graphs,
from
the
1st
graph,
fig.10,
we
can
clearly
see
that,
At
the
start
of
the
capture,
the
traffic
has
an
even
slope
(constant
throughput)
for
approximately
900
seconds,
when
there
is
a
major
disruption,
as
shown
by
the
discontinuity
in
the
graph.
This
gap
suggests
TCP
retransmissions
have
occurred
for
the
packet
for
which
we
have
chosen
to
plot
the
graph.
Similarly,
from
the
2nd
graph,
fig.11,
the
traffic
has
an
exponential
rise
for
approximately
1300
seconds
from
the
start
of
the
capture,
when
there
is
a
major
discontinuity
in
the
graph.
These
gaps
suggest
retransmissions
have
occurred
for
the
packet
for
which
we
have
chosen
to
plot
the
graph.
From
the
3rd
graph,
fig.12,
the
graph
clearly
shows
an
exponential
rise
throughout
the
graph
with
an
increasing
throughput
i.e.
with
an
even
slope.
So
thus,
we
can
conclude
from
this
graph
that
there
is
no
retransmissions
occurred
for
the
capture
of
the
dictionary
torrent
file.

20. Throughput
Graphs
The
throughput
graphs
shows
the
throughput
of
the
TCP
stream
Vs
time.
fig
13.
Throughput
graph
for
the
vuze
sponsored
torrent
file
fig.14
throughput
graph
for
the
linux
distribution
file

21.
fig.15
Throughput
graph
for
the
dictionary
torrent
file
From
all
the
above
3
graphs,
the
throughputs
of
each
trace
file
can
be
calculated.
Throughput
is
the
average
rate
of
successful
message
delivery
over
a
communication
channel.
The
throughput
is
usually
measured
in
bits
per
second.
From
the
1st
graph,
fig
13,
the
average
throughput
can
be
calculated
as
30000
B/s,
which
is
pretty
high
for
a
successful
communication.
As
this
torrent
file
was
downloaded
at
faster
download
rate,
the
average
throughput
will
be
always
high.
Similarly,
from
the
2nd
graph,
fig14
the
average
throughput
can
be
calculated
as
1000
B/s,
which
suggests
that
the
torrent
file
has
been
downloaded
at
high
speed
download
rate,
and
has
successful
message
transfers
over
the
communication
channel.
From
the
3rd
graph,
fig
15,
the
average
throughput
can
be
calculated
as
only
around
30B/s,
which
is
very
low.
As
the
file
was
downloaded
at
very
slow
download
rate,
the
throughput
was
also
considered
to
be
less.
I/O Graphs:
I/O graphs are user configurable graphs of the captured network packets. We can select

22. various filters. It is customizable with a lot of various options and is used to visual
interpret the data we have captured. We can customize several features of this graph. For
instance, we could create filters to show ARP and DHCP traffic and display the lines on
the graph in red and blue so that we can more easily differentiate the throughput trends
between these two protocol types.
The most important two things we will be modifying are the settings for the x-axis and y-
axis of the graph, which allow you to modify the intervals and units used for displaying
the required information.
I/O graphs are also used to find out the response times problems of the packets in the
trace file by looking at the spikes generated from the I/O graph files.
The general way to find out the response time problems is to find the delta time between
the packets. This is represented in the time column in the main window. We can scroll
through all the packets and find the no with higher value in the time column to indicate
the higher response times.
There’s an alternative approach to this:
Try plotting I/O Graphs, and out of the graph generated from that spikes are shown as
packets by default. The x-axis interval is around 1 sec and on the y-axis with units set to
packets/tick and scale set to auto.
Now, change y-axis to advanced tab, which opens up a new column. We can add new
features into our graph window by adding syntax commands in the new column, which
was generated by changing unit to “advanced”.
To calculate the delta time from the previous captured packets, the syntax would be
“frame.time_delta_displayed”.
This is entered in the filter field present in the main window. Add the same syntax to
“sum” column present in the I/O graph and press “ Graph 2” button to generate advanced
I/O graph to calculate the delta times from the previous captured packets. Spikes are now
indicated with a red graph, which shows where the problems with the response times
occur. Here, we can observe that x-axis is changed from 0 to 1000 and above (varies from
file to file).
We can see some spikes from the newly generated I/O graph then, which suggests the
higher response time delay problems. By clicking on a spike with higher value, which
will take us to main window with the packet with the greater delay time by automatically
scrolling down through the trace file to the place where the problem occurs. We can then
find out the packet with the response time problem and the delta time of that packet.
We can continue in a similar fashion to find out the larger delta times by clicking on the
higher spikes generated in the graph.

23. To find out the larger delays in response times for each of the 3 different trace files, we
proceed with,
fig.16 I/O graph for a Vuze sponsored torrent file
From the above graph, the spikes can be located at various instances on the graph. Here,
the 1st spike is found at 1382s, at which the packet no. 547022 has resulted in a higher
response time delay of 1382.55544 s, which was found out by clicking on the spike
present in the graph.

24. fig 17. I/O graph for Linux distribution trace file
From the above graph, the spikes can be located at various instances on the graph. Here,
the 1st spike is found at 464s, at which the packet no.160329 has resulted in a higher
response time delay of 464.388496 s, which was found out by clicking on the spike
present in the graph.
Fig 18 I/O Graph for dictionary torrent file

25. From the above graph, the spikes can be located at various instances on the graph.
Here, the 1st spike is found at 4961s, at which the packet no.257352 has resulted in a
higher response time delay of 4961.487553 s, which was found out by clicking on the
spike present in the graph. When compared with two other trace files, the dictionary
based torrent trace file was found out to have more spikes in the I/O Graph generated by
using the syntax filter
“frame.time_delta_display”.
This suggests that many packets in the trace file had higher response time delays, which
clearly suggests that this torrent trace file was downloaded with slow download speed
rate, with less no. of seeders who were to present and increase the speed of downloading
a torrent file.
Expert Info
In order to filter out the abnormal traffic that is slowing our download, we’ll use the
Expert Info window. To open this window, click Analyze in the menu bar and select
Expert Info. Now choose the setting Error+Warn+Note from the drop-down box next to
the words Severity filter. Next, we begin to explore the problematic packets in our
capture.
In Expert info window, we may encounter with TCP Previous segment lost packets.
These packets tell us that during the course of data transfer, a packet was suddenly
dropped. In response, the client sends Duplicate ACK packets to the server, requesting
that that the lost packet is sent again. The client continues to send Duplicate ACKs until it
receives the requested packet. We then see the retransmission of the dropped packet as
TCP Retransmission in the Expert Infos window.
At the beginning of our download, we see only one or two Duplicate ACKs in a row, but
as the download progresses, when we encounter more and more Duplicate ACKs we can
conclude that there is more latency. If there are more Segment losses and Duplicate
ACKs it shows the sign of a slow download in progress.

26. 2nd trace file

27. 3rd trace file

28. from the above graphs, we can clearly see that there are less no of previous segment
losses and duplicate acks in 1st two trace files. Coming to the 3rd graph, we can clearly
see that there are more no of previous segment losts and more no of duplicate acks which
clearly shows the sign of a slow download is in progress.

29. Conclusion
and
Future
Work:
As
it
can
be
observed
from
the
readings,
for
a
slower
download
the
RTT
is
higher.
This
can
be
observed
from
the
third
trace
file.
Also
as
we
consider
Throughput
graph,
we
can
see
that
the
throughput
is
lower
for
the
third
trace
as
compared
to
the
other
two,
thus
reiterating
what
was
observed
during
the
download.
Also,
From
the
expert
window
panel,
we
can
observe
more
segment
losses
and
duplicate
ACKs
which
shows
the
sign
of
a
slow
download
in
progress.
In
this
project,
we
had
looked
more
into
understanding
the
basic
working
of
the
BitTorrent
protocol
more
than
anything
else.
We
looked
at
how
it
worked
based
on
different
conditions
like
number
of
seeders,
location
of
download
(i.e.,
the
network),
popularity
of
the
file
and
other
real
world
conditions.
For
doing
this
we
found
WireShark
as
an
appropriate
tool
to
perform
the
tasks
we
needed.
We
detected
that
the
third
trace,
which
was
taken
on
a
Clemson
wireless
network
was
slower
as
compared
to
the
other
two
downloads.
This
might
be
because
of
a
variety
of
conditions
like
the
file
not
being
very
popular.
Lesser
number
of
seeders
etc.
Comparing
the
first
two
downloads
,the
major
difference
lies
in
the
fact
that
the
first
download
was
a
sponsored
download
from
Vuze.
Therefore,
Vuze
was
functioning
more
like
a
content
delivery
system,
more
than
anything
else.
This
was
similar
in
a
way
to
the
new
kind
of
content
delivery
system
being
developed
by
BitTorrent
called
BitTorrent
DNA
,
the
difference
lying
with
the
fact
that
thought
,
the
download
speed
for
Vuze
was
high
it
hogged
most
of
the
bandwidth,
and
this
is
where
DNA
might
bring
in
a
change.
Looking
into
the
future
we
feel
that
the
BitTorrent
protocol
,
which
is
relatively
new
might
undergo
a
metamorphosis
into
something
which,
delivering
content
to
users
,
doesn’t
hog
most
of
the
bandwidth.
REFERENCES
[1]
Wireshark
&
Ethereal
Network
Protocol
Analyzer
Toolkit
-­‐
Angela
Orebaugh,
Gilbert
Ramirez,
Jay
Beale
[2]
Practical
Packet
Analysis:
Using
Wireshark
to
Solve
Real-­‐World
Network
Problems
-­‐
Chris
Sanders

30. [3]“BitTorrent”-­‐
http://www.medianet.kent.edu/surveys/IAD06S-­‐
P2PArchitectures-­‐chibuike/P2P%20App.%20Survey%20Paper.htm#_2.2_Bittorrent
[4]
"Wireshark
User's
Guide"
-­‐
http://www.wireshark.org/download/docs/user-­‐
guide-­‐a4.pdf