Transcript CIS 460 – Network Analysis and Design

CIS 460 – Network Analysis and
Design
Chapter 4 –
Characterizing Network Traffic
Characterizing Traffic Flow
• Identifying sources and destinations of
network traffic
• analyzing the direction and symmetry of
data traveling between sources/destinations
• Some bi-directional and symmetric (Both
ends of the flow send traffic at about the
same rate) or bi-directional and asymmetric
(clients send small queries and servers send
large streams of data)
Identifying Major Traffic Sources
and Stores
• Identify user communities and data stores for
existing and new applications
• User community is a set of workers who use a
particular application or set of applications
• Use Table 4-1 chart (pg 86) to document user
communities
• Use Table 4-2 (pg 87) to document major data
stores
• Data store is where application-layer data resides
Documenting Traffic Flow on the
Existing Network
• Identify and characterize individual traffic
flows between sources and stores
• Measuring traffic flow behavior can help
determine which routers should be peers in
routing protocols that use a peering system
–
–
–
–
–
Characterize the behavior of existing networks
Plan for network development and expansion
Quantify network performance
verify the quality of network service
ascribe network usage to users and applications
Documenting Traffic Flow on the
Existing Network (Cont’d)
• Individual network traffic flow can be
defined as protocol and application
information transmitted between
communicating entities during a single
session
• Simplest method to characterize flow is to
measure the number of Mbytes per second
between communicating entities.
Characterizing Types of Traffic Flow
for New Network Applications
• Flow types
–
–
–
–
–
terminal/host
client/server
per-to-peer
server/server
distributed computing
Terminal/Host Traffic Flow
• Usually asymmetric
• Terminal sends few characters/host sends
many
• Full-screen terminal applications terminal
sends character typed and host sends data to
repaint screen
• Data from host to terminal equals size of
screen plus commands and attribute bytes
(color and highlight of characters)
Client/Server Traffic Flow
• Best known and most widely used flow type
• Client requests usually less than 64 bytes
except when writing to server
• Responses range from 64 bytes to 1500
bytes or more
• Hypertext Transfer Protocol (HTT) is
probably most widely used today
• Downside of network computing is large
amounts of data from server to client
Peer-to-Peer Traffic Flow
• Usually bi-directional and symmetric.
• Entities usually transfer equal amounts of
protocol and application information
• Small networks
Server-to-Server Traffic Flow
• Transmissions between servers and
transmissions between servers and
management applications
• Flow is generally bi-directional, symmetry
depends on the application
Distributed Computing Traffic
Flow
• Applications that require multiple
computing nodes working together
• Data travels between a task manager and
computing nodes and between computing
nodes
• Task manager tells the computing nodes
what to do on an infrequent basis
• Might require protocol analyzer or model
with a network simulator
Documenting Traffic Flow for
Network Applications
• Document the flow type for each
application and list user communities and
data stores that are associated with
applications
• Use a table similar to Table 4-4 on pg. 94 to
document.
• Add a comment to quantify the type of flow
Characterizing Traffic Load
• Not likely to be precise because many
factors impact it
• To avoid bottlenecks research application
usage patters, idle times between packets
and sessions, frame sizes, and other traffic
behavior patterns for application and system
protocols
Calculating Theoretical Traffic
Load
• Traffic load is the sum of all the data that is
ready to transmit at a particular time
• Traffic load parameters
– Number of stations
– Average time that a station is idle between
frames
– Time required to transmit a message once
access is gained
Calculating Theoretical Traffic
Load (Cont’d)
• Study idle times and frame sizes with a protocol
analyzer and estimate the number of stations to
determine if proposed capacity is enough
• For client/server idle time for the server
depends on the number of clients
• In addition to investigating idle times between
packets, frames, sizes, and flow behavior, also
investigate application usage patterns and Q
oS requirements.
Calculating Theoretical Traffic
Load (Cont’d)
• To accurately characterize traffic load you
need to understand application usage patters
and QoS requirements in addition to idle
times and frame sizes
Documenting Application Usage
Patterns
• Identify user communities
• number of users in the communities
• Applications the users employ
–
–
–
–
frequency of application sessions
length of average application session
number of simultaneous users of an application
Can more accurately predict the aggregate
bandwidth required
Refining Estimates of Traffic
Load Caused by Applications
• Research size of data objects sent by
applications
• overhead caused by protocol layers
• any addition load caused by application
initialization
• Because applications and users vary widely
in behavior it is hard to accurately estimate
average size of data objects
Estimating Traffic Overhead for
Various Protocols
• Once you now the protocols used you can
calculate traffic load more precisely by
adding the size of protocol headers to the
size of data objects.
• Table 4-6 (pg 99) shows some typical
protocol header sizes
Estimating Traffic Load Caused by
Workstation and Session Initialization
• Workstation initialization can cause a
significant load on a network depending on
the applications and protocols used
• Appendix A tables show typical workstation
behavior for 7 protocols
Estimating Traffic Load Caused
by Routing Protocols
• It is especially important to estimate traffic
load caused by routing protocols when
topology includes many networks on one
side of a slow WAN link
• Table 4-7 (pg 101) shows bandwidth used
by routing protocols
• Usually multiple packets are required to
send routing tables
Characterizing Traffic Behavior
• Need to understand protocol and application
behavior in addition to traffic flows and
load to select an appropriate network design
• Need to check for extra bandwidth
utilization caused by protocol inefficiencies
and non-optimal frame sizes or
retransmission timers
Broadcast/Multicast Behavior
• A broadcast frame goes to all network stations on
a LAN
• A multicast frame goes to a subset of stations
• Layer-2 internetworking devices send broadcast
and multicast frames out all ports. All devices on
one side of a router are considered part of a single
broadcast domain.
• Can limit size of broadcast domains by using
virtual LANs
Broadcast/Multicast Behavior
(Cont’d)
• Too many broadcast frames can overwhelm
end stations, switches and routers.
• CPUs on network stations can become
overwhelmed by processing high levels of
broadcasts and multicasts
• Broadcast traffic is necessary and
unavoidable.
• Take into consideration the broadcast
behavior of desktop protocols
Network Efficiency
• Efficiency refers to whether applications
and protocols used bandwidth effectively.
• It is effected by frame size, the interaction
of protocols used by applications and
windowing and flow control and error recovery mechanisms.
Frame Size
• Use a frame size that is the maximum
supported for the medium in used has a
positive impact on network performance.
• File transfer applications should use the
largest possible maximum transmission unit
(MTU)
• Some protocols cannot support very large
frame sizes. AppleTalk is limited to 599
bytes of user data.
Frame Size (Cont’d)
• In IP environment avoid increasing the MTU
to larger than the maximum supported for the
media traversed by the frames
• Check to see if data-link layer parameters
affect frame size.
• In Token-ring bridges can be configured with
a maximum frame-size parameter that
specifies the largest frame that the bridge can
forward
Protocol Interaction
• Inefficiency can be caused by the
interaction of protocols and the
misconfiguration of acknowledgement
timers and other parameters.
Windowing and Flow Control
• The send window and receive window play a part
in TCP packet transmission.
• The receive window size is set in every TCP
packet the amount of data it is prepared to receive
• Data is forwarded until the send window is empty
• The receive window is based on size of memory
and how quickly data can be processed
• Optimize efficiency by increasing memory and
CPU power on end stations
Error-Recovery Mechanisms
• Poorly designed error recovery mechanisms
can waste bandwidth.
• Connectionless protocols usually do not
implement error recovery
• Error-recovery mechanisms for connectionoriented protocols vary. Using a protocol
analyzer you can determine if your
customers protocols implement effective
error recovery
Characterizing Quality of Service
Requirements
• Just knowing the load requirement for an
application is not sufficient
• Need to know if the requirement is flexible
or inflexible
• Some continue to work (although slowly) if
bandwidth is insufficient
• Voice and video may be useless with
sufficient bandwidth
ATM Quality of Service
Specifications
• Five QoS categories
–
–
–
–
–
Constant bit rate (CBR)
Real-time variable bit rate (rt_VBR)
Non-real-time variable bit rate (nrt-VBR)
Unspecified bit rate (UBR)
Available bit rate (ABR)
Constant Bit Rate Service
Category
• When used a source end-system reserves
network resources in advance and asks for a
guarantee that the negotiated QoS be
assured to all cells as long as the cells
conform to the relevant conformance tests
• Intended to support real-time applications
Realtime Variable Bit Rate
Service Category
• rtVBR connections are characterized in
terms of a PCR, Sustainable Cell Rate
(SCR), and Maximum Burst Size (MBS)
Non-realtime Variable Bit Rate
Service Category
• Nrt-VBR service category is intended for
non-real-time applications that have bursty
traffic characteristics. No delay bounds are
associated with this service category
Unspecified Bit Rate Service
Category
• UBR service does not specify any trafficrelated service guarantees.
• Where not enforced, the value of PCR is
informational only.
• This category is intended for non-real-time
applications including traditional computer
communications applications such as file
transfer and e-mail.
Available Bit Rate Service
Category
• With ABR the transfer characteristics provided
by the network can change subsequent to
connection establishment.
• A flow control mechanism offers several types
of feedback to control the source rate in
response to changing ATM-layer conditions
• Feedback is conveyed through control cells
called resource management cells or RM-cells.
Integrated Services Working Group
Quality of Service Specifications
• In an IP environment you can use the Resource
Reservation Protocol (RSVP). It provides
– Packet classifier that determines the QoS class for
each packet
– An admission control function that determines
whether the node has sufficient available resources
– A pocket scheduler that determines when particular
packets are forwarded to meet QoS requirements
Controlled-Load Service
• Provides a client data flow with a QoS
closely approximating the QoS that same
flow would receive on an unloaded
network.
• Intended for applications that are highly
sensitive to overload conditions
• Does not accept or make use of specific
target values for parameters such as delay or
loss.
Guaranteed Service
• RFC 2212 describes the network node
behavior required to deliver a service called
guaranteed service that guarantees both
bandwidth and delay characteristics.
• Guarantees that packets will arrive within
the guaranteed delivery time and will not be
discarded due to queue overflows
Guaranteed Service (Cont’d)
• Intended for applications that need a guarantee
that a packet will arrive no later than a certain
time after it was transmitted by its source.
• A flow is described using a token bucket. A
token bucket has a bucket rate and a bucket
size. The rate specifies the continually
sustainable data rate and the size specifies the
extent by which the data rate can exceed the
sustainable rate
Documenting QoS Requirements
• Classify each network application in a
service category.
• Complete the QoS Requirements column in
Table 4-4.
• Find out if any service-level agreements
will be made with regards to applications.
Summary
• This chapter provided techniques for
analyzing network traffic caused by
applications and protocols and discussed
methods for identifying traffic sources and
data stores, measuring traffic flows and
load, documenting applications and protocol
usage, and evaluating Quality of service
(QoS) requirements.