1. Top-Down Network Design Chapter Four Characterizing Network Traffic
Oppenheimer

2. Objectives 1
To expose to the students about techniques for characterizing traffic flow, traffic volume, and protocol behavior 2
To analyze network traffic patterns that help you in selecting appropriate logical and physical network design solutions
MMD©2013

3. Characterizing Network Traffic
In this step the flow of the traffic both existing and to be added or changed will be accounted for
This is done by identifying
Traffic flow
Location of traffic sources and data stores
Traffic load/volume
Traffic behavior
Quality of Service (QoS) requirements
Copyright Kenneth M. Chipps Ph.D.

4. Characterizing Traffic Flow
To determine the sources and destinations of traffic; first we need to 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 users who are widely geographically distributed
Create a chart of these groups
MMD©2013

5. User Community list Community Name Number of Users Location
Application
Enterprise Accounting 5
Building B
Floor 2
Rooms 3-5
MAS90
CEO Accounting 1
Building A
Corner Office
Quicken
Network
Managers 3
Building C
Deep Dark
Basement
OpenView
AlertPage
MMD©2013

6. Characterizing Traffic Flow
Next identify where the data stores of these user communities are located
This could be a
Server
Server Farm
Mainframe offsite
NAS
Create a chart of these sites along with the user communities
MMD©2013

7. Data Store list Data Store Name Location Application Used By
Accounting
Data
Building C
Even Deeper and Darker Basement
MAS90
Enterprise Accounting
CEO‘s Budget
Building A
Corner Office
Quicken
CEO
OpenView
Logs
Deep Dark
Basement
Network
Managers
AlertPage
MMD©2013

8. Characterizing Traffic Flow
For the data flow from the user communities to their data stores, measure or estimate the traffic flow over the links
Use a network analyzer or network management tool for this
This is not likely to be exact
It is being used to identify bottlenecks
MMD©2013

9. Traffic Flow list Application Traffic Type Protocols Used
User Community
Data Store
Bandwidth Needed
QoS
MMD©2013

10. Characterizing Traffic Flow
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
MMD©2013

11. Types of traffic
MMD©2013

12. Types of traffic
Different traffic types have different characteristics
Terminal/Host
Applications based on Terminal / Host are low - volume character traffic. The traffic from the terminal will be a few characters while the host returns screen full of characters.
Client/Server
The traffic flow in Client / server environment is bi-directional where clients send queries and requests to a server and the server responds with data or permission for the client to send data.
Traffic sent to the host is usually less than 100 bytes and the return traffic from the host can be more than 1500 bytes.
MMD©2013

13. Types of traffic Server-to-Server Distributed Computing
The flow depends on the relationship between the servers
It includes transmissions between servers and transmissions between servers and management applications
Distributed Computing
Several computers join together to solve a single problem
Normally the exchange is quite high (volume of traffic)
It is bi-directional
MMD©2013

14. Types of traffic Peer-to-peer Thin-client:
The flow is usually bi-directional. Communicating entities transmit approximately equal amounts of information.
Thin-client:
It is a computer or a computer program which depends heavily on some other computer (its server) to fulfill its traditional computational roles.
MMD©2013

15. Types of traffic list Application Type of Traffic Protocol User
Community
Data
Store
Bandwidth
QoS
Enterprise
Accounting
Client/Server
Browser/Server IP
Average
of 2 Mbps
from 8 to 5 weekdays
None
Note this is blank
Because the CEO’s
Quicken Data
Does not leave CEO’s office NA
OpenView
Terminal/Server
Average of 2 Kbps
24X7X365
Logs
AlertPage
Average of
65 Kbps
Every hour
MMD©2013

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 base-lining tool or protocol analyzer are not available, this is the best that can be done
MMD©2013

17. Traffic Flow Estimates List
Type of Application
Typical Data Size
Kbytes
Terminal Screen 4
Graphical Screen
500 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
MMD©2013

18. Business and Social Sciences Library and Computing Center
Administration
Business and Social Sciences
Math and Sciences
50 PCs
25 Macs
30 PCs
30 Library Patrons (PCs)
30 Macs and 60 PCs in Computing Center
Library and Computing Center
App Kbps
App Kbps
App Kbps
App Kbps
App Kbps
Total 808 Kbps
App Kbps
App Kbps
App Kbps
App Kbps
App Kbps
App Kbps
App Kbps
Total 1900 Kbps
App Kbps
App Kbps
App Kbps
App Kbps
Total 126 Kbps
App Kbps
Total 220 Kbps
Arts and Humanities
Server Farm
10-Mbps Metro Ethernet to Internet
Traffic Flow Example
MMD©2013

19. Characterizing Traffic Load
Purpose:
To avoid a design with any critical bottleneck.
To avoid bottleneck:
Research for application usage patterns, idle times between packets and sessions, frame sizes, and other traffic behavioral patterns for application and system approach.
Give large amounts of bandwidth at a problem.
LAN bandwidth is extremely cheap, Gigabit Ethernet also most organizations can afford.
MMD©2013

20. Characterizing Traffic Load: Steps
Calculating Theoretical Traffic Load
To calculate whether capacity is sufficient, you should know:
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
Documenting Application-Usage Patterns
Few data obtained during characterizing traffic flow  user communities, number of users in communities, and the applications that users employ.
Additional information required:
The frequency of application sessions (number of session 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
MMD©2013

21. Characterizing Traffic Load: Steps
Refining Estimates of Traffic Load Caused by Applications
Need to research the size of data objects sent by applications, the overhead caused by protocol layers, and any additional load caused by application initialization.
Table 4-5 shows some estimates for object sizes
Estimating Traffic Load Caused by Routing Protocols
At this point of designing process, you might not have selected routing protocols for new network but you should have identified routing protocols running on the existing network.
Use table 4-7 as guidance that shows the amount of legacy distance-vector routing protocols.
MMD©2013

22. Size of Objects on Networks
Table 4-5 : Approximate Size of Objects that applications transfer across networks
MMD©2013

23. Bandwidth used by Legacy Routing Protocols: Samples
Table 4-7: Bandwidth used by Legacy Routing Protocols
MMD©2013

24. Measuring Traffic Flow and Load
How do you actually determine what size data lines are required
This is often difficult and inexact
Formulas are available as discussed below, but often the best way is to send the normal files over a controlled circuit and time it
MMD©2013

25. Measuring Traffic Flow and Load
The file isn't going to cross the network in one big monolithic package
It will be divided into packets
Each packet will have a size, hopefully as big as bytes, but that depends on the protocol, configuration settings, application, operating system, and so on
MMD©2013

26. Measuring Traffic Flow and Load
Each 1500 byte packet will be encapsulated in the Frame Relay header and followed by the 2-byte Frame Check Sequence
Also, Frame Relay packets are encapsulated in a 1-byte Flag field at the beginning and end
You have to take those bytes into account for each packet
That 1500 bytes won't all be data from the file, however
MMD©2013

27. Measuring Traffic Flow and Load
Some of the bytes will be used by
A network-layer header
A transport-layer header
One, or more upper-layer headers
The packets will undoubtedly be acknowledged at one or more layers
Those ACKs use bytes and time
MMD©2013

28. Measuring Traffic Flow and Load
Will you be using a protocol that allows for a sliding window and can send many packets without waiting for an ACK until the send window slides closed
If so, how big is the send window by default
This usually depends on the recipient's receive window
Does the window tend to slide closed a lot
Or will you use a ping pong protocol that requires an ACK for each packet
MMD©2013

29. Measuring Traffic Flow and Load
Does the recipient tend to store the data in RAM and ACK quickly or does it write to disk, a slow mechanical process, and then ACK
This may depend on the state of the receive window, the amount of RAM available, and so forth
What sort of negotiation happens before the data can be sent
Any transport or session layer establishment, such as a TCP 3-way handshake
MMD©2013

30. Measuring Traffic Flow and Load
How about at the upper layers
Before file bytes are sent, are there negotiations and packets related to file size, file name, file access rights
Is a user name and password sent
Are these challenged with some sort of security feature, adding bytes and time to your calculation
MMD©2013

31. Measuring Traffic Flow and Load
Are you using any sort of encryption or compression
Is this a VPN or IPSec or other tunnel that adds even more bytes to each packet
What about the error rate
Do some packets get dropped due to an error and have to be retransmitted
That adds bytes and time
MMD©2013

32. Measuring Traffic Flow and Load
And how about queuing delay at the local routers and any Frame Relay switches inside the provider's network
And processing delay
How quickly does the recipient process the packets and send ACKs
What is the turnaround time at the sender
How quickly does it prepare and output the next set of packets after an ACK is received
MMD©2013

33. Measuring Traffic Flow and Load
So, in summary, a formula may be mathematically correct
But if it is not based on how data is sent on a network, then it will not produce accurate answers
So you need to get answers about which protocols and application are sending this data
MMD©2013

34. Characterizing Traffic Behavior
Broadcast/Multicast Behavior
Broadcasts
Broadcast frame = frame that goes to all network stations on a LAN
All 1s in binary data-link layer destination address
FF: FF: FF: FF: FF: FF
Doesn’t necessarily use huge amounts of bandwidth
But does disturb every CPU in the broadcast domain
Multicasts
Multicast frame = frame that goes to a subset of stations.
First bit sent is a one
01:00:0C:CC:CC:CC (Cisco Discovery Protocol)
Should just disturb NICs that have registered to receive it
Requires multicast routing protocol on internetworks
MMD©2013

35. Characterizing Traffic Behavior
Network Efficiency
Efficiency refers to whether applications and protocols use bandwidth effectively. Efficiency is affected by:
Frame size
Protocol interaction (refer to page 114 of text book for examples)
Windowing and flow control
Error-recovery mechanisms
MMD©2013

36. Characterizing QoS Requirements
Besides information about load, you also need to know if the requirements is flexible or inflexible.
Two techniques in analyzing QoS requirements: (you might need to read your text pg 119 –126)
ATM service specifications
Constant bit rate (CBR)
Realtime variable bit rate (rt-VBR)
Non-realtime variable bit rate (nrt-VBR)
Unspecified bit rate (UBR)
Available bit rate (ABR)
Guaranteed frame rate (GFR)
MMD©2013

37. QoS Requirements IETF integrated services working group specifications
Controlled load service
Provides client data flow with a QoS closely approximating the QoS that same flow would receive on an unloaded network
Guaranteed service
Provides firm (mathematically provable) bounds on end-to- end packet-queuing delays
MMD©2013

38. QoS Requirements
IETF differentiated services working group specifications
RFC 2475
IP packets can be marked with a differentiated services codepoint (DSCP) to influence queuing and packet-dropping decisions for IP datagrams on an output interface of a router
Grade of Service Requirements for Voice Applications
Documenting QoS Requirements
Work closely with your customer and fill in the QoS Requirements column of table 4-4.
MMD©2013

39. Summary Continue to use a systematic, top-down approach
Don’t select products until you understand network traffic in terms of:
Flow
Load
Behavior
QoS requirements – most technical part
MMD©2013

40. Review Questions
List and describe six different types of traffic flows.
What makes traffic flow in voice over IP networks challenging to characterize and plan for?
Why should you be concerned about broadcast traffic?
How do ATM and IETF specifications for QoS differ?
MMD©2013