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 connection-oriented 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 traffic-related 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.