congestion control - universitetet i oslo...congestion 2 problem areas •receiver capacity...

Congestion Control

INF3190 / INF4190

Foreleser: Carsten GriwodzEmail: [email protected]

INF3190 / INF4190 - Data Communication

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

ered

Congestion tends to amplify itselfNetwork layer: unreliable service

Router simply drops packet due to congestionTransport 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 establishedCongestion is noticed at DA Choke packet is sent to AThe flow is reduced at AThe flow is reduced at D

A

B C

D

E F

Hop-by-hop Choke packets

A heavy flow is establishedCongestion is noticed at DA Choke packet is sent to AThe flow is reduced at FThe 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 bedisadvantaged

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)

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

Average rate andBurstiness

AppliedIn ATMIn 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 toflow off for a certain amount of time

• 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 intime)

• Token Bucket Permits a limited burst











packet 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



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 forsome periods

• Usually only with applications that requirelow 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 lengthD M Fragment offset

Time to live Protocol

Destination AddressSource address

Header checksum

0 0001 1 1 1

EffectShapers drop excessive trafficEF traffic is hardly everdroppedOvertakes other traffic

Internet Congestion Control

TCP Congestion Control



TCP limits sending rate as a function of perceivednetwork 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



sender receiver Initially, the CONGESTION WINDOWis 1 MSS (message segment size)

roun

d 1

roun

d 2

roun

d 3

roun

d 4

sent packetsper round(congestion window)

time

16

8

4

2

1

Then, the size increases by 1 for eachreceived ACKuntila threshold is reachedoran ACK is missing



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 1

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


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 mightseverely 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 athreshold• 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 tolink capacity

• Compute an average RTT forall 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 Δ equallybetween flows

If Δ < 0 ⇒ Divide Δ betweenflows proportionally to theircurrent 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 anRTT

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 isbounded

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 thanTCP’s

• Formal: Its arrival rate is at mostsome constant over the squareroot of 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 TCPAdapt to bandwidth changes more slowly than TCPUse different equations or statistics, i.e., not AIMDNot 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 - universitetet i oslo...congestion 2 problem areas •receiver capacity...

Documents