Lecture 6: Network Analysis: Process Part 1

Transcription

1 Lecture 6: Network Analysis: Process Part 1 Instructor: Hussein Al Osman Based on Slides by: Profs Makrakis and Shirmohammadi Hussein Al Osman CEG

2 Overview The principles, guidelines, and procedures for requirements analysis are part of the process model. How do you gather and mange user, application, device, and network requirements? Determine which service metrics to measure. Introduce modeling and 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 Hussein Al Osman CEG

3 Requirements Analysis Process Gather and List Requirements Develop Service Metrics Characterize Behavior Develop Requirements Map Requirements Hussein Al Osman CEG

4 Requirements Analysis Process Gather and List Requirements Develop Service Metrics Characterize Behavior Develop Requirements Map Requirements Hussein Al Osman CEG

5 Gathering and Listing Requirements Determining initial conditions of project Type of 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 scope of the Project: size, distance, number of sites You might or might not be aware of outside forces: political, administrative, financial Hussein Al Osman CEG

6 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-tier network: has no distinctive set of applications, users or hosts that have significantly greater performance requirements. Exercise 1 Hussein Al Osman CEG

7 Working with Users Customer Expectations: Estimating resources and schedule, from a rapid initial evaluation of 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, ( , fax, mail) Follow up surveys with telephone calls Follow up with face to face meetings. Conduct whiteboard sessions. Spend time with some high-performance users Hussein Al Osman CEG

8 Requirements Management and Tracking Since the requirements gathering phase is interactive and continuous, tracking and management of 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 versions must be kept, for historical reasons and for accountability, and managed. Hussein Al Osman CEG

9 Mapping Location Information Central Campus LAN Application G Servers North Campus LAN Applications E,F Servers Storage Server South Campus LAN Applications A,D Hussein Al Osman CEG

10 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 Application Traffic across Network Performance and Session Data Collected Existing Network Performance and Session Data Collected Hussein Al Osman CEG

11 Requirements Analysis Process Gather and List Requirements Develop Service Metrics Characterize Behavior Develop Requirements Map Requirements Hussein Al Osman CEG

12 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 Hussein Al Osman CEG

13 Measurement Tools Configuring and measuring service levels: use your basic Network Management Tools 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 Hussein Al Osman CEG

14 Requirements Analysis Process Gather and List Requirements Develop Service Metrics Characterize Behavior Develop Requirements Map Requirements Hussein Al Osman CEG

15 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) Hussein Al Osman CEG

16 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 temporal and spatial behaviors of traffic flows, equipment type, placement, configuration, and behavior under 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. Hussein Al Osman CEG

17 Requirements Analysis Process Gather and List Requirements Develop Service Metrics Characterize Behavior Develop Requirements Map Requirements Hussein Al Osman CEG

18 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? Hussein Al Osman CEG

19 Availability Measures A common measure for availability is a percentage of uptime or downtime. For example % ( 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 % 5.3m 26.3s 6s 0.86s Is it enough to just specify a percentage as a requirement? Hussein Al Osman CEG

20 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. Testbed Low Performance High Performance 99.5 %Uptime Hussein Al Osman CEG

21 Develop Delay Requirements Several delay measures are used: End to end Round trip Delay variation (jitter). Delay requirements Interaction Delay (INTD) waiting time seconds Human Response Time (HRT) human perceptive delay 100 ms Network propagation delay Depends on technology and distance (< 10 msec) Hussein Al Osman CEG

22 Develop Delay Requirements Hussein Al Osman CEG

23 Interactive Applications Delays Interactive-Burst Interactive-Burst or Interactive-Bulk Interactive-Bulk Human Response Time Delay (Seconds) Interaction Delay Hussein Al Osman CEG

24 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 limitations early 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. Hussein Al Osman CEG

25 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 delay as 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? Hussein Al Osman CEG

26 Develop Capacity Requirements Capacity requirements often used are: Peak data rate, sustained data rate, minimum data rate, or combinations of 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. Hussein Al Osman CEG

27 Capacity for Some Typical Apps Application Average Completion Time (Seconds) Average Data Size (Bytes) Distributed Computing Web Transactions Database Entries/Queries Payroll Entries Hussein Al Osman CEG

28 Exercise 1 Single-tier or multi-tier? Back Hussein Al Osman CEG

29 Thank You! Hussein Al Osman CEG