0% found this document useful (0 votes)
40 views

Transp Layer2

This document discusses approaches to congestion control, including end-to-end control used by TCP and network-assisted control used by ATM. It provides examples of TCP and ATM congestion control. For TCP, it describes the additive increase, multiplicative decrease approach where the congestion window is slowly increased until a loss event triggers cutting the window in half. It also discusses the use of slow start to initially ramp up transmission rate exponentially until the first loss event.
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
40 views

Transp Layer2

This document discusses approaches to congestion control, including end-to-end control used by TCP and network-assisted control used by ATM. It provides examples of TCP and ATM congestion control. For TCP, it describes the additive increase, multiplicative decrease approach where the congestion window is slowly increased until a loss event triggers cutting the window in half. It also discusses the use of slow start to initially ramp up transmission rate exponentially until the first loss event.
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

Transport Layer(contd..

) Layer

Approaches towards congestion control


Two broad approaches towards congestion control: End-end congestion control: Network-assisted congestion control:

no explicit feedback from network congestion inferred from end- routers provide feedback to end systems system observed loss, delay single bit indicating congestion approach taken by TCP (SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at

Case study: ATM ABR congestion control


elastic service if senders path underloaded: sender should use available bandwidth if senders path congested: sender throttled to minimum guaranteed rate

ABR: available bit rate:

sent by sender, interspersed with data cells bits in RM cell set by switches (network-assisted) NI bit: no increase in rate (mild congestion) CI bit: congestion indication RM cells returned to sender by receiver, with bits intact

RM (resource management) cells:

Case study: ATM ABR congestion control


Two-byte ER (explicit rate) field in RM cell
congested switch may lower ER value in cell sender send rate thus maximum supportable rate on path

EFCI bit in data cells: set to 1 in congested switch


if data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell

TCP congestion control: - additive increase, multiplicative decrease


Approach: increase transmission rate (window size),

probing for usable bandwidth, until loss occurs additive increase: increase CongWin by 1 MSS every RTT until loss detected multiplicative decrease: cut CongWin in half after loss
c o n g e s tio n w in d o w 2 4 K b y te s

congestion window size

Saw tooth behavior: probing for bandwidth

1 6 K b y te s

8 K b y te s

time tim e

TCP Congestion Control: details


sender limits transmission: Roughly,
LastByteSent-LastByteAcked CongWin CongWin Bytes/sec RTT

rate =

CongWin is dynamic, function of perceived network congestion

AIMD slow start conservative after timeout events

How does sender perceive congestion? loss event = timeout or 3 duplicate acks TCP sender reduces rate (CongWin) after loss event three mechanisms:

TCP Slow Start


When connection begins, CongWin = 1 MSS
Example: MSS = 500 bytes & RTT = 200 msec initial rate = 20 kbps

When connection begins,

increase rate exponentially fast until first loss event

available bandwidth may be >> MSS/RTT


desirable to quickly ramp up to respectable rate

TCP Slow Start (more)


When connection begins, increase rate exponentially until first loss event:
-double CongWin every RTT -done by incrementing CongWin for every ACK received
Host A
RTT

Host B
one segm en t

two segm ents

Summary: initial rate is slow


but ramps up exponentially fast

four segm en

ts

time

Refinement
Implementation:
Variable Threshold At loss event, Threshold is set to 1/2 of CongWin just before loss event
Q: When should the exponential increase switch to linear? A: When CongWin gets to 1/2 of its value before timeout.

Refinement: inferring loss


After 3 dup ACKs: CongWin is cut in half window then grows linearly But after timeout event: CongWin instead set to 1 MSS; window then grows exponentially to a threshold, then grows linearly

3 dup ACKs indicates

network capable of delivering some segments timeout indicates a more alarming congestion scenario

Summary: TCP Congestion Control


When CongWin is below Threshold, sender in slowstart phase, window grows exponentially. When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly. When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold. When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.

You might also like