Title: Computer Networks with Internet Technology William Stallings
1Computer Networks with Internet
TechnologyWilliam Stallings
- Chapter 05
- Congestion and Performance Issues
2High-Speed LANs
- Speed and power of personal computers has
increased - LAN viable and essential computing platform
- Client/server computing dominant architecture
- Web-focused intranet
- Frequent transfer of potentially large volumes of
data in a transaction-oriented environment - 10-Mbps Ethernet and 16-Mbps token ring not up to
job
3Uses of High-Speed LANs
- Centralized server farms
- Client systems draw huge amounts of data from
multiple centralized servers - E.g. color publishing
- Servers hold tens of gigabytes of image data that
must be downloaded to workstations - Power workgroups
- Small number of users drawing data across network
- E.g.s Software development group, computer-aided
design (CAD) - High-speed local backbone
- LANs proliferate at a site,
- High-speed interconnection is necessary
4Corporate Wide Area Networking Needs
- Up to 1990s, centralized data processing model
- Dispersed employees into multiple smaller offices
- Growing use of telecommuting
- Application structure changed
- Client/server and intranet computing
- More reliance on PCs, workstations, and servers
- GUIs gives user graphic applications, multimedia
etc. - Internet access
- A few mouse clicks can trigger huge volumes of
data - Traffic patterns unpredictable
- Average load has risen
- More data transported off premises
- Traditionally 80 traffic local 20 wide area
- No longer applies
- Greater burden on LAN backbones and on WAN
5Digital Electronics Examples
- Digital Versatile Disk (DVD)
- Huge storage capacity and vivid quality
- Digital camcorder
- Easy for individuals and companies to make
digital video files and place on Web sites - Â Digital Still Camera
- Individual personal pictures
- Companies online product catalogs with full-color
pictures of every product
6QoS on The Internet
- IP designed to provide best-effort, fair delivery
service - All packets treated equally
- As traffic grows, congestion occurs, all packet
delivery slowed - Packets dropped at random to ease congestion
- Only networking scheme designed to support both
traditional TCP and UDP and real-time traffic is
ATM - Means constructing second infrastructure for
real-time traffic or replacing existing IP-based
configuration with ATM - Two types of traffic
- Elastic traffic can adjust, over wide ranges, to
changes in delay and throughput - Supported on TCP/IP
- Handle congestion by reducing rate data presented
to network
7Elastic Traffic
- File transfer, electronic mail, remote logon,
network management, Web access - E-mail insensitive to changes in delay
- User expects file transfer delay proportional to
file size and so is sensitive to changes in
throughput - With network management, delay is not concern
- If failures cause congestion, network management
messages must get through minimum delay - Interactive applications, (remote logon, Web
access) quite sensitive to delay - Even for elastic traffic QoS-based service could
help
8Inelastic Traffic
- Inelastic traffic does not easily adapt, if at
all, to changes in delay and throughput - E.g. real-time traffic
- Voice and video
- RequirementsÂ
- Throughput minimum value may be required
- Delay e.g. stock trading
- Delay variation Larger variation needs larger
buffers - Packet loss Applications vary in packet loss
that they can sustain - Difficult to meet with variable queuing delays
and congestion losses - Need preferential treatment to some applications
- Applications need to be able to state requirements
9Supporting Both
- When supporting inelastic traffic, elastic
traffic must still be supported - Inelastic applications do not back off in the
face of congestion - TCP-based applications do
- When congested, inelastic traffic continues high
load, - Elastic traffic crowded off
- Reservation protocol can help
- Deny requests that would leave too few resources
available to handle current elastic traffic
10Figure 5.1 Application Delay Sensitivity and
Criticality
11Performance Requirements Response Time
- Time it takes a system to react to a given input
- Time between last keystroke and beginning of
display of result - Time it takes for system to respond to request
- Quicker response imposes greater cost
- Computer processing power
- Competing requirements
- Providing rapid response to some processes may
penalize others - User response time
- Between user receiving complete reply and enters
next command (think time) - System response time
- Between user entering command and complete
responseÂ
12Figure 5.2 Response Time Results for
High-Function Graphics
13Figure 5.3 Response Time Requirements
14Throughput
- Higher transmission speed makes possible
increased support for different services - e.g., Integrated Services Digital Network ISDN
and broadband-based multimedia services - Need to know demands each service puts on storage
and communications of systems - Services grouped into data, audio, image, and
video
15Figure 5.4 Required Data Rates for Various
Information Types
16Figure 5.5Effective Throughput
17Performance Metrics
- Throughput, or capacity
- Data rate in bits per second (bps)
- Affected by multiplexing
- Effective capacity reduced by protocol overhead
- Header bits TCP and IPv4 at least 40 bytes
- Control overhead e.g. acknowledgementsÂ
- Delay
- Average time for block of data to go from system
to system - Round-trip delay
- Getting data from one system to another plus
delay acknowledgement  - Transmission delay Time for transmitter to send
all bits of packet - Propagation delay Time for one bit to transit
from source to destination - Processing delay Time required to process packet
at source prior to sending, at any intermediate
router or switch, and at destination prior to
delivering to application - Queuing delay Time spend waiting in queues
18Example Effect of Different Types of Delay
64kbps
- Ignore any processing or queuing delays
- 1-megabit file across USA (4800km)
- Fiber optic link
- Propagation rate speed of light (approximately 3
? 108 m/s) - Propagation delay (4800?103)/(3?108) 0.016 s
- In that time host transmits (64 ? 103)(0.016)
1024 bits - Transmission delay (106)/(64 ? 103) 15.625 s
- Time to transmit file is Transmission delay plus
propagation delay 15.641 s - Transmission delay dominates propagation delay
- Higher-speed channel would reduce time required
19Example Effect of Different Types of Delay 1
Gbps
- Propagation delay is still the same
- Note this as it is often forgotten!
- Transmission delay (106)/(106 ? 103) 0.001 s
- Total time to transmit file 0.017 s
- Propagation delay dominates
- Increasing data rate will not noticeably speed up
delivery of file - Preceding example depends on data rate, distance,
propagation velocity, and size of packet - These parameters combined into single critical
system parameter, commonly denoted a
20a (1)
- where
- R data rate, or capacity, of the link
- L number of bits in a packet
- d distance between source and destination
- v velocity of propagation of the signal
- D propagation delay
21a (2)
- Looking at the final fraction, can also be
expressed - Â
- Â
- For fixed packet length, a dependent on R ? D
product - 64-kbps link, a 1.024 ? 103
- 1-Gbps link, a 16
22Impact of a
- Send sequence of packets and wait for
acknowledgment to each packet before sending next - Stop-and-wait protocol
- Transmission time normalized to 1 propagation
time is a - a gt 1
- Link's bit length greater than that of packet
- Assume ACK packet is small enough to ignore its
transmission time - t 0, Station A begins transmitting packet
- t 1, A completes transmission
- t a, leading edge of packet reaches B
- t 1 a, B has received entire packet
- Immediately transmits small acknowledgment packet
- T 1 2a, acknowledgment arrives at A
- Total elapsed time is 1 2a
- Hence normalized rate packets can be transmitted
is 1/(1 2a) - Same result with a lt 1
23Figure 5.6 Effect of a on Link Utilization
24Throughput as Function of a
- For a gt 1 stop-and-wait inefficient
- Gigabit WANs even for large packets (e.g., 1 Mb),
channel is seriously underutilized
25Figure 5.7 Normalized Throughput as a Function of
a for Stop-and-Wait
26Improving Performance
- If lots of users each use small portion of
capacity, then for each user, effective capacity
is considerably smaller, reducing a - Each user has smaller data rate
- May be inadequate
- If application uses channel with high a,
performance can be improved by allowing
application to treat channel as pipeline - Continuous flow of packets
- Not waiting for acknowledgment to individual
packet - Problems
- Flow control
- Error control
- Congestion control
27Flow control
- B may need to temporarily restrict flow of
packets - Buffer is filling up or application is
temporarily busy - By the time signal from B arrives at A, many
additional packets in the pipeline - If B cannot absorb these packets, they must be
discarded
28Error control
- If B detects error it may request retransmission
- If B unable to store incoming packets out of
order, A must retransmit packet in error and all
subsequent packets - Selective retransmission v. Go-Back-N
29Congestion control
- Various methods by which A can learn there is
congestion - A should reduce the flow of packets
- Large value of a
- Many packets in pipeline between onset of
congestion and when A learns about it
30Queuing Delays
- Often queuing delays are dominant
- Grow dramatically as system approaches capacity
- In shared facility (e.g., network, transmission
line, time-sharing system, road network, checkout
lines, ) performance typically responds
exponentially to increased demand - Figure 5.8 representative example
- Upper line shows user response time on shared
facility as load increases - Load expressed as fraction of capacity
- Lower line is simple projection based on
knowledge of system behavior up to load of 0.5 - Note performance will in fact collapse beyond
about 0.8 to 0.9
31Figure 5.8 Projected Versus Actual Response Time
32What Is Congestion?
- Congestion occurs when the number of packets
being transmitted through the network approaches
the packet handling capacity of the network - Congestion control aims to keep number of packets
below level at which performance falls off
dramatically - Data network is a network of queues
- Generally 80 utilization is critical
- Finite queues mean data may be lost
33Figure 5.9 Input and Output Queues at Node
34Effects of Congestion
- Packets arriving are stored at input buffers
- Routing decision made
- Packet moves to output buffer
- Packets queued for output transmitted as fast as
possible - Statistical time division multiplexing
- If packets arrive to fast to be routed, or to be
output, buffers will fill - Can discard packets
- Can use flow control
- Can propagate congestion through network
35Figure 5.10 Interaction of Queues in a Data
Network
36Figure 5.11Ideal NetworkUtilization
37Practical Performance
- Ideal assumes infinite buffers and no overhead
- Buffers are finite
- Overheads occur in exchanging congestion control
messages
38Figure 5.12The Effects of Congestion
39Figure 5.13 Mechanisms for Congestion Control
40Backpressure
- If node becomes congested it can slow down or
halt flow of packets from other nodes - May mean that other nodes have to apply control
on incoming packet rates - Propagates back to source
- Can restrict to logical connections generating
most traffic - Used in connection oriented that allow hop by hop
congestion control (e.g. X.25) - Not used in ATM nor frame relay
- Only recently developed for IP
41Choke Packet
- Control packet
- Generated at congested node
- Sent to source node
- e.g. ICMP source quench
- From router or destination
- Source cuts back until no more source quench
message - Sent for every discarded packet, or anticipated
- Rather crude mechanism
42Implicit Congestion Signaling
- Transmission delay may increase with congestion
- Packet may be discarded
- Source can detect these as implicit indications
of congestion - Useful on connectionless (datagram) networks
- e.g. IP based
- (TCP includes congestion and flow control - see
chapter 17) - Used in frame relay LAPF
43Explicit Congestion Signaling
- Network alerts end systems of increasing
congestion - End systems take steps to reduce offered load
- Backwards
- Congestion avoidance in opposite direction to
packet required - Forwards
- Congestion avoidance in same direction as packet
required
44Categories of Explicit Signaling
- Binary
- A bit set in a packet indicates congestion
- Credit based
- Indicates how many packets source may send
- Common for end to end flow control
- Rate based
- Supply explicit data rate limit
- e.g. ATM
45Traffic Management
- Fairness
- Quality of service
- May want different treatment for different
connections - Reservations
- e.g. ATM
- Traffic contract between user and network
46Flow Control
- Limits amount or rate of data sent
- Reasons
- Source may send PDUs faster than destination can
process headers - Higher-level protocol user at destination may be
slow in retrieving data - Destination may need to limit incoming flow to
match outgoing flow for retransmission
47Flow Control at Multiple Protocol Layers
- X.25 virtual circuits (level 3) multiplexed over
data link using LAPB (X.25 level 2) - Multiple TCP connections over HDLC link
- Flow control at higher level applied to each
logical connection independently - Flow control at lower level applied to total
traffic
48Figure 5.14 Flow Control at Multiple Protocol
Layers
49Flow Control Scope
- Hop Scope
- Between intermediate systems that are directly
connected - Network interface
- Between end system and network
- Entry-to-exit
- Between entry to network and exit from network
- End-to-end
- Between end user systems
50Figure 5.15Flow Control Scope
51Error Control
- Used to recover lost or damaged PDUs
- Involves error detection and PDU retransmission
- Implemented together with flow control in a
single mechanism - Performed at various protocol levels
52Self-Similar Traffic
- Predicted results from queuing analysis often
differ substantially from observed performance - Validity of queuing analysis depends on Poisson
nature of traffic - For some environments, traffic pattern is
self-similar rather than Poisson - Network traffic is burstier and exhibits greater
variance than previously suspected - Ethernet traffic has self-similar, or fractal,
characteristic - Similar statistical properties at range of time
scales milliseconds, seconds, minutes, hours,
even days and weeks - Cannot expect that the traffic will "smooth out"
over an extended period of time - Data clusters and clusters cluster
- Merging of traffic streams (statistical
multiplexer or ATM switch) does not result in
smoothing of traffic - Multiplexed bursty data streams tend to produce
bursty aggregate stream
53Effects of Self-Similar Traffic (1)
- Buffers needed at switches and multiplexers must
be bigger than predicted by traditional queuing
analysis and simulations - Larger buffers create greater delays in
individual streams that originally anticipated - Self-similarity appears in ATM traffic,
compressed digital video streams, SS7 control
traffic on ISDN-based networks, Web traffic, etc. - Aside self-similarity common natural
landscapes, distribution of earthquakes, ocean
waves, turbulent flow, stock market fluctuations,
pattern of errors and data traffic - Buffer design and management requires rethinking
- Was assumed linear increases in buffer sizes gave
nearly exponential decreases in packet loss and
proportional increase in effective use of
capacity - With self-similar traffic decrease in loss less
than expected, and modest increase in utilization
needs significant increase in buffer size
54Effects of Self-Similar Traffic (2)
- Slight increase in active connections through
switch can result in large increase in packet
loss - Parameters of network design more sensitive to
actual traffic pattern than expected - Designs need to be more conservative
- Priority scheduling schemes need to be reexamined
- Prolonged burst of traffic from highest priority
could starve other classes - Static congestion control strategy must assume
waves of multiple peak periods will occur - Dynamic strategy difficult to implement
- Based on measurement of recent traffic
- Can fail to adapt to rapidly changing conditions
- Congestion prevention by appropriate sizing
difficult - Traffic does not exhibit predictable level of
busy period traffic - Congestion avoidance by monitoring traffic and
adapting flow control and routing difficult - Congestion can occur unexpectedly and with
dramatic intensity - Congestion recovery is complicated by need to
make sure critical network control messages not
lost in repeated waves of traffic
55Why Have We Only Just Found Out?
- Requires processing of massive amount of data
- Over long observation period
- Practical effects obvious
- ATM switch vendors, among others, have found that
their products did not perform as advertised - Inadequate buffering and failure to take into
account delays caused by burstiness
56Required Reading