Example Application of Flow Analysis

Guaranteed Flows

Ci Ri Di

CP

Predictable Flows
RP
Best-Effort Flows

FIGURE 4.39

197

DP
CBE

A Multi-Part Flow Specification

4.8.2 Capacity and Service Planning

Capacity and service plans are written descriptions of the network performance
required for the flows described in the flowspec. A capacity plan describes network
performance in terms of capacity only. It is used in conjunction with a one-part
flowspec. A service plan describes network performance in terms of sets of capacity,
delay, and RMA. It is used in conjunction with two-part and multi-part flowspecs.
While a flowspec lists flows and combines their performance requirements,
capacity and service plans describe what may be needed in order to support such
requirements. As we see in the chapter on performance (Chapter 8), there are many
mechanisms we may choose to support performance requirements in the network.

4.9

Example Application of Flow Analysis

We now bring the concepts of flow analysis together for an example network, in this
case a network to support computing and storage management. For this network
project the computing and storage devices already exist in multiple buildings on a
campus. The buildings and devices that will be using this network for computing
and storage management are shown in Figure 4.40.
From the requirements analysis process, we have been able to determine that
there are four types of flows for this network:
Type 1: Flows between high-performance computing devices. There are compute
servers that are the high-performance devices for this network. The first type of flow
consists of traffic flows between these devices. Flows are sometimes (approximately

198

C H A P T E R 4 Flow Analysis

Campus LAN
Compute Server
Building A

Compute Servers (5)

Compute Server
Building B

Compute Server

Main
Engineering
Building

Storage Servers (2)

Building C

External
Access

...
Internet
External
Users

External
Access Server

Off-Site
Data Archival

Storage Servers
FIGURE 4.40

Building and Device Locations for the Example

10% of the time) synchronized between pairs of devices. At other times these
devices may draw data from the local data store of another computing device, from
the storage server at the Main Engineering building, or request a computing or
data management task from a device. Most computing tasks are controlled from
Main Engineering.
Type 2: Data migration from computing to storage at Main Engineering. These flows
may be from each compute server as its task is completed; from the local data store
at each compute server at a specific time; or from the compute server at Main
Engineering at the completion of a combined (multi-server) task.
Type 3: Data migration to external server. Final data sets, or extracts of final data
sets, are pushed from the Main Engineering storage server to a storage server at a
building where external (Internet) access is managed. Data at this external access
server are used to feed other campuses and for remote (off-site) data archival.
Type 4: Data archival and Internet access. These are flows from the external access
server to users on the Internet, as well as flows to off-site archival servers.
These flow types are added to our map, as shown in Figure 4.41.
From discussions with various users of these applications, we learned that flow
usually runs in this order: type 1type 2type 3type 4. For flow type 1, a Main
Engineering compute server may act as a server for the compute servers in Buildings
AC and for getting data from the storage servers in Main Engineering. This
follows a hierarchical clientserver flow model. Compute servers from Buildings

Example Application of Flow Analysis

1
Compute Server

199

Campus LAN

Building A
2

2
1
Compute Server 1
Building B
12
Compute Server

1
Compute Servers (5)
2

Main
Engineering
Building

External
Access

2
1
3
Storage Servers (2)

Building C

...
4

Internet

4
External
Access Server

External
Users

Off-Site
Data Archival

Storage Servers
FIGURE 4.41

The Map with Flow Types Added

AC and Main Engineering may also act as synchronized peers, using a distributedcomputing flow model.
From discussions with engineering users we found that the computing application runs in either batch or interactive mode, from about 10 minutes to several
hours, generating files of sizes ranging from 1 to 2 MB (synchronization or sync
files), 10 to 100 MB (interactive updates), and 100 MB to over 1 GB for final
data sets.
Interactivity for the computing application is needed to steer or direct the
computation. This requires synchronization on the order of HRT (100 ms), and
updates on the order of 1 second. Users expect to have up to two tasks running
concurrently.
For flow type 2, data are stored at the storage servers in Main Engineering.
Data can be from interactive updates, final data sets, and extracts (selected subsets
of the final data set). Data also migrate from local stores at each computer server,
usually every few hours.
For flow type 3, full data sets as well as extracts of the data sets are migrated to
the external access server. Extracts are approximately 80% of the size of a full data
set. Data sets are migrated hourly.
For flow type 4, users from other campuses, via the Internet, access data.
Data sets are archived at an off-site facility. The system is expected to support the
download of a full final data set within a few minutes.

200

C H A P T E R 4 Flow Analysis

Performance Envelope from Requirements Analysis

Characteristics of flow type 1. Flows of type 1 involve the frequent passing of
12 MB sync files with delays on the order of HRT, 10100 MB update files on
the order of 1 second, and final data sets of 500 MB1 GB on the order of minutes
to hours, with up to two tasks running concurrently. From this information we
can estimate a range for capacity performance for these flows. Each of these flows
is multiplied by 2 for concurrency.
Sync files: (1 to 2 MB)(8 b/B)(2 concurrent tasks)/101 s = 160 to 320 Mb/s
Update files: (10 to 100 MB)(8 b/B)(2 concurrent tasks)/1 s = 160 Mb/s to 1.6 Gb/s
Final data sets: (500 to 1000 MB)(8 b/B)(2 concurrent tasks)/102 to 104 s =
800 Kb/s to 160 Mb/s
Characteristics of flow type 2. These flows involve migrating (pushing)
updates, final data sets, and extracts. The delay characteristics of these flows are much
less strict than for the computing function, with delays ranging from 10 to 104 seconds.
Update files: (10 to 100 MB)(8 b/B)/10 to 104 s = 8 Kb/s to 80 Mb/s
Final data sets: Same as for flow type 1
The performance envelope for final data sets, updates, and synchronization files
is shown in Figure 4.42.
106

Data
Migration

Computing Region

104
Final Data
Sets

s
b/

103

File Size (MBytes)

105

102
Updates
101

Sync

b/

100

104 103 102 101 100 10 102

1/Delay (Seconds1)

FIGURE 4.42

The Performance Envelope for the Example

Example Application of Flow Analysis

201

Flow Models
For flow type 1 between compute servers and the Main Engineering storage servers,
flows can follow distributed-computing and hierarchical clientserver computing
flow models, as shown in Figure 4.43.
In the distributed-computing model each device can act as a data source and
sink, and data transfer is synchronized between devices at about 100 ms. In the
hierarchical clientserver model, data sets can flow from the storage server to the
compute servers in Main Engineering, which then pass down to compute servers
in Buildings AC. There is no synchronization for this model.
Flow type 2 consists of data pushes from each compute server to the storage
server in Main Engineering. Each compute server is a data source, while the Main
Engineering storage server is a data sink (Figure 4.44).
For flow type 3, the storage servers in Main Engineering are data sources, and
the external access server is a data sink (Figure 4.45).
For flow type 4 a clientserver flow model exists between external users of the
data, including off-site archival, and the external access server (Figure 4.46).

Flow Type 1: Distributed Computing

Flow Type 1: Hierarchical ClientServer

Compute Server

Compute Server

Building A

Building A

Compute Server

Compute Servers (5)

Compute Server

Building B

Main
Engineering
Building

Building B

Compute Server

Storage Servers (2)

Compute Server

Building C

Building C
All Devices

FIGURE 4.43

Flow Models for Flow Type 1

Compute Servers (5)

Main
Engineering
Building

Storage Servers (2)

202

C H A P T E R 4 Flow Analysis

Flow Type 2: Data Migration

Compute Server
Building A

Compute Servers (5)

Compute Server
Main
Engineering
Building

Building B

Compute Server

Storage Servers (2)

Building C
FIGURE 4.44

Flow Model for Flow Type 2

Flow Type 3: Data Migration

Main
Engineering
Building

External
Access

Storage Servers (2)

External
Access Server

FIGURE 4.45

Flow Model for Flow Type 3

Example Application of Flow Analysis

203

...
External
Access

Internet
External Users

External
Access Server

Off-Site
Data Archival

Storage Servers
FIGURE 4.46

Flow Model for Flow Type 4

Building A
F1

F2

F4

Building B

Main
Engineering
Building

F5

External
Access

F6

Internet

F7
F3
Off-Site
Data Archival

Building C

FIGURE 4.47

A Flow Map for the Example

Flow Map
Figure 4.47 is an example of a flow map that describes flows between buildings.
Note that all devices have been removed from this map. This is often done for larger
networks, as the number of devices on a map can become unwieldy. Also, a flow
aggregation point has been added between Buildings AC and Main Engineering.
This is done to show the aggregated performance requirements at Main Engineering
(flow F4).
For this flow map, flows F1, F2, and F3 have the same performance requirements, consisting of flow types 1 and 2. Flow F4 is an aggregate of flows F1, F2,
and F3 (flow types 1 and 2). Flow F5 consists of flow type 3, and flows F6 and F7
are flows of flow type 4.
Next we combine the performance requirements from each of the flow types
and apply them to flows F1 through F7, as shown in Figure 4.48.

204

C H A P T E R 4 Flow Analysis

Performance Requirements
Flow ID
Capacity (Mb/s)

Delay (ms)

F1: Flow Type 1

Synchronization Files
Update Files
Final Files
Result for Flow Type 1

320

100

1600

1000
105

160
1600

100

F1: Flow Type 2

80

104

Final Files

160

105

Result for Flow Type 2

160

104

Update Files

Result for F1

1760

100

Result for F2

1760

100

Result for F3

1760

100

F4: Flow Type 1

1600

100

F4: Flow Type 2

Update Files

320

104

Final Files

640

105

Result for Flow Type 2

640

104

Result for F4

2240

Result for F5

16

103

Result for F6

80

102

Result for F7

16

103

FIGURE 4.48

100

Performance Requirements for Flows

Conclusions

Building A

205

Profiles:
P1: 1.76 Gb/s, 100 ms
P2: 16 Mb/s, 103 s

P1
2.24 Gb/s,
100 ms

Building B

P1

F4

Main
Engineering
Building

P2

External
Access

F6

Internet

80 Mb/s,
102 s
P2

Building C

P1

Off-Site
Data Archival

FIGURE 4.49

Performance Requirements Added to the Flow Map

Predictable Flows

CP = 1.76 Gb/s
DP = 100 ms

Best-Effort Flows

FIGURE 4.50

C BE = 50 Mb/s

Two-Part Flowspec for Each Flow with Performance Profile P1

When these performance requirements are added to the flow map from
Figure 4.47, we get Figure 4.49. Two performance profiles were generated for
multiple flows: P1 for flows F1, F2, and F3; and P2 for flows F5 and F7.
A two-part flowspec for each flow that has a performance profile of P1 (F1,
F2, and F3) would look like Figure 4.50.

4.10

Conclusions

Flow analysis takes an end-to-end perspective of network performance requirements, combining capacity, delay, and RMA requirements into a specification that
is used as input to the network architecture and design, to evaluate and help select
technologies and diversity strategies for the network. In building the flow specification we use various techniques, including data sources and sinks and flow models,
to identify and determine individual and composite flows as well as critical flows.

206

C H A P T E R 4 Flow Analysis

Flow analysis is the final part of the analysis process. We began this process by
gathering, deriving, managing, and tracking requirements for the network, from
users, applications, devices, and networks that will be part of the planned network. In developing requirements for the network, we considered performance
requirements (in terms of capacity, delay, and RMA) and the many ways to categorize requirements for users, applications, devices, and networks. This information,
along with initial conditions, problem definitions, and goals, was collected in the
requirements specification and mapped out in a requirements map.
Performance requirements, on a per-application basis or grouped by user,
application, device, or network, are added to the directionality, hierarchy, and
diversity of traffic flows to characterize them. Some tools, such as data sources and
sinks, flow models, and flow aggregation points, can be used to help us determine
which flows are important in a network and where flows are likely to occur. You
are encouraged to develop other tools to aid in analyzing flows, or modify those
presented in this book to fit your needs.
While flow analysis is presented here as part of the overall analysis process,
in preparation to architect and design a network, it should be noted that flow
analysis can be performed on any network, regardless of what state it is in. Notice
that throughout the flow analysis process, no network technologies, topologies, or
underlying infrastructures were shown or mentioned. Flow analysis allows us to
separate traffic movement and performance requirements from an existing network,
giving us the freedom to determine what flows should look like when the network
does not restrict movement or performance. If you analyze flows on an existing
network (regardless of whether or not you are developing a new network or
upgrading the existing network), the results of this analysis will indicate if the
existing network needs to be modified to fit the traffic flows.
Now that we have an idea of what to expect of the network in terms of requirements and flows, we are prepared to begin the process of network architecture.

4.11
1.

Exercises

Show flows for each set of devices and applications below. Label each as either
a unidirectional or bidirectional flow.
a. Clientserver application: Downstream (from server to client): 1.2 Mb/s capacity; upstream (from client to server): 15 Kb/s capacity.
b. Streaming video (UDP) from video server to a subscribers PC: 300 Kb/s capacity, 40 ms delay (one-way).

Exercises

c.
d.

207

Downloading pages from the Web: Downstream: 250 Kb/s capacity, 5 second
delay; upstream: 100 Kb/s capacity.
Transaction processing from point-of-sale machine to server: Upstream (from
PoS machine to server): 30 Kb/s capacity, 100 ms round-trip delay; downstream: 50 Kb/s capacity.

2.

Devices can act as both data sources and sinks, depending on the application and
flow. Which of the following devices (for the applications given) are data sinks?
Data sources?
a. A storage device receiving streaming video from a camera
b. A video editing unit, using video from the storage device in (a)
c. A Web server and its clients
d. A storage disk farm

3.

Which flow models apply to each set of flows described below?

a. Users on the Internet accessing the same Web server
b. Forty workstations processing batch jobs overnight, managed by a central
mainframe
c. Email use across the Internet
d. A transaction-processing application, authorizing credit card transactions
between a companys retail stores and its headquarters

4.

For each of the examples in Exercise 3, give the most likely direction(s) for the
flows described by each flow model.

5.

Develop a flow model for real-time/near-real-time flows. How would you characterize the flows for this model? What are likely data sources and sinks? Apply your
model to a videoconferencing application.

6.

You are developing a network for a companys online transaction processing (OLTP)
application (e.g., a retail sales network). Its current system is a mainframe that has
several terminals connected to it, either directly or through a terminal server, as in
Figure 4.51. It is moving to a hierarchical clientserver network, where there will be

Mainframe

User Devices

Data

Terminal Server

...
User Devices

FIGURE 4.51

A Mainframe Environment for an OLTP Application

208

C H A P T E R 4 Flow Analysis

Manager

Database
Server

Database
Server

Database
Server
Data

Data

Data

...

...

...

User Devices

User Devices

User Devices

FIGURE 4.52

A Hierarchical ClientServer Environment for an OLTP Application

multiple regional database servers, each acting in a clientserver fashion and updating each others regions via a database manager, as in Figure 4.52.
a. Show the probable data sources and sinks for both environments.
b. How does migrating from the mainframe environment to the hierarchical client
server environment modify the traffic flows in the network?
c. In what ways does the network environment improve the traffic flows?
d. What are some of the potential trade-offs between the two environmentsfor
example, in security, management, and performance?