T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer

To expose to the students about techniques for characterizing traffic flow, traffic volume, and protocol behavior O BJECTIVES To analyze network traffic patterns that help you in selecting appropriate logical and physical network design solutions

C HARACTERIZING N ETWORK T RAFFIC  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 3

C HARACTERIZING T RAFFIC F LOW  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- characterize user communities by application and protocol rather than by department boundary.  Create a chart of these groups 4

Community Name Number of Users LocationApplication Enterprise Accounting 5Building B Floor 2 Rooms 3-5 MAS90 CEO Accounting 1Building A Corner Office Quicken Network Managers 3Building C Deep Dark Basement OpenView Network Managers 3Building C Deep Dark Basement AlertPage U SER C OMMUNITY LIST 5

C HARACTERIZING T RAFFIC F LOW  Next identify where the data stores of these user communities are located  Data store(data sink) – is an area in a network where application layer data resides.  This could be a Server Server Farm Mainframe offsite NAS  Create a chart of these sites along with the user communities 6

Data Store Name LocationApplicationUsed By Accounting Data Building C Even Deeper and Darker Basement MAS90Enterprise Accounting CEO‘s BudgetBuilding A Corner Office QuickenCEO OpenView Logs Building C Deep Dark Basement OpenViewNetwork Managers AlertPage Logs Building C Deep Dark Basement AlertPageNetwork Managers D ATA S TORE LIST 7

C HARACTERIZING T RAFFIC F LOW  Documenting traffic flow (TF) on the existing network  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 8

CONTINUE  Measuring TF behavior can help a network designer to do the following:  Characterize the behavior of the existing network  Plan for network development and expansion  Quantify network performance  Verify the quality of network services  Ascribe network usage to users and applications 9

CONTINUE  An individual network TF can be defined as protocol and application information transmitted between communicating entities during a single session.  a flow has attributes such as :  Direction symmetry  Routing path and routing options  No of packets  No of bytes  Address for each end of the flow  ** a communicating entity can be an end system (host), a network or an autonomous system 10

CONTINUE  Simple method for characterizing the size of flow = measure the number of Kbytes/Mbytes per second between communicating entities.  Use protocol analyzer or network management system to record load between important sources and destinations.  Cisco tools : Cisco Flow collector and data analyzer 11

C HARACTERIZING TYPES OF TF FOR NEW NETWORK APPLICATIONS  A network flow can be characterized by two things:  Direction  Symmetry Direction= specifies whether data travels in both directions or just in one directions. It 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. 12

T YPES OF TRAFFIC 13

CONTINUE  A good technique for characterizing network traffic flow is to classify applications as supporting one of a few well-known flow types:  Terminal/host TF  Client/server TF  Peer-to-peer TF  Server/Server TF  Distributed computing TF  Thin client 14

T YPES 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.  Example: Telnet ◦ 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.  Example; HTTP, TCP/IP 15

T YPES OF TRAFFIC  Server-to-Server 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 16

T YPES OF TRAFFIC  Peer-to-peer The flow is usually bi-directional. Communicating entities transmit approximately equal amounts of information.  Thin-client/server-based computing: It is a computer or a computer program which depends heavily on some other computer (its server) to fulfill its traditional computational roles. User applications originate on a central server – better security, easy to managed A computing appliance is a thin client designed to perform specific or dedicated tasks. i.e. cash register, a dedicated machine, a databse retrieval device etc.. Lower support cost (advantage) Example; Windows NT terminal Server edition 17

ApplicationType of Traffic ProtocolUser Community Data Store BandwidthQoS Enterprise Accounting Client/Server Browser/Server IPEnterprise Accounting Data Average of 2 Mbps from 8 to 5 weekdays None OpenViewTerminal/ServerIPAverage of 2 Kbps 24X7X365 OpenView Logs Average of 2 Kbps 24X7X365 None AlertPageTerminal/ServerIPAverage of 65 Kbps Every hour 24X7X365 AlertPage Logs Average of 65 Kbps Every hour 24X7X365 None T YPES OF TRAFFIC LIST 18

T YPES OF T RAFFIC  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 19

Type of ApplicationTypical Data Size Kbytes Type of ApplicationTypical Data Size Kbytes Terminal Screen4Graphical Screen Presentation Document 2,000 Web Page50High Resolution Image50,000 Spreadsheet100Multimedia Object100,000 Word Processing Document 200Database1,000,000 T RAFFIC F LOW E STIMATES L IST 20

T RAFFIC F LOW E XAMPLE 21 Administration Business and Social Sciences Math and Sciences 50 PCs 25 Macs 50 PCs 30 PCs 30 Library Patrons (PCs) 30 Macs and 60 PCs in Computing Center Library and Computing Center App Kbps App 2 60 Kbps App Kbps App 4 48 Kbps App Kbps Total 808 Kbps App 1 48 Kbps App 2 32 Kbps App 3 96 Kbps App 4 24 Kbps App Kbps App Kbps App Kbps Total 1900 Kbps App 1 30 Kbps App 2 20 Kbps App 3 60 Kbps App 4 16 Kbps Total 126 Kbps App 2 20 Kbps App 3 96 Kbps App 4 24 Kbps App 9 80 Kbps Total 220 Kbps Arts and Humanities Server Farm 10-Mbps Metro Ethernet to Internet

C HARACTERIZING T RAFFIC L OAD 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. 22

C HARACTERIZING T RAFFIC L OAD : S TEPS 1. 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 2. 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 23

C HARACTERIZING T RAFFIC L OAD : S TEPS 3. 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 4. 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. 24

S IZE OF O BJECTS ON N ETWORKS Table 4-5 : Approximate Size of Objects that applications transfer across networks 25

B ANDWIDTH USED BY L EGACY R OUTING P ROTOCOLS : S AMPLES 26 Table 4-7: Bandwidth used by Legacy Routing Protocols

C HARACTERIZING TRAFFIC BEHAVIOR  To select appropriate network design solutions, designer need to understand protocol and application behavior in addition to traffic flows and load.  Exp: to select appropriate LAN topologies, designer need to investigate the level of broadcast traffic on the LAN. 27

C HARACTERIZING T RAFFIC B EHAVIOR 1. 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 28

CONTINUE Multicasts ◦ Multicast frame = frame that goes to a subset of stations. ◦ Example: 01:00:0C:CC:CC:CC (Cisco Discovery Protocol) ◦ Should just disturb NICs that have registered to receive it 29

CONTINUE  switches and bridges forward broadcast and multicast frames out all ports.  Too many broadcast frames can overwhelm end stations, switches and routers.  It is important to research the level of broadcast traffic in your proposed design and limit the number of stations in a single broadcast domain. ( A broadcast domain is a logical division of a computer network, in which all nodes can reach each other by broadcast at the data link layer. A broadcast domain can be within the same LAN segment or it can be bridged to other LAN segments-Ref: wiki) computer networknodesbroadcastdata link layer  Broadcast traffic is necessary and unavoidable since routing and switching protocols use broadcast and multicast to share information about the internetwork topology. 30

CONTINUE  Server send broadcast and multicast to advertise their services  Desktop protocols i.e. TCP/IP use need broadcast/multicast frames to find services etc..  Hence, when designing network topology, be sure to take into consideration the broadcast behavior of desktop protocols. 31

C HARACTERIZING T RAFFIC B EHAVIOR 2. Network Efficiency  Efficiency refers to whether applications and protocols use bandwidth effectively. Efficiency is affected by: Frame size Protocol interaction (pg 114) Windowing and flow control Error-recovery mechanisms 32

C HARACTERIZING Q O S R EQUIREMENTS 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) 1. 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) 33

Q O S R EQUIREMENTS 2. 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 34

Q O S R EQUIREMENTS  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

S UMMARY  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 36

R EVIEW Q UESTIONS  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? 37