Top-Down Network Design

Chapter Four
Characterizing Network Traffic

Copyright 2010 Cisco Press & Priscilla Oppenheimer

Characterizing Network Traffic
◼ Characterizing traffic flow involves identifying
sources and destinations of network traffic.
◼ Analyzing the direction and symmetry(equilibrium/
balancity) of data traveling between sources and
destinations.
◼ In some applications, the flow is bidirectional and symmetric.
(Both ends of the flow send traffic at about the same rate.)
◼ In other applications, the flow is bidirectional and
asymmetric. (Clients send small queries and servers send large
streams of data.)
◼ In a broadcast application, the flow is unidirectional and
asymmetric.
Step 1 in Collecting Network Traffic
To determine the sources and destinations of traffic first, identify the user
communities
◦ A user community is a collection of staff that do basically the same thing, such as the
accounting program users
◦ This may be a limited group, isolated to a single area or building or it may be the email users
who are widely geographically distributed
◦ Create a chart of these groups

3
User Community List

Community Number Location Application

Name of Users

Enterprise 5 Building B MAS90

Accounting Floor 2
Rooms 3-5
CEO Accounting 1 Building A Quicken
Corner Office

Network 3 Building C OpenView

Managers Deep Dark
Basement
Network 3 Building C AlertPage
Managers Deep Dark
Basement

4
Step 2 in Collecting Network Traffic
Next identify where the data these user communities use is located
This could be a
◦ Server
◦ Server Farm
◦ Mainframe offsite
◦ NAS
◦ SAN

Create a chart of these sites along with the user communities

5
Data Stores List
Data Store Location Application Used By
Name

Accounting Building C MAS90 Enterprise

Data Even Deeper Accounting
and Darker
Basement
CEO‘s Budget Building A Quicken CEO
Corner Office

OpenView Building C OpenView Network

Logs Deep Dark Managers
Basement
AlertPage Building C AlertPage Network
Logs Deep Dark Managers
Basement

6
 Step 3 in Collecting Network Traffic
o For the data flow from the user communities to their data stores, measure or
estimate the traffic flow over the links
o Use protocol analyzer or network management tool for this
o Measure the number of MB or Kbps/Mbps of flow over the links
o This is not likely to be exact
o It is being used to identify bottlenecks

7
Traffic Flow List
Application Traffic Type Protocols User Data Store Bandwidth QoS
Used Community Needed

8
Step 4 in Collecting Network Traffic
The type of traffic is important
This will influence the type of link required
At this stage the QoS is important as well since it will affect the type of link
◦ Only some link types can support QoS

Again a chart is used to collect this information

9
Types of Traffic
◼ 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.

10
◼ 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

11
◼ 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.

12
◼ 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.

13
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.

14
◼ The audio voice flow between two IP endpoints
RTP,
◼ RTP is 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).

15
Type of Traffic List
Application Type of Protocol User Data Bandwidth QoS
Traffic Community Store
Enterprise Client/Server IP Enterprise Accounting Average None
Accounting Browser/Server Accounting Data of 2 Mbps
from 8 to 5
weekdays
Note this is blank Because the CEO’s Quicken Data Does not leave CEO’s NA NA NA
office

OpenView Terminal/Server IP Average of 2 Kbps OpenView Average of 2 None

24X7X365 Logs Kbps
24X7X365

AlertPage Terminal/Server IP Average of AlertPage Average of None

65 Kbps Logs 65 Kbps
Every hour Every hour
24X7X365 24X7X365

16
Types of Traffic
A quick estimate of traffic flow can be made by using the following table
This table shows the average flows for the different types of data
In many cases, especially when tools such as a baselining tool or protocol analyzer are not
available, this is the best that can be done

17
Traffic Flow Estimates List
Type of Application Typical Data Size Type of Application Typical Data
Kbytes Size
Kbytes
Terminal Screen 4 Graphical Screen 500

Email 10 Presentation Document 2,000

Web Page 50 High Resolution Image 50,000

Spreadsheet 100 Multimedia Object 100,000

Word Processing Document 200 Database 1,000,000

18
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.
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.
Calculating Theoretical Traffic Load
◼ For example, for a network with a proposed
capacity of 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
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.
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.
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.
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.
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.
◼ 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
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 worst case (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.
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.
Traffic Overhead for Various
Protocols
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)
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)
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.
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.
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.