Flow vs.

congestion control
Flow control
Keeping a fast sender from overrunning a slow receiver

Congestion control
Keeping a set of senders from sending to much data into the network because of lack of resources at some point

We will look at how TCP achieves flow and congestion control

1

Data flow, ACKs, window advertisement

Data (SequenceNum) Sender Acknowledgment + Adv ertisedWindow Receiv er

Receiver : send ACKs from data received; also sends (advertises) receiver buffer information
2

TCP header format

0 4 10 SrcPort SequenceNum Acknowledgment HdrLen 0 Checksum Options (v ariable) Data Flags Adv ertisedWindow UrgPtr 16 DstPort 31

TCP Flow Control

Receive side of TCP connection has a receive buffer:

flow control
sender wont overflow receivers buffer by transmitting too much, too fast

Speed-matching service: matching the send rate to the receiving applications drain rate Application process may be slow at reading from buffer

Kurose & Ross

4

TCP congestion control

An end-to-end scheme
Send packets into the network and react to packet losses Determine how much capacity is available in the network

As connections come and go, available bandwidth changes over time

Any given source must be able to adjust the number of packets in transit CongestionWindow : used by source to limit how

much data is allowed to have in transit at a given time

5

Additive Increase/ Multiplicative Decrease (AIMD)

MaxWindow = Min{CongestionWindow, AdvertisedWindow}

TCP source can send no faster than the slowest component (network or destination) can

A source sets CongestionWindow based on level of congestion it perceives in network Decrease window when congestion goes up Increase window when congestion goes down

AIMD
How does a source determine that the network is congested?
Congestion Packet drop Timeout Every time source successfully sends a window of packets, add 1 to CongestionWindow (additive increase) Set CongestionWindow to half of its previous value (multiplicative decrease)

Additive increase
Source Destination

Packets in transit during additive increase, with one packet being added each RTT

Typical sawtooth pattern of AIMD

70 60 50 40 30 20 10 1.0 2.0 3.0 4.0 5.0

Multiplicative decrease

6.0

7.0

8.0

9.0

10.0

Time (seconds)

Additive increase

AIMD is a necessary condition for a congestion control mechanism to be stable (See Chiu and Jains paper)
9

Slow Start
Additive increase is the right approach when source is operating close to available capacity When connection starts, it may take a while to ramp up
TCP uses slow start to increase window rapidly (exponentially) from cold start! Slow start is slower than original TCP in which source starts to send as many packets as AdvertisedWindow allows

Every time source successfully sends a window of packets, doubles the number of packet to CongestionWindow

10

Source

Destination

Slow Start

11

Slow start vs. additive increase

Source Destination Source Destination

12

Slow start

Additive increase

Slow Start Graph

13

Fast Retransmit and Fast Recovery

TCP timeout may take a long time Fast retransmit
Trigger retransmission after 3 duplicate ACKs

Fast recovery
After fast retransmit, cut CongestionWindow in half rather than dropping CongestionWindow all the way back to 1 packet, and then continue with additive increase That is, use slow start at the beginning of a connection and whenever a timeout occurs. Otherwise, follow AIMD

14

Fast retransmit
Sender Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Packet 6 ACK 2 ACK 2 Retransmit packet 3 ACK 6 ACK 1 ACK 2 ACK 2 Receiv er

Three duplicate ACKs

15

Congestion Avoidance
16

DECbit
Idea : split the responsibility for congestion control between the router and end nodes Router monitor the load it experiencing and explicitly notifies the end node when the congestion is about to occur Notification : binary congestion bit (DECbit) Destination node copies the congestion bit into the ACK and sends back to source Source node adjust its sending rate

17

DECbit

A router sets this bit in a packet if its average queue length is greater than or equal to 1 at the time the packet arrives.
18

DECbit
Source Adjustment : Packets with the bit set < 50% increases its congestion window by one packet Packets with the bit set >= 50% decreases its congestion window to 0.875 times from the previous value

19

RED
Random Early Detection (RED)
Each router monitors its own queue length and, when it detects congestion is taking place, notifies the source to adjust its CongestionWindow Notification is implicit: A packet of the source is dropped

RED computes a weighted average queue length

AvgLen = (1 Weight) AvgLen+Weight SampleLen

0 <Weight < 1 SampleLen adalah panjang antrian ketika ukuran sample dibuat
20

RED
RED memiliki dua batas panjang antrian yang memicu aktivitas tertentu yaitu : MinThreshold dan MaxThreshold if AvgLen MinThreshold queue the packet
if MinThreshold < AvgLen < MaxThreshold

calculate probability P drop the arriving packet with probability P

if MaxThreshold AvgLen

drop the arriving packet

21

RED

22

TempP =

MaxP (AvgLen MinThreshold) (MaxThreshold MinThreshold) = TempP/(1 count TempP)

23

Count : newly arriving packets have been queued

Explicit Congestion Notification

RED could also work with an explicit feedback scheme by marking packets
Set Explicit Congestion Notification (ECN) bits IPs TOS field bits are used

Such a scheme is called active queue management

Exchange information between hosts and routers

24

Source-based Congestion Avoidance

Detect the congestion from the end host Idea : watch some signs from the networks router if its queue is building up

25

 There are another algorithms can be used in this congestion control method, such as :
(CurrentWindow OldWindow)(CurrentRTT OldRTT)

26

Example 1:
Source : detects from measurable increase of RTT for @ successive packet it sends Simple algorithm: check the current RTT whether it is greater than the average of the minimum and maximum RTTs seen so far. If it is than decreases the CongestionWindow by 1/8

27

Example 2:
The decision as to whether or not to change the current window size is based on :
changes to both the RTT and the window size.

The window is adjusted once every two round-trip delays based on the product:

28

Example 2:
If the result is positive, the source decreases the window size by one-eighth; If the result is negative or zero, the source increases the window by one maximum packet size.

29

Example 3:
Another approaches congestion is the attening of the sending rate. Every RTT, it increases the window size by one packet and compares the throughput achieved to the throughput when the window was one packet smaller. If the difference is less than one-half the throughput achieved when only one packet was in transitas was the case at the beginning of the connectionthe algorithm decreases the window by one packet. This scheme calculates the throughput by dividing the number of bytes outstanding in the network by the RTT.
30

Equation-based congestion control

Real-time applications use UDP, which is greedy Add TCP-like congestion control mechanism to UDP
Result: UDP+CC Be TCP-friendly in the sense of being fair to competing TCP flows

Ensure that flows behavior adheres to an equation that models TCPs behavior:
1 Rate RTT p
where p is the loss rate

Note that the receiver will have to periodically report the loss rate

31

Related reading
Peterson & Davie: 5.1-5.2 (UDP/TCP background) Kurose & Ross: 3.5.5, 3.7 (TCP Flow/Congestion Control) Peterson & Davie: 6.3 (TCP Congestion Control) Peterson & Davie: 6.4.2 (RED) Peterson & Davie: 6.5.4 (Equation-based Congestion Control)

32