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

NetworkCongestion Causes Effects Controls

Uploaded by

Wrecking Wolf
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views

NetworkCongestion Causes Effects Controls

Uploaded by

Wrecking Wolf
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

Data Communication & Networks

G22.2262-001

Session 9 - Main Theme


Network Congestion: Causes, Effects, Controls

Dr. Jean-Claude Franchitti

New York University


Computer Science Department
Courant Institute of Mathematical Sciences

Agenda
„ What is Congestion?
„ Effects of Congestion
„ Causes/Costs of Congestion
„ Approaches Towards Congestion Control
„ TCP Congestion Control
„ TCP Fairness
„ Conclusion

1
Part I

What is Congestion?

What is Congestion?
„ Congestion occurs when the number of packets being
transmitted through the network approaches the packet
handling capacity of the network
„ Congestion control aims to keep number of packets
below level at which performance falls off dramatically
„ Data network is a network of queues
„ Generally 80% utilization is critical
„ Finite queues mean data may be lost
„ A top-10 problem!

2
Queues at a Node

Part II

Effects of Congestion?

3
Effects of Congestion
„ Packets arriving are stored at input buffers
„ Routing decision made
„ Packet moves to output buffer
„ Packets queued for output transmitted as fast as
possible
„ Statistical time division multiplexing
„ If packets arrive to fast to be routed, or to be output,
buffers will fill
„ Can discard packets
„ Can use flow control
„ Can propagate congestion through network 7

Interaction of Queues

4
Part III

Causes/Costs of Congestion

Causes/Costs of Congestion: Scenario 1


• two senders, two
receivers
• one router, infinite
buffers
• no retransmission

• large delays when


congested
• maximum
achievable
throughput
10

5
Causes/Costs of Congestion: Scenario 2

• one router, finite buffers


• sender retransmission of lost packet

11

Causes/Costs of Congestion: Scenario 2


• always: λ = λout (λ’in = λin)
in
• “perfect” retransmission only when loss: λ > λout
in
• retransmission of delayed (not lost) packet makes λin larger
(than perfect case) for same λout

“costs” of congestion:
• more work (retrans) for given “goodput”
12
• unneeded retransmissions: link carries multiple copies of pkt

6
Causes/Costs of Congestion: Scenario 3
• four senders Q: what happens as λin
• multihop paths and λin increase ?
• timeout/retransmit

13

Causes/Costs of Congestion: Scenario 3

Another “cost” of congestion:


• when packet dropped, any “upstream transmission
capacity used for that packet was wasted!
14

7
Part IV

Approaches Towards Congestion Control

15

Approaches Towards Congestion Control

Two broad approaches towards congestion control:

End-end congestion Network-assisted


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

8
Case Study: ATM ABR Congestion Control

• ABR: available bit RM (resource


rate: management) cells:
• “elastic service” • sent by sender, interspersed
with data cells
• if sender’s path
• bits in RM cell set by
“underloaded”: switches (“network-assisted”)
– sender should use
available bandwidth
– NI bit: no increase in rate
(mild congestion)
• if sender’s path
– CI bit: congestion
congested: indication
– sender throttled to
minimum guaranteed rate
• RM cells returned to sender
by receiver, with bits intact

17

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 minimum 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 18

9
Part V

TCP Congestion Control

19

TCP Congestion Control


• end-end control (no network How does sender
assistance) perceive congestion?
• sender limits transmission: • loss event = timeout or
LastByteSent-LastByteAcked ≤ CongWin 3 duplicate acks
• Roughly, • TCP sender reduces
rate (CongWin) after
CongWin
rate = Bytes/sec loss event
RTT
three mechanisms:
• CongWin is dynamic, – AIMD
function of perceived – slow start
network congestion – conservative after
timeout events 20

10
TCP AIMD
multiplicative decrease: additive increase:
cut CongWin in half increase CongWin by
after loss event 1 MSS every RTT in
the absence of loss
congestion
window
events: probing
24 Kbytes

16 Kbytes

8 Kbytes

time

Long-lived TCP connection 21

TCP Slow Start

• When connection • When connection


begins, CongWin = 1 begins, increase rate
MSS exponentially fast until
– Example: MSS = 500 first loss event
bytes & RTT = 200 msec
– initial rate = 20 kbps
• available bandwidth
may be >> MSS/RTT
– desirable to quickly ramp
up to respectable rate

22

11
TCP Slow Start (more)

• When connection Host A Host B

begins, increase rate one segm


ent
exponentially until

RTT
first loss event: two segm
ents
– double CongWin
every RTT
four segm
ents
– done by incrementing
CongWin for every
ACK received
• Summary: initial rate time
is slow but ramps up
exponentially fast 23

Refinement
Philosophy:
• After 3 dup ACKs: • 3 dup ACKs indicates
– CongWin is cut in half network capable of
– window then grows linearly delivering some segments
• But after timeout event: • timeout before 3 dup
ACKs is “more alarming”
– CongWin instead set to 1
MSS;
– window then grows
exponentially
– to a threshold, then grows
linearly

24

12
Refinement (more)
• Q: When should
the exponential
increase switch to
linear?
• A: When
CongWin gets to
1/2 of its value
before timeout.

Implementation:
• Variable Threshold
• At loss event, Threshold is
set to 1/2 of CongWin just
before loss event 25

Summary: TCP Congestion Control


„ When CongWin is below Threshold, sender in slow-
start 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

26

13
Part VI

TCP Fairness

27

TCP Fairness
Fairness goal: if K TCP sessions share same
bottleneck link of bandwidth R, each should have
average rate of R/K
TCP connection 1

bottleneck
TCP
router
connection 2
capacity R

28

14
Why is TCP Fair?
Two competing sessions:
– Additive increase gives slope of 1, as throughout increases
– multiplicative decrease decreases throughput proportionally

R
Connection 2 throughput equal bandwidth share

loss: decrease window by factor of 2


congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase

Connection 1 throughput R
29

Fairness (more)
• Fairness and UDP Fairness and parallel TCP
• Multimedia apps often connections
do not use TCP • nothing prevents app from
– do not want rate opening parallel
throttled by congestion connections between 2
control hosts.
• Instead use UDP: • Web browsers do this
– pump audio/video at
• Example: link of rate R
constant rate, tolerate
packet loss supporting 9 connections;
– new app asks for 1 TCP, gets rate
• Research area: TCP R/10
friendly – new app asks for 11 TCPs, gets
30
R/2 !

15
Part VII

Conclusion

31

Assignment & Readings

„ Assignment #5 (due 04/15/10)


„ Assigned at the completion of Session 8
„ Readings
„ Chapter 3 (3.6, 3.7)
„ RFC 2581

32

16
Next Session:
Java Sockets

33

17

You might also like