Top Down Network Design Chapter 4 Notes.
Characterizing Network Traffic
Characterizing Traffic Flow
• Characterizing traffic flow is the process of identifying sources and
destinations of network traffic and analyzing the direction and symmetry of
data traveling between sources and destinations.
• Flow can be bidirectional and symmetric. (Both ends of the flow send
traffic at about the same rate.)
• In other applications, the flow can be bidirectional and asymmetric.
• Client stations send small queries and servers send large streams of data.
• In a broadcast application, the flow is unidirectional and asymmetric.
Identifying Major Traffic Sources and Stores
• First identify user communities and data stores for existing and new
• A user community is a set of workers who use a particular application or
set of applications.
• A user community can be a corporate department or set of departments.
• As more corporations use matrix management and form virtual teams to
complete ad-hoc projects, it becomes more necessary to characterize
user communities by application and protocol usage rather than by
Documenting Traffic Flow on the Existing Network
• Documenting traffic flow involves identifying and characterizing individual
traffic flows between traffic sources and stores.
• RFC 2722 describes an architecture for the measurement and reporting of
network traffic flows, and discusses how the architecture relates to an
overall traffic flow architecture for intranets and the Internet.
• Measuring traffic flow behavior can help a network designer determine
which routers should be peers in routing protocols that use a peering
system, such as the Border Gateway Protocol (BGP).
• Measuring traffic flow behavior can also help network designers do the
o Characterize the behavior of existing networks
o Plan for network development and expansion
o Quantify network performance
o Verify the quality of network service
o Ascribe network usage to users and applications
• An individual network traffic flow can be defined as protocol and
application information transmitted between communicating entities during
a single session.
• A flow has attributes such as: o direction,
o routing path and routing options,
o number of packets, number of bytes, and
o addresses for each end of the flow.
• The simplest method for characterizing the size of a flow is to measure the
number of Kbytes or Mbytes per second between communicating entities.
• To characterize the size of a flow, use a protocol analyzer or network
management system to record load between important sources and
Characterizing Types of Traffic Flow for New Network Applications
• Characterize by direction and symmetry.
• Direction specifies whether data travels in both directions or in just one
• Direction also specifies the path that a flow takes as it travels from source
to destination through an internetwork.
• Symmetry describes whether the flow tends to have higher performance
or QoS requirements in one direction than the other direction.
• Characterize network traffic flow by classifying applications as supporting
one of a few well-known flow types:
o Terminal/host traffic flow
o Client/server traffic flow
o Peer-to-peer traffic flow
o Server/server traffic flow
o Distributed computing traffic flow
Terminal/Host Traffic Flow
• Terminal/host traffic is usually asymmetric.
• The terminal sends a few characters and the host sends many characters.
• Telnet is an example of an application that generates terminal/host traffic.
• With some full-screen terminal applications, such as some IBM 3270-
based terminal applications, the terminal side sends characters typed by
the user and the host side returns data to repaint the screen.
• More modern terminal applications just send changes to the user's screen,
thus reducing network traffic.
• Terminal/host traffic flows are less prevalent on networks than they once
were, but they have not disappeared
• Thin clients, which have become quite popular, can behave like
terminal/host applications. Client/Server Traffic Flow
• Client/server traffic is the best known and most widely used flow type.
• Clients send queries and requests to a server. The server responds with
data or permission for the client to send data.
• The flow is usually bidirectional and asymmetric.
• Requests from the client are typically small frames, except when writing
data to the server, in which case they are larger.
• Responses from the server range from 64 bytes to 1500 bytes or more,
depending on the maximum frame size allowed for the data link layer in
• Hypertext Transfer Protocol (HTTP) is probably the most widely used
• The flow for HTTP traffic is not always between the web browser and the
web server because of caching.
• A cache engine is software or hardware that makes recently accessed
web pages available locally, which can speed the delivery of the pages
and reduce WAN bandwidth utilization.
• A cache engine can also be used to control the type of content that users
are allowed to view.
Thin Client Traffic Flow
• A special case of the client/server architecture is a thin client, which is
software or hardware that is designed to be particularly simple and to work
in an environment where the bulk of data processing occurs on a server.
• With thin client technology, (also known as server-based computing), user
applications originate on a central server
• A downside of thin client technology is that the amount of data flowing
from the server to the client can be substantial, especially when many
computers start up at the same time every day.
• Networks with thin clients should be carefully designed with sufficient
capacity and an appropriate topology. Switched networking (rather than
shared media) is recommended, and to avoid problems caused by too
much broadcast traffic.
Peer-to-Peer Traffic Flow
• flow is usually bidirectional and symmetric.
• Communicating entities transmit approximately equal amounts of
• There is no hierarchy.
• Each device is considered as important as each other device, and no
device stores substantially more data than any other device.
• There are many flows in both directions.
• Recently peer-to-peer applications for downloading music, videos, and
software have gained popularity. • Most enterprises and many university networks disallow this type of peer-
to-peer traffic for two reasons. First, it can cause an inordinate amount of
traffic, and, second, the published material is often copyrighted by
someone other than the person publishing it.
Server/Server Traffic Flow
• Server/server traffic includes transmissions between servers and
transmissions between servers and management applications.
• Servers talk to other servers to implement directory services, to cache
heavily used data, to mirror data for load balancing and redundancy, to
back up data, and to broadcast service availability
• 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.
Distributed Computing Traffic Flow
• Distributed computing refers to applications that require multiple
computing nodes working together to complete a job.
• Some complex modeling and rendering tasks cannot be accomplished in a
reasonable timeframe unless multiple computers process data and run
• The visual effects for movies are often developed in a distributed-
• data travels between a task manager and computing nodes and between
• McCabe distinguishes between tightly coupled and loosely coupled
computing nodes. Nodes that are tightly coupled transfer information to
each other frequently. Nodes that are loosely coupled transfer little or no
Traffic Flow in Voice over IP Networks
• The most important concept to understand when considering traffic flow in
VoIP networks is that there are multiple flows.
• The flow associated with transmitting the audio voice is separate from the
flows associated with call setup and teardown.
• The flow for transmitting the digital voice is essentially peer-to-peer,
between two phones or PCs running software, such as Microsoft's
NetMeeting or Cisco's SoftPhone.
• Call setup and teardown, on the other hand, could be characterized as a
client/server flow because a phone needs to talk to a more complicated
device, such as a server or traditional phone switch, that understands
phone numbers, addresses, capabilities negotiation, and so on. • These protocols generally fit the client/server paradigm, but they also use
distributed and peer-to-peer processing, and have some terminal/host
Documenting 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.
• You can use Table 4-4 to enhance the Network Applications charts already
discussed in Chapters 1 and 2.
• When identifying the type of traffic flow for an application, select one of the
o Distributed computing
Characterizing Traffic Load
• To select appropriate topologies and technologies to meet a customer's
goals, it is important to characterize traffic load with traffic flow.
• Characterizing traffic load can help you design networks with sufficient
capacity for local usage and internetwork flows.
• The goal is simply to avoid a design that has any critical bottlenecks.
• To avoid bottlenecks, you can research application usage patterns, idle
times between packets and sessions, frame sizes, and other traffic
behavioral patterns for application and system protocols.
• Another approach to avoiding bottlenecks is simply to throw large amounts
of bandwidth at the problem. A strict interpretation of systems analysis
principles wouldn't approve of such an approach, but bandwidth is cheap
these days. LAN bandwidth is extremely cheap.
Calculating Theoretical Traffic Load
• traffic load (sometimes called offered load) is the sum of all the data
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 adequate 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.
• In general, to calculate whether capacity is sufficient, only a few
parameters are necessary:
o The number of stations
o The average time that a station is idle between sending frames
o The time required to transmit a message once medium access is
gained • By studying idle times and frame sizes with a protocol analyzer, and
estimating the number of stations, you can determine if the proposed
capacity is sufficient.
• 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.
• The research you do on the size of user communities and the number of
data stores (servers) can help you calculate an approximate aggregated
bandwidth requirement for each application and fill in the "Approximate
Bandwidth Requirement for the Application" column in Table 4-4.
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:
o The frequency of application sessions (number of sessions per day,
week, month or whatever time period is appropriate)
o The length of an average application session
o The number of simultaneous users of an application
• If it is not practical to research these details, you can make some
o assume that the number of users of an application equals the
number of simultaneous users.
o assume that all applications are used all the time so that your
bandwidth calculation is a worst-case (peak) estimate.
o assume that each user opens just one session and that a session
lasts all day until the user shuts down the application at the end of
Refining Estimates of Traffic Load Caused by Applications
• you 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.
• (Some applications send much more traffic during initialization than during
Estimating Traffic Overhead for Various Protocols
• To completely characterize application behavior, you should investigate
which protocols an application uses.
• you can calculate traffic load more precisely by adding the size of protocol
headers to the size of data objects Estimating Traffic Load Caused by Workstation and Session Initialization
• workstation initialization can cause a load on networks due to the number
of packets and, in some cases, the number of broadcast packets.
• this is becoming less of a problem as network bandwidth has become so
inexpensive, and extremely fast CPUs in workstations are readily available
so that broadcast processing isn't a concern
• The tables in Appendix A show typical workstation behavior for the
o Novell NetWare
o TCP/IP with DHCP
o NetBIOS (NetBEUI)
o NetBIOS with a Windows Internet Naming Service (WINS) server
Boot-Time Traffic for Older Protocols
• Many universities, schools, governments, and nonprofit organizations still
use older protocols.
• Also, some companies that have theoretically standardized on TCP/IP are
often surprised when a network engineer studies their network traffic.
• A lot of equipment that is supposedly running only TCP/IP tends to still
send out traffic for other protocols.
• Printers are notorious for still sending Novell NetWare traffic in many
Estimating Traffic Load Caused by Routing Protocols
• To characterize network traffic caused by routing protocols, Table 4-7
shows the amount of bandwidth used by legacy distance-vector routing
• Estimating traffic load caused by legacy routing protocols is especially
important in a topology that includes many networks on one side of a slow
• A router sending a large distance-vector routing table every minute can
use a significant percentage of WAN bandwidth
• Newer routing protocols, such as OSPF and EIGRP, use very little
bandwidth. In the case of OSPF, your main concern should be the amount
of bandwidth consumed by the database synchronization packets that
routers send every 30 minutes.
• By subdividing an OSPF network into areas and using route
summarization, this traffic can be minimized
• 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 only sends route updates
when there are changes.
Characterizing Traffic Behavior
• To select appropriate network design solutions, you need to understand
protocol and application behavior in addition to traffic flows and load.
• For example, to select appropriate LAN topologies, you need to
investigate the level of broadcast traffic on the LANs.
• To provision adequate capacity for LANs and WANs, you need to check
for extra bandwidth utilization caused by protocol inefficiencies and
nonoptimal frame sizes or retransmission timers.
• A broadcast frame is a frame that goes to all network stations on a LAN.
• A multicast frame is a frame that goes to a subset of stations
• Layer 2 internetworking devices, such as switches and bridges, forward