Você está na página 1de 7

Chapter 12 Congestion in Data Networks What Is Congestion?

• Effect of Congestion Control • Congestion occurs when the number of packets being
¾ Ideal Performance transmitted through the network approaches the packet
¾ Practical Performance handling capacity of the network
• Congestion Control Mechanisms
• Congestion control aims to keep number of packets
¾ Backpressure
below level at which performance falls off dramatically
¾ Choke Packet
¾ Implicit Congestion Signaling • Data network is a network of queues
¾ Explicit Congestion Signaling ¾ Can congestion occur at Circuit Switching network?
• Congestion Control in Data Network • Generally 80% utilization is critical
¾ ATM Traffic Management & Congestion Control
• Frame Relay Congestion Control • Finite queues mean data may be lost

Spring, 2003 EE 4272 Spring, 2003 EE 4272

Effects of Congestion Interaction of Queues


• Packets arriving are stored at
input buffers -> Routing
Congestion at
decision made -> Packet
one point in the
moves to output buffer
network can
• Packets queued for output propagate
transmitted as fast as possible through out a
¾ Statistical TDM region or the
entire network
• If packets arrive too fast to be
routed/output, buffers fill up
¾ Discard packets
¾ Flow control

Spring, 2003 EE 4272 Spring, 2003 EE 4272

1
Ideal Performance Practical Performance
Moderate
• Ideal goal of network • Ideal assumes infinite congestion
utilization: infinite buffer buffers and no overhead state
Buffer fill up

throughput = full capacity Å • Buffers are finite


traffic load = full capacity
• Overheads occur in
exchanging congestion
• Normalized by the control messages
maximum theoretical
throughput

• Power = thrupt/delay

Spring, 2003 EE 4272 Spring, 2003 EE 4272

Mechanisms for Congestion Control Backpressure

• Backpressure (connection oriented hop-by-hop net flow control) : X.25 • If node becomes congested it can slow down or halt flow
• Choke Packet (a control packet from congested node) : crude of packets from other nodes
• Implicit Congestion Signaling
• Explicit Congestion Signaling • 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

Spring, 2003 EE 4272 Spring, 2003 EE 4272

2
Choke Packet Implicit Congestion Signaling

• Control packet • Transmission delay may increase with congestion


¾ Generated at congested node • Packet may be discarded
¾ Sent to source node • Source can detect these as implicit indications of
¾ e.g. ICMP source quench congestion -> responsibility of end systems
¾ From router or destination
¾ Source cuts back until no more source quench message • Useful on connectionless (datagram) networks
¾ Sent for every discarded packet, or anticipated ¾ e.g. IP based
(TCP includes congestion and flow control - see chapter 17)
• Rather crude mechanism ¾

Spring, 2003 EE 4272 Spring, 2003 EE 4272

Explicit Congestion Signaling Congestion Control in Packet Switched Networks


• Network alerts end systems of increasing congestion
• End systems take steps to reduce offered load • Send control packet to some or all source nodes
• Typically used in connection-oriented network ¾ Requires additional traffic during congestion
¾ Backwards • Rely on routing information
¾ Congestion avoidance in opposite direction to packet required
¾ Forwards ¾ May vary too rapidly
Congestion avoidance in same direction as packet required ??
¾
• End-to-end probe packets
• Categories of Explicit Signaling
¾ Adds to overhead
¾ Binary: A bit set in a packet indicates congestion
¾ Credit based • Add congestion info to packets as they cross nodes
¾ Indicates how many packets source may send
¾ Either backwards or forwards
¾ Common for end-to-end flow control
¾ Rate based
¾ Supply explicit data rate limit
¾ e.g. ATM
Spring, 2003 EE 4272 Spring, 2003 EE 4272

3
ATM Traffic Management Latency/Speed Effects
• High speed, small cell size, limited overhead bits • ATM 150Mbps: ~2.8x10 - 6seconds to insert single cell

• Time to traverse network depends on propagation delay, switching


• Requirements & Challenges delay
¾ Majority of traffic not responsive to flow control (e.g. • If source and destination on opposite sides of USA, propagation
voice, video) time ~ 48x10 - 3seconds
¾ Feedback slow due to small transmission time compared
• Given implicit congestion control, by the time dropped cell
with propagation delay
notification has reached source, 7.2x106 bits have been transmitted
¾ Wide range of application demands
• Not a good strategy for ATM
¾ Different traffic patterns
¾ Different network services
¾ High speed switching and transmission increases volatility
¾ Fluctuation in routing policy and flow control

Spring, 2003 EE 4272 Spring, 2003 EE 4272

Cell Delay Variation Network Contributions to Cell Delay Variation


• Packet switched networks
• For ATM voice/video, data is a stream of cells
¾ Queuing delays
¾ Delay across network must be short
¾ Rate of delivery must be constant ¾ Routing decision time
• There will always be some variation in transit
• Frame relay: As above but to lesser extent
¾ Delay cell delivery to application so that constant bit rate can be maintained

• ATM
¾ Less than frame relay
¾ ATM protocol designed to minimize processing overheads at switches
¾ ATM switches have very high throughput
¾ Only noticeable delay is from congestion
¾ Must not accept load that causes congestion

Spring, 2003 EE 4272 Spring, 2003 EE 4272

4
Cell Delay Variation at The UNI Origins of Cell Delay Variation
• Even application produces data at fixed rate
• Processing at three layers of ATM causes delay
¾ Interleaving cells from different connections
¾ Operation and maintenance cell interleaving
¾ If using synchronous digital hierarchy frames, these are
inserted at physical layer
¾ Can not predict these delays

Spring, 2003 EE 4272 Spring, 2003 EE 4272

Traffic & Congestion Control Framework Traffic Management & Congestion Control Techniques

• ATM layer traffic and congestion control should support • Resource management using virtual paths
QoS classes for all foreseeable network services
• Connection admission control
• Should not rely on AAL protocols that are network
• Usage parameter control (UPC)
specific, nor higher level application specific protocols ->
more general • Selective cell discard
• Should minimize network and end-to-end system • Traffic shaping
complexity
• Determine whether a given new connection can be
accommodated
• Agree performance parameters with subscriber -> contract

Spring, 2003 EE 4272 Spring, 2003 EE 4272

5
Resource Management Using Virtual Paths Connection Admission Control
• Separate traffic flow according to
service characteristics • First line of defense
¾ User-to-user application
¾ User-to-network application • User specifies traffic characteristics for new
¾ Network-to-network application connection (VCC or VPC) by selecting a QoS
• Concern with: • Network accepts connection only if it can meet the
Cell loss ratio
¾
demand
¾ Cell transfer delay
¾ Cell delay variation • Traffic contract
• VCCs within a VPC should ¾ Peak cell rate
experience similar network ¾ Cell delay variation
performance
¾ Sustainable cell rate
• Options for allocation:
¾ Burst tolerance
¾ Aggregate peak demand
¾ Statistical multiplexing
Spring, 2003 EE 4272 Spring, 2003 EE 4272

Usage Parameter Control Traffic Shaping


• Smooth out traffic flow and reduce cell clumping
• Monitor connection to ensure traffic conforms to contract
• Token bucket
• Protection of network resources from overload by one
connection
• Done on VCC and VPC
¾ Peak cell rate and cell delay variation
¾ Sustainable cell rate and burst tolerance
• Discard cells that do not conform to traffic contract
• Called traffic policing

Spring, 2003 EE 4272 Spring, 2003 EE 4272

6
Frame Relay Congestion Control Techniques
• Minimize discards
• Maintain agreed QoS
• Discard strategy
• Minimize probability of one end user monopoly • Congestion avoidance
• Simple to implement • Explicit signaling
Little overhead on network or user
¾
• Congestion recovery
• Create minimal additional traffic
• Implicit signaling mechanism
• Distribute resources fairly
• Limit spread of congestion
• Operate effectively regardless of traffic flow
• Minimum impact on other systems
• Minimize variance in QoS

Spring, 2003 EE 4272 Spring, 2003 EE 4272

Você também pode gostar