Rab Nawaz Jadoon

cloutedcoughNetworking and Communications

Oct 28, 2013 (4 years and 16 days ago)

76 views

Department of Computer Science
DCS
COMSATS Institute of
Information Technology
Characterizing Network Traffic
Rab Nawaz Jadoon
Assistant Professor
COMSATS
IIT
,
Abbottabad
Pakistan
Telecommunication Network Design (TND)
Department of Computer Science
Characterizing Types of Traffic Flow
for
New
Network Applications
2
Department of Computer Science
Characterizing Traffic Flow

A good technique for characterizing network
traffic flow is to classify applications as
supporting one of a few well
-
known flow types.

Terminal/Host Traffic Flow

Asymmetric

For example Telnet (terminal sends few character, while
host sends back many character
i.e
user name and
password authentication
.

Client/Server Traffic Flow

Bidirectional flow

Asymmetric

For example, FTP, HTTP protocols etc.

Request from the clients are small frames while responses
ranges from 64 bytes to 15 bytes.
3
Department of Computer Science
Traffic Flow

Thin Client traffic Flow/Server based computing

A special case of client/server architecture

Bulk of data processing on server side.

Peer to Peer Traffic Flow

Bidirectional and symmetric

Each device is considered as important as each other
device, and no device stores substantially more data than
any other device.

Recently, peer
-
to
-
peer applications for downloading music,
videos, and software have gained popularity.

Each user publishes music or other material and allows other users on
the Internet to download the data.

This is because of every user acts as both a distributor and consumer
of data.

Traffic flow is bidirectional and symmetric.

E.g. video conferencing
4
Department of Computer Science
Traffic Flow

Server/Server Traffic Flow

Servers talk to other servers to,

implement directory services,

cache heavily used data,

mirror data for load balancing and redundancy,

back up data,

broadcast service availability
.

With server/server network traffic, the flow is generally
bidirectional.

The symmetry of the flow depends on the application.

With most server/server applications, the flow is
symmetrical, but in some cases there is a hierarchy of
servers, with some servers sending and storing more data
than others.
5
Department of Computer Science
Traffic Flow

Distributed Computing Traffic Flow

With distributed computing, data travels between a
task manager and computing nodes and between
computing nodes.

Characterizing traffic flow for distributed computing
applications might require you to,

Study the traffic with a protocol analyzer or model potential
traffic with a network simulator.
6
Department of Computer Science
Traffic Flow in VOIP Networks

Traffic flow in VoIP networks is that there are
two flows.

The flow associated with transmitting the audio
voice.

The flow associated with call setup and teardown.

The flow for transmitting the digital voice is peer
-
to
-
peer,
between two phones or between two PCs running software
such as Skype or Cisco IP Communicator (CIPC).

Call setup and teardown, on the other hand, can be
characterized as a client/server flow because a phone needs
to talk to a more complicated machine like server or
switching machine
.
7
Department of Computer Science
Traffic Flow

The audio voice flow between two IP endpoints

RTP,

RTP

Connectionless, run on top of UDP
.

The main call setup, teardown, and control protocols
in an IP network are,

H.323, the Cisco Skinny Client Control Protocol (SCCP),
Simple Gateway Control Protocol (SGCP), Media Gateway
Control Protocol (MGCP), and Session Initiation Protocol
(SIP).
8
Department of Computer Science
Documenting Traffic Flow for New and Existing
Network Applications
9
Department of Computer Science
Documenting Traffic Flow

To document traffic flow for new (and existing)
network applications, characterize the flow type for
each application and list the user communities and
data stores that are associated with applications.
10
Department of Computer Science
11
Department of Computer Science
Traffic Load

Characterizing traffic load can help you design
networks with sufficient capacity for local usage
and internetwork flows.

traffic load estimates are unlikely to be precise.

The goal is simply to avoid a design that has any
critical bottlenecks.
12
Department of Computer Science
Traffic load

Traffic load(sometimes called offered load) is
the sum of all the data all network nodes have
ready to send at a particular time.

A general goal for most network designs is that
the network capacity should be more than
enough
to handle the traffic load.

The challenge is to determine if the capacity
proposed for a new network design is sufficient
to handle the potential load.
13
Department of Computer Science
Calculating Theoretical Traffic Load

For example, for a network with a proposed
capacity

1 Mbps,

If 1000 stations send 1000
-
bit frames every second,
the offered load equals the capacity.

This is according to the theory of the William Stalling
14
Department of Computer Science
Calculating Theoretical Traffic Load

In general, to calculate whether capacity is
sufficient, only a few parameters are necessary
:

The number of stations.

The average time that a station is idle between
sending frames.

The time required to transmit a message once
medium access is gained.
15
Department of Computer Science
Calculating Theoretical Traffic Load

For a client/server application, idle time for the
server depends on,

The number of clients using the server,

and the architecture and performance characteristics
of the server (disk access speed, RAM access speed,
caching mechanisms, and so on).

Idle time on the client side depends partly on user
action, which means it is impossible to precisely
predict idle time.
16
Department of Computer Science
Calculating Theoretical Traffic Load

After you have identified the approximate traffic
load for an application flow,

you can estimate total load for an application by
multiplying the load for the flow by the number of
devices that use the application.
17
Department of Computer Science
Traffic Load

In general, to accurately characterize traffic
load,

you need to understand

Application usage patterns and

QoS
requirements in addition to idle times and frame sizes.
18
Department of Computer Science
Documenting Application
-
Usage
patterns

The first step in documenting application
-
usage
patterns is to identify user communities, the
number of users in the communities, and the
applications the users employ.

(this is already covered before)
19
Department of Computer Science
Documenting Application
-
Usage
patterns

In addition to identifying the total number of
users for each application, you should also
document the following information:

The frequency of application sessions (number of
sessions per day, week, month, or whatever time
period is appropriate)

The length of an average application session

The number of simultaneous users of an application
20
Department of Computer Science
Documenting Application
-
Usage
patterns

you can more accurately predict the aggregate
bandwidth requirement for all users of an
application.

If it is not practical to research these details, you can
make some assumptions:

The number of users of an application equals the number of
simultaneous (real time) users.

All applications are used all the time, so that your
bandwidth calculation is a
worstcase
(peak) estimate.

Each user opens just one session, and that session lasts all
day until the user shuts down the application at the end of
the day.
21
Department of Computer Science
Estimates of Traffic Load Caused by
Applications

To completely characterize application behavior,
you should investigate which protocols an
application uses.

When you know the protocols, you can calculate
traffic load more precisely by adding the size of
protocol headers to the size of data objects.

Table (next slide) shows some typical protocol
header sizes.
22
Department of Computer Science
Traffic Overhead for Various
Protocols
23
Department of Computer Science
Estimates of Traffic Load Caused by
Applications

In addition to applications that are set to start
upon
bootup
, the following system
-
level
protocols send packets as a workstation
initializes:

Address Resolution Protocol (ARP)

Dynamic Host Configuration Protocol (DHCP)

Internet Control Message Protocol (ICMP),
rsion
4
and 6

Internet Group Management Protocol (IGMP),
version 4 and 6

Domain Name System (DNS)
24
Department of Computer Science
Cont…

Multicast DNS (
mDNS
)

NetBIOS name queries

Network Time Protocol (NTP)

Simple Service Discovery Protocol (SSDP)

Service Location Protocol (SLP)

Simple Network Management Protocol (SNMP)
25
Department of Computer Science
Estimating Traffic Load Caused by
Routing Protocols

Estimating traffic load caused by legacy routing
protocols is important in a topology that
includes many networks on one side of a slow
WAN link.

A router sending a large distance
-
vector routing table
every 30sec can use a significant percentage of WAN
bandwidth.
26
Department of Computer Science
Estimating Traffic Load Caused by
Routing Protocols

Because routing protocols limit the number of
routes per packet, on large networks, a router
sends multiple packets to send the entire table.

Routing Information Protocol (RIP), for example,
sends a routing packet every 30 seconds.

Each route in the packet uses 20 bytes, and there
are 25 routes per packet.

When headers are added, this means that a router
running RIP sends one or more 532
-
byte packets
every 30 seconds, depending on the size of the
routing table.
27
Department of Computer Science
Estimating Traffic Load Caused by
Routing Protocols

Newer routing protocols, such as

Open Shortest Path First (OSPF) and

Enhanced Interior Gateway Routing Protocol
(EIGRP), use little bandwidth.

EIGRP also sends Hello packets but more
frequently than OSPF (every 5 seconds).

On the other hand, EIGRP doesn’t send any periodic
route updates or database
-
synchronization packets.

It sends route updates only when there are changes.
28
Department of Computer Science
29