congestion control - universitetet i osloheim.ifi.uio.no/~inf3190/forelesninger05/2005mai04...04....

04. Mai 2005 1 INF-3190: Congestion Control

Congestion Control

Foreleser: Carsten GriwodzEmail: [email protected]


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 Controlsender receiver Initially, the CONGESTION WINDOW

is 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

21

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


TCP Congestion Control

16

8

4

21

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


Congestion Control: Example! Parameters

! Maximum segment size = 1024 bytes! Initial congestion window = 64 KB

! Areas! Previously (transm. nr. = 0)

! Congestion window before timeout: 64 KB! Threshold after timeout: 32 KB! Congestion window after timeout: 1 KB

! Exponential area! �slow start�

! Linear area! �congestion avoidance�

! Note! Altways observe receiver�s window size, i.e. use minimum of

! Congestion window! Actual send window (receiver status)


Additive Increase! Objective

! To avoid immediate network overload! After just recent overload has finished! After timeout! At the start of a data transmission

! Method: congestion window! Defined/initiated at connection set-up

! Initial max. window size = 1 segment! Threshold (based on previous max. window size)

! Max. size of segment to be transferred! To be doubled as long as

! 1. segment size below a certain threshold and! 2. all ACKs arrive in time (i.e. correct segment transfer)! (each burst acknowledged, i.e. successfully transmitted,

doubles congestion window)! To be linearly increased

! 1. segment size above a certain threshold and! 2. all ACKs arrive in time (i.e. correct segment transfer)


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


The TCP family! TCP Tahoe

! Oldest TCP variation still around! Assumes that every packets loss is due to congestion! If there is at least one loss during one RTT

! Reduction of threshold to half of the congestion window! Congestion window back to 1! Slow start

! Only the missing packet is retransmitted! Efficient handling of single losses! Inefficient handling of multiple losses by RTT

! �Fast Retransmit�! One packet is sent for every arriving packet! If there is a gap, acknowledge the last packet before the gap again! Sender interprets 3 ACKs for the same packet as a loss event


The TCP family! TCP Reno

! Next oldest variation still around! In case of Fast Retransmit, continue with �Fast Recovery�

! Reduction of the threshold to half the congestion window! Congestion window to the new threshold! Do not enter slow start

! Increase the congestion window for every ACK, even if it is a duplicate ACK

! An arriving ACK means that a packet has arrived! Although the sender doesn�t know which


The TCP family! Problem: Packets get dropped in bursts

! When queues get full and routers drop packets, all senders require time to notice the problem and back off

! Multiple losses are more likely than Tahoe and Reno assume! Particularly bad for Reno

! First approach! TCP New Reno

! TCP New Reno! Most frequently used today! Sender-only modification to TCP Reno! Define duration of Fast Recovery

! Note the highest sequence number sent when fast recovery was entered! Stay in fast recovery until that sequence number is ACK�d

! For duplicate ACKs received during fast recovery! Don�t reduce the congestion window or threshold! Retransmit the lost packet! Do not extend the fast recovery period! Increase the congestion window by 1 (as for good ACKs)


The TCP family! Problem: Assumes that every loss is an indication for congestion

! But loss may be due to bit errors! Severity: growing because of wireless links, satellite links and new bit-error

sources at multi-gigabit speeds! Approach

! TCP SACK

! TCP Sack (Selective ACK)! Becoming wide-spread! Modification at both sides! Reports in addition to standard cumulative ACK

! Successfully received blocks of packets behind a gap! Always including the packets that triggered the ACK in first block

! Uses a TCP option! There can�t be more than 40 bytes TCP options per packet! SACK requires 2+8*n! Most likely used with 10 bytes timestamp option (PAWS option)! Therefore no more than 3 blocks

! Distinguish: single loss, multiple loss, actual duplicates


The TCP family! Bottleneck router

! Term used under the assumption that exactly one router between sender and receiver is responsible for packet loss

! Approaches look for! Capacity of the bottleneck router! Available bandwidth at the bottleneck router

! Bandwidth-delay product

! 1 Gbit/s, 40msec # 41Mbit can be �in flight�

...

...

...Data Acknowledgements

t=0 t=11.2 µsec t=20 msec t=40 msec


The TCP family! Problem: A loss event reduces congestion window but

not sending rate! Tahoe, Reno, New Reno and SACK will send a new packet for

every incoming ACKs until congestion window is used up! They send in bursts! Bottleck router�s queue grows and shrinks

! Oscillating RTTs, packet drops! Approach

! TCP FACK

! TCP FACK (Forward ACK)! Quite rare! Sender-only modification! In Fast Recovery

! Sender uses a timer to spread packets evenly over one RTT


The TCP family! Problems

! Determines available bandwidth by probing! Incresse the transmission rate until there is a loss event! Severity: blocks advancement of the sliding window until the packet is retransmitted

! Climbs very slowly to highest bandwidth utilization when bandwidth is high! The threshold that ends slow start is fixed to 64k in original TCP! Severity: inhibits high bandwidth communication, esp. communication among

supercomputers! Does not use more than 75% of the available bandwidth! Sawtooth pattern! Severity: resource waste, intensive jitter in high bandwidth environments

! Can�t use high bandwidth if delay is high due to limited credit window size! The problem of �high bandwidth delay products�! Impossible to have more than 216 bytes unacknowledged! Severity: most severe for satellite communication and communication among

supercomputers; problem increases linearly with network speeds, and network speed grows potentially


The TCP family! TCP Vegas

! Rare! Sender-only modification! Tries to fix all of the 3 problems above! Model

! Congestion build-up can be detected! RTT gets longer! Throughput drops


The TCP family! TCP Vegas

! Congestion window maintenance! In each RTT, time-stamp one packet! Between two marked packets, count bytes sent and bytes ACK�d! If throughput lower than expected congestion window � 1! If throughput higher than expected congestion window + 1

! Retransmission handling! Course-grained 500ms timer for original retransmission behavior! Maintain a fine-grained timer for every packet in flight! Retransmit if on the first duplicate ACK if the RTT is exceeded

according to the fine-grained timer! Slow start handling

! Grow congestion window only every second RTT in slow start! Don�t leave slow start until congestion is detected

⇒TCP Vegas is a congestion avoidance approach


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


Datagram Congestion Control Protocol(DCCP)

! Congestion control is plugable! One proposal is TCP-Friendly Rate Control (TFRC)

! Equation-based TCP-friendly congestion control! Receiver sends rate estimate and loss event history! Sender uses models of SACK TCP to compute send rate

)321()8

33,1min(

32

1

2ppbp

tbp

RTT

T

RTO ++=

Steady state TCP send rate

Loss probability

Number of packets ack�d by one ACK

Retransmission timeout

congestion control - universitetet i osloheim.ifi.uio.no/~inf3190/forelesninger05/2005mai04...04....

Documents