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

37
TOP-DOWN NETWORK DESIGN CHAPTER FOUR CHARACTERIZING NETWORK TRAFFIC Oppenheimer

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

Page 1: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

TOP-DOWN NETWORK DESIGN

CHAPTER FOUR

CHARACTERIZING NETWORK TRAFFIC

Oppenheimer

Page 2: 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

OBJECTIVES

AAB@2013

2

1

2 To analyze network traffic patterns that help you in selecting appropriate logical and physical network design solutions

Page 3: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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

AAB@2013

3

Page 4: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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- characterize user communities by application and protocol rather than by department boundary.

Create a chart of these groups

AAB@2013

4

Page 5: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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

Network

Managers

3 Building C

Deep Dark

Basement

AlertPage

USER COMMUNITY LIST

AAB@2013

5

Page 6: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

CHARACTERIZING TRAFFIC FLOW

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

AAB@2013

6

Page 7: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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

Building C

Deep Dark

Basement

OpenView Network

Managers

AlertPage

Logs

Building C

Deep Dark

Basement

AlertPage Network

Managers

DATA STORE LIST

AAB@2013

7

Page 8: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

CHARACTERIZING TRAFFIC FLOW

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

AAB@2013

8

Page 9: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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

AAB@2013

9

Page 10: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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

AAB@2013

10

Page 11: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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

AAB@2013

11

Page 12: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

CHARACTERIZING 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.

AAB@2013

12

Page 13: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

TYPES OF TRAFFIC

AAB@2013

13

Page 14: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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

AAB@2013

14

Page 15: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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.

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

AAB@2013

15

Page 16: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

TYPES 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

AAB@2013

16

Page 17: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

TYPES 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 email machine, a databse retrieval device etc..

Lower support cost (advantage)

Example; Windows NT terminal Server edition

AAB@2013

17

Page 18: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

Application Type ofTraffic

Protocol UserCommunity

DataStore

Bandwidth QoS

EnterpriseAccounting

Client/ServerBrowser/Server

IP EnterpriseAccounting

AccountingData

Averageof 2 Mbpsfrom 8 to 5 weekdays

None

OpenView Terminal/Server IP Average of 2 Kbps24X7X365

OpenViewLogs

Average of 2 Kbps24X7X365

None

AlertPage Terminal/Server IP Average of65 KbpsEvery hour24X7X365

AlertPageLogs

Average of65 KbpsEvery hour24X7X365

None

TYPES OF TRAFFIC LIST

AAB@2013

18

Page 19: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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

AAB@2013

19

Page 20: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

Type of Application Typical Data Size

Kbytes

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

TRAFFIC FLOW ESTIMATES LIST

AAB@2013

20

Page 21: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

TRAFFIC FLOW

EXAMPLE

AAB@2013

21

Administration

Business and Social Sciences

Math and Sciences

50 PCs 25 Macs50 PCs

50 PCs30 PCs

30 Library Patrons (PCs) 30 Macs and 60 PCs in Computing Center

Library and Computing Center

App 1 108 KbpsApp 2 60 KbpsApp 3 192 KbpsApp 4 48 KbpsApp 7 400 KbpsTotal 808 Kbps

App 1 48 KbpsApp 2 32 KbpsApp 3 96 KbpsApp 4 24 KbpsApp 5 300 KbpsApp 6 200 KbpsApp 8 1200 KbpsTotal 1900 Kbps

App 1 30 KbpsApp 2 20 KbpsApp 3 60 KbpsApp 4 16 KbpsTotal 126 Kbps

App 2 20 KbpsApp 3 96 KbpsApp 4 24 KbpsApp 9 80 KbpsTotal 220 Kbps

Arts and Humanities

Server Farm

10-Mbps Metro Ethernet to Internet

Page 22: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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.

AAB@2013

22

Page 23: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

CHARACTERIZING TRAFFIC LOAD: STEPS

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

AAB@2013

23

Page 24: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

CHARACTERIZING TRAFFIC LOAD: STEPS

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.

AAB@2013

24

Page 25: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

SIZE OF OBJECTS ON NETWORKS

Table 4-5 : Approximate Size of Objects that applications transfer across networks

AAB@2013

25

Page 26: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

BANDWIDTH USED BY LEGACY ROUTING

PROTOCOLS: SAMPLES

AAB@2013

26

Table 4-7: Bandwidth used by Legacy Routing Protocols

Page 27: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

CHARACTERIZING 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.

AAB@2013

27

Page 28: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

CHARACTERIZING TRAFFIC BEHAVIOR

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

AAB@2013

28

Page 29: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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

AAB@2013

29

Page 30: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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)

Broadcast traffic is necessary and unavoidable since routing and switching protocols use broadcast and multicast to share information about the internetwork topology.

AAB@2013

30

Page 31: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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.

AAB@2013

31

Page 32: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

CHARACTERIZING TRAFFIC BEHAVIOR

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

AAB@2013

32

Page 33: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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)

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)

AAB@2013

33

Page 34: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

QOS REQUIREMENTS

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

AAB@2013

34

Page 35: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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.

AAB@2013

35

Page 36: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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

AAB@2013

36

Page 37: T OP -D OWN N ETWORK D ESIGN C HAPTER F OUR C HARACTERIZING N ETWORK T RAFFIC Oppenheimer.

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?

AAB@2013

37