Top-Down Network Design Chapter Four Characterizing Network Traffic Oppenheimer

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

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 2000-2011 Kenneth M. Chipps Ph.D. www.chipps.com

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 email users who are widely geographically distributed Create a chart of these groups MMD©2013

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

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

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

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

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

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

Types of traffic MMD©2013

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

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

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

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

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

Traffic Flow Estimates List Type of Application Typical Data 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 MMD©2013

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 1 108 Kbps App 2 60 Kbps App 3 192 Kbps App 4 48 Kbps App 7 400 Kbps Total 808 Kbps App 1 48 Kbps App 2 32 Kbps App 3 96 Kbps App 4 24 Kbps App 5 300 Kbps App 6 200 Kbps App 8 1200 Kbps Total 1900 Kbps App 1 30 Kbps App 2 20 Kbps App 3 60 Kbps App 4 16 Kbps Total 126 Kbps App 9 80 Kbps Total 220 Kbps Arts and Humanities Server Farm 10-Mbps Metro Ethernet to Internet Traffic Flow Example MMD©2013

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

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

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

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

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

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

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 1500 bytes, but that depends on the protocol, configuration settings, application, operating system, and so on MMD©2013

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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