Transcript Introduction

CSE 550
Computer Network Design
Dr. Mohammed H. Sqalli
COE, KFUPM
Spring 2007 (Term 062)
Outline
 Characterizing the Existing Internetwork
 Sniffing Network Traffic
 Characterizing Network Traffic
CSE-550-T062
Lecture Notes - 4
2
Characterizing the
Existing Internetwork
Introduction
 Develop an understanding of the existing network’s
structure, uses, and behavior
→ Determine whether a customer’s design goals are
realistic
 Identify performance problems
 Help the designer select solutions to solve these
problems
 Develop a baseline for future measurements of
performance
 Successful network design (for existing networks)
 Ensure interoperability between existing and
anticipated networks
CSE-550-T062
Lecture Notes - 4
4
Characterizing the Existing
Internetwork - Outline  Characterizing the Network Infrastructure
 Checking the Health of the Existing Internetwork
 Tools for Characterizing the Existing Internetwork
 Network Health Checklist
CSE-550-T062
Lecture Notes - 4
5
Characterizing the Network
Infrastructure
 Develop a set of network maps
 Learn the location of major:
 Internetworking devices
 Network Segments
 Document names and addresses of major devices
and segments
 Identify any standard methods for addressing and
naming
 Document the types and lengths of physical cabling
 Investigate architectural and environmental
constraints (e.g., cement walls for wireless
networks)
CSE-550-T062
Lecture Notes - 4
6
Network Infrastructure
- Develop a Network Map  Location of major hosts, interconnections devices,
and network segments
 Data on the performance characteristics of network
segments
 Get insight into:


Where users are concentrated
Level of traffic a network design must support
 Goal: obtain a map or maps of existing network
 Some customers may have maps of the new network
design

Be careful of any assumptions that do not match the
business and technical requirements
CSE-550-T062
Lecture Notes - 4
7
Network Infrastructure
- Develop a Network Map  Tools for developing network maps:


A network map may not exist for some companies - “Firefighting” mode
Network-diagramming tools:


HPOpenview, IBM’s Tivoli, CiscoWorks, Whatsup, etc.
Microsoft Visio, etc.
 Large Internetworks


Develop many maps, one for each location
Top-Down method:



Maps that show high-level information, e.g., WAN
More precise maps, e.g., buildings, floors, rooms, devices, etc.
Top-Down approach based on OSI model

CSE-550-T062
Logical map of applications and services (e.g., web), then a
map for network services (e.g., DHCP), then a map for layer-3
topology (e.g., OSPF), and then one that shows information
about data link layer links and devices (e.g., STP, VLANs)
Lecture Notes - 4
8
Network Infrastructure
- Develop a Network Map  Show web caching servers on network maps
because they can affect traffic flow
 Logical architecture or topology



Topology: e.g., hierarchical vs. flat
Methods for connecting devices: e.g., start, ring, etc.
Look for what may hinder scalability (e.g., flat
topology)
 Physical topology
 Modular Block Diagram
 Depicts the major functions of the network, in a
modular fashion
CSE-550-T062
Lecture Notes - 4
9
Example - Network Diagram for an
Electronics Manufacturing Company
CSE-550-T062
Lecture Notes - 4
10
Example Modularized Network Topology
CSE-550-T062
Lecture Notes - 4
11
Network Infrastructure
- Network Addressing and Naming  Include the names of major sites, routers, network segments,
and servers in the network map
 Document any standard strategy used by your customer for
naming network elements:
 Names assignment:



Airport codes for sites
Alias suffix, e.g., rtr for router
Naming services: DNS or WINS

Document servers location and configuration info
 Investigate network layer addressing schemes:




Limitations: e.g., use of unregistered IP addresses
Use of IP subnet masking
Use of route summarization (supernetting)
Some routing protocols do not support: classless
addressing, VLSM, or discontiguous subnets
CSE-550-T062
Lecture Notes - 4
12
Example - A Discontibuous Subnet
CSE-550-T062
Lecture Notes - 4
13
Network Infrastructure
- Characterizing Wiring and Media  Document cabling design and wiring of the existing
network
 Assess how well equipment and cables are labeled
 Network diagram should include:





Connections between buildings
Cable distances
Location of wiring closets, etc.
Information about vertical and horizontal wiring
Number of pairs of wires and the type of wiring (or
wireless technology) is use
 Ask the client for a copy of certification tests
 Cables improperly installed → difficult to meet
availability goals
CSE-550-T062
Lecture Notes - 4
14
Example - Campus Network Wiring
CSE-550-T062
Lecture Notes - 4
15
Chart - Building Wiring
CSE-550-T062
Lecture Notes - 4
16
Network Infrastructure
- Architectural and Environmental Constraints  Check for cabling that runs near places that could
damage or break cables
 Check any legal right-of-way issues before cabling
is put in place
 Pay attention to architectural issues that could
affect feasibility of implementing your network design

Sufficient support exists, such as AC, power, sufficient
space for cabling conduits, patch panels, etc.
 Wireless installation
 Wireless site survey: confirms signal propagation,
strength, and accuracy in different locations
 Placement of wireless access points
CSE-550-T062
Lecture Notes - 4
17
Check the Health of the Existing
Internetwork
 In particular, analyze segments that will
interoperate the most with the new network
design (mainly, backbone networks)
 Develop a baseline of network performance
to:



Demonstrate how much better the new
internetwork performs
Prove that your new design has not made
performance worse
Identify which protocols are really running on
the network
CSE-550-T062
Lecture Notes - 4
18
Health of the Existing Internetwork
- Develop a Baseline of Network Performance  Allocate many days for baseline analysis
(measurements) if you want the baseline to
be accurate
 Find a typical time period to do the analysis,
e.g., during periods of normal traffic load
 Use your understanding of the customer’s
technical and business goals to be more
efficient in developing the baseline
CSE-550-T062
Lecture Notes - 4
19
Health of the Existing Internetwork
- Analyze Network Availability  Gather statistics on the MTBF, and MTTR for the
internetwork as a whole, and for major segments
 Compare this to information gathered about MTBF
and MTTR goals
 Document the availability characteristics of the
current network
CSE-550-T062
Lecture Notes - 4
20
Health of the Existing Internetwork
- Analyze Network Utilization  Different tools use different averaging windows for
computing network utilization
 Using a long interval reduces the amount of data
to be analyzed, but granularity is sacrificed
CSE-550-T062
Lecture Notes - 4
21
Health of the Existing Internetwork
- Analyze Network Utilization  For troubleshooting, a small interval helps




recognize peaks caused by problems such as
broadcast storms
For performance analysis and baselining purposes,
use an interval of 1 to 5 minutes
For long-term load analysis, to determine peak
hours, days, and months, set the interval to 10
minutes
Better to use smaller intervals when collecting data
to develop a baseline (can be summarized later)
Measure utilization from broadcast traffic vs. unicast
traffic, and by each major protocol, e.g., use RMON
CSE-550-T062
Lecture Notes - 4
22
Health of the Existing Internetwork
- Analyze Network Accuracy  For WAN connections


Use BER tester (BERT) on serial lines
Check routers for errors on their serial interfaces
 In packet-switched networks




Measure frame errors (frames with bad CRC)
Use protocol analyzers to check the CRC on received frames
Use a protocol analyzer that includes an expert system to help
identify quickly upper-layer problems
Measure lost packets (e.g., ping, packets dropped by routers)
 In Switched Ethernet Networks




Check for collisions: should be < 0.1% of frames
Check that there are no late collisions
Check the autonegotiation of speed
Check the autonegotiation of half vs. full duplex
CSE-550-T062
Lecture Notes - 4
23
Health of the Existing Internetwork
- Analyze Network Efficiency  Efficiency can be improved
by:


Changing frame and
receive window sizes on
clients and servers
Increasing the MTU on
router interfaces
 Use protocol analyzers to
examine the current frame
sizes on the network
 Frame size if often bimodal
(document the mean and
standard deviation)
CSE-550-T062
Lecture Notes - 4
24
Health of the Existing Internetwork
- Analyze Delay and Response Time  Response time can be measured in many ways:
Ping: measure the RTT and RTT variance
 Protocol analyzer: measure amount of time between
frames
 Run some representative applications, e.g., e-mail,
uploading a file, downloading a web page
 Test the response time of network-service protocols such as
DNS queries, DHCP requests for an IP address, etc.
 Measure how much time a workstation takes to boot
 Measure response times when the network is experiencing
problems or change, e.g., while routing protocols are
converging

CSE-550-T062
Lecture Notes - 4
25
Health of the Existing Internetwork
- Check Status of Major Devices  Determine for each major device (e.g., router,
switch, firewall):




How busy the device is (CPU utilization)
How many packets it has processed
How many packets it has dropped
Status of buffers and queues
 You may use commands on the device
 You can also use SNMP with the standard
MIB II and vendors’ private MIB extensions
CSE-550-T062
Lecture Notes - 4
26
Tools for Characterizing the Existing
Internetwork
 Protocol analyzers (e.g., Ethereal): captures
traffic, decodes the protocols in packets, and
provides statistics to characterize load,
errors, and response time
 Network monitoring and management tools
(e.g., MRTG)
 Remote monitoring tools (e.g., RMON)
 Cisco Tools (e.g., CDP)
CSE-550-T062
Lecture Notes - 4
27
Organizations - For More Info
 IETF Internet Protocol Performance Metrics
(IPPM)
 The Cooperative Association for Internet Data
Analysis (CAIDA)
 The National Laboratory for Applied Network
Research (NLANR)
CSE-550-T062
Lecture Notes - 4
28
Network Health Checklist
CSE-550-T062
Lecture Notes - 4
29
Network Health Checklist
CSE-550-T062
Lecture Notes - 4
30
Sniffing Network Traffic
Sniffing Network Traffic
 By looking at what is going on inside the network
wire - called “sniffing”
 By analyzing how the network is being used -
looking at application use
 We do this to better understand how the network
resource, bandwidth, is being used and how its use
impacts the network design
 By capturing traffic you can really see how your
network is performing
CSE-550-T062
Lecture Notes - 4
32
Sniffing Network Traffic
 There are several ways to collect data to
determine network traffic
 One way is to look inside the wire - otherwise
known as “sniffing” the network traffic
 Lets look at how Ethereal sniffer tool does
this as an example
CSE-550-T062
Lecture Notes - 4
33
Sniffing Network Traffic
Analyze
Optimize
CSE-550-T062
Predict
Lecture Notes - 4
34
Characterizing Services
 Traffic Characterization



What kind of traffic is generated?
How often is it generated?
What is the relative impact on the network?
 Method for Characterizing a Service



Use a network capturing and analysis tool
Capture the appropriate traffic
Identify each frame in the capture
CSE-550-T062
Lecture Notes - 4
35
Frame Types
CSE-550-T062
Broadcast
Deliver to all hosts
Multicast
Deliver to registered members
Directed
Deliver to specified address
Lecture Notes - 4
36
Example - Ethereal
 Free software (www.ethereal.com)
 Network packet analyzer
 Tries to capture network packets and tries to display
that packet data as detailed as possible
 Some intended purposes:
 Collect network statistics
 Troubleshoot network problems
 Examine security problems
 Debug protocol implementations
 Learn network protocol internals
CSE-550-T062
Lecture Notes - 4
37
Example - Ethereal
CSE-550-T062
Lecture Notes - 4
38
Example - Ethereal
CSE-550-T062
Lecture Notes - 4
39
Example - Ethereal
CSE-550-T062
Lecture Notes - 4
40
Characterizing Network
Traffic
Characterizing Network Traffic
 Characterizing Traffic Flow
 Characterizing Traffic Load
 Characterizing Traffic Behavior
 Characterizing QoS Requirements
CSE-550-T062
Lecture Notes - 4
42
Characterizing Traffic Flow
 Identifying Major Traffic Sources and Stores
 Documenting Traffic Flow on the Existing
Network
 Characterizing Types of Traffic Flow for New
Network Applications
 Documenting Traffic Flow for New and
Existing Network
CSE-550-T062
Lecture Notes - 4
43
Characterizing Traffic Flow
- Identify Major Traffic Sources  Identify user communities for existing and new
applications
 User community: set of workers who use a
particular application or set of applications
 Characterize user communities by application and
protocol usage (rather than by department)
User Community
Name
CSE-550-T062
Size of Community
(Number of Users)
Location(s) of
Community
Lecture Notes - 4
Application(s) Used
by Community
44
Characterizing Traffic Flow
- Identify Major Data Stores  Identify data stores for existing and new applications
 Data Store (i.e., data sink): is an area in a network
where application layer data resides
 A data store can be a server, server farm, SAN, etc.
or any component of an internetwork where large
quantities of data are stored
Data Store
CSE-550-T062
Location
Application(s)
Lecture Notes - 4
Used by User Community
(or Communities)
45
Characterizing Traffic Flow
- Document Traffic Flow on Existing Network  Characterize individual traffic flows between traffic
sources and stores
 An individual network traffic flow: is a protocol and
application information transmitted between
communication entities (host, network, or AS) during
a single session
 A flow has attributes such as:






Direction: unidirectional vs. bi-directional
Symmetry: symmetric vs. asymmetric
Routing path and routing options
Number of packets
Number of bytes
Addresses for each end of the flow
CSE-550-T062
Lecture Notes - 4
46
Characterizing Traffic Flow
- Document Traffic Flow on Existing Network  Measuring traffic flow behavior can help
designer to:





Characterize the behavior of existing
networks
Plan for network development and expansion
Quantify network performance
Verify the quality of network service
Ascribe network usage to users and
applications
CSE-550-T062
Lecture Notes - 4
47
Characterizing Traffic Flow
- Document Traffic Flow on Existing Network  To characterize the size of a flow, measure the
number of KBps or MBps between important
communication entities

Use a protocol analyzer or a network management
system (NMS)
CSE-550-T062
Lecture Notes - 4
48
Characterizing Traffic Flow
- Types of Traffic Flow for New Network Applications  Classify applications as supporting one of
the following well-known flow types:







Terminal/host traffic flow
Client/server traffic flow
Thin client traffic Flow
Peer-to-peer traffic flow
Server/server traffic flow
Distributed computing traffic flow
Traffic flow in Voice over IP networks
CSE-550-T062
Lecture Notes - 4
49
Traffic Flow for New Network Applications
- Terminal/host Traffic Flow  Usually asymmetric
 Less prevalent on networks today
 Example: telnet
CSE-550-T062
Lecture Notes - 4
50
Traffic Flow for New Network Applications
- Client/Server Traffic Flow  Most widely used flow type
 Flow is usually bi-directional and asymmetric
 Clients rely on servers to access resources, e.g.,
storage, peripherals, application software, etc.
 Clients send queries and requests to a server,
typically small frames
 The server responds with data or permission for the
client to send data (response ranges from 64 bytes to
1500 bytes or more)
 Example: HTTP - probably the most widely used
client/server protocol (caching and CDNs may reduce
network traffic and provide fast delivery of content)
CSE-550-T062
Lecture Notes - 4
51
Traffic Flow for New Network Applications
- Thin Client Traffic Flow  A special case of client/server architecture
 Two cases:
 The application runs on the central server
 The software is installed on the server and is
downloaded into the client machine for execution
 Downside: amount of data flowing from the server to
the client can be substantial

Especially when many computers start up at the same
time every day
 Network including thin clients should be carefully
designed with sufficient capacity and appropriate
topology
CSE-550-T062
Lecture Notes - 4
52
Traffic Flow for New Network Applications
- Peer-to-Peer Traffic Flow  Each host acts as both client and server
 Usually bi-directional and symmetric
 Communicating entities transmit approximately equal amounts




of information
All devices have similar importance
No device stores substantially more data (no central server)
Example: Unix hosts with FTP, Telnet, HTTP, and NFS sessions
Many enterprises and university networks disallow P2P
Internet traffic, because:
 It causes huge amount of traffic
 Published material is often copyrighted by other than
publisher
CSE-550-T062
Lecture Notes - 4
53
Traffic Flow for New Network Applications
- Server/Server Traffic Flow  Generally bi-directional
 Symmetry depends on the application: e.g.,
asymmetric (hierarchy of servers)
 Includes transmissions between servers and
transmissions between servers and management
applications
 Examples: Data mirroring, backup, network
management data update
CSE-550-T062
Lecture Notes - 4
54
Traffic Flow for New Network Applications
- Distributed Computing Traffic Flow  Refers to applications that require multiple
computing nodes working together to complete a
job

Example: complex modeling tasks, extreme computing,
heavy simulations
 Data travels between a task manager and
computing nodes and between computing nodes
 Three types:



Task manager tells the computing nodes what to do on
an infrequent basis  little traffic flow
There is frequent communication between the task
manager and the computing nodes
Task manager allocates tasks based on resource
availability  flow prediction is difficult
CSE-550-T062
Lecture Notes - 4
55
Traffic Flow for New Network Applications
- Traffic Flow in Voice over IP Networks  There are multiple flows:
 Flow associated with transmitting the audio voice
(peer-to-peer) – call switching (using RTP)
 Flows associated with call setup and teardown
(client/server) – call control (e.g., using H.323)
 Audio voice packets may be switched through the
internetwork using a different path than used by the
call control packets
 Both types of flows should be analyzed differently
with different bandwidth and QoS requirements
CSE-550-T062
Lecture Notes - 4
56
Characterizing Traffic Flow
- Document Traffic Flow for New and Existing Network -
CSE-550-T062
Lecture Notes - 4
57
Characterizing Traffic Load
 Calculating Theoretical Traffic Load
 Documenting Application-Usage Patterns
 Refining Estimates of Traffic Load Caused
by Applications
 Estimating Traffic Load Caused by Routing
Protocols
CSE-550-T062
Lecture Notes - 4
58
Characterizing Traffic Load
- Calculate Theoretical Traffic Load  Traffic load (i.e., offered load): is the sum of all the data





network nodes have ready to send at a particular time
Goal for most network design: network capacity should be
more than adequate to handle the traffic load
Challenge: determine if capacity proposed is sufficient to
handle the potential load (for a new network)
 By studying idle times and frame sizes, and
 Estimating the number of stations
Assumptions can be made about frame size and idle time for
an application
May use protocol analyzer or a modeling tool to estimate an
average idle time (for both server and client sides)
Estimate total load for an application by multiplying the load
for the flow by the number of devices that use the application
CSE-550-T062
Lecture Notes - 4
59
Characterizing Traffic Load
- Document Application-Usage Patterns  Need to identify:
 Total number of users per application
 Frequency of application sessions
 Length of an average application session
 Number of simultaneous users of an application
 If it is not practical to research the application details,
some assumptions can be made:



Number of application users = simultaneous users
All applications are used all the time (worst-case
estimate)
Each user opens just one session and the session
lasts all day
CSE-550-T062
Lecture Notes - 4
60
Characterizing Traffic Load
- Estimates of Traffic Load  Estimate:




Size of data objects sent by applications
Traffic overhead caused by various protocols
Additional traffic load caused by application initialization
Traffic load caused by routing protocols
 Size of data objects
CSE-550-T062
Lecture Notes - 4
61
Characterize Traffic Behavior
 Broadcast/Multicast behavior
 Network Efficiency
CSE-550-T062
Lecture Notes - 4
62
Characterize Traffic Behavior
- Broadcast/Multicast Behavior  Broadcast traffic is necessary and unavoidable:
 Routing and switching protocols use broadcasts
and multicasts to share information about the
internetwork topology
 Servers send broadcasts and multicasts to advertise
their services
 Layer 2 internetworking devices forward broadcast
and multicast frames out all ports

Can be a scalability problem for large flat networks
 A router does not forward broadcasts or multicasts
 VLANs can also be used to limit the size of a
broadcast domain
CSE-550-T062
Lecture Notes - 4
63
Characterize Traffic Behavior
- Broadcast/Multicast Behavior  Research the level of broadcast traffic in your
proposed design and limit the number of stations in
a single broadcast domain
 If > 20% of the network traffic is broadcasts or
multicasts, the network needs to be segmented
using routers or VLANs.
CSE-550-T062
Lecture Notes - 4
64
Characterize Traffic Behavior
- Network Efficiency  Efficiency refers to whether applications and
protocols use bandwidth effectively
 Efficiency is affected by:


Frame size:
 Using the maximum size supported has a positive
impact on performance
 Avoid increasing MTU to more than maximum
supported
Interaction of protocols used by an application:
 Features implemented in more than one layer, e.g.,
timeouts and acknowledgments
 Misconfiguration of acknowledgment timers, etc.
CSE-550-T062
Lecture Notes - 4
65
Characterize Traffic Behavior
- Network Efficiency  Efficiency is affected by (Cont.):
 Windowing and flow control:
 Implemented by connection-oriented protocols such
as TCP
 Protocols are based on either TCP or UDP (no flow
control)
 Error-recovery mechanisms:
 If poorly designed, they can waste bandwidth
 Implemented by connection-oriented protocols
 In the Selective ACK (SACK) implemented in TCP,
the sender retransmits only the missing segments
 Use a protocol analyzer to determine if your
customer’s protocols implement effective error
recovery or not
CSE-550-T062
Lecture Notes - 4
66
Characterize QoS Requirements
 General QoS Design Principles
 Document QoS Requirements
 ATM QoS Specifications
 IETF Integrated Services
 IETF Differentiated Services
 Quality of Service Application Categories
CSE-550-T062
Lecture Notes - 4
67
Characterize QoS Requirements
- General QoS Design Principles  Vital to understand the service-level requirements
for applications that require preferential treatment
within the network
 QoS technologies are simply the enablers to
organizational objectives
 Start from a high level and clearly define the
organizational objectives, e.g.:




Is the objective to enable VoIP only?
Is video also required? If so, what type(s) of video:
interactive or streaming?
Are some applications considered mission critical? If
so, what are they?
Does the organization want to censor certain types of
traffic? If so, what are they?
CSE-550-T062
Lecture Notes - 4
68
Characterize QoS Requirements
- General QoS Design Principles  “QoS is a system of managed unfairness” (Szigeti
& Hattingh 2004)
Creates political and organizational repercussions
when implemented
 Solicit executive endorsement of QoS objectives
before design and deployment

 The company needs to clearly define how many
classes of traffic are required to meet the
organizational objectives
CSE-550-T062
Lecture Notes - 4
69
Characterize QoS Requirements
- Document QoS Requirements  Some applications can be categorized as needing
controlled-load or guaranteed service
 You may simply use the terms: inflexible and
flexible
 Inflexible: describes any application that has
specific requirements for constant bandwidth,
delay, delay variation, accuracy, and throughput
(e.g., multimedia applications)
 Flexible: describes applications that simply expect
the network to make a best effort to meet
requirements
CSE-550-T062
Lecture Notes - 4
70
Document QoS Requirements
- Voice Applications  For voice applications, document the different
requirements for:

Call control: no strict delay requirements, but
requires high network availability and
possibly a high Grade of Service (GoS)


GoS: fraction of calls successfully completed in a
timely fashion (= Call Completion Rate (CCR))
Audio stream: QoS classification should be
listed using the ATM term CBR or the IETF
term guaranteed service
CSE-550-T062
Lecture Notes - 4
71
Characterize QoS Requirements
- ATM QoS Specifications  ATM Forum defines 6 service categories:
 Constant bit rate (CBR): Voice and video
 Realtime variable bit rate (rt-VBR): Variable rate
compressed video streams
 Non-realtime variable bit rate (nrt-VBR): Frame Relay
 Available bit rate (ABR): Preferable for TCP/IP traffic
 Unspecified bit rate (UBR): File transfer and e-mail
 Guaranteed frame rate (GFR): Multiple TCP/IP
connections
 Work with your customer to correctly map
applications and protocols to the correct service
category (to meet network performance objectives)
CSE-550-T062
Lecture Notes - 4
72
ATM QoS Specifications
- CBR and rt-VBR  Constant bit rate (CBR):

A source end system reserves network resources in
advance


It can emit cells at the peak cell rate (PCR) at any time and for
any duration and the QoS commitments should pertain
Intended to support realtime applications requiring tightly
constrained delay variation, e.g., voice and video
 Realtime variable bit rate (rt-VBR):



Traffic that relies on accurate timing between the traffic
source and destination
Sources are expected to transmit at a rate that varies with
time, e.g., bursty traffic
May support statistical multiplexing of realtime data
sources
CSE-550-T062
Lecture Notes - 4
73
ATM QoS Specifications
- nrt-VBR and ABR  Non-realtime variable bit rate (nrt-VBR):



Intended for non-realtime applications that have bursty
traffic characteristics
No delay bounds
May support statistical multiplexing of connections
 Available bit rate (ABR):





Transfer characteristics provided by the network can
change subsequent to connection establishment
A flow-control mechanism offers feedback to control the
source rate in response to changing conditions
Intended for non-realtime applications
Does not require bounding the delay or the delay variation
Bandwidth available can vary, but not become < MCR
(Minimum Cell Rate)
CSE-550-T062
Lecture Notes - 4
74
ATM QoS Specifications
- UBR and GFR  Unspecified bit rate (UBR):



Does not specify any traffic-related service guarantees
No flow-control mechanisms
Intended for non-realtime applications, e.g., file transfer and
e-mail
 Guaranteed frame rate (GFR):

Designed for applications that:




Require a minimum rate guarantee, and
Can benefit from dynamically accessing additional
bandwidth available in the network
Can be used to transport multiple TCP/IP connections
over a single GFR virtual circuit
Under congestion conditions, the network attempts to
discard complete frames instead of cells
CSE-550-T062
Lecture Notes - 4
75
Characterize QoS Requirements
- IETF QoS Specifications  Two primary types of Internet standards based QoS
architectures in the industry today:


Integrated Services (IntServ)
Differentiated Services (DiffServ)
 These approaches are complimentary in nature:
 DiffServ enables better QoS scalability
 IntServ provides a guaranteed traffic delivery
 Together, they can form a robust QoS deployment
CSE-550-T062
Lecture Notes - 4
76
IETF QoS Specifications
- Integrated Services (IntServ)  Analogous to a custom mail service (e.g.,
diplomatic mail, courier services), with certain
parameters regarding loss and delivery guaranteed
 Key endpoints are the sender and receiver
applications that request a desired service from the
network for a set of flows
 Utilizes Resource ReSerVation Protocol (RSVP) to
signal a specific service (end-to-end signaling)

Ideal for end-to-end delay and jitter sensitive
applications, such as Voice and Video
 State-maintenance (for each RSVP-flow and
reservation)
 Admission control at each network element
CSE-550-T062
Lecture Notes - 4
77
IETF QoS Specifications
- Integrated Services (IntServ)  Describes three main classes of service (CoS) that
an application can request:



Guaranteed services: provides a service that
guarantees delay and bandwidth
Controlled load: provides the application flow with a
QoS closely approximating the QoS that the same
flow would receive from an unloaded network
element
 Uses capacity (admission) control to ensure that
this service is received even when the network
element is overloaded
Best-effort service: provides no service guarantees
of any type
CSE-550-T062
Lecture Notes - 4
78
IETF QoS Specifications
- Differentiated Services (DiffServ)  Can be compared to different tiers of mail service
such as regular, registered, priority, and express mail


Each service offers particular parameters of delivery
The piece of mail is stamped at each intermediate
handling point to ensure that it gets the required
service
 Offers different network service levels to a packet
 Enables scalable service discrimination in the Internet
or enterprise network (without the need for per-flow
based state and signaling at every hop)
CSE-550-T062
Lecture Notes - 4
79
IETF QoS Specifications
- Differentiated Services (DiffServ)  Packets of a particular service (application) belong to
a particular “class”
 Treatment of each “class” is described by PHB (Per
Hop Behaviors) with which the node must comply
 DiffServ provides simple and coarse methods of
categorizing traffic into different classes, i.e., class
of service (CoS)



Packets are first divided into classes by marking the
type of service (ToS) byte in the IP header
A 6-bit bit-pattern, called the Differentiated Services
Code Point (DSCP), is used for this
QoS parameters are applied to these classes
CSE-550-T062
Lecture Notes - 4
80
IETF QoS Specifications
- Differentiated Services (DiffServ)  The major working attribute of DiffServ is the
definition of different PHBs that an application can
receive from the network
 The three DiffServ PHBs are:



Expedited Forwarding (EF): Provides a strict priority
service for packets marked in this way
Assured Forwarding (AF): Provides a qualified
delivery guarantee and makes the provision of
oversubscription to this service
Class Selectors (CS): Provides code points in the IP
header field and is a way of using/identifying the IP
Precedence bits in the presence of DSCP bits set
CSE-550-T062
Lecture Notes - 4
81
IETF QoS Specifications
- IntServ vs. DiffServ  Neither method offers a complete solution
 Elements of both should be combined to provide a
method applicable to the widest range of traffic and
applications types
 DiffServ mechanisms provide bandwidth guarantees at
different levels, but no bandwidth reservations
 Reservation implies that a certain amount of bandwidth
has been agreed to be set aside for a particular flow of
packets

With the advent of faster platform processors, IOS
enhancements and faster links (Gigabit Ethernet), using
IntServ RSVP is again a consideration
 Possible scenario: all voice traffic is on demand RSVP
IntServ based and other applications are DiffServ based
CSE-550-T062
Lecture Notes - 4
82
Quality of Service Application Categories
- Cisco QoS Baseline Model -
CSE-550-T062
Lecture Notes - 4
83
Quality of Service Application Categories
- Cisco QoS Baseline Model -
CSE-550-T062
Voice
EF
Interactive-Video
AF41
Streaming-Video
CS4
Call Signaling
CS3
IP Routing
CS6
Network Management
CS2
Mission-Critical Data
AF31
Transactional Data
AF21
Bulk Data
AF11
Best Effort
DSCP 0
Scavenger
CS1
Lecture Notes - 4
84
QoS Requirements of VoIP (Voice)
 Voice traffic should be marked to DSCP EF per QoS baseline
 This gives voice bearer traffic the highest level of priority and





ensures that the PHBs will always forward this traffic first
Voice Quality is directly affected by all three QoS quality
Factors: Loss, Latency and Jitter
Loss should be no more than 1%
One-way latency, mouth to ear, should be no more than 150ms
 However, there is room for 200ms by most specs, but this
should only be done if absolutely required and 150ms cannot
be met
Average one-way jitter should be targeted at less than 30ms
 This entails working with and tuning the jitter buffer if
applicable on various end devices
Guaranteed priority bandwidth within the range of 21 to 320
kbps per call depending of the codec, sampling rate and layer
2 overhead
CSE-550-T062
Lecture Notes - 4
85
QoS Requirements of Interactive-Video
 For Interactive-video (video conferencing) traffic, the
following guidelines are recommended:





Should be marked DSCP AF41: Excess
videoconferencing traffic can be marked down by a
policer to AF42 or AF43
Loss should be no more than 1%
One-way latency should be no more than 150ms
Jitter should be no more than 30ms
May need to overprovision the minimum priority
bandwidth guarantee to the size of the
videoconferencing session plus 20%
 For example, a 384kbs videoconferencing session
requires 460kbs of guaranteed priority bandwidth
CSE-550-T062
Lecture Notes - 4
86
QoS Requirements of Streaming-Video
 For Streaming-video traffic, the following guidelines are
recommended:
 Streaming Video (whether unicast or multicast) should be
marked to DSCP CS4 per QoS baseline
 Loss should be no more than 5%
 Latency should be no more than 4 to 5 seconds (dependant
on the video application’s capabilities)
 There are no significant jitter requirements
 Guaranteed bandwidth requirements depend on the
encoding format and rate of the video stream
 Streaming-Video is typically unidirectional:


Therefore, remote sites might not require provisioning for
Streaming-Video traffic on their WAN serial links or VPN links
Non compliant organizational Streaming video applications
(either unicast or multicast) such as entertain video content,
may be marked as scavenger DSCP CS1
CSE-550-T062
Lecture Notes - 4
87
Network Traffic Checklist
CSE-550-T062
Lecture Notes - 4
88
References
 P. Oppenheimer, “Top-Down Network Design,” Cisco





Press, 2nd edition, 2004
J. McCabe, “Network Analysis, Architecture, and
Design” Morgan Kaufmann Publishers, Inc., 2nd
edition, 2003
T. Szigeti & C. Hattingh, “End-to-End QoS Network
Design: Quality of Service in LANs, WANs, and
VPNs” Cisco Press, 2004
Applied Methodologies, Inc. “NYC Utility - QoS
Strategy and White Paper”, April 2005
Dr. Khalid Salah (ICS, KFUPM), CSE 550 Lecture
Slides, Term 032
RFCs
CSE-550-T062
Lecture Notes - 4
89