1 / 39

Flow Analysis

Flow Analysis. IACT 424 IACT 924 Corporate Network Design and Implementation. Overview. Background Flows Types of Flows Identifying and Developing Flows Flow Models Flow Prioritisation Flow Specification Flowspec algorithm. Background.

Télécharger la présentation

Flow Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Flow Analysis IACT 424 IACT 924 Corporate Network Design and Implementation

  2. Overview • Background • Flows • Types of Flows • Identifying and Developing Flows • Flow Models • Flow Prioritisation • Flow Specification • Flowspec algorithm

  3. Background • Once we have identified the requirements of the network • We can use the requirements map as the basis for where traffic will flow in the network • Flow analysis is • The process of characterising traffic flows • Where they are likely to occur • Levels of performance they will require • Does NOT show every possible flow • Only those that will have the greatest impact

  4. Flows • Sets of network traffic that have common attributes • Traffic may include • Applications • Protocol information • Control information

  5. Flows • Attributes may include • Source/destination addresses • Types of information • Directionality • Other end-to-end information

  6. Flows • Flows are end-to-end entities that can be associated with • Applications • Device or network • End user • Flows combine requirements with location information to show where performance and services are required

  7. Types of Flows • Individual • Flow for a single session of an application • Basic unit of flow used • May be considered individually or added to become composite flows • When individual flows have a guaranteed requirement the requirements remain with THAT flow

  8. Types of Flows • Composite • Combination of requirements from multiple apps or individual flows that share some commonality • Performance requirements for individual and composite flows are determined through development of a flow specification

  9. Critical flows • Some flows are more important than others • Higher performance • Strict requirements • Important users/applications/devices • We need to prioritise flows and determine critical flows

  10. Identifying and Developing Flows • Can usually be identified and developed from the requirements specification • We should have • Set of network requirements • Mappings of application and/or device locations

  11. Identifying and Developing Flows • To identify and develop flows • Identify applications/devices that will generate/terminate traffic flows • Choose applications and devices to focus on (from prioritisation) • Use requirements spec and map to determine where flows will go • Flow models discussed later

  12. Identifying and Developing Flows • From an application perspective flows can be identified by • Focussing on a particular • Application • Application group • Device • Function (video conferencing etc) • Developing a profile • Common or selected applications • Choosing the top N (3,5,10 etc) to be applied across the network

  13. Identify Flows, Flow requirements and locations Determine where Sources and Sinks are located Apply flow models where needed Combine performance requirements for flows into flow specifications

  14. Data Sources and Sinks Tools to provide directionality to flows Data sources generate Data sinks terminate

  15. Data Sources and Sinks • Almost all devices on a network will act as data sources and sinks

  16. Data Sources and Sinks • Typical data sources • Devices that do a lot of computing or processing • Devices that generate a large amount of data • Servers, mainframes, parallel systems, clusters • Specialised devices • Cameras, video production, application servers, medical instruments

  17. Data Sources and Sinks • Typical data sinks • Data storage or archival devices • Devices that manipulate or display large amounts of data

  18. Flow Models • Groups of flows that exhibit specific, consistent behaviour characteristics • Primary characteristics are • Directionality • Preference of a flow to have more requirements in one direction • Hierarchy & Interconnectivity • Where flows combine • Where they can be grouped • Flows between peers • Devices at same level of hierarchy • Identify critical flows

  19. Flow Models • Some types of flow models • Peer-to-peer • Client server • Hierarchical client-server • Distributed computing

  20. Flow Models: Peer-to-peer • Users and applications fairly consistent in their flow behaviour throughout network • Act at the same level in hierarchy • Cannot distinguish between flows • All flows are critical OR • No flows are critical

  21. Flow Models: Peer-to-peer • Flows are equivalent • Can be described by a single specification/profile • Examples • Early Internet (FTP, Telnet etc) • File sharing systems • Use when you do not have any other information about flows

  22. Flow Models: Client-server • Currently the most generally applicable model • Has both directionality and hierarchy • Flows are asymmetric • Focused towards the client • Therefore • Server acts as a data source • Client acts as a data sink

  23. Flow Models: Client-server • Predominant flows are from the server therefore these are the critical flows • Examples • E-commerce • Video editing • Web applications

  24. Flow Models: Hierarchical Client-server • Layers or tiers are added to the client-server flow model • Characteristics of client-server with multiple layers between servers • Additional flows from a server to support servers • Servers may act as data sources or sinks or both

  25. Flow Models: Hierarchical Client-server • Indicated when • Multiple applications work together and share information to accomplish a task • Multiple client-server applications are managed by a higher level application

  26. Flow Models: Hierarchical Client-server • Critical flows are dependant upon application behaviour • Inherently client-server • Servers supporting multiple sessions • Client-server flows may be the only critical ones • Servers communicate with each other • to update common databases • Share information between servers • Server-server flows may also be critical • Examples • Replication of web servers • Scientific visualisation simulations

  27. Flow Models: Distributed Computing • Characteristics • Can have the inverse characteristics of client server • Can be a hybrid of peer-to-peer and client-server characteristics

  28. Flow Models: Distributed Computing • Distinctions can be made based upon • Relationship between task manager and computing devices • What the task is • Close coupling between devices  peer-to-peer flows • Loose coupling  client-server • May have “clusters” • Tasks can have • Coarse granularity  each task is assigned to a computing devices • Fine granularity  task is subdivided between several devices

  29. Flow Models: Distributed Computing • This type of flow model may have the most inflexible requirements • Devices may halt while waiting for information from neighbour devices

  30. Flow Prioritisation • Ranking of flows based upon their importance • Business objectives and impact of flow on customers business • Political objectives • One or more performance requirements of the flow • Security requirements for each flow • Number of users, applications and/or devices served by a flow • Need to prioritise flows to determine which flows get resources first

  31. Flow Prioritisation: Example • Flow information

  32. Flow Prioritisation: Example • Prioritisation by number of users

  33. Flow Prioritisation: Example • Prioritisation by reliability

  34. Flow Specification • Results of identifying, defining and describing flows are combined into a flow specification (flowspec) • Lists flows and their requirements • Describe flows • Best effort, predictable and guaranteed requirements • Combines performance requirements for composite flows • Can also be used to combine requirements for all flows in a section

  35. Flow Specification • Three types • One part (unitary) • All flows are best effort • Two part • Contains flows that have predictable requirements • May contain best-effort flows • Multi part • Flows that have guaranteed requirements • May contain predictable and best-effort

  36. Flowspec algorithm • A mechanism for combining performance requirements for flows to give optimal composite performance • Applies the following rules • Best effort flows only have capacity requirements  only use capacities in best effort calculations • Predictable flows use all available performance requirements  combine requirements for each characteristic to maximise overall performance • Guaranteed requirement flows need each individual requirement listed

  37. Flowspec algorithm • For one part flowspecs • Capacities of flows are combined

  38. Flowspec algorithm • For two part flowspecs • Capacities of flows are combined • Predictable capacities, delays and RMA are added • Goal is to maximise each requirement • Cp= capcity required for predictable flows • Dp= minimum delay requirement • Rp= maximum RMA requirement

  39. Flowspec algorithm • For multi part flowspecs • As for two part • Guaranteed requirements are added • Keep them individual Ci Ri Di

More Related