Transcript Congestion Control Foreleser: Carsten Griwodz Email:

Congestion Control
Foreleser: Carsten Griwodz
Email: [email protected]
26. Apr. 2006
1
INF-3190: Congestion Control
Congestion

2 problem areas

Receiver capacity


Network capacity


Approached by congestion control
Possible approach to avoid both bottlenecks




Approached by flow control
Receiver capacity: “actual window”, credit window
Network capacity: “congestion window”
Valid send window = min(actual window, congestion window)
Terms

Traffic


All packets from all sources
Traffic class

26. Apr. 2006
All packets from all sources with a common distinguishing property, e.g.
priority
3
INF-3190: Congestion Control
Congestion

Persistent congestion



Router stays congested for a long time
Excessive traffic offered
Transient congestion

Congestion occurs for a while
Router is temporarily overloaded
Often due to burstiness

Burstiness


Average rate r
 Burst size b (#packets that appear at
the same time)
Token bucket model

26. Apr. 2006
4
INF-3190: Congestion Control

Reasons for congestion,
among others




maximum transmission
capacity of
the subnet

perfect
desirable
congested
When too much traffic is
offered


Incoming traffic overloads outgoing lines
Router too slow for routing algorithms
Too little buffer space in router
packets delivered
Congestion
packets sent by application
Congestion sets in
Performance degrades sharply
Congestion tends to amplify itself

Network layer: unreliable service


Router simply drops packet due to congestion
Transport layer: reliable service

Packet is retransmitted
Congestion
Higher delays
Retransmissions
26. Apr. 2006
=> More delays at end-systems
=> Retransmissions
=> Additional traffic
5
INF-3190: Congestion Control
Congestion Control

General methods of resolution



Increase capacity
Decrease traffic
Strategies

Repair





When congestion is noticed
Explicit feedback (packets are sent from the point of congestion)
Implicit feedback (source assumes that congestion occurred due to other
effects)
Methods: drop packets, choke packets, hop-by-hop choke packets, fair
queuing,...
Avoid




26. Apr. 2006
Before congestion happens
Initiate countermeasures at the sender
Initiate countermeasures at the receiver
Methods: leaky bucket, token bucket, isarithmic congestion control,
reservation, …
6
INF-3190: Congestion Control
Repair

Principle


No resource reservation
Necessary steps


26. Apr. 2006
Congestion detected
Introduce appropriate procedures for reduction
7
INF-3190: Congestion Control
Repair by Packet dropping

Principle



At each intermediate system
Queue length is tested
Incoming packet is dropped if it cannot be buffered


We may not wait until the queue is entirely full
To provide

Connectionless service


No preparations necessary
Connection-oriented service

26. Apr. 2006
Buffer packet until reception has been acknowledged
8
INF-3190: Congestion Control
Repair by Packet dropping
Output
lines
Input
lines

Assigning buffers to queues at output lines
1. Maximum number of buffers per output line

Packet may be dropped although there are free lines
2. Minimal number of buffers per output line

Sequences to same output line (“bursts”) lead to drops
3. Dynamic buffer assignment

26. Apr. 2006
Unused lines are starved
9
INF-3190: Congestion Control
Repair by Packet dropping
4. Content-related dropping: relevance

Relevance of data connection as a whole
or every packet from one end system to another end system


Relevance of a traffic class

26. Apr. 2006
Examples
 Favor IPv6 packets with flow id 0x4b5 over all others
 Favor packets of TCP connection
(65.246.255.51,80,129.240.69.49,53051) over all others
Examples
 Favor ICMP packets over IP packets
 Favor HTTP traffic (all TCP packets with source port 80)
over FTP traffic
 Favor packets from 65.246.0.0/16 over all others
10
INF-3190: Congestion Control
Repair by Packet dropping

Properties


Very simple
But


Retransmitted packets waste bandwidth
Packet has to be sent 1 / (1 - p) times before it is accepted


(p ... probability that packet will be dropped)
Optimization necessary to reduce the waste of
bandwidth
Dropping packets that have not gotten that far yet
 e.g. Choke packets

26. Apr. 2006
11
INF-3190: Congestion Control
Repair by Choke Packets

Principle


Reduce traffic during congestion by telling source to slow down
Procedure for router

Each outgoing line has one variable


Calculating u: Router checks the line usage f periodically (f is 0
or 1)



Utilization u ( 0≤u≤1 )
u=a*u+(1-a)*f
0 ≤ a ≤ 1 determines to what extent "history" is taken into account
u > threshold: line changes to condition "warning“


26. Apr. 2006
Send choke packet to source (indicating destination)
Tag packet (to avoid further choke packets from down stream
router) & forward it
12
INF-3190: Congestion Control
Repair by Choke Packets

Principle


Reduce traffic during congestion by telling source to slow down
Procedure for source

Source receives the choke packet


Reduces the data traffic to the destination in question by x1%
Source recognizes 2 phases
(gate time so that the algorithm can take effect)


26. Apr. 2006
Ignore: source ignores further Choke packets until timeout
Listen: source listens if more Choke packets are arriving

yes:

no:
further reduction by X2%;
go to Ignore phase
increase the data traffic
13
INF-3190: Congestion Control
Repair by Choke Packets
Hop-by-Hop Choke Packets
Principle



Reaction to Choke packets already at router (not only at end system)
Plain Choke packets
B
C
A




B
D
E

Hop-by-hop Choke packets
A
F
D
E
A heavy flow is established
Congestion is noticed at D
A Choke packet is sent to A
The flow is reduced at A
The flow is reduced at D
26. Apr. 2006
C





14
F
A heavy flow is established
Congestion is noticed at D
A Choke packet is sent to A
The flow is reduced at F
The flow is reduced at D
INF-3190: Congestion Control
Repair by Choke Packets

Variation

u > threshold: line changes to condition "warning“

Procedure for router



Procedure at receiver


Do not send choke packet to source (indicating destination)
Tag packet (to avoid further choke packets from down stream router)
& forward it
Send choke packet to sender
Other variations

Varying choke packets depending on state of congestion



Warning
Acute warning
For u instead of utilization


26. Apr. 2006
Queue length
....
15
INF-3190: Congestion Control
Repair by Choke Packets

Properties


Effective procedure
But

Possibly many choke packets in the network



End systems can (but do not have to) adjust the traffic
Choke packets take time to reach source


Transient congestion may have passed when the source reacts
Oscillations


26. Apr. 2006
Even if Choke bits may be included in the data at the senders
to minimize reflux
Several end systems reduce speed because of choke packets
Seeing no more choke packets, all increase speed again
16
INF-3190: Congestion Control
Repair with Fair Queuing

Background


Principle



On each outgoing line each end-system receives its own queue
Packet sending based on Round-Robin
(always one packet of each queue (sender))
Enhancement "Fair Queuing with Byte-by-Byte Round Robin“



End-system adapting to traffic (e.g. by Choke-Packet algorithm) should not be
disadvantaged
Adapt Round-Robin to packet length
But weighting is not taken into account
Enhancement "Weighted Fair Queuing“


Favoring (statistically) certain traffic
Criteria variants



26. Apr. 2006
In relation to VPs (virtual paths)
Service specific (individual quality of service)
etc.
17
INF-3190: Congestion Control
Congestion Avoidance
26. Apr. 2006
18
INF-3190: Congestion Control
Avoidance

Principle


Appropriate communication system behavior and design
Policies at various layers can affect congestion

Data link layer




Network layer





Flow control
Acknowledgements
Error treatment / retransmission / FEC
Datagram (more complex) vs. virtual circuit (more procedures
available)
Packet queueing and scheduling in router
Packet dropping in router (including packet lifetime)
Selected route
Transport layer


26. Apr. 2006
Basically the same as for the data link layer
But some issues are harder (determining timeout interval)
19
INF-3190: Congestion Control
Avoidance by Traffic Shaping

Motivation


Congestion is often caused by bursts
Bursts are relieved by smoothing the traffic (at the price of a delay)
Original packet arrival
Smoothed stream
Peak rate
time

Procedure


Negotiate the traffic contract beforehand (e.g., flow specification)
The traffic is shaped by sender



Average rate and
Burstiness
Applied


26. Apr. 2006
In ATM
In the Internet (“DiffServ” - Differentiated Services)
20
INF-3190: Congestion Control
Traffic Shaping with Leaky Bucket

Principle



Described by



Continuous outflow
Congestion corresponds to
data loss
Implementation
Symbolic:
with limited buffers
bucket with
Input
outflow per time
lines
Packet rate
Queue length
Implementation

Easy if packet length stays
constant (like ATM cells)
Output
lines
26. Apr. 2006
21
INF-3190: Congestion Control
Traffic Shaping with Token Bucket

Principle




Permit a certain amount of data
to flow off for a certain amount of
time
Controlled by "tokens“
Number of tokens limited
Implementation

Add tokens periodically


Remove token


Until maximum has been reached)
Depending on the length of the
packet (byte counter)
Comparison

Leaky Bucket


Max. constant rate (at any point
in time)
Token Bucket

26. Apr. 2006
Permits a limited burst
22
INF-3190: Congestion Control
Traffic Shaping with Token Bucket

Principle





Permit a certain amount of data
to flow off for a certain amount of
time
Controlled by "tokens“
Number of tokens limited
Number of queued packets limited
Implementation

Add tokens periodically


Remove token


Until maximum has been reached)
Depending on the length of the
packet (byte counter)
packet burst
Comparison

Leaky Bucket


Max. constant rate (at any point
in time)
Token Bucket

26. Apr. 2006
Permits a limited burst
23
INF-3190: Congestion Control
Traffic Shaping with Token Bucket

Principle





Permit a certain amount of data
to flow off for a certain amount of
time
Controlled by "tokens“
Number of tokens limited
Number of queued packets limited
Implementation

Add tokens periodically


Remove token


Until maximum has been reached)
Depending on the length of the
packet (byte counter)
Comparison

Leaky Bucket


Max. constant rate (at any point
in time)
Token Bucket

26. Apr. 2006
Permits a limited burst
24
INF-3190: Congestion Control
Avoidance by Reservation: Admission
Control
A
A
B

Principle



Prerequisite: virtual circuits
Reserving the necessary resources (incl. buffers) during connect
If buffer or other resources not available



B
Alternative path
Desired connection refused
Example


Network layer may adjust routing based on congestion
When the actual connect occurs
26. Apr. 2006
25
INF-3190: Congestion Control
Avoidance by Reservation
Admission Control

sender
Sender oriented

Sender (initiates reservation)
1. reserve
Must know target addresses
(participants)
Not scalable
Good security
data flow



2. reserve
3. reserve
receiver
26. Apr. 2006
26
INF-3190: Congestion Control
Avoidance by Reservation
Admission Control

sender
Receiver oriented

Receive (initiates reservation)



Needs advertisement before
reservation
Must know “flow” addresses


data flow
2. reserve
Sender

3. reserve
Need not to know receivers
More scalable
Insecure
1. reserve
receiver
26. Apr. 2006
27
INF-3190: Congestion Control
Avoidance by Reservation
Admission Control

sender
Combination?
1. reserve

Start sender oriented reservation
data flow
2. reserve
reserve from
nearest router
3. reserve
receiver
26. Apr. 2006
28
INF-3190: Congestion Control
Avoidance by Buffer Reservation

Principle



One buffer per router and
connection (simplex, VC=virtual
circuit)
1
2
Implementation variant: Sliding
Window protocol

rsvd for
conn 1
unreserved
buffers
Implementation variant: Stopand-Wait protocol


Buffer reservation
3
m buffers per router and
(simplex-) connection
Properties


Congestion not possible
Buffers remain reserved,


Even if there is no data
transmission for some periods
1
Usually only with applications that
require low delay & high
bandwidth
26. Apr. 2006
2
3
29
INF-3190: Congestion Control
Avoidance by Isarithmic Congestion
Control

Principle

Limiting the number of packets in the network by assigning
"permits“


Amount of "permits" in the network
A "permit" is required for sending



When sending: "permit" is destroyed
When receiving: "permit" is generated
Problems





Parts of the network may be overloaded
Equal distribution of the "permits" is difficult
Additional bandwidth for the transfer of "permits" necessary
Bad for transmitting large data amounts (e.g. file transfer)
Loss of "permits" hard to detect
26. Apr. 2006
30
INF-3190: Congestion Control
Avoidance: combined approaches

Controlled load


Traffic in the controlled load class experiences the network as empty
Approach


Allocate few buffers for this class on each router
Use admission control for these few buffers





Reservation is in packets/second (or Token Bucket specification)
Router knows its transmission speed
Router knows the number of packets it can store
Strictly prioritize traffic in a controlled load class
Effect


Controlled load traffic is hardly ever dropped
Overtakes other traffic
26. Apr. 2006
31
INF-3190: Congestion Control
Avoidance: combined approaches

Expedited forwarding



Very similar to controlled load
A differentiated services PHB (per-hop-behavior)
Approach


Set aside few buffers for this class on each router
Police the traffic




Shape or mark the traffic
Only at senders, or at some routers
Strictly prioritize traffic in a controlled load class
Effect



Shapers drop excessive
traffic
EF traffic is hardly ever
dropped
Overtakes other traffic
Version
IHL
DS
Total length
Identification
DM
Fragment offset
Time to live
Protocol
Header checksum
Source address
Destination Address
1 0 1 1 1 0 0 0
26. Apr. 2006
32
INF-3190: Congestion Control
Internet Congestion Control
TCP Congestion Control
26. Apr. 2006
33
INF-3190: Congestion Control
TCP Congestion Control

TCP limits sending rate as a function of
perceived network congestion



Little traffic – increase sending rate
Much traffic – reduce sending rate
TCP’s congestion algorithm has four major
“components”:




Additive-increase
Multiplicative-decrease (together AIMD algorithm)
Slow-start
Reaction to timeout events
26. Apr. 2006
34
INF-3190: Congestion Control
TCP Congestion Control
receiver
Initially, the CONGESTION WINDOW
is 1 MSS (message segment size)
round 1
sender
round 2
sent packets
per round
(congestion window)
round 3
16
Then, the size increases by 1 for each
received ACK
until
a threshold is reached
or
an ACK is missing
8
round 4
4
2
1
26. Apr. 2006
35
time
INF-3190: Congestion Control
TCP Congestion Control
Normally, the threshold is 64K
sent packets
per round
(congestion window)
Loosing a single packet (TCP Tahoe):
 threshold drops to half CONGESTION WINDOW
 CONGESTION WINDOW back to 1
80
75
70
65
16
60
55
Loosing a single packet (TCP Reno):
 if notified by timeout: like TCP Tahoe
 if notified by fast retransmit:
threshold drops to half CONGESTION WINDOW
 CONGESTION WINDOW back to new threshold
50
45
40
35
8
30
25
20
4
15
2
10
1
5
26. Apr. 2006
36
time Congestion Control
INF-3190:
AIMD

Threshold



Assumption


Adaptive
Parameter in addition to the actual and the congestion window
Threshold, i.e. adaptation to the network: “sensible window size”
Use: on missing acknowledgements


Threshold is set to half of current congestion window
Congestion window is reduced



Implementation- and situation-dependant: to 1 or to new threshold
Use slow start of congestion window is below threshold
Use: on timeout



Threshold is set to half of current congestion window
Congestion window is reset to one maximum segment
Use slow start to determine what the network can handle


26. Apr. 2006
Exponential growth stops when threshold is hit
From there congestion window grows linearly (1 segment) on successful
transmission
39
INF-3190: Congestion Control
TCP Congestion Control

Some parameters



65.536 byte max. per segment
IP recommended value TTL interval 2 min
Optimization for low throughput rate

Problem


Algorithm


1 byte data requires 162 byte incl. ACK
(if, at any given time, it shows up just by itself)
Acknowledgment delayed by 500 msec because of window
adaptation
Comment

26. Apr. 2006
Often part of TCP implementation
40
INF-3190: Congestion Control
TCP Congestion Control

TCP assumes that every loss is an indication for
congestion

Not always true


Packets may be discarded because of bit errors
Low bit error rates




High bit errors rates




Optical fiber
Copper cable under normal conditions
Mobile phone channels (link layer retransmission)
Modem cables
Copper cable in settings with high background noise
HAM radio (IP over radio)
TCP variations exist
26. Apr. 2006
41
INF-3190: Congestion Control
TCP Congestion Control

TCP congestion control is based on the notion that the
network is a “black box”


Congestion indicated by a loss
Sufficient for best-effort applications, but losses might
severely hurt traffic like audio and video streams
 congestion indication better enabling features like
quality adaptation

Approaches

Use ACK rate rather than losses for bandwidth estimation


Example: TCP Westwood
Use active queue management to detect congestion
26. Apr. 2006
42
INF-3190: Congestion Control
Internet Congestion Control
TCP Congestion Avoidance
26. Apr. 2006
52
INF-3190: Congestion Control
Random Early Detection (RED)


Random Early Detection (discard/drop) (RED) uses active queue
management
Drops packet in an intermediate node based on average queue
length exceeding a threshold



TCP receiver reports loss in ACK
Sender applies multiple decrease
Idea


Congestion should be attacked as early as possible
Some transport protocols (e.g., TCP) react to lost packets by rate
reduction
26. Apr. 2006
53
INF-3190: Congestion Control
Random Early Detection (RED)

Router drops some packet before congestion significant (i.e., early)


Gives time to react
Dropping starts when moving avg. of queue length exceeds
threshold



Small bursts pass through unharmed
Only affects sustained overloads
Packet drop probability is a function of mean queue length

Prevents severe reaction to mild overload

RED improves performance of a network of cooperating TCP
sources

No bias against bursty sources

Controls queue length regardless of endpoint cooperation
26. Apr. 2006
54
INF-3190: Congestion Control
Early Congestion Notification (ECN)

Early Congestion Notification (ECN) - RFC 2481




an end-to-end congestion avoidance mechanism
Implemented in routers and supported by end-systems
Not multimedia-specific, but very TCP-specific
Two IP header bits used



ECT - ECN Capable Transport, set by sender
CE - Congestion Experienced, may be set by router
Extends RED

if packet has ECT bit set




ECN node sets CE bit
TCP receiver sets ECN bit in ACK
sender applies multiple decrease (AIMD)
else

26. Apr. 2006
Act like RED
55
INF-3190: Congestion Control
Early Congestion Notification (ECN)
Tail drop
RED
ECN

Effects



Congestion is not oscillating - RED & ECN
ECN-packets are never lost on uncongested links
Receiving an ECN mark means



26. Apr. 2006
TCP window decrease
No packet loss
No retransmission
56
INF-3190: Congestion Control
Endpoint Admission Control

Motivation



Applicability





Let end-systems test whether a desired throughput can be
supported
In case of success, start transmission
Only for some kinds of traffic (traffic classes)
Inelastic flows
Requires exclusive use of some resources for this traffic
Assumes short queues in that traffic class
Send probes at desired rate


Routers can mark or drop probes
Probe packets can have separate queues or use main queue
26. Apr. 2006
57
INF-3190: Congestion Control
Endpoint Admission Control

Thrashing and Slow Start Probing

Thrashing




Many endpoints probe concurrently
Probes interfere with each other and all deduce insufficient
bandwidth
Bandwidth is underutilized
Slow start probing





26. Apr. 2006
Probe for small bandwidth
Probe for twice the amount of bandwidth
…
Until desired speed is reached
Start sending
58
INF-3190: Congestion Control
XCP: eXplicit Control Protocol
Provide feedback
initialize
Round-trip-time
Desired congestion window
update
Feedback
IP header
26. Apr. 2006
XCP
TCP header
Payload
59
INF-3190: Congestion Control
XCP: eXplicit Control Protocol

Congestion Controller




Goal: Match input
traffic to link capacity
Compute an average
RTT for all connections
Looks at queue




26. Apr. 2006
Fairness Controller


Combined traffic
changes by 
 ~ Spare Bandwidth
 ~ - Queue Size
sendable per RTT
So,  =  Spare - 
Goal: Divide 
between flows to
converge to fairness
Looks at a state in XCP
header


If  > 0  Divide 
equally between flows
If  < 0  Divide 
between flows
proportionally to their
current rates
Queue
60
INF-3190: Congestion Control
TCP Friendliness
26. Apr. 2006
61
INF-3190: Congestion Control
TCP Friendliness - TCP Compatible

A TCP connection’s throughput is bounded



Congestion windows size changes


AIMD (additive increase, multiple decrease) algorithm
TCP is said to be fair


wmax - maximum retransmission window size
RTT - round-trip time
Streams that share a path will reach an equal share
A protocol is TCP-friendly if

Colloquial


It long-term average throughput is not bigger than TCP’s
Formal

26. Apr. 2006
Its arrival rate is at most some constant over the square root of the packet
loss rate
62
INF-3190: Congestion Control
TCP Friendliness
A TCP connection’s throughput is
bounded
The TCP send rate limit is
Rs 
 wmax - maximum retransmission
window size
 RTT - round-trip time
Congestion windows size changes
 AIMD algorithm
 additive increase, multiple decrease
wmax
RTT
In case of at least one loss in an
RTT
w    w,  1
In case of no loss ,
2
w  w  , 1
TCP is said to be fair
 Streams that share a path will
reach an equal share
26. Apr. 2006
That’s not generally true
 Bigger RTT
 higher loss probability per RTT
 slower recovery
 Disadvantage for long-distance traffic
63
INF-3190: Congestion Control
TCP Friendliness

A protocol is TCP-friendly if


Rr  p  C
Colloquial: It long-term average
throughput is not bigger than
TCP’s
Formal: Its arrival rate is at most
some constant over the square
root
of the packet loss rate
P – packet loss rate
C – constant value
Rr – packet arrival rate

The AIMD algorithm with ≠1/2 and ≠1 is still TCP-friendly,

TCP-friendly protocols may - if the rule is not violated -
if the rule is not violated




Probe for available bandwidth faster than TCP
Adapt to bandwidth changes more slowly than TCP
Use different equations or statistics, i.e., not AIMD
Not use slow start (i.e., don’t start with w=0)
26. Apr. 2006
64
INF-3190: Congestion Control
Datagram Congestion Control Protocol
(DCCP)

Datagram Congestion Control Protocol



Transport Protocol




Under development
http://www.ietf.org/html.charters/dccp-charter.html
Offers unreliable delivery
Low overhead like UDP
Applications using UDP can easily change to this new protocol
Accommodates different congestion control mechanisms

Congestion Control IDs (CCIDs)




Add congestion control schemes on the fly
Choose a congestion control scheme
TCP-friendly Rate Control (TFRC) is included
Half-Connection

26. Apr. 2006
Data Packets sent in one direction
65
INF-3190: Congestion Control