1. 1 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Functional Capabilities The Project Engineer Squeeze Schedule Quality Cost NOTE: Project engineers are basically 25% solids, 70% liquids and 5% air. Ie virtually incompressible. Thus, increasing the pressure from any particular axis will inevitably cause one or more of the others to blow out. Alternatively, the whole project may explode

2. 2 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management CSE4884 Network Design and Management Lecturer: Ken Fletcher Lecture 11 Revision This presentation is a summary of Lectures 1 through 5

3. 3 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management CSE4884 Network Design and Management Lecturer: Ken Fletcher Lecture 1 Architectural Design and Strategy This lecture was high-level and conceptual Aim: to set the scene for subsequent lectures

4. 4 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management System Life Cycle - Conceptual Ideas Decision Design Implement System Operations Review Operations GO NO-GO Progress Clockwise Strategy Studies

5. 5 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Project Lifecycle - Eng’g Processes System Specifications System Specifications System and Sub-System Specifications Detail Design Ideas Sub-system Testing System Testing Acceptance Testing Progress Clockwise Review Operations Strategy Studies Operations Analysis Architectural Design User Requirements Specification User Oriented Testing - Functional and Performance System Oriented Testing- Technical Functionality, plus Connectivity and Interfacing Acquire and Implement Sub-systems Sub-system Oriented Testing- Detailed Functionality, plus Connectivity and Interfacing

6. 6 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Network Strategy Development n Network Life Cycle is a sequence of: –Strategy Determination; Architectural Concepts –Designing the network; –Implementing the network; –Operation and Maintenance of the network; n (Maintenance = Approx 10% of initial cost per annum) –Modification of network as needs change; –Upgrading equipment/software to remain current; and finally –Closing Down, Dismantling, and Disposing of the equipment, documentation, circuits etc. n ‘Network Strategy’ should consider ALL of these steps Initial costs Costs approx equal to Initial costs

7. 7 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management What is Architecture (2)? n IEEE Glossary of Software Engineering Terms Architectural Design –The process of defining a collection of hardware and software components and their interfaces to establish a framework for the development of a computer system System Architecture –The structure and relationships among the components of a system. The system architecture may also include the system’s interface with its operational environment.

8. 8 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management What is Architecture (3)? n Horowitz...includes the hardware and software components, their interfaces, and the execution concept that underlies system processing n Ron McGann (1994) The glue or unifying influence that turns a collection of functional components into a cohesive system. n Bob Paalep (2000) Harmony between the parts

9. 9 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Why Architecture? n Supports achievement of the ‘...ability’ requirements –Reliability, Availability, Maintainability –Testability of the system –Adaptability, Expandability, Flexibility –Portability to new hosts etc n Leads to higher quality of service overall –Consistency of style gives consistency of behaviour n Causes lower lifecycle costs –eg parts or components may be interchangeable or re-usable throughout the system –Lower training costs for operators, users, maintainers –Reuse of design effort when expanding, or for other networks

10. 10 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Architectural Style n Should be based on what is available: Resources, eg Materials and Components Skills and Numbers of Staff - eg Don’t have high tech solution if network can’t be maintained Services Available Do not design an ATM system if best circuits available are 9600 bps Environment Is it a progressive or cautious customer? High tech or low tech infrastructure? Growth Potential and need Customer Expectations eg Acceptance of early Volkswagens was slow in Australia because of their rear-mounted engine.

11. 11 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Architectural Style: n A Housing Architect endeavours to produce a house design which is: –Functional, Coherent and Integrated –Aesthetically Pleasing –Cost Effective –Compliant with Customers Brief ie A building which is pleasing and effective, NOT A COLLECTION OF ROOMS n A poor builder can make the best design seem bad, but a good builder cannot make a poor design good. n With networks, the same concepts apply, but we need to also consider attributes such as: Expandable, Testable, Reliable, Maintainable, Robust and Secure “Harmonious”

12. 12 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Architecture n Good architecture Higher Initial Costs Buildable, Operable, Reliable Systems Lower Development and Life Cycle Costs Satisfied Customers Repeat Business

13. 13 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Network Strategy and Architecture n Usually an “Infrastructure Plan” for the organisation n WHY? Because it tends to set out what services will be available, when and where n Is this good or bad? Not good - (but not totally bad either) Because the network should support the organisation, not direct and control it. Having Network Strategy as the Infrastructure Plan for an organisation is like putting the cart before the horse.

14. 14 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Scope of Strategy Studies n Include all forms of communications in study –Voice, data, fax, telemetry, video, fire & security alarms –Don’t forget needs of ‘roaming’ or mobile users for data n WHY? In order to: –gain understanding of trends and intentions –look for possible rationalisation –ensure that future changes are allowed for –avoid simply automating yesterday’s approach and technology Outcome of Strategy Study is an Architectural Concept or Design

15. 15 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Strategy Study in Six Stages Stage 1Analysis of EXISTING Networks Stage 2Identify FUTURE Requirements and Constraints Stage 3Definition and Evaluation of Options Stage 4Strategy Consolidation Stage 5Report to Management Stage 6Recording the Concept for Later Detailed Design

16. 16 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Stage 1Analyse EXISTING Networks n Traffic Loads and Capacity n Reliability and functionality n Residual working life of –current systems, –facilities (buildings and power supplies etc), –communications and support equipment n Consider existing contracts for –systems, –equipment, –facilities, –provision of services such as telecommunications services, –facilities management, etc

17. 17 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Stage 2FUTURE Req’ts & Constraints n Identify Future Network and Facility Requirements –Architectural Broad Brush Estimates –Don’t worry about How, concentrate on WHAT is required n Traffic Loads and Characteristics n Functions and capabilities needed (not only ‘wanted’) n Available buildings and environmental support eg is the company vacating suitable buildings somewhere?

18. 18 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Stage 3Consider Options n Define and Evaluate Options and alternative solutions –This is where you consider the questions: ‘HOW to do it’ and ‘HOW MUCH would it cost if done this way’ n Capture evaluation of alternatives in ‘Trade Studies’ –A ‘Trade Study’ compares costs, benefits, risks, timescale of several alternatives –eg Is it better to use a cheap, slow network, or a faster but more expensive one?

19. 19 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Stage 4Strategy Consolidation n Consolidate the viable options identified in Trade Studies into two or three alternate architectural designs n There may be some issues which are independent of the architecture (eg colour of paint on boxes) - Identify these issues separately for resolution n Prepare Study Report Briefly describe each major architectural option IncludeCosts & Resources (dollars), people, buildings Schedule (Time Table) –Milestones and Proposed payment schedule if applicable Risks, and their mitigation Benefits of that option - absolute benefits, and in comparison to alternate architectures

20. 20 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Stage 5Report to Management n Present the highlights of the written report to management and answer their questions n Why do we do this? Remember the Golden Rule “The one who controls the gold makes the rules” n Follow up and respond to their directions and guidance

21. 21 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Stage 6Recording Concept for Later n Document the concept or architecture for posterity If a particular style or option has been selected –then write a System Specification –This is a formalised description of the system. Use precise and quantitative language –eg –"The coffee cup shall hold 250cc of liquid when the liquid level is 1cm below the top the rim." is precise and testable, while –"The coffee cup is to be of normal size" is vague and imprecise, and can not be tested. Whether the product meets the specification is a matter of personal opinion - thus leading to arguments.

22. 22 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Written Requirements n A project without stated requirements can never be considered to be wrong - but it will be a failure n Unwritten (and un-agreed) requirements inevitably lead to mis- matched expectations between stakeholders. Verbal statements and assumptions lead to mis-understandings n Interpretations and ‘understandings’ of statements of requirements are renown for variations - even in co-operative environments. n Common sense is rare, and is dependent on each person’s own personal history DO NOT RELY ON ‘COMMON SENSE’

23. 23 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management CSE4884 Network Design and Management Lecturer: Ken Fletcher Lecture 2 Network Design Principles This lecture introduced the major factors to be considered in a design, and briefly addressed these.

24. 24 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management General Design Approach n Network design is a complex task - as much people-handling & political as technical issues requires patience and endurance n Starting conditions: Usually a request ‘to install a network’ Sometimes with written ‘brief’, such as the document from L1 Strategy Studies “Stage 6 - Recording Concept for Later” n Ending Conditions: A detailed specification of the technical design, from which the network could be built, tested, and implemented. n Frequently, the designer then also implements the network

25. 25 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management COSTS! Customer Has: Technical Design Equipment sizing and numbers Circuit Dimensioning (bandwidth and numbers of circuits) Traffic volumes and characteristics Functionality and Acceptable Delays Money Needs & expectations To Pay Minimises Customer Needs Drive Basic Decisions

26. 26 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Major Stakeholders & Roles Customer Has: Money to pay for products & services Business Needs & Expectations Employees ( Operators and Users) Designer Has: Knowledge (education &training) Wisdom (experience) Vendors Have: Products & Services Skilled Workforce All are needed to implement and support the network

27. 27 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Project Engineer/Designer Role Network Implementation Tasks (build, install, test, train staff etc) Project Engineer / Designer is a buffer between the customer and the implementers Customer (With Needs & Money ) Needs & Expectations Money to pay costs Specifications & Requirements Costs Problems and Resolutions

28. 28 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Main Design Drivers n Network Design driven by five main issues: Functionality Required What is the network to do? Performance Required How fast is to be? Reliability and Availability Required When is it needed, and impact of not being available when needed Facilities and Capabilities Available - (sometimes a constraint) What buildings/rooms/equipment are available – –Are they suitable? –Must they be used? Price or Cost If lucky, you get what you pay for, but rarely more than that

29. 29 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Components within Computer Network n The computer communications network will essentially consist of: Processor(s) of all kinds; Mainframes, Servers, email servers, etc Node(s); Hubs, Switching Centres Signal Carriers - Radio circuits, Line(s) and possibly modems; Communications circuits linking sites/hubs etc Terminal(s); Desktop computers, printers, POS terminals, etc Miscellaneous Components Crypto gear, firewalls, telemetry interfaces etc

30. 30 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Key Points n The key points when approaching network design are: Proper definition & specification of the technical problem, AND Well specified evaluation criteria - eg What is `good response'? What is `a reliable system'? What constitutes `an expandable network'? Don't rely on intuition or assume that you know what is wanted, this is usually dangerous. –Remember: ‘Assume’ makes an ass (donkey) out of you and me ( Ass / u / me )

31. 31 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Design is an Iterative Process Design Activity Goals Demand Resources Adjust Criteria Review Results Network Design Temper Design Order Circuits Order Equip't Iterative Design Process Design Documents Spec’ns Drawings Plans

32. 32 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Design Goals n The major design goals are to: –Deliver the functionality, performance and connectivity required –Mininise costs –Optimise performance Speed Capacity –Efficiently use the Facilities provided (efficient use of space etc) –Meet Objectives in: Implementation Ease Availability and Reliability Maintainability Servicing Flexibility Robustness

33. 33 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Performance Required Performance requirements drive the ‘dimensioning’ of the network ie number of circuits/components, and the bandwidth required for their connection

34. 34 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Response Time n Covered mainly in lectures 3 and 4, and also in lecture 7 Response time is performance in interactive mode n Typical User view: –The time from pressing the key that `commits' the input command, and viewing the full output screen.(ie end-to-end delay) n Typical Specialist view: –Time from last input character going to line, and first output character being received at the computer(ie transit delay). n Need agreed definition –Either view is valid - but remember the golden rule, and who has the gold. –Try for peak or busy hour definition EG. “95% of traffic items shall be handled within ‘n’ seconds” What should ‘n’ be?

35. 35 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management End-to-End Delay The total time for an item to transit the network - including all: communications transit times –(usually negligible, except for satellite links) queuing times at intermediate nodes error recovery delays etc and sometimes includes processing times n Ensure that you know whether ‘allowable delay’ includes processing times. It is often included in the ‘perceived comms delay’

36. 36 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Throughput Related to response time figure but effect is quite different. n Throughput is a `batch' type of concept Inevitably difficult to define Inevitably difficult to specify meaningfully Interrelates with response time - good response times imply good throughput TRY: –“Throughput is the bulk traffic able to be handled by the network.” eg 1000K file transfer in one minute. NOTE: –If no priority system for traffic, a bulk file transfer will cause the communications link loading to approach 100% utilisation for short periods, thereby creating significant delays for interactive traffic.

37. 37 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Busy Rate Goal n This area of design is covered in Lecture 6 n Usually related to `LOSS' aspects ie. those situations like a busy line on a telephone, where the request is lost if unable to be satisfied immediately. –Dial up circuits –Port Selection –Virtual Circuits n Usually set to some acceptable criteria (`grade of service’ or ‘degree of congestion’) –say 1% in busy hour is a typical rate for congestion of outgoing telephone calls being unable to be completed due to circuit/switch congestion.

38. 38 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Maintenance Goal n Covered in Lecture 8 n How much effort is management prepared to expend on support of Hardware and on Software for: –fault prevention, –fault correction, and –environmental maintenance (keeping up with technology) Consider: Should you specify high reliability equipment and configurations in your design, even though it costs much more than simpler commercial grade equipment? n Mean Time Between Failures (MTBF) –concept For each critical component For the communication carrier's circuits n Needs to be specified carefully –eg `Over any six months period, the MTBF shall be greater than xxx hours.‘

39. 39 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Servicing Goal n Mean Time to Restore (MTTR) concept –Central or Capital City installations Service personnel are less than an hours drive away Spares warehouses are close to hand –Remote Installations Service personnel may have to fly in Consider holding extended spares stocks on site –Communications Carrier's MTTR (probably very high, but …) n Needs to be specified carefully –Define whether MTTR is to respond, repair, restart or RESTORE; –EG `Over six months, the MTTR shall not exceed three hours on average, nor five hours for any single incident.’ n NOTE: Many other terms apply to these concepts - eg –Inherent availability, mean down time, etc

40. 40 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Implementation Ease Goal n Not specifically covered in later lectures n The ease or difficulty of implementation - –closely related to ‘Technical Risk’, but with broader considerations n How long to achieve implementation? n How much upheaval in the organisation? n What is the risk of project failure: –equipment inadequate –supplier/vendor failure to deliver –traffic estimates grossly inappropriate –facilities not available on time –Training –state-of-the-art equipment is often as crude as kindergarten art Leading Edge technology is BLEEDING edge for managers

41. 41 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Robustness Goal How well the network stands up to stress and shocks n Electrical and installation aspects Over/Under Temperatures Uninterruptable/No-Break Power Supplies n Circuit aspects Overloads Zero Loads Circuit transients - `hits' and `failures' Circuit major outages n Application Dependencies Peaky interactive loads Unexpected large batch loadings n MUST BE COST_JUSTIFIED - no system can be perfect –Many people demand high robustness, but cost is 200% to 500% more

42. 42 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Security Goals n Discussed further in Lecture 9 n ALWAYS treat security as exercise in RISK MANAGEMENT –(AS/NZS 4444 of 1999 “Information Security Management” and AS/NZS ISO/IEC 17799:2001 “Code of Practice”) n Base security on impact assessments and costs n Avoid knee jerk reactions and quick fixes Match network security to application/installation security

43. 43 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Performance Issues n Regarding performance issues, this subject concentrates on: –Network and Line Capacity Line bps or Char/Sec Nodes Packets etc per second –Delays Waiting in queues for service Service Times n For all lines, actual throughput is always less than the theoretical maximum possible throughput due to: polling error block retransmissions synch frames and overheads effect of random traffic patterns Line utilisation = (Actual Load handled / Maximum Possible)

44. 44 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Traffic Characteristics n Design is significantly affected by Type of traffic activity being handled Volume of traffic to be handled –eg average transaction (packet) size –eg average number of packets/second during the busy hour n Strange as it may seem, you will spend more time determining and analysing these issues than actually ‘designing’ the network. (consider the assignment effort) n Informal studies have indicated that actual network loads experienced within a short time of commissioning the new system are often 100% above the ‘design load’

45. 45 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Interactive (eg Query/Response) This type of traffic normally appears as Query/Response situations, where the response is required within one to three seconds of the query. Typically, the traffic volumes are very asymmetrical (short query, large response) n Bursty - Random Traffic patterns n Two way flow, (although one direction dominates) n Performance objectives `seconds’ n Variable sizes and numbers of records

46. 46 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management BATCH Traffic n These types of traffic flows were the norm before interactive terminals became common. Still in widespread use today. Examples: Overnight backups, End of Day POS dump. n One major direction of flow at any time –Usually very asymmetrical at any point in time n Many records - size & number determinable (more or less) n Performance objectives `hours’ rather than seconds –Usually this traffic type is ‘overnight’ n Impacts N/W performance badly –Line and switch gear utilisations approach maximums during large batch flows - thus there is little capacity left for other network users at that time. –Having interactive work and batch work at the same time on the same network always leads to complaints about performance and delays.

47. 47 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Message Volumes Traffic volumes are critical to response time/throughput. n `Communication item' sizes Average size - best by application if available Statistical distribution of sizes Are these figures constant throughout the day/week/month? n Totals in-out for each application Volumes of traffic - by application if available n Peak Times (NOTE: WA is 2-3 hours later) Special Days (Holidays, Religious festivals) Identifying the peak times for each application may be very useful n NEED TO UNDERSTAND BUSINESS / LOCAL PEAKS eg First Tuesday in November = holiday for many, peak for TAB

48. 48 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management `Turnpike Effect' and Growth (AKA as `Suppressed Demand’, Freeway Effect, etc) n Well designed systems encourage greater use - especially enquiry systems n Need to add a contingency allowance for the unknown suppressed demand n Martin 1968: –"If terminals provide a useful service, their utilisation will expand to fill the system capacity"

49. 49 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Network Delay and Response Times A small example

50. 50 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Network Delays n What is involved in the delay? Node delays: Usually small (and consistent) –Specialised processors etc used in switches and hubs Delays Affected by CPU and buffer numbers –Low processor CPU power means less nominal ‘packets per second’ –Low memory size means lower capability for switching (buffer overflows etc) Line Delays Trunk Lines and Branch Lines Generally, Comms lines are the bottle neck points in a network aa they are the slowest Note: These delays are for each node and line transited.

51. 51 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Response Times example n Query (1000 bytes) / response (10,000 bytes) using a mainframe / 10Mbps LAN n Response Time = the SUM of : –Inbound Terminal Delay (usually small - say 50 milliseconds) –Inbound Queuing Delay (queued traffic held in terminal waiting for LAN access. Time delayed depends on other terminals & traffic - say 20 milliseconds) –Inbound Service Time (time to transmit a packet on the network) (depends on line speed and message size - say 10 milliseconds) –Front End Processor (FEP) Delays (should be small - say 10 milliseconds) –Mainframe delays (could be comparatively large - say 1000 milliseconds) –FEP Delays on output (say 100 milliseconds) –Outbound Queuing (held in FEP while waiting for LAN access - 1000 ms) –Outbound Service Time (say 50 milliseconds) –Outbound Terminal Delay (say 50 milliseconds) n Total time - 2290 milliseconds - of which 60 can be assigned directly to ‘network’ (the inbound and outbound service times). Most of the rest is waiting times.

52. 52 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management CSE4884 Network Design and Management Lecturer: Ken Fletcher Lecture 3 Network Dimensioning This lecture was the start of detailed design work dependent on calculations

53. 53 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Notes Lecture 3 introduced Queueing Theory concepts and simple cases Lecture 4 continued Queueing Theory, covering Spread of response times Call centres Discussion on psychology and queueing systems Loss systems was covered in Lecture 6

54. 54 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management References n James MARTIN –Design of real time software. –Systems Analysis for Communication Systems (Chap 31) This chapter was handed out at the lectures. These books date from the late 60s and early 70s, are out of print, and in many ways obsolete in so far as the subject matters suggested by their titles. However, they still rank amongst the best textbooks for self study of queuing theory.

55. 55 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Fundamental Considerations n Traffic Volumes Average per day or week During the peak period (15 to 60 minutes) During extreme situations n Traffic Flow characteristics Random requests (“arrivals”) Bursts of traffic n Acceptable Delays in peak periods Average delay “Maximum” delay - effectively 90th or 95th percentile This information must be obtained from the Customer (See notes associated with the Traffic Analysis Tutorial)

56. 56 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Transaction Arrivals Storage Hopper Used to buffer the irregular arrivals into the metering device Metering Device Allows one item to pass each revolution of the roller If no items are present, then nothing is passed on that cycle. Conveyer Belt Output Rate On average will not exceed the slower of: a.arrivals; or b.metering rate. Conveyor and Hopper Model

57. 57 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Overloads n Overloads occur when the system is instantaneously receiving more traffic than it can handle immediately: What happens to the traffic unable to be processed immediately? What happens if the overload is too severe, or continues for too long? Consider the Conveyor and Hopper Model

58. 58 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Short term overloads due to randomness of arrivals Irregular Transaction Arrivals averaging 2 per second Storage Hopper empty 50% of time Metering Device four per second, (when available) Conveyer Belt Output average two per second Normal Operation - Average Arrival rate is less than metering rate

59. 59 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Sustained (or Severe) Overload Transaction Arrivals averaging 5 per second Storage Hopper gradually fills up (at average rate of 1 per second) and eventually overflows Metering Device 4 per second Conveyer Belt Output 4 per second Overload Operation - Average Arrival rate exceeds metering rate

60. 60 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Effect of Zero Size Hopper Transaction Arrivals averaging 5 per second No Storage Hopper Capacity other than item being processed Metering Device 4 per second Conveyer Belt Output 4 per second Rejected or lost arrivals With zero size hopper, this system becomes a ‘loss system’ in that any traffic not handled immediately is lost

61. 61 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Handling Overloads n Excess traffic may be: Queued in some (more or less) orderly manner (including ordered, priority and random queuing) –Known as a Queuing or Delay System eg computer systems Rejected and re-tried automatically within a short time –Known as a Bidding Contention system eg CSMA/CD, Ethernet Rejected and lost from the system (assumed to be lost, but usually tried some considerable time later) –Known as a Loss System eg older type (electro-mechanical) telephone exchanges n These are theoretical, perfect case situations. –In practice most systems are primarily one or another type, but with variations, and they default to Loss Systems under extreme situations

62. 62 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management QUEUING or DELAY SYSTEMS: n QUEUING OR DELAY systems handle SHORT TERM OVERLOADS OR CONGESTION by forcing some activities/customers to wait. n ie Any systems which form a waiting queue are Queuing Systems. n LOSS or BAULKING SYSTEMS are those which handle overload or congestion by locking out all activities or customers. ie They ignore or lose customers when overloaded. (In most cases, this means that the customers tries again at the customer’s (in)convenience). eg Getting on engaged number on the telephone.

63. 63 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Problems faced by Designers n How big will the queues grow? n How long will the total delay be? –average delay for average loads? –delays under peak load? –effect of extreme overload? What is the variability of the delay? –How can the variability be improved? n What are the trade offs? –faster switching equipment –more bandwidth to enable faster lines –reduce the traffic load

64. 64 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Five Ways to Approach the Problem n 1.Avoidance/Denial of problem - run away from it n 2.Seat of the pants - Guesswork, not too bad if you have the right experience n 3.Thumbnail calculations - Educated guesswork n 4.Mathematical Calculations and Analysis n 5.Simulations and Models Approaches 1 and 2 are unprofessional. Approach 4 is good, but tedious, slow and high complexity Approach 3 is adequate for most cases. –Also, it is fast, and only requires copies of some graphs. –In most cases a good estimate can be made using a simple formula. Approach 5 is best - but can be time consuming to set up

65. 65 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Queuing Theory - Approach #3 n Approach 3 n THUMBNAIL CALCULATIONS or EDUCATED GUESSWORK It is: Cheap Quick Uses conservative assumptions and graphs to simplify the mathematical approach Generally within 10% to 20% accuracy when compared to simulation approaches (Better than the accuracy of traffic activity projections on most systems.)

66. 66 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Points To Remember n Estimates only, not exact calculations n Queuing delays only handle short term overloads –“Short Term” is the time until the ‘hopper’ (buffer pool) overflows n Overload is defined as: “current input rate exceeding the activity rate of the servers” that is, more arrivals than can be handled in the time

67. 67 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Components to be Considered (1) n Input Characteristics –Effect of population size –Average input rate or frequency –Distribution of arrivals - random/peaked/…etc n Queue Characteristics –Queue discipline priority/FIFO/random/ordered/... –What happens when the queue space is full? n Service Facility –Average time and variability to service an event –Number of servers –Average load (“utilisation”)

68. 68 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Transaction Arrivals “Input Characteristics” Storage Hopper Queue in a Buffer Pool Behaviour of this area is called “Queuing Characteristics” Metering Device “Service Facility” Characteristics here determine the queue size (and variability), and hence Queue Delays of items in the Queue or Buffer Pool or Hopper Conveyer Belt Output Rate On average will not exceed the slower of: a.arrivals; or b.metering rate. Components to be Considered (2)

69. 69 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Input Characteristics n 1Population Size Effects All arrivals from some population of potential requestors. –Assumptions of this method. – Infinite population size to draw from –Requestor waits for service of a request before requesting more. – Effects – As population is finite, this assumption is conservative. –Small populations can smooth the peaks. n 2Input Rate or Frequency. “Load Intensity” –Taken as average arrivals per time period, for example: ‘3 arrivals/minute’, or ‘5 transactions/second’

70. 70 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Input Characteristics (2) n 3Input Traffic Distribution. Generally the mathematical distribution (dispersion) of input traffic requests is not known. Most networks are probably not describable mathematically Some assumptions are needed to enable analysis Consider these distributions of traffic arrivals or requests: –Random –Constant arrivals –Smoother than Random –Rougher than Random

71. 71 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Random Arrivals n There are many possible distributions of input traffic. The most common distribution is ‘unknown’. Think of it as a RANDOM distribution, unless you have evidence that something else is more appropriate. n Random arrivals ( Distribution most commonly assumed) –Also Known As (AKA) Poisson distribution Exponential distribution Erlang-1 distribution (more of this later) Events are random and independent of each other Arrivals are independent of each other, and drawn from an infinite size population.

72. 72 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Digression to Random Distributions (1) n The main traffic flow distribution is ‘Random’ This can be ‘random arrivals’ as in previous OHP Later we will also discuss ‘random service times’ and other occurrences which are distributed randomly n Just what does this concept of ‘RANDOM’ really mean? Occurrences are random and independent of each other –eg Any particular occurrence of something (such as a transaction arrival) has no effect on the probability of another occurrence happening - nor on its size, duration etc. Ie all occurrences are truly independent of each other –These occurrences will happen at some ‘long term’ average rate which we can define (both the rate and the ‘long term’) Eg 85 occurrences per hour

73. 73 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Random Distributions (2) n Basically, it means that the distribution of the aspect being discussed is described by the Poisson formula n where P(n)=Probability of exactly n occurrences (eg arrivals per second, seconds of transmission time, etc) n=mean value of all possible n e=2.71828

74. 74 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Random Distributions (3) Counts or Occurrences Prob of Specific Count Note: See ‘Tools and Toys’ for a spreadsheet model for you to use in ‘what if’ games.

75. 75 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Random Distributions (4) n This is a good approximation in most cases n Mathematically, an assumption of Random arrivals (or service times, message length distributions etc) allows a very simplified approximate solution to a complex problem (‘simplified’ is a relative term) n We rarely have to calculate the formula - just recognise that the functions have the general shape of graphs shown n There is another important aspect of this distribution that we discuss next lecture - its Standard Deviation n So ends the digression, back to considerations of other input traffic distributions

76. 76 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Constant Rate Arrivals n Constant rate (Even rate) eg 1 arrival every half second ‘on the dot’ Not common in general computer work May occur in communications nodes receiving packetised data from another node, particularly in periods of low activity Common in cyclic processors and polling situations Assumption: Treat as if random –System will perform better than estimated, especially at higher utilisations and variability of response times will be much lower

77. 77 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Smoother than Random n Smoother than random –Typically caused by a limited population size –Effect:The load intensity (arrival rate) decreases as the queue size increases –Example:If VDUs are locked out until their previous commands are processed –Typical DistributionBernoulli-Engset distribution Assumption:Treat as if random –system will perform slightly better than estimated, especially at higher utilisations

78. 78 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Rougher than Random n Rougher than random –Typically described (somewhat inaccurately) as “the heavier the load, the higher the probability of more load arriving”. –Examples: – VDU not locked out while previous command is processed, and the frustrated/impatient operator hits the enter key many times. –Also, the loading pattern on an ‘alternate’ or overload-only resource. –AKA:Hyper-geometric distribution Assumptions BE EXTREMELY CAREFUL IN THESE CASES.

79. 79 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management The Queue Itself Transaction Arrivals “Input Characteristics” Storage Hopper Queue in a Buffer Pool Behaviour of this area is called “Queue Characteristics” Metering Device “Service Facility” Characteristics here determine the queue size (and variability), and hence Queue Delays of items in the Queue or Buffer Pool or Hopper Conveyer Belt Output Rate On average will not exceed the slower of arrivals or metering rate

80. 80 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Queue Characteristics (1) - Discipline How will the waiting items be queued? –Affects variability of waiting time, but not queue size unless the queue ordering is based on expected service time, ie short tasks are queued ahead of longer tasks Discipline –Normally found in Communications Systems FIFOMost common Priority (FIFO within priority)Relatively common PredeterminedH/W Interrupts, some polling systems Round robinCommon polling BaulkingRemoving items from queues –Special Circumstances SortedDisk access arms movement Random Common In markets, but not computers –Generally, ‘FIFO’ gives least variable delays. ‘Sorted’ gives overall efficiency at cost of variability in delays

81. 81 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Queue Characteristics (2) - Q-Full Possible results of queue full ie all buffers full: –Indeterminate Not good –Crash Better than indeterminate –Lockout input (Also Known As throttling input) Good for VDUs Poor for cyclic processing such as rotating RADAR systems – Drop excess Packet switches drop excess when overloaded Requires techniques to maintain system integrity –Overflow queue from RAM to Disk or other bulk random storage device Intuitively seems OK BUT –Technically complex –NOT recommended for general use –Modern RAM vs disk storage costs work against this approach in most cases

82. 82 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Transaction Arrivals “Input Characteristics” Storage Hopper Queue in a Buffer Pool Behaviour of this area is called “Queue Characteristics” Metering Device “Service Facility” Characteristics here determine the queue size (and variability), and hence Queue Delays of items in the Queue or Buffer Pool or Hopper Conveyer Belt Output Rate On average will not exceed the slower of: a.arrivals; or b.metering rate. Service Facility Characteristics

83. 83 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Service Facility (1) n This is the area where most design work is possible. input characteristics are determined by external issues - –traffic loads and distribution characteristics are determined by the work to be done queuing characteristics may be design issues if you are in control of the software, for example –traffic queuing discipline may be a design parameter, but is usually dictated by the customer’s work or application software ‘Service facility characteristics’ for communications systems are: –the design line speed for output; and –number of output lines. Some factors for consideration...

84. 84 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Service Facility (2) - “Utilisation” n Average Utilisation = (time facility in use) / (time available) or (actual load) / (maximum possible load) eg. Shop with one server. –average time to serve each customer is 3 minutes, and –average of 12 customers per hour server is busy for a total of 36 minutes in the hour, Then utilisation (of the server) = (36) / (60) = 0.6 = 60%

85. 85 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Service Facility (3) - Service Times n Service times may be : –Constanteg Fixed length packet processing Time slices in a time sliced processor or –Variableeg Variable length messages or packets Disk I/O times Constant gives most consistent queue behaviour ‘Variable’ generally considered as random Most are somewhere between these two extremes, that is: most communications servers are smoother than random Treat them as if Random - this is a conservative approach

86. 86 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Service Facility (4) - Number of servers n May be any integer (or whole) number n Communications systems usually have single servers, but multiple server situations are not uncommon. n Consider multi server systems: When higher speed lines are needed, but not available When higher speed interface boxes are needed, but not available (or too expensive), such as gateways, encryptors, format converters; or In the checkout line at supermarkets, banks, and McDonalds.

87. 87 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Which is Better System & Why? A B C Multiple Single Server Queues X Y Z Single Queue, Multiple Servers

88. 88 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management “All Servers Busy” n The formula for “all servers busy” in a multi-server system, and the graphs plotted by the spreadsheet Delays.XLS (in ‘Tools and Toys’ on the web page). (Assumes a random system, FIFO discipline, all servers equally loaded etc) n This function is the heart for all queueing work in this subject. (It is not necessary to remember or evaluate this formula)

89. 89 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Queuing Formulas n The formula ‘all servers busy’ is the heart of many other formulae used to estimate delays, queue sizes, etc. These are quite complex. –They are derived and discussed in Martin - ‘Systems Analysis for Data Transmission’ Chapter 31 Queuing Calculations. n For our approach, pre-plotted graphs are used rather than complex calculations. n n The spreadsheet Delays.XLS can be used to plot the most commonly used graphs. Others are in the handouts from Martin - Chapter 31

90. 90 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Graphs n The main graphs are of the form: Average q size per server See the class work sheets for other graphs. The model “Delays_?.XLS” (where ? is a version number) is an Excel spreadsheet which will calculate and print the three most common multi-server graphs. Reference this file through the ‘Tools and Toys’ area of the web page Utilisation

91. 91 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Some other graphs n The handouts from James Martin contain many other graphs. The main graphs are also available from the tool “Delays.xls” available via the Tools and toys, or under ‘Queueing Graphs’ on the lectures and tutorials page Eg Mean number of items in a queue (waiting and being served) Mean queueing times Effect of different dispatching disciplines Standard deviations of queueing times etc n Some of these will be shown on the OHP projector – but you can look these up for yourself on the references given.

92. 92 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Notes re Graphs n These graphs are based on assumptions – n General Assumptions (but check carefully on each graph): Random arrivals Random Service times All servers equally loaded in a multi server situation FIFO Dispatching. n Most of the graphs are of the same form: X axis is utilisation of the servers, Y axis is the number of items, usually on a ‘per server’ basis

93. 93 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Formulas for single server queues n These formulas apply to single server queues where the: input is random, ie random traffic arrivals service times are random, eg variable length transactions, and queuing discipline is First in-First out. n These formulas should be remembered as this is the most common queuing situation. n Average Queue Size (including the one being processed) = Utilisation / (1 - Utilisation) Low Utilisation indicates small average queue size High utilisation leads to large queue size Regardless of utilisation, –sometimes queue is empty, sometimes quite large –in theory could go to infinite length n Average queuing time (including processing)= Service time * (1 + number of queued items)

94. 94 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Effects of Utilisation & Multi Servers n Single Server Low utilisation (less than 0.2) –queue rarely builds, delays are minimal Medium utilisation (say 0.5) –av queue size, including one being served, = 1 element High utilisation (say 0.8) –average queue size = 4 elements n Multiple servers increases capacity and reduces variability of delays for any particular utilisation multiple servers reduce q size, and variability of delays formulae are frightening, (but surprisingly easy once you get into the style)

95. 95 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Simple Examples n For some mechanism Each action takes 0.05 seconds ie 20 actions per second Load is 15 actions per second Single Server n Find Utilisation, Average Queue Size, and Average Queue delay n Answers Utilisation (15/20 = 0.75) Av queue size (including element being serviced) –from graph (3 elements): by calculation 0.75/0.25=3 elements Av queue delay (including element being serviced) from graph –(4 service times = 4 * 0.05 = 0.2 seconds)

96. 96 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Simple Examples (2) n Now have 2 servers, each capable of 10 actions per second n Answers Find utilisation (15/20) = 0.75 Average queue size (including elements being serviced) =1.6 * 2 3.2 elements Average delay 2.3 service times = 2.3 * 0.1 =0.23 seconds n Summary delay is slightly longer, but variability is less. WHY?

97. 97 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Simple Examples (3) n Now 2 servers each able to handle 20 actions per second n Answers Find utilisation (15/2/20)=0.375 Average queue size 0.5 * 2 = 1 element Average delay 1.2 * (1/20) = 0.06 seconds n Summary Doubling number of high speed servers reduces average delay to one third.

98. 98 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Comparison of Mechanisms n TopicCase 1Case 2Case 3 n Load, actions per second151515 n Number of Servers1 22 fastslowfast n Service time on a server, seconds0.050.10.05 n Total Capacity actions per second202040 n Utilisation0.7500.7500.375 n Average Queue Size33.21 n Average Delay seconds0.20.230.06

99. 99 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management A Useful Formula for link Design. n The normal formulae and graphs for single server queues are adequate for most circumstances where analysis of an existing system is required. n During design work, we often do not know the utilisation until the end of the design, and hence have to design re-iteratively until a suitable solution is found. The following formula is useful in this circumstance. n Note: Assumptions of this derivation: Single server random arrivals FIFO queuing random service times

100. 100 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Derivation of Formula (1) n Let: D = Allowable average delay seconds L = Average Size of Data item (packet, block, etc) bits k = Line speed required to transmit L bits in D secondsbps  k = L/D bits per second n To allow for network congestion and the associated queuing delays: Let: Z = Average Line Loading bps K = Actual Line Speed that will be neededbps p = Utilisation of the line (when running at speed K) = actual/possible = Z/K Average Service Time = L/K seconds (Continued)

101. 101 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Derivation of Formula (2) Average queuing Time = Average Service Time * ( 1 + ( Utilisation / (1- Utilisation ) ) = ( ( L / K ) * ( 1 + ( p / ( 1 - p ) ) ) ) = ( ( L / K ) * ( 1 / (1 - p ) ) ) = ( L / (K ( 1 - p ) ) seconds Actual Line Speed Required K = k * ( 1 / ( 1 - p ) )  K = ( L / D ) * ( 1 / ( 1 - p ) )  K = ( L / D ( 1 - p ) )  K ( 1 - p ) = L / D  K - K p = L / D But p = Z / K  K - K * ( Z / K ) = L / D  K - Z = L / D  K = ( L / D ) +Z bits per second

102. 102 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Derivation of Formula (3) n In narrative: –Without allowing for line errors, the notional line speed required is equal to the sum of the average line loading (bits per second) plus the line speed required to transmit an average block or packet within the required or allowable delay time. n In other words –The notional line speed required is: the line load (in bps) (AKA background load) plus the line speed (in bps) needed to process an average transaction within the desired time, assuming that there is no other traffic

103. 103 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Example usage of this Formula: n Example task Average line loading from all sources Z = 100 bytes per second = 800 bits per second D = Allowable delay is three seconds L = Average block size is 375 bytes = 3000 bits n Required line speed Min. Line Speed Required = ( L / D ) + Z bps = (3000/3) + 800 bps = 1800 bps Do you believe it could be this easy? see next page

104. 104 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Check Formula by Normal Approach. n Previous sheet estimated that 1800 bps was adequate Now that we know the ‘answer’ of 1800 bps, we can check it using normal formula or graphs n Utilisation p = 800/1800 = 0.444 n Average Service time = 3000/1800 seconds = 1.667 seconds n Queuing Delay= Service time * (1 + p/(1-p)) = 1.667 * (1 + 0.444 / (1-0.444)) = 1.667 * (1 + 0.799) = 3 seconds (as is required) (See, delay systems queuing theory is easier than people think it is)

105. 105 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management In Practice n This formula can be applied to a communications design problem, in order to estimate the required minimum line speed. However, as lines and modems are normally usable only at certain discrete speeds (eg 2400, 4800, 9600, 14400, 19200, 28800, 33400, 48000, 64000 bps etc) the designer must use the next higher available speed. 1.First estimate the minimum line speed required using the formula or graphs, or other method 2.Then choose the next higher available speed, and 3.Finally, estimate the average delays inherent in the system by recalculating, using the chosen line speed and estimated loadings.

106. 106 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management CSE4884 Network Design and Management Lecturer: Ken Fletcher Lecture 4 Queueing Theory Part 2 Dispersion of Queueing times Queue Notation Call Centre Considerations Practicalities

107. 107 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Shortcomings of Averages n Previous lectures referred to ‘average’ delay times & queue sizes. n Often need to estimate the time within which 90% (or some other figure) of the traffic will get through the system. –This is usually more meaningful than the ‘average’ or ‘mean’. Delays - seconds Percent of transactions Probability of delays For ‘random’ system with average delay of 1 second Another way to show the same info is “100% less cumulative” which leads to ‘delayed more than x’ eg 37% are delayed more than one second 14% delayed more than two seconds; and 5% delayed more than three seconds Cumulative - ‘delayed x or less’ eg 39% delayed half a second or less 63% delayed one second or less,

108. 108 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Spread or Dispersion of Queuing Times n The spread or dispersion of queuing times is estimated by considering the ‘incomplete gamma function’ n The basic parameter required is ‘standard deviation’ of delays This is significantly affected by: –Number of servers –Variability of times between requests (inter-arrival times) –Variability of Service times –Queuing Discipline (dispatching discipline)

109. 109 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Dispersion of Queuing Times (2) n For the case of: Single server queue (this is important) Random inter arrival times –(exponential or Erlang-1) Random (exponential) service times First-in/first-out dispatching n THEN Standard Deviation of Queuing time S(x) = Mean Service Time * Mean Queue Size = Mean Service Time * (1+(p/(1-p))) ie: The Standard Deviation equals the mean. (This is true for `exponential' or Random traffic only.) Standard deviation for other traffic characteristics is a little more involved...

110. 110 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management ERLANG Distributions 12345678910 123456789 13579 2468 27 38 49 5 16 Distribution is Erlang-2 Distribution is Erlang-5 As the number of channels increases, the inter-event time per output channel approaches a constant value ie Erlang-("infinity") = constant inter-event times ArrivalsOutputs Random, Exponential or Erlang-1

111. 111 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management The Erlang and Gamma Distributions: n ‘Erlang-n’ distribution is a special case of the general GAMMA distribution. The Gamma distribution has a parameter R, calculated as follows: R = (E (x) /s (x) ) 2 where E (x) is the mean response time, and s (x) is the standard deviation of response times If : R is greater than 1 then activity is smoother than random (infinity if the inter-arrival times are constant), R=1 then the activity is random, and R is less than 1, the activity is rougher than random Erlang-n distributions are those cases when R is an integer (This is sometimes known as ‘Erlang’s Constant’) Use Gamma charts or tables for integer R (Erlang-n distributions) and non-integer R (General Gamma distributions) –These charts and tables will be handed out during the lecture The Cumulative graph shown on the earlier OHP slide is the Gamma curve for an Erlang-1 distribution (ie when R=1)

112. 112 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Use of Gamma Tables/Graphs n A very useful approximation of the probability of queues exceeding certain sizes or response times being within certain constraints is given by using using Gamma Graphs or Tables n Steps: a. Estimate the mean response time E (x) b. Estimate the standard deviation of queuing time s (x) c. Select a Gamma distribution with the parameter R = (E (x) /s (x) ) 2 d. Use tables or graphs of the Gamma distribution to solve the problem NOTE:This method is approximate only - but results are usually within 10% in practice. n More accurate alternatives are: Mathematical calculations (very tedious, and probably inappropriate) Simulation (excellent)

113. 113 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Example - Use of Gamma Graphs n Example 1: We have measured the average response time of a real time communications system to be 3 seconds, and the standard deviation to be 1.5 seconds. What percentage of transactions will exceed: a.6 seconds b.9 seconds c.12 seconds n Basic information given in problem statement: E (x) = 3,s (x) = 1.5 n From these, R = (E (x) /s (x) ) 2 = (3/1.5) 2 = 2 2 = 4 Therefore use the R=4 curve on the Gamma graph (in the handouts), (or on the next OHP slide)

114. 114 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Gamma Graph for R=1 & R = 4 n Partial Gamma Graph Time / Average delay (T/E x ) Percent of transactions R=1 R=4

115. 115 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Use of Gamma Graphs, Ex 1(Cont) n For case a. T = 6, T/E (x) = 6/3 = 2 Using the R=4 curve on the Gamma graph, for T/E (x) = 2, the probability (t>T) is about 0.96 –(Tables give 0.9576) Therefore about 1.000-0.96 =4% exceed 6 seconds. Time / Average delay (T/E x ) Percent of transactions

116. 116 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Case a expanded R=1 R=4 Time / Average delay (T/E x ) Percent of transactions

117. 117 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Use of Gamma Graphs, Ex 1(Cont) n For case b. T = 9, T/E (x) = 9/3 = 3 the probability (t>T) is about 0.999 - just below 100% We could say virtually none exceed 9 seconds NOTE: - Tables give 0.9977, therefore about 0.23% exceed 9 seconds Such a figure could not be read from this graph. n For case c. From studying these graphs, none could be said to exceed 12 seconds.

118. 118 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Gamma Graphs and Tables It is very difficult to accurately read the graphs, particularly when the figure of interest is the difference between the readout and 100%. ie A small error in reading the graph gives a large percentage error in the final result. That is why it is better to use the tables. Consider case b above. If the graph had been read as.999, the estimate of t>T would have been over 50% in error.

119. 119 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Use of Gamma Tables, Ex 1 n As a designer, you have to satisfy the following requirements: “The network shall have an average response time within 3 seconds, and 90% of responses within 4 seconds” n This seems reasonable at first sight. Your task is to select an appropriate line speed. To do so requires that you determine the average delay that will be used in the line speed calculations. n This is not easy - as the next slides show.. n For a start, there are actually two requirements stated. average within 3 seconds; and 90% within 4 seconds

120. 120 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Use of Gamma Tables, Ex 1 Try 1 n “A network is to have an average response time within 3 seconds, and 90% of responses within 4 seconds.” n Try #1 - aim to meet both of these requirements exactly: E (x) = 3,s (x) is unknown R = (E (x) /s (x) ) 2 = (3/ s (x) ) 2 –For the 90% limit, T = 4, T/E (x) = 4/3 = 1.33 –Using the 90% probability on the Gamma graph, for T/E (x) = 1.33, approximate value of R = (E (x) /s (x) ) 2 required is between 15 & 20. Therefore (3/ s (x) ) 2 = 20 (using 20 as the R value) s (x) = 0.67 Summary This approach for an average response time of 3 seconds, requires a standard deviation of 0.67 seconds. This is most unusual, if it is even possible in practice.

121. 121 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Gamma Tables, Ex 1, try 2 n “A network is to have an average response time within 3 seconds, and 90% of responses within 4 seconds”. Note the emphasis on ‘within’ n Try #2 Aim for a network with an average response time of something less than 3 seconds, and ensure that 90% are within 4 seconds. (Nobody will complain!) –Let standard deviation equal the response time, as we know that this is the pattern for truly random (exponential) distributions.. –Therefore E (x) = 3 or less, and s (x) = E (x) R = (E (x) /s (x) ) 2 = (1) 2 = 1 –For the 90% limit, T = 4, T/E (x) = 4/ s (x) –Using the 90% probability on the Gamma graph, and curve for R = 1, the approximate value of T/E (x) = 2.3 = 4/ s (x) –Therefore s (x) = 4/2.3 = 1.74, say 1.75 seconds Summary: If we dimension the network for an average response time of 1.75 seconds, with a standard deviation of about 1.75 seconds, we can achieve 90% of transactions completed within 4 seconds, assuming all network response times are truly random.

122. 122 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Gamma Tables, Ex 1, try 3 n Try #3 - Try #2 was workable, but in practice networks and their host computers are usually a little better than truly random. They frequently operate between R=1.2 and R=2 Let us explore this approach, and see what happens if relax the average response time to be used in design work. Doing so may reduce costs. Note that we are making a judgement here that R not greater than 2 is OK. Let us assume R=2. n Assume 2 Seconds average response time. What is the Std Deviation required to meet the requirement of “90% within 4 seconds” ? For this try, E (x) = 2, s (x) = s (x) –Therefore R = (E (x) /s (x) ) 2 = (2/ s (x) ) 2 –For the 90% limit, T = 4, T/E (x) = 4/2 = 2 –Using the 90% probability on the Gamma graph, and for T/E (x) = 2 –the approximate value of R needed is 2, as explained above. –Since R = (E (x) /s (x) ) 2 = (2/ s (x) ) 2 = 2 therefore s (x) = 1.414 seconds n Summary: If we dimension the network for a design average response time of 2 seconds, we have a high probability of meeting the ‘90% within four seconds’ requirement.

123. 123 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Summary of the 3 approaches n In order to meet the requirements of 90% within 4 seconds, and an average time within 3 seconds, we have calculated three answers, and now include a fourth for comparison: Avg Time (Seconds) Std Deviation (Seconds) Erlangs constant R Comments Is it achievable in practice? 1.75 1Yes, but perhaps too pessimistic 21.412Better and more realistic. BE CAREFUL 30.6720Standard deviation is too tight DO NOT USE for network design 30infinityConstant response time is unachievable Networks do not operate this way

124. 124 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Limitations of These Techniques n The techniques used here are effective and adequately accurate for most cases. However: They are approximations only They assume random behaviour ie random arrivals and service times They assume infinite memory to store queues Use these techniques to gain a feeling for the system, and how the system will behave under various loads

125. 125 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Erlang C formula and Call Centres Call centres are widely used, but the queuing and occupancy issues are rarely appreciated. Most organisations do not understand the interaction between staffing levels and customer wait times

126. 126 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Typical Call Centre n Customers Calling for Service Automatic Call Distributor (ACD) PSTN “Trunks” Computer Data base “CALL CENTRE”

127. 127 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Call Centres n The Call Centre has incoming calls from customers/clients a mechanism to accept the call from the customer, and distribute it to available operators (ACD or PABX) operator or ‘agent’ positions, fitted with computers or other resources to help satisfy customers needs (typically computers and network to database servers) n Incoming calls are accepted and queued (as a single queue) until an operator or ‘agent’ is available Thus Call Centres are a single queue with multiple servers

128. 128 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Call Centres Parameters n The significant variables that affect call centre dimensioning include: characteristics of input traffic –variability or randomness of call arrivals –how long the caller is prepared to wait before being served (Often called “Target Wait Time”) characteristics of the service being provided –time taken to service the call, –variability or randomness of service time –time taken between calls for ‘wrap up’ activity, operator rest break etc n The concept of ‘occupied capacity’ applicable to both trunks and operators is important...

129. 129 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Measures of Traffic Loading-“Erlangs” n Key factor is the concept of OCCUPIED CAPACITY eg 2 x 10 minute calls are equivalent to 1 x 20 minute call, as far as `occupation’ is concerned. n Traffic loading measured in ERLANGS - Abbreviation ‘E’ Erlangs of traffic (or Traffic Load) = # Calls per unit time * Avg Holding Time per call eg20 calls in 60 minutes, average holding time = 3 minutes = (20/60) * 3 = 1 Erlang = 1E If all the traffic items neatly stacked end-to-end totally occupied the link for the period considered, then there is one Erlang of Traffic.

130. 130 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Erlang Calculation Examples n 30 calls in 120 minutes, average holding time = 4 minutes = (30 / 120) * 4 = 1 E n 20 calls in 60 minutes, average holding time = 9 minutes = (20 / 60) * 9 = 3 E n 5 calls in 30 minutes, average holding time = 3 minutes = (5 / 30) * 3 = 0.5 E n 4 Erlangs of Traffic is measured over a period of 3 hours. There were 120 calls during the time. What was the average holding time? (6 minutes)

131. 131 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Erlangs and Utilisation n Erlangs are analogous to Utilisation as used in delay systems queuing. The concept of utilisation (as discussed in ‘delay systems’) is related to Erlangs as follows: Utilisation = (load in Erlangs) / (number of servers) or Erlangs of load = Number of servers * Utilisation eg 30% utilisation is EQUAL to: 0.3 Erlangs of load on a single server queue, or 0.6 E on a two-server queue, or 1.2 E on a four-server queue, or 3.0 E on a 10 server queue

132. 132 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Erlang C Formula n A widely used formula for estimating the wait times and other dimensioning factors of this system is the Erlang C formula (shown here for background information only) Let A = Erlangs of Offered Traffic Let M = Number of Servers Then Probability of Delay            A M A M A X A M M X X M M ( ! ).( () ) ( ! )( () ). ! 1 1 1 1 0 1

133. 133 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Erlang C Formula (2)

134. 134 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Erlang C Assumptions and Limitations n Erlang C assumes: –Random (Erlang-1) traffic arrivals –Random (Erlang-1) service times –First-in/first-out (FIFO) queue discipline –All traffic waiting will continue to wait until serviced. n Limitations and practicalities –Above assumptions are somewhat conservative in practice, and lead to an over-capable installation (ie a call centre designed to the formula can usually handle traffic a little better than the formula indicates) –Various proprietary formulas are used by specialist companies These are usually derived from Erlang C, and take into account ‘baulking’ situations where customers discontinue their wait when it is too long

135. 135 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Erlang C Implementations n Call Centre Managers usually want to know –Average wait times –Service levels - percentage of calls answered within target wait times –Agent or operator busy-ness (Agent occupancy - or “Utilisation”) n Calculating using Erlang C formula is difficult and error prone There are many Erlang C calculators on the Internet –These usually give a single answer to a specific set of parameters - which is good, but does not teach the relationships between parameters ErlangC spreadsheet ( available via the subject web page) plots graphs showing relationships over a range of parameter values n Your assignment requires extensive work on ErlangC problems

136. 136 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Queuing Theory in Practice

137. 137 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Practical Queuing Theory (1) n Remember basic ‘single server’ formulas, as single server queues are the most common case. Avg Queue Size = (Util / (1-Util)) items Avg Delay time = (1+qsize) * (service time) These formulas give conservative but reasonably accurate approximation for multiple servers provided that utilisation is less than 50% n Generally don’t plan for more than 30 to 50 per cent utilisation for single server queues. –Check the graphs to see where multiple server queues turn around the ‘knee’ and always stay below that limit. –Drawing a line from the 50% utilisation of a single server to the 100 per cent mark on the X axis gives a conservative upper limit for the multiple server curves.

138. 138 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Practical Queuing Theory (2) n For situations with extremely limited memory: For single server queues, a pragmatic estimate of the minimum size to for the queue pool in a computer system is: –(3 to 5 times average queue size) plus 1 element Rounded up to next whole number. –This gives some 93 to 98 per cent probability of the queue not exceeding the pool size. In all cases, provision must be made for queue size overflowing the pool size. A common technique is to throttle or disable the input. –If the pool size is too small, then frequent overflow conditions (eg throttling) will occur. –If pool is too large, then memory resources are wasted.

139. 139 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Practical Queuing Theory (3) n Call Centres are a case of ‘single queue with multiple servers’ n Use the traditional queuing theory graphs when dealing with communications equipments or single server queues n Use Erlang C formula (spreadsheet and graphs) for single queue with multiple servers n Both sets of formulas can be useful in other domains - eg –Bank queues, Supermarket queues, Ticket sales queues etc –Printing queues –ISP customer port estimates

140. 140 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Practical Queuing Theory (4) n Use these techniques in ‘trade off’ studies. n There are some 30 graphs available in the James Martin texts, which cover many other aspects, such as probability of queues exceeding certain sizes. n Remember that for all practical purposes, doubling the line speed of a busy line (eg 60% utilisation) reduces delays to about 1/3rd of the original, and costs about 30% more n However, doubling the load on a busy line (anything above 35% to 40% utilisation) will probably cause system failure due to overload.

141. 141 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Queues and Psychology n Users expect perceived small tasks to be performed more quickly than perceived larger tasks n Non linear response times cause problems, eg doubling the load of a lightly loaded line usually trebles the response time. n Variability of response times upsets people –Consistent or constant times (even if somewhat poor) are more acceptable than wide variations which are sometimes excellent and sometimes very poor. –Bad response times or unusual delays frustrate users, who often aggravate the problem by making multiple requests for service, or by trying other commands etc.

142. 142 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Queueing Theory Summary n Mathematical work behind the graphs and spreadsheets is well proven for the defined situations (eg random traffic etc). –Review this section, using the tools and toys available from the Internet and the subject web pages to gain an intuitive feeling for network behaviour under load. This is important in understanding user’s reaction to a network. n The strict mathematical approach is not required in practice - using the graphs is accurate enough because: –In practice, the traffic characteristics and loads that are given as the basis for design work are often little better than guesswork. The actual load is often 50% to 100% more than the customer indicated as the design load –Traffic loads change (inevitably increase) faster than anticipated. n Simulation approaches are best for complex systems - and the price of simulation software is decreasing steadily.

143. 143 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management CSE4884 Network Design and Management Lecturer: Ken Fletcher Lecture 5 Network Topologies & Types This aim of this lecture was to get students thinking about why some things are the way they are, rather than simply accepting them without thinking. Along the way we covered some history, and introduced some ideas that may be useful in your future work.

144. 144 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management “What colour is the wind, Daddy”? n That song made me think about the things that we take for granted - the things that we neither challenge nor think about. –What colour is the wind? –What colour is margarine? Why? –How did the concept we know as packet switching arise? Why? What are the alternatives? –Why do we switch telecommunications traffic? What are the alternatives? What factors are necessary to enable switching to occur? Back to basics! Think outside the square ! Let’s challenge some of our basic thoughts about networks (or more accurately - the concepts that we take for granted)

145. 145 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Topologies and Types n Networks have many possible topologies Point to point Styles Dedicated links Inter meshed Bus styles Broadcast Switched Styles Matrix switching Rings and loops Hierarchical and others - eg hybrid topologies n All are based on point-to-point links joining nodes. n Inter-action between nodes & ‘data’ provides design flexibility

146. 146 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Point-to-Point Links The basic building blocks Eg the Lego blocks of networking

147. 147 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Point to Point links n Simplest Concept - one communications circuit joining each pair of node points n Each link independent of others n If nodes can switch traffic, then we have switched network Independent Point-to-Point links A-B and B-C connecting nodes NOTE: Do not assume Node B is a switch. Nodes may be a simple amplifier, signal regenerator or a relay point. Smart nodes may allow for speed or timing differences by use of simple buffering techniques, and may even be format or protocol change points Node A Node B Node C

148. 148 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Dedicated Point-to-point Examples n Dedicated in this sense means “used exclusively” n Examples of dedicated point-to-point links: –Direct connected printer on desktop computer –‘Leased line’ from Melbourne to Sydney (passes through many telephone exchanges, amplifiers, regenerators etc, but is ‘direct-patched’ at each - therefore considered as “point-to-point”) by user –Broadcast is from one point to many on same link eg Radio and TV, subscription ‘newswire services’ (eg Dow Jones ‘ticker tape’) –An electrical “bus” is many points all connected on one line (really a controlled broadcast), and takes many forms - eg Computer motherboard bus, Multi-drop, Polled network, Ethernet –Telephone line from exchange to home is a point-to-point circuit, used mainly for voice grade traffic in the past, many other uses in future –Queuing Theory from Lectures 3 & 4 can be applied to these links when links are dedicated and used for data (including digitised voice)

149. 149 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Dedicated Point-to-Point Links n Traffic may be addressed or unaddressed items –Addressed traffic is switchable - eg packetised data –Unaddressed is not, of itself, switchable eg analogue voice n Record formats, lengths and characteristics not constrained n Line speed (“bandwidth”) is determined by capability of the circuits and termination equipment n Frequently used as the main trunk routes between nodes in switched networks –Message switched –Packet Switched –Circuit switched

150. 150 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Non-Dedicated Point-to-Point Links n Sometimes apparent point-to-point links may involve shared bandwidth, or statistical multiplexing eg: VPN carried over the internet - dedicated bandwidth from end to local node (POPs, etc), but transfers between POPs are statistically multiplexed in a packet switched network Some Telco services are statistically multiplexed (eg those with variable bandwidth charging) Lectures 3 and 4 queueing theory does not apply in these cases as the customer cannot be cognisant of the traffic loading. Queueing theory is used by the Telco to design the network supporting such links, and may be used by customer personnel to assist in understanding network behaviour n Queuing Theory applies to Time Division Multiplexed (TDM) and Frequency Division Multiplexed (FDM) links which give constant link bandwidth

151. 151 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Multiple ‘Parallel’ Point-to-Point n Multiple circuits connecting same two nodes Logically parallel (but may be physically different) eg n Examine each case on its merits eg reliability, cost, availability of circuits and bandwidth Node A Node B 1 2 3 Physically different Example: Link 1 - Primary link - eg wireline Link 2 - Secondary - eg radio Link 3 - Emergency dial up Node A Node B Logically Parallel 3 logically parallel links Dashed lines normally used to indicate some difference in links

152. 152 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Extending Simple Point-to-Point “Broadcast” to disperse widely

153. 153 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Broadcast Links n Data is transmitted by one node and can be read by any connected node n If A broadcasts a transmission, it is read by B, C and D One Dedicated Point-to-Point multi-drop or broadcast link A-B-C-D NOTE: Do not assume any node is a switch Node A Node B Node C Node D

154. 154 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Broadcast Common Implementations n Radio and TV broadcasting (‘A’ is radio transmitter or cable signal source - B, C, D (and others) are receive only) n Broadcast news services eg ‘Newswire services’ (A is the service provider - B C D are receive only) n Polled networks (A is the master controller - B C D are ‘terminals’ that only transmit in response to polling interrogation from master controller ) n Multi-drop networks and Bus networks (A is the master computer - B C D are fundamentally receive only) n Bidding-Contention networks eg Ethernet (All notionally equal, can be prioritised by using differing back-off times) Node A Node B Node C Node D

155. 155 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Broadcast Issues Security is an issue, encryption needed for privacy ‘spoofing’ and impersonation easy Terminals traditionally ‘dumb’, not able to implement good protocols If used for two way traffic: –Used where utilisation of each individual connection is low, and individual line costs are relatively high eg: Automated Teller Machines are usually a polled multi drop network, POS Terminals etc are either dial up (low usage) or polled multi drop terminals (many transactions per day) –Determination of which terminal gains line control or responds is moderately complex (eg polling software) –Bidding Contention systems (eg Ethernet) avoid software complexity by simple back-off protocols if line is busy or collision detected - at the cost of utilisation efficiency.

156. 156 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Switched Networks Inter-action between nodes & ‘data’ provides design flexibility Traffic may be addressed or unaddressed items – Addressed traffic is switchable - eg packetised data or voice – Unaddressed traffic is not, of itself, switchable eg analogue voice

157. 157 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Whoa! - Why do we have Switching? n Think about connecting several nodes without switching: = Terminating Equipment - eg Telephone 4 Nodes all with point-to-point connections to every other node Number of terminations = 12 (by counting) Formula= n nodes * (n-1) connections at each = ( 4 * 3) = 12 Number of links = 6 (by counting) Formula= n nodes * (n-1) connections / 2 = (4 * 3 / 2)= 6 (You can ‘prove’ these formulae by drawing similar diagrams with 3 or 5 nodes each, and then by counting.) A D B C Summary : Very good connectivity, reasonably cheap, no congestive interference between connections Minimal standardisation needed and Each link could be different types (Morse code, analog voice, data etc)

158. 158 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Can unswitched networks grow? n Effect of increasing the number of nodes (see previous formulae) : n Approach becomes unworkable as numbers of nodes increases n Summary: - –good concept for small numbers of nodes/sites, else unworkable –where total inter-connectivity is not needed a hierarchy of sub-groups can be implemented to limit the exponential growth in numbers of connections

159. 159 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Switching at Termination Points n Increase in terminal numbers controlled by switching at the nodes - ie one terminal servicing several links via a simple switch Issues : Cheaper - only one terminal per node (but still has multiple links) Each node can only communicate with one other node at any time - others are prevented from communicating to any active node (“lockout” or “congestion”). C and D on diagram can not establish communications with B and A at this time, nor with each other Standardisation required, as all terminals (and switches) must be able to inter-work Summary: Somewhat cheaper than previous style, but the lockout situation is significant problem Standards and pre-planning necessary, eg all terminals must interface to each other C A D B C

160. 160 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Central Switching Concept n Try a simple central switching concept A D B C Central Switch Issues: Numbers of links and terminals reduced to manageable numbers - thus facilitating networks of tens or hundreds of nodes BUT - the ‘lockout’ situation still applies - thus requiring careful design Lect 3 / 4 covered line utilisation (generally due to multiplexing) Lect 6 covers congestion issues Standardisation of interfaces very important Summary: Somewhat cheaper than previous style, especially with larger numbers of nodes Lockout situation (congestion) becomes more significant with increased numbers of nodes Standards and pre-planning very important

161. 161 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Switching n Switching may be of many styles eg: Single central switching as in previous slide Complex switching ‘cloud’ where a number of local switches connect local areas into ‘regions’ which then interconnect to other regions etc n Some terminology Local Switch Local Terminations “Lines or Tails” One per termination Local Switch Local Terminations “Lines” or “Tails” One per termination Trunks Multiple links or multiplexed data lines inter-connecting local switches

162. 162 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Switched Networks n To switch traffic requires two aspects working together: –Nodes with switching capability –Something (usually Traffic characteristics) that triggers the node to switch traffic n Switching nodes: –Circuit Switches eg Telephone exchanges, PABXs –Packet switches eg Routers, ATM Switches etc –Message Switches - eg Email Servers –Many of the following are switches or have an internal switching aspect to their operation: Gateways; firewall and content filters Auto Voice Response units (“press 1 for sales, 2 for accounts, 3 for..” SOHO ‘multi-function telephone devices - fax, answering machine etc in one unit

163. 163 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Switching Triggers n Many things may trigger switching, eg Data switches: –Packet and message headers (“addressed traffic”) Circuit /switches and Pseudo Circuit Switches –Telephone call dialing tones and pulses, –Pilot messages which set up ‘virtual dedicated circuits’ (circuit switches use traffic preamble (dialing tones/pulses, or ‘pilot messages’) to establish the circuit, then traffic switches “unaddressed”) –SOHO Fax/voice/scanner/printer/ unit uses the presence or absence of fax synchronisation tones to determine if an answered call is voice or fax Miscellaneous Something not directly associated with information content of traffic items –Incoming circuit identification (my home PABX), –Date/time (‘after hours’ switching of telephones in PABX) –Data format etc

164. 164 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Switching Techniques & OSI Layers n Different switching techniques apply at different OSI layers n Switching nodes increase in functionality and complexity as the switching is applied higher in the protocol stack - ie simplest for circuit switching, most complex for message switching 1 2 3 4 5 6 7 Circuit switches - (eg PABXs) Packet switches (eg Routers etc) Message switches (eg Email servers, gateways)

165. 165 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Circuit Switching n Historically –started with manual plug patch switchboards about 1880, –automated telephone exchanges (‘decadic’) from about 1920s –crossbar exchanges introduced 1960s, –computer based programmable exchanges widespread from 1980s n Low complexity and low functionality compared to message switch –Typically applied at Layer 1 May be a physical ‘patch cord’, or electronic –Used for analog voice and dedicated data circuits –Was used for some data circuits in the 1980s n Generally circuit switching is established by some pre-amble to information transfer - eg –dial pulses or tones on PSTN, –pilot message or –external triggering on data circuit switches

166. 166 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Message Switching n Manual message switching started with the Morse Code telegraph, and was developed to an art form by the 1970s HeaderBody of Message - (50 to 10,000 chars)Trailer Header contains: ‘Start of Message’ flag - often “ZCZC” Message Sequence Number Recipients Address Senders Identification Priority or Precedence Date and Time Sent etc end ‘begin text’ flag - usually “BT” Trailer contains: ‘End of Message’ flag – often “NNNN” followed by about 25 characters which punched out all paper tape rows (very obvious to human reader). Body text was not permitted to contain ‘Start of Message’ or ‘End of Message’ flags

167. 167 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management “Torn-Tape” Message Switching By 1975, Messages 50 to 10000 characters long Messages punched into 5 channel paper tape, formatted with a header which, although in paper tape punching, could be easily interpreted by operators (ie human readable) typically used asynchronous 50, 75, 110, 300 and 600 bps lines Punched into paper tape at each node and hand switched to output reader ‘Store and Forward’ (S&F) AKA ‘Send and Forget’ protocols, without acknowledgements (used one-up sequence numbering on messages when sent - receiving node checked sequence and sent ‘service message’ to sending station if messages missing or garbled). Entire message had to be received at a node before re-transmission to next node started. Over-length messages were split in ‘parts’ (each <10000 chars), and sent as separate messages

168. 168 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management “Automated” Message Switching n Electro mechanical switching was used in 1950s - 1960s –These punched the paper tape at each node, but switching was carried out semi-automatically rather than totally manually as in “torn tape”. n By mid 1960s, software driven computer switching was being used. Usually these read the incoming character stream, and switched it out without punching paper tapes n NOTE –The protocols and header formats were still based on a manually driven paper tape concept - consequently the software to cope with this was complex –The fact that the network could be manually switched using paper tape resolved the unreliability issues of the computer based systems - simply have some paper tape readers/punches and enough operators able to read paper tapes

169. 169 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Message Switching Issues Message Headers & operating procedures human oriented (1980s message switches began using protocols oriented to computer based switching) 5 Channel paper tape orientation limited character representations (eg 32 character basic set) Approx 10000 character limitation per message Header formats and protocols geared to high line error rates (message switching was workable with very poor grade lines - as bad as 3 bits in error per 1000 bits transmitted ie BER = 3 per 1000) Excessive delays across multi-hop networks, Protocols required that an entire message be received at a node before being forwarded or switched. A 10,000 character message transmitted at 10 char per second took about 12 minutes per hop just for ‘service time’. Handling and queue delays could easily take delay to 2 hours per hop. A major rethink was needed!

170. 170 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Packet Switching History n In the early 1950s, the idea was raised of messages using ‘machine oriented’ headers and protocols. n By late 1960s, ‘Packet Switching’ was emerging, with concepts of –1000 bit packets to reduce both end to end delays and error recovery overheads –fixed length packets (to reduce software overheads) –automatic breakdown of over-length items to packet sizes –high speeds, even as high as 9600 bps if circuits available –7 and 8 bit characters to allow for full ASCII/EBCDIC char sets –computer oriented headers/protocols, not manually readable –automated detection and recovery of packets with transmission errors (garbles) –packet queued for switching as soon as received ‘error free’ –“Positive acknowledgments” and receipts (ACKs & NAKs) rather than the “Implied acknowledgments” of the ‘send and forget’ style

171. 171 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Packet Switching Concepts n Traffic sources and sinks (Hosts) interface to the network via Packet Assemblers / Disassemblers (PADs) n The network internal arrangements of nodes is of little concern to the hosts. Host A PAD Node Host B PAD The “Network”

172. 172 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Packet Switching Concepts n Records broken into packets at the PAD before transmission n On receipt of a packet, the node checks for errors etc. Nodes switch traffic packets by interpreting the packet header n Each packet is processed and switched independently n At the destination PAD, data is re-assembled into records. 1 2 3 4 5 6 7 PAD A 1 2 3 4 5 6 7 PAD B 1 2 3 4 Node 1 1 2 3 4 Node n

173. 173 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management End to end delays n Message Switching –Consider a 1000 char message at 75 bps Asynchronous –Usually 7.5 bits per char, therefore 10 chars per second –Message time per hop equaled 100 seconds, plus manual switching and re-queuing time (say 10 minutes per hop) –10 hop messages took minimum of 100 minutes end to end n Packet Switching –Packet switch concepts allowed on-forwarding of each packet as soon as possible (with automated switching). End to end delay dropped dramatically –Why? – let’s look at the effect of a nine packet message over five hops

174. 174 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Packets and Hops (1) n The spreadsheet model ‘Packets and Hops’ shows 5 scenarios –First as shown on next slide –Then with first hop slow –Then last hop slow –Then middle hop slow –Then two slow hops animated two slides forward from here n Study the spreadsheet and answer the questions yourself n The general formula for delays over multiple hops is shown on a later slide

175. 175 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Packets and Hops Spreadsheet (final 1) RECEIVING SITE Packets finishing transmission over each hopSENDING SITE Packets completely received H1H2H3H4H5 Packets queued for transmission 0P1P2P3P4P5P6P7P8P9 1P1 P2P3P4P5P6P7P8P9 2P1P2 P3P4P5P6P7P8P9 3P1P2P3 P4P5P6P7P8P9 4P1P2P3P4 P5P6P7P8P9 5P1P2P3P4P5 P6P7P8P9 6P1P2P3P4P5P6 P7P8P9 7P1P2P3P4P5P6P7 P8P9 8P1P2P3P4P5P6P7P8 P9 9P1P2P3P4P5P6P7P8P9 10P1P2P3P4P5P6P7P8P9 11P1P2P3P4P5P6P7P8P9 12P1P2P3P4P5P6P7P8P9 13P1P2P3P4P5P6P7P8P9 14P1P2P3P4P5P6P7P8P9 This is the ‘final’ situation of Scenario 1 as it appears in the spreadsheet. Next 2 slides are an animated version of scenarios 1 and 5 Use ‘slide show’ to view animation

176. 176 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Packets and Hops (animated Scenario 1) RECEIVING SITE Packets finishing transmission over each hopSENDING SITE Packets completely received H1H2H3H4H5 Packets queued for transmission 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 P1 P3 P4P5 P6 P7P8 P9P2 P1P3P4P5P6P7P8P9P2P1 P2P3P4P5P6P7P8P9P2P1 P3P4P5P6P7P8P9P3P2P1 P9P8 P7 P6P5P4 P3P2P1 P9P8P7P6P5P4 P3P2P1 P9 P8P7P6P5 P4P3P2 P1P9P8P7 P6P5P4P3P2 P1 P9P8P7P6P5P4P3P2P1 P4 P3P2 P1 P4P5P6P7P8P9 P5P4P3P2P1P5P6P7P8P9 P6 P5P4 P3 P2P1 P6P7P8P9 P7 P6P5 P4 P3P2 P1 P7 P8P9 P8 P7P6 P5 P4P3 P2P1P8 P9 P8P7P6P5P4P3P2P1P9 Green shaded areas indicate which hops are idle at any time

177. 177 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Packets and Hops (animated Scenario 5) RECEIVING SITE Packets (or portions of a packet) finishing transmission over each hop SENDING SITE Packets completely received H5H4 Queue at H4H3H2 Queue at H2H1 Packets queued for transmission (or being transmitted) 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 P1 P3 P4P5 P6 P7P8 P9P2 P1P3P4P5P6P7P8P9P2P1 P3P4P5P6P7P8P9P2 P1 P1start P3P4P5P6P7P8P9P3P1endP1P2 P4P5 P6 P7P8 P9 P4P2 startP2P1 P3 P5P6P7P8P9P5P1P2 end P1start P2P3P4 Table continues to time slot 24 P6P7P8P9P6 P1endP1 P2P3 start P3P4P5 P7P8P9P7 P1P2P2 startP3 end P3P4P5P6 P8P9 P8P1 P3 P2P2 end P4 start P4P5P6P7 P9 P2P1P3P3 startP4 endP4P5P6P7P8 P2P3P3 endP4P5 startP5P6P1P7P8P9 P3P2P4 startP4P5 endP5P6P1P7P8P9 P3P4 endP4P5P6 startP2P1P6P7P8P9 P3P4P5P5 startP6 endP2P1P6P7P8P9 P4P5P5 endP6P3P2P1P7 startP7P8P9 P4P5P6P6 startP3P2P1P7 endP7P8P9 Green shaded areas indicate which hops are idle at any time

178. 178 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management How long does it take? n Total message transfer time of a multi-packet message over a multi hop network is: –(processing, queueing and service time for all packets of the message) over the ‘slowest’ hop, plus –one packet service time over each other hop In theory, the (queuing time plus service time) for one packet over each other hop should be used, but in practice the service time appears to be more appropriate n See ‘Packets and Hops’ on the ‘Resources’ web page

179. 179 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Digital Switching Networks Summary n Inter-action between nodes & ‘data’ provides design flexibility n Traffic may be switched from place to place across a network n Nodes may be arranged as: –simple star network simplest, links may be homogenous or heterogeneous –hierarchical networks (SNA) links and protocols usually homogenous (ie “Same Type”), failure of a nodal point disables all subordinates –Looped (eg Token Ring, FDDI) two-way ring raises reliability, at cost of software complexity –Intermeshed networks multiple cross links give robustness Careful thought is necessary in planning the addressing structure –Hybrid Networks - multiple types interconnected

180. 180 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Hybrid Networks n Typically Inter-Connected Networks n Usually Heterogenous Hosts (“Heterogenous” = Mixed types) n Mixtures of protocols and link speeds/types n Addressing schemes can be complex –Should follow Internet conventions today n Total software complexity can be enormous n Large scale networks are increasingly inter-connected hybrid style n Treat each sub-network as a separate entity n Design each sub-network according to the appropriate requirements

181. 181 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Terminology Points for Discussion n Can a LAN be other than a broadcast or multi-drop circuit? n What are the inherent differences among: Personal Area Networks - PANs; Local Area Networks - LANs; Campus Area Networks - CANs; Metropolitan Area Networks - MANs; and Wide Area Networks - WANs? n How would you classify a satellite circuit? WHY?

182. 182 Copyright Ken Fletcher 2004 Australian Computer Security Pty Ltd Printed 16-May-15 00:58 Prepared for: Monash University Subj: CSE4884 Network Design & Management Summary n Point to point link is ‘building block’ for all networks n Network flexibility comes from switching capabilities of nodes n Nodes normally switch according to information carried in data n Network performance limited by congestion at nodes & links n Many topologies and switching styles possible n Packet switching grew from Message Switching experience n Overall delay is sum of individual delays n Packet switching allows overlaps of delays n Total delay = complete transaction over slowest link plus one packet delay over each other link