bab 6 pertemuan 2 vs2

8/2/2019 Bab 6 Pertemuan 2 Vs2

1/32

1

Flow vs. congestion control

Flow control

Keeping a fast sender from overrunning a slowreceiver

Congestion controlKeeping a set of senders from sending to much

data into the networkbecause of lack of resourcesat some point

We will look at how TCP achieves flow andcongestion control


2/32

2

Data flow, ACKs, windowadvertisement

Sender

Data (SequenceNum)

Acknowledgment +Adv ertisedWindow

Receiver

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


3/32

3

TCP header format

Options (v ariable)

Data

Checksum

SrcPort DstPort

HdrLen 0 Flags

UrgPtr

AdvertisedWindow

SequenceNum

Acknowledgment

0 4 10 16 31


4/32

4

TCP Flow Control

Receive side of TCP

connection has a receive

buffer:

Speed-matching service:

matching the send rate to

the receiving applications

drain rate

Application process may

be slow at reading from

buffer

sender wont overflow

receivers buffer by

transmitting too much,

too fast

flow control

Kurose & Ross


5/32

5

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 bandwidthchanges 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


6/32

6

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 ofcongestion it perceives in network

Decrease window when congestion goes up

Increase window when congestion goes down


7/32

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 (additiveincrease)

Set CongestionWindow to half of its previousvalue (multiplicative decrease)

7


8/32

8

Additive increaseSource Destination

Packets in transit during additiveincrease, with one packet beingadded each RTT


9/32

9

Typical sawtooth pattern of AIMD

60

20

1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0

Time (seconds)

70

30

40

50

10

10.0

Additive increase

Multiplicative decrease

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


10/32

10

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 AdvertisedWindowallows

Every time source successfully sends a window of

packets, doubles the number of packet to

CongestionWindow


11/32

11

Slow Start

Source Destination


12/32

12

Slow start vs. additive increaseSource Destination Source Destination

Slow start Additive increase


13/32

Slow Start Graph

13


14/32

14

Fast Retransmitand 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 halfrather than dropping CongestionWindow all the wayback 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


15/32

15

Fast retransmit

Packet 1

Packet 2

Packet 3

Packet 4

Packet 5

Packet 6

Retransmit

packet 3

ACK 1

ACK 2

ACK 2

ACK 2

ACK 6

ACK 2

Sender Receiv er

Three duplicate ACKs


16/32

Congestion Avoidance

16


17/32

DECbit

17

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


18/32

DECbit

18

A router sets this bit in a packet if its averagequeue length is greater than or equal to 1 at thetime the packet arrives.


19/32

DECbit

19

Source Adjustment :

Packets with the bit set < 50% increases its congestion

window by one packet

Packets with the bit set >= 50%

decreases its congestionwindow to 0.875 times from the previous value


20/32

20

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


21/32

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


22/32

RED

22


23/32

23

MaxP (AvgLen MinThreshold)

(MaxThreshold MinThreshold)

P = TempP/(1 count TempP)

Count : newly arriving packets have been queued

TempP =


24/32

24

Explicit Congestion Notification

RED could also work with an explicitfeedback

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


25/32

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


26/32

There are another algorithms can be used in this

congestion control method, such as :

(CurrentWindow OldWindow)(CurrentRTT OldRTT)

26


27/32

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 theaverage of the minimum and maximum RTTs seen so

far. If it is than decreases the CongestionWindow by

1/8

27


28/32

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-tripdelays based on the product:

28


29/32

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 increasesthe window by one maximum packet size.

29


30/32

Example 3:

Another approaches congestion is the flattening of the

sending rate.

Every RTT, it increases the window size by one packet

and compares the throughput achieved to the throughputwhen 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 algorithmdecreases the window by one packet.

This scheme calculates the throughput by dividing the

number of bytes outstanding in the network by the RTT.

30


31/32

31

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 competingTCP 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


32/32

32

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)

bab 6 pertemuan 2 vs2

Documents