congestion control

26. Apr. 2006 1 INF-3190: Congestion Control

Congestion Control

Foreleser: Carsten GriwodzEmail: [email protected]


Congestion 2 problem areas

Receiver capacity Approached by flow control

Network capacity Approached by congestion control

Possible approach to avoid both bottlenecks 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

All packets from all sources with a common distinguishing property, e.g. priority


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


Congestion Reasons for congestion,

among others Incoming traffic overloads outgoing

lines Router too slow for routing algorithms Too little buffer space in router

When too much traffic isoffered

Congestion sets in Performance degrades sharply

maximum transmissioncapacity ofthe subnet

perfect

desirable

congested

packets sent by application

pack

ets

deliv

ere

d

Congestion tends to amplify itself Network layer: unreliable service

Router simply drops packet due to congestion Transport layer: reliable service

Packet is retransmitted

Congestion => More delays at end-systemsHigher delays => RetransmissionsRetransmissions => Additional traffic


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

Before congestion happens Initiate countermeasures at the sender Initiate countermeasures at the receiver Methods: leaky bucket, token bucket, isarithmic congestion

control, reservation, …


Repair Principle

No resource reservation Necessary steps

Congestion detected Introduce appropriate procedures for reduction


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

Buffer packet until reception has been acknowledged


Repair by Packet dropping

Assigning buffers to queues at output lines1. 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 Unused lines are starved

Outputlines

Inputlines


Repair by Packet dropping4. Content-related dropping: relevance

Relevance of data connection as a wholeor every packet from one end system to another end system

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

Relevance of a traffic class 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


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


Repair by Choke Packets Principle

Reduce traffic during congestion by telling source to slow down

Procedure for router Each outgoing line has one variable

Utilization u ( 0≤u≤1 )

Calculating u: Router checks the line usage f periodically (f is 0 or 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“ Send choke packet to source (indicating destination) Tag packet (to avoid further choke packets from down stream

router) & forward it


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)

Ignore: source ignores further Choke packets until timeout Listen: source listens if more Choke packets are arriving

yes: further reduction by X2%;go to Ignore phase

no: increase the data traffic


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

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

A

B C

D

E F

Hop-by-hop Choke packets

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

A

B C

D

E F


Repair by Choke Packets Variation

u > threshold: line changes to condition "warning“ Procedure for router

Do not send choke packet to source (indicating destination) Tag packet (to avoid further choke packets from down stream

router) & forward it Procedure at receiver

Send choke packet to sender

Other variations Varying choke packets depending on state of congestion

Warning Acute warning

For u instead of utilization Queue length ....


Repair by Choke Packets Properties

Effective procedure But

Possibly many choke packets in the network Even if Choke bits may be included in the data at the senders

to minimize reflux 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

Several end systems reduce speed because of choke packets Seeing no more choke packets, all increase speed again


Repair with Fair Queuing Background

End-system adapting to traffic (e.g. by Choke-Packet algorithm) should not be disadvantaged

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“ Adapt Round-Robin to packet length But weighting is not taken into account

Enhancement "Weighted Fair Queuing“ Favoring (statistically) certain traffic Criteria variants

In relation to VPs (virtual paths) Service specific (individual quality of service) etc.


Congestion Avoidance


Avoidance Principle

Appropriate communication system behavior and design Policies at various layers can affect congestion

Data link layer Flow control Acknowledgements Error treatment / retransmission / FEC

Network layer 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 Basically the same as for the data link layer But some issues are harder (determining timeout interval)


Avoidance by Traffic Shaping Motivation

Congestion is often caused by bursts Bursts are relieved by smoothing the traffic (at the price of a delay)

Procedure Negotiate the traffic contract beforehand (e.g., flow specification) The traffic is shaped by sender

Average rate and Burstiness

Applied In ATM In the Internet (“DiffServ” - Differentiated Services)

Smoothed streamPeak rate

Original packet arrival

time


Traffic Shaping with Leaky Bucket

Principle Continuous outflow Congestion corresponds to

data loss

Described by Packet rate Queue length

Implementation Easy if packet length stays

constant (like ATM cells)

Outputlines

Inputlines

Symbolic:bucket with

outflow per time

Implementationwith limited buffers


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

Until maximum has been reached)

Remove token Depending on the length of

the packet (byte counter) Comparison

Leaky Bucket Max. constant rate (at any

point in time) Token Bucket

Permits a limited burst





Controlled by "tokens“ Number of tokens limited Number of queued packets

limited Implementation

Add tokens periodically Until maximum has been

reached) Remove token

Depending on the length of the packet (byte counter)

Comparison Leaky Bucket

Max. constant rate (at any point in time)

Token Bucket Permits a limited burst

packet burst





Controlled by "tokens“ Number of tokens limited Number of queued packets

limited Implementation

Add tokens periodically Until maximum has been

reached) Remove token

Depending on the length of the packet (byte counter)

Comparison Leaky Bucket

Max. constant rate (at any point in time)

Token Bucket Permits a limited burst


Avoidance by Reservation: Admission Control

Principle Prerequisite: virtual circuits Reserving the necessary resources (incl. buffers) during connect If buffer or other resources not available

Alternative path Desired connection refused

Example Network layer may adjust routing based on congestion When the actual connect occurs

A

B

A

B


Avoidance by ReservationAdmission Control

Sender oriented Sender (initiates reservation)

Must know target addresses (participants)

Not scalable Good security

1. reserve

2. reserve

3. reserve

receiver

sender

data flow



Receiver oriented Receive (initiates reservation)

Needs advertisement before reservation

Must know “flow” addresses

Sender Need not to know receivers More scalable Insecure

1. reserve

2. reserve

3. reserve

receiver

sender

data flow



Combination?

Start sender oriented reservation

receiver

sender

data flow

reserve from nearest router

1. reserve

2. reserve

3. reserve


Avoidance by Buffer Reservation Principle

Buffer reservation Implementation variant: Stop-

and-Wait protocol One buffer per router and

connection (simplex, VC=virtual circuit)

Implementation variant: Sliding Window protocol

m buffers per router and (simplex-) connection

Properties Congestion not possible Buffers remain reserved,

Even if there is no data transmission for some periods

Usually only with applications that require low delay & high bandwidth

1

2

3

unreservedbuffers

rsvd forconn 1

1

2

3


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


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


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

Version IHL DSIdentification

Total lengthDM Fragment offset

Time to live Protocol

Destination AddressSource address

Header checksum

0 0001 1 1 1

Effect Shapers drop

excessive traffic EF traffic is hardly ever

dropped Overtakes other traffic


Internet Congestion Control

TCP 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


TCP Congestion Control sender receiver Initially, the CONGESTION

WINDOW is 1 MSS (message segment size)

rou

nd

1ro

un

d 2

rou

nd

3ro

un

d 4

sent packetsper round(congestion window)

time

16

8

4

2

1

Then, the size increases by 1 for each received ACK untila threshold is reachedoran ACK is missing


TCP Congestion Control

16

8

4

2

1

Normally, the threshold is 64K

sent packetsper round

(congestion window)

time

40

20

10

5

80

15

30

25

35

75

55

45

50

65

60

70

Loosing a single packet (TCP Tahoe): threshold drops to half CONGESTION WINDOW CONGESTION WINDOW back to 1Loosing 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


AIMD Threshold

Adaptive Parameter in addition to the actual and the congestion window

Assumption 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

Exponential growth stops when threshold is hit From there congestion window grows linearly (1 segment) on

successful transmission


TCP Congestion Control Some parameters

65.536 byte max. per segment IP recommended value TTL interval 2 min

Optimization for low throughput rate Problem

1 byte data requires 162 byte incl. ACK (if, at any given time, it shows up just by itself)

Algorithm Acknowledgment delayed by 500 msec because of window

adaptation Comment

Often part of TCP implementation


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

Optical fiber Copper cable under normal conditions Mobile phone channels (link layer retransmission)

High bit errors rates Modem cables Copper cable in settings with high background noise HAM radio (IP over radio)

TCP variations exist


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


Internet Congestion Control

TCP Congestion Avoidance


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


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


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 Act like RED


Early Congestion Notification (ECN)

Effects Congestion is not oscillating - RED & ECN ECN-packets are never lost on uncongested links Receiving an ECN mark means

TCP window decrease No packet loss No retransmission

Tail drop

RED

ECN


Endpoint Admission Control Motivation

Let end-systems test whether a desired throughput can be supported

In case of success, start transmission

Applicability 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


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 Probe for small bandwidth Probe for twice the amount of bandwidth … Until desired speed is reached Start sending


XCP: eXplicit Control Protocol

IP header TCP headerXCP Payload

Round-trip-time

Desired congestion window

Feedback

initialize

update

Provide feedback


XCP: eXplicit Control Protocol Congestion

Controller Goal: Match input

traffic to link capacity Compute an average

RTT for all connections

Looks at queue Combined traffic

changes by ~ Spare Bandwidth ~ - Queue Size

sendable per RTT So, = Spare -

Queue

Fairness Controller 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


TCP Friendliness


TCP Friendliness - TCP Compatible

A TCP connection’s throughput is bounded wmax - maximum retransmission window size RTT - round-trip time

Congestion windows size changes AIMD (additive increase, multiple decrease) algorithm

TCP is said to be fair 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

Its arrival rate is at most some constant over the square root of the packet loss rate


TCP Friendliness

RTT

wRs

max

21, ww

In case of at least one loss in an RTT

In case of no loss , 1, ww

Congestion windows size changes

AIMD algorithm additive increase, multiple

decrease

TCP is said to be fair Streams that share a path will

reach an equal share

That’s not generally true Bigger RTT

higher loss probability per RTT slower recovery

Disadvantage for long-distance traffic

A TCP connection’s throughput is bounded

wmax - maximum retransmission window size

RTT - round-trip time

The TCP send rate limit is


TCP Friendliness A protocol is TCP-friendly if

Colloquial: It long-term averagethroughput is not bigger than TCP’s

Formal: Its arrival rate is at mostsome constant over the square rootof the packet loss rate

The AIMD algorithm with ≠1/2 and ≠1 is still TCP-friendly, if the rule is not violated

TCP-friendly protocols may - 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)

CpRr

P – packet loss rate

C – constant value

Rr – packet arrival rate


Datagram Congestion Control Protocol (DCCP)

Datagram Congestion Control Protocol Under development http://www.ietf.org/html.charters/dccp-charter.html

Transport Protocol 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 Data Packets sent in one direction

congestion control

Documents

congestion windowvalid

congestion controlforeleser

isarithmic congestion

choke packets

testedincoming packet

minactual window

leaky bucket

endsystemshigher delays