Chapter Two

Analyzing Technical Goals and

Tradeoffs
Technical Goals
 Scalability
 Availability
 Performance
 Security
 Manageability
 Usability
 Adaptability
 Affordability
 Scalability
 Scalability refers to how much growth a
network design must support.
 For many enterprise network design
customers, scalability is a primary goal.
 Many large companies add users, applications,
additional sites, and external network
connections at a rapid rate.
 The network design you propose to a customer
should be able to adapt to increases in network
usage and scope

3
 Scalability
 Some technologies are more scalable
 Flat network designs, for example, don’t scale well
 Try to learn
 Number of sites to be added
 How extensive will the networks be at each new
site
 How many users will be added
 How many more servers will be added
 Availability
 Availability can be expressed as a percent
uptime per year, month, week, day, or hour,
compared to the total time in that period
 For example:
 24/7 operation
 Network is up for 165 hours in the 168-hour week
 Availability is 98.21%
 Different applications may require different
levels
 Some enterprises may want 99.999% or
“Five Nines” availability
Availability Downtime in Minutes

Per Hour Per Day Per Week Per Year

99.999% .0006 .01 .10 5
99.98% .012 .29 2 105
99.95% .03 .72 5 263
99.90% .06 1.44 10 526
99.70% .18 4.32 30 1577
1-.99999=.00001, .00001*60=.0006min or .036 sec
 Disaster Recovery
 Most large institutions have recognized the need for a plan to
sustain business and technical operations after natural
disasters
 Also, some large enterprises must plan how to recover from
satellite outages.
 Unfortunately, institutions have also found the need to specify
a recovery plan for unnatural disasters, such as bombs,
terrorist attacks, riots, or hostage situations.
 A disaster recovery plan includes a process for keeping data
backed up in one or more places that are unlikely to be hit by
disaster, and a process for switching to backup technologies if
the main technologies are affected by a disaster.

7
99.999% Availability May Require Triple
Redundancy

ISP 1 ISP 2 ISP 3

Enterprise

Disaster Recovery – includes planning, backup, testing

 Availability
 Availability can also be expressed as a
mean time between failure (MTBF) and
mean time to repair (MTTR)
 Availability = MTBF/(MTBF + MTTR)
 For example:
 The network should not fail more than once every
4,000 hours (166.67 days) and it should be fixed
within one hour
 4,000/(4000 +1) = 99.975 or 99.98% availability
 Performance
 Analyzing a customer’s network performance goals
is tightly tied to analyzing the existing network
 Analyzing the existing network can help you
determine what changes need to be made to meet
performance goals.
 Network performance goals are also tightly linked to
scalability goals.
 You should gain an understanding of plans for
network growth before analyzing performance goals
Network Performance
 Common performance factors include
 Bandwidth
 Throughput
 Bandwidth utilization
 Offered load
 Accuracy
 Efficiency
 Delay (latency) and delay variation
 Response time
Network Performance Definitions
 Capacity (bandwidth): The data-carrying capability of a
circuit or network, usually measured in bits per second
(bps)
 Utilization: The percent of total available capacity in use
 Optimum utilization: Maximum average utilization
before the network is considered saturated
 Throughput: Quantity of error-free data successfully
transferred between nodes per unit of time, usually
seconds
 Offered load: Sum of all the data all network nodes
have ready to send at a particular time

12
Network Performance Definitions
 Accuracy: The amount of useful traffic that is correctly
transmitted, relative to total traffic
 Efficiency: An analysis of how much effort is required to
produce a certain amount of data throughput
 Delay (latency): Time between a frame being ready for
transmission from a node and delivery of the frame
elsewhere in the network
 Delay variation: The amount of time average delay
varies
 Response time: The amount of time between a request
for some network service and a response to the request

13
Bandwidth Vs. Throughput
 Bandwidth and throughput are not the
samething
 Bandwidth is the data carrying capacity of
a circuit
 Usually specified in bits per second
 Throughput is the quantity of error free
data transmitted per unit of time
 Measured in bps, Bps, or packets per second (pps)
Factors that Affect Throughput
 The size of packets
 Inter-frame gaps between packets
 Client speed (CPU, memory, and HD access
speeds)
 Server speed (CPU, memory, and HD access
speeds)
 Network design
 Protocols
 Distance
 Errors
 etc., etc., etc.
Throughput Vs. Goodput
 You need to decide what you mean by
throughput
 Are you referring to bytes per second,
regardless of whether the bytes are user
data bytes or packet header bytes
 Or are you concerned with application-layer
throughput of user bytes, sometimes called
“goodput”
 In that case, you have to consider that bandwidth is
being “wasted” by the headers in every packet
Performance (continued)
 Efficiency
 How much overhead is required to deliver an
amount of data?
 How large can packets be?
 Larger better for efficiency (and goodput)
 But too large means too much data is lost if a packet
is damaged
 How many packets can be sent in one bunch without
an acknowledgment?
Efficiency
Small Frames (Less Efficient)

Large Frames (More Efficient)

Delay from the User’s Point of View

 Response Time
 A function of the
application and the
equipment the
application is
running on, not just
the network
 Most users expect
to see something
on the screen in
100 to 200
milliseconds
 Application Layer Throughput
 Most end users are concerned about the
throughput for applications.
 Marketing materials from some networking
vendors refer to application layer throughput as
goodput .
 Calling it goodput sheds light on the fact that it
is a measurement of good and relevant
application layer data transmitted per unit of
time.

20
 Applications Throughput Constraints
 You need to work with your customer to identify
throughput requirements for all applications
that can benefit from maximized application
layer throughput,
 Also, explain to your customer the factors that
constrain application layer throughput, which
include the followings:

21
Applications Throughput Constraints

 End-to-end error rates

 Protocol functions, such as handshaking,
windows, and acknowledgments
 Protocol parameters, such as frame size and
retransmission timers
 Lost packets at internetworking devices

22
 Applications Throughput Constraints
 Workstation and server performance factors:
 Disk-access speed
 Disk-caching size
 Device driver performance
 Computer bus performance
 Processor (CPU) performance
 Memory performance (access time for real and virtual
memory)
 Operating system inefficiencies
 Application inefficiencies or bugs

23
 Delay from the Engineer’s Point of View

 Propagation delay
 A signal travels in a cable at about 2/3 the
speed of light in a vacuum
 Transmission delay (also known as
serialization delay)
 Time to put digital data onto a transmission line
 For example, it takes about 0.0053 ms to output a
1024 byte packet on a 1544 Mbps T1 line
 Packet-switching delay
 Queuing delay
 Packet-switching delay
 Packet-switching delay can be quite small on high-
end switches, in the 5- to 20-microsecond range for
64-byte Ethernet frames.
 Routers tend to introduce more latency than
switches.
 The amount of latency that a router causes for
packet switching depends on many variables,
including:
 router architecture,
 configuration, and
 software features that optimize the forwarding of packets.

25
 Routers and Switches delay
 A router has a more complicated job than a Layer 2 switch.
 When a packet comes into a router, the following would
happen:
 The router checks its routing table,
 Decides which interface should send the packet, and
 Encapsulates the packet with the correct data link layer header
and trailer.
 Routing vendors, such as Cisco, have advanced caching
mechanisms so that a frame destined for a known
destination can receive its new encapsulation quickly without
requiring the CPU to do any table lookup or other processing.
These mechanisms minimize packet-switching delay

26
Queuing Delay and Bandwidth Utilization

15
A verage Q ueue D epth

12
9
6
3
0
0.5 0.6 0.7 0.8 0.9 1
Average Utilization

 Number of packets in a queue increases exponentially as

utilization increases
Example Queue depth= utilization/(1-utilization)

 A packet switch has 5 users, each offering

packets at a rate of 10 packets per second
 The average length of the packets is 1,024
bits
 The packet switch needs to transmit this data
over a 56-Kbps WAN circuit
 Load = 5 x 10 x 1,024 = 51,200 bps
 Utilization = 51,200/56,000 = 91.4%
 Average number of packets in queue =U/(1-U)
(0.914)/(1-0.914) = 10.63 packets
Delay Variation

 The amount of time average delay

varies
 Also known as jitter
 Voice, video, and audio are
intolerant of delay variation
 So forget everything we said
about maximizing packet sizes
 There are always tradeoffs
 Efficiency for high-volume applications
versus low and non-varying delay for
multimedia Delay variation should be 1or 2% of the delay
Delay=40ms, DV= 0.4 or 0.8 ms
Security

 Focus on requirements first

 Detailed security planning later (Chapter 8)
 Identify network assets
 Including their value and the expected cost
associated with losing them due to a security
problem
 Analyze security risks
Network Assets

 Hardware
 Software
 Applications
 Data
 Intellectual property
 Trade secrets
 Company’s reputation
Security Risks

 Hacked network devices

 Data can be intercepted, analyzed, altered, or
deleted
 User passwords can be compromised
 Device configurations can be changed
 Reconnaissance attacks (gather network info/ discover
possible access).

 Denial-of-service attacks (target the availability of a

network by flooding it with random traffic).
Manageability

 Performance management :
Analyzing traffic and applications for optimization.

 Fault management:
Detecting, isolating & correcting problems.

 Configuration management:
Controlling, operating, identifying and collecting data from managed devices.

 Security management:
Monitoring and testing security and protection policies.

 Accounting management:
Accounting of network usage to allocate costs to network users.
Usability

 Usability: the ease of use with which network

users can access the network and services
 Networks should make users’ jobs easier
 Some design decisions will have a negative
affect on usability:
 Strict security, for example
Adaptability

 Avoid incorporating any design elements

that would make it hard to implement new
technologies in the future
 Change can come in the form of new
protocols, new business practices, new
fiscal goals, new legislation
 A flexible design can adapt to changing
traffic patterns and Quality of Service
(QoS) requirements
Affordability
 A network should carry the maximum
amount of traffic possible for a given
financial cost
 Affordability is especially important in
campus network designs (low cost is often more
important than availability and performance).

 WANs are expected to cost more, but

costs can be reduced with the proper use
of technology (Availability is more important than low cost)
 Cost of hiring, training and maintaining personnel to operate & manage
the network.
 Network Applications
Technical Requirements

Name of Cost of Acceptable Acceptable Throughput Delay Must be Delay

Application Downtime MTBF MTTR Goal Less Than: Variation
Must be Less
Than:

email low 200hr 1hr 80% 100ms 1or 2% of delay

Making Tradeoffs

 Scalability 20
 Availability 30
 Network performance 15
 Security 5
 Manageability 5
 Usability 5
 Adaptability 5
 Affordability 15
Total (must add up to 100) 100
 Chapter Two: Analyzing Technical Goals and Tradeoffs
Technical Goals Checklist
• I have documented the customer’s plans for expanding the number of sites, users, and servers for the next year
• and next two years.
• The customer has told me about any plans to migrate departmental servers to server farms or intranets.
• The customer has told me about any plans to integrate System Network Architecture SNA or other mainframes
into the multiprotocol internetwork.
• The customer has told me about any plans to implement an extranet to communicate with partners or other
companies.
• I have documented a goal for network availability in percent uptime and/or MTBF and MTTR.
• I have documented any goals for maximum average network utilization.
• I have documented goals for network throughput.
• I have documented goals for PPS throughput of internetworking devices.
• I have documented goals for accuracy and acceptable BERs.
• I have discussed with the customer the importance of using large frame sizes to maximize efficiency.
• I have discussed with the customer the tradeoffs associated with large frame sizes and serialization delay.
• I have identified any applications that have a more restrictive response-time requirement than the industry
standard of less than 100 ms.
• I have discussed network security risks and requirements with the customer.
• I have gathered manageability requirements, including goals for performance, fault, configuration, security,
and accounting management.
• Working with my customer, I have developed a list of network design goals, including both business and
technical goals. The list starts with one overall goal and includes the rest of the goals in priority order.
Critical goals are marked as such.
• I have updated the Network Applications chart to include the technical application goals shown in
Table 2–3: Network Applications Technical Requirements
Summary

 Continue to use a systematic, top-down

approach
 Don’t select products until you understand
goals for scalability, availability, performance,
security, manageability, usability, adaptability,
and affordability
 Tradeoffs are almost always necessary