Lecture 6: Network Analysis: Process – Part 1halos072/CEG4190_files/Lecture06.pdf · Lecture 6:...

Hussein Al Osman CEG4190 6-1

Lecture 6:Network Analysis:Process – Part 1

Instructor: Hussein Al Osman

Based on Slides by: Profs Makrakis and Shirmohammadi


Overview

• The principles, guidelines, and procedures for requirements analysis are part of the process model.– How do you gather and mangeuser, application, device,

and network requirements?– Determine which service metricsto measure.– Introduce modelingand simulation.– Develop performance requirements for delay, capacity,

and RMA.– General and environment specific thresholds.– The importance of predictable and guaranteed

performance.– Traffic flow analysis by mapping requirements to

geographic locations.

Lecture 7


Requirements Analysis Process

Gather and List Requirements

Develop Service Metrics

Characterize Behavior

Develop Requirements

Map Requirements







Map Requirements


Gathering and Listing Requirements

• Determining initial conditions of project– Typeof Project:

• New network, a modification, an analysis of network problems, outsourcing, consolidation, or upgrade.

• Example of initial design goals:– Upgrade technology, improve performance, support new users,

– The scopeof the Project:• size, distance, number of sites

– You might or might not be aware of outside forces: political, administrative, financial


Performance Target Tiers

• Part of the initial conditions for your network project maybe determining its performance target– Is the performance target a multi-tier or single tier

network.

• Multi-tier network: where one or more user, application, and/or devices requirements are significantly greater than those of other performance requirements for that network.

• Single-tiernetwork: has no distinctive set of applications, users or hosts that have significantly greater performance requirements.

Exercise 1


Working with Users

• Customer Expectations:– Estimating resources and schedule, from a rapid initial evaluationof the

problem, to quickly evaluate feasibility of expectations

– Most of the time, customer expectations need to be adjusted

• This is a very soft skill– Survey/questionnaire, (email, fax, mail)

– Follow up surveys with telephone calls

– Follow up with face to face meetings.

– Conduct whiteboard sessions.

– Spend timewith some high-performance users


Requirements Management and Tracking

• Since the requirements gathering phase is interactive and continuous, trackingand managementof changes becomes important.

• Similar to software requirements management, although not as complicated as that.

• Tools should be used to capture requirements:– Word processor

– Spread sheet

– Proprietary tools

• Different versionsmust be kept, for historicalreasons and for accountability, and managed.


Mapping Location Information

North Campus LAN

Cen

tral

Cam

pu

s L

AN

South Campus LAN

45

40

Servers

Storage Server2

51

Servers88

2214

Application G

Applications E,F

Applications A,D


Taking Performance Measurements

• Useful to measure performance levels of applications that will be use on the planned network

• Can be done in a controlled environment (left figure) or actual network (right figure).

• Difference between two methods?

Application Session Traffic

Performance and Session

Data Collected

Existing Network

Performance and Session

Data Collected

Application Traffic across Network







Map Requirements


Developing Service Metrics• For performance characteristics to be useful, they

must be configurable, measurable, and verifiable.– Service metrics for Availability

• RMA, in terms of MTBF (or MTBCF), MTTR• Uptime or downtime

– Error and loss rates, BER, CLR (Cell Loss Rate), CMR (Cell mis-insertion ratio), frame and packet loss rates

– Service metrics for capacity• Data rates: Peak data Rate (PDR), sustained data rate (SDR),

minimum data rate• Data size: burst size and duration

– Service metrics for delay• End-to-end, round-trip or system delay• Latency• Delay variation


Measurement Tools

• Configuring and measuring service levels: use your basic Network ManagementTools– Simple Network Management Protocol (SNMP)

– Common Management Information Protocol (CMIP)• Bytes in/out, IP packets in/out, dropped ICMP packets,

capacity limits, delay, downtime.

– Ping, traceroot, pathchar (available from ee.lbl.gov)• round-trip delay, per-link capacity, path traces

– TCPdump







Map Requirements


Characterizing Behaviour

• How do users and applications use the network? Helps us understand their requirements.

• Usage patterns– Frequency and duration of application sessions

– Number of simultaneous sessions

• Application behaviour– Data sizes

– Frequency and time duration data passes the network

– Traffic flow characteristics

– Degree of multicasting (broadcasting)


Modeling and Simulation

• This is often useful in predicting, determining, or estimating requirements and data flows.

• Good in the architecture and design process for understanding temporaland spatialbehaviors of traffic flows, equipmenttype, placement, configuration, and behaviorunder stress.

• The advantage of this is that they can be used over and over again.

• We are using the OPNET tool in this course for simulation.







Map Requirements


Develop RMA Requirements• This is done through defining thresholds on the values.

– General thresholds are those that apply to most or all networks– Environment specific thresholds are determined from the environment of the current

project• These measures are generally defined as:

– MTBF/MTBCF/MTTR• These are generally expressed in hours. • Reliability is estimated by measuring the failure rate per hours of operation.

– MTBF = 1/failureRate• The failure rate of a system is computed by adding the failure rates (total hours)

of the components and then inverting this value.• MTTR: Time to restore the system to fully operational status once it has

experienced a fault.• Availability is a Relationship of Reliability to Maintainability:

– (MTBF) / (MTBF + MTTR) OR MTBCF / (MTBCF + MTTR)• Reflects only failure time, not scheduled maintenance downtime.• Can be improved by:

– Replacing faulty components at a quicker scheduled rate.– Design redundant paths for critical components. (expensive)

• Is it possible to have MTBF and MTBCF on the same network?


Availability Measures• A common measure for availability is a percentage of uptime

or downtime. – For example 99.999% (“five nines” reliability)– Most systems operate at 99.99% uptime (general threshold)

% Uptime Yearly Monthly Weekly Daily

99% 87.6h 7.3h 1.68h 14.4m

99.9% 8.76h 44m 10m 1.4m

99.99% 53m 4.4m 1m 8.6s

99.999% 5.3m 26.3s 6s 0.86s

Is it enough to just specify a percentage as a requirement?


Availability Examples

• Pacific Bell’s switched multimegabit data services (SMDS)– Mean time between service outages of 3500 hours or more,

with an MTTR of 3.5 hrs or less.

• Bellcore specifications for SMDS– Availability of 99.9%. Similar measure to Pacific but less

specific.

%Uptime99.5 99.99

HighPerformanceTestbed Low Performance


Develop Delay Requirements

• Several delay measures are used:– End to end

– Round trip

– Delay variation (jitter).

• Delay requirements– Interaction Delay (INTD) waiting time

• 10 – 30 seconds

– Human Response Time (HRT) human perceptive delay• 100 ms

– Network propagation delay• Depends on technology and distance (< 10 msec)

Develop Delay Requirements



Interactive Applications Delays

Delay (Seconds)

0.10.01 1.0 10.0 100.0

Human ResponseTime

Interaction Delay

Interactive-Burst Interactive-Burst orInteractive-Bulk

Interactive-Bulk


Delay Thresholds• Reduce delay: determine the ultimate delay bottleneck within the

system– Reduce one at a time until the delay is at an acceptable level.

• We must keep in mind real physical limitationsearly in the design, for example:– Real physical limitations determine that the physical delay of a network

from Los Angeles and Tokyo is ~120 ms. No matter what you do you cannot improve this.

• Where can one look in order to improve on the delay of a network that theoretically can support say 10 ms delay but actually has a 100 ms delay?– Improve or tune the OSs and/or network protocols.

• Difficult to do and requires a great deal of experience

– Get better device peripherals.• Quick research can determine performance problems with devices.


Delay Variation (Jitter) Requirements

• Delay variation is often coupled with end-to end or round trip delay to give an overall delay performance value.

• A rule of thumb is use a 1% to 2%of end-to-end delayas the delay variation.

• For example:– An estimate for delay variation when the end-to-end delay is

40 ms is approximately 400 to 800 µs.

• What type of applications are impacted more by jitter than by the delay itself?


Develop Capacity Requirements

• Capacity requirements often used are:– Peak data rate, sustained data rate, minimum data rate, or

combinationsof all of these.

• We only have a “intuitive” feeling of particular application limits:– Telnet will not have a data rate of 100 Mb/s and that FTP

should not run at 10 Kb/s if greater capacity is available.


Capacity for Some Typical Apps

Application Average Completion Time

(Seconds)

Average Data Size

(Bytes)

Distributed Computing

103 107

Web Transactions 10 104

Database Entries/Queries

2-5 103

Payroll Entries 10 102


Exercise 1• Single-tier or multi-tier?

Back

Thank You!


Lecture 6: Network Analysis: Process – Part 1halos072/CEG4190_files/Lecture06.pdf · Lecture 6:...

Documents

Transcript of Lecture 6: Network Analysis: Process – Part 1halos072/CEG4190_files/Lecture06.pdf · Lecture 6:...