Date post: | 26-Dec-2015 |
Category: |
Documents |
Upload: | preston-simmons |
View: | 221 times |
Download: | 0 times |
1
Computer Networks
Lecture 17
Congestion Control; AIMD; TCP Reno
10/31/2013
Admin.: Assignment 4
proj-sol (part 1): 129 400 3045 FishThread.java 388 1457 12873 Node.java 51 167 1145 PingRequest.java 83 250 2106
SimpleTCPSockSpace.java 181 605 5248 TCPManager.java 889 3088 26381 TCPSock.java 60 149 1316 TCPSockID.java 123 382 3866 TransferClient.java 147 500 5059 TransferServer.java 2051 6998 61039 total
2
proj: 129 400 3045 FishThread.java 341 1301 11313 Node.java 51 167 1145 PingRequest.java
50 128 909 TCPManager.java 132 460 3146 TCPSock.java
123 382 3866 TransferClient.java 147 500 5059 TransferServer.java 973 3338 28483 total
Part 1: Design discussion with instructor or a TF: Nov. 11; Code check point: 11:55 pm, Nov. 15
Part 2: Design discussion with instructor or a TF: Nov. 14; Code and report: 11:55 pm, Nov. 19.
3
Recap: Connection Management
Connection setup: agree on initial sequence numbers to avoid
accepting duplicate/out of order packets Internet solution: Three-Way-Handshake
(TWH)
Connection close both sides can release allocated resources Internet solution: time wait
4
%netstat -t -a CLOSED
LISTEN
SYN RCVD
SYN
SYN/ACK
ACK
CLOSED
SYN SENT
ESTABLSIHED
ESTABLSIHED
FIN
ACK
ACK
FINWAIT 1
ESTABLSIHED ESTABLSIHED
CLOSEWAIT
FINLASTACK
FINWAIT 2
TIMEWAIT
5
A Summary of Questions
How to improve the performance of rdt3.0? sliding window protocols
What if there are duplication and reordering? network guarantee: max packet life time transport guarantee: sender not reuses a
seq# before life time seq# management and connection
management How to determine the “right” parameters?
6
History
Key parameters for TCP in mid-1980s fixed window size W timeout value = 2 RTT
Network collapse in the mid-1980s UCB LBL throughput dropped by 1000X ! Blamed timeout and fixed window size
7
Timeout Ideal timeout = RTT
too short: premature timeout• unnecessary retransmissions/duplicates
too long: slow reaction to segment loss
Measure RTT: measuretime from segment transmission until ACK receipt
8
From Ideal to Implementation
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
Exponential weighted moving average influence of past sample decreases exponentially
fast typical value: = 0.125
Problem: SampleRTT vary, want a “smoother” estimated RTT
o use several recent measurements, not just current SampleRTT
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RTT
(mill
isec
onds
)
SampleRTT Estimated RTT
9
Setting TimeoutProblem: using the average of SampleRTT will generate many timeouts due to network variations
Solution: EstimtedRTT plus “safety
margin” Q: what is margin in original
TCP Margin should depend on
variation: large variation in EstimatedRTT -> larger safety margin
RTT
10
TCP Timeout
TimeoutInterval = EstimatedRTT + 4*DevRTT
DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|
(typically, = 0.25)
Then set timeout interval:
RTT
freq.
11
An Example TCP Session
12
A Summary of Questions
How to improve the performance of rdt3.0? sliding window protocols
What if there are duplication and reordering? network guarantee: max packet life time transport guarantee: sender not reuses a
seq# before life time seq# management and connection
management How to determine the “right” parameters?
timeout: mean + variationo sliding window size
13
Principles of Congestion Control
Big picture: How to determine a flow’s sending rate? a top-10 problem !Congestion: informally: “too many sources sending too much
data too fast for the network to handle” different from flow control ! manifestations:
lost packets (buffer overflow at routers) long delays (queueing in router buffers) wasted bandwidth
14
Some General Questions
How can congestion happen?
What is congestion control?
Why is congestion control difficult?
15
flow 2 (5 Mbps)
flow 1
router 1 router 2
10 Mbps5 Mbps20 Mbps
Cause/Cost of Congestion: Single Bottleneck
- Flow 2 has a fixed sending rate of 5 Mbps- We vary the sending rate of flow 1 from 0 to 20 Mbps- Assume
no retransmission; link from router 1 to router 2 has infinite buffer
20 Mbps
20 Mbps
throughput: e2e packets delivered in
unit time
Delay?
sending rate by flow 1 (Mbps)
throughput of flow 1 & 2 (Mbps)
5
10
50
sending rate by flow 1 (Mbps)
delay at central link
50
16
flow 2 (5 Mbps)
flow 1
router 1
10 Mbps5 Mbps20 Mbps
Cause/Cost of Congestion: Single Bottleneck
Assume no retransmission the link from router 1 to router 2 has finite buffer throughput: e2e packets delivered in unit time
20 Mbps
20 Mbps
Zombie packet: a packet dropped at the link from router 2 to router 5; the upstream transmission from router 1 to router 2 used for that packet was wasted!
router 3
router 4
router 2
router 5
router 6
sending rate by flow 1 (Mbps)
throughput of flow 1 & 2 (Mbps)
5
10
50 x
10)5,10min( 55
5 xxx
17
Summary: The Cost of Congestion
Cost Packet loss
wasted upstream bandwidth when a pkt is discarded at downstream
wasted bandwidth due to retransmission (a pkt goes through a link multiple times)
High delayLoad
Load
De
lay
Th
rou
ghp
ut knee cliff
congestioncollapse
packetloss
18
Outline
Admin and recap Transport congestion control
what is congestion congestion control
19
Window-based: Congestion control by
controlling the window size of a transport scheme, e.g., set window size to 64KBytes
Example: TCP
Rate-based: Congestion control by
explicitly controlling the sending rate of a flow, e.g., set sending rate to 128Kbps
Example: ATM
Discussion: rate-based vs. window-based
Rate-based vs. Window-based
20
Window-based Congestion Control
A main advantage of window-based congestion control is self-clocking: considers flow conservation, and adjusts to RTT variation automatically
21
Sliding Window Congestion Control
Transmission rate limited by congestion window size, cwnd, over segments:
Assume cwnd segments, each with MSS bytes sent in one RTT:
throughput cwnd * MSS
RTT Bytes/sec
cwnd
MSS: Minimum Segment Size
22
The Desired Properties of a Congestion Control Scheme
Efficiency: close to full utilization but low delay- fast convergence after disturbance
Fairness (resource sharing)
Distributedness (no central knowledge for scalability)
23
A Simple Model
User 1
User 2
User n
d =
xi > Xgoal?
x1
x2
xn
Flows observe congestion signal d, and locally take actions to adjust rates.
24
Linear Control
Proposed by Chiu and Jain (1988) The simplest control strategy
cong.d(t) if)(
cong. nod(t) if )()1(
txba
txbatx
iDD
iIIi
Discussion: values of the parameters?
25
State Space of Two Flows
x2
x1
overload
underload
efficiency line: x1+x2=C
fairness line: x1=x2
cong.d(t) if)(
cong. nod(t) if )()1(
txba
txbatx
iDD
iIIi
x(0)
26
x0
efficiency efficiency: distributed linear rule
x0
intersection
x0
congestion
fairness
x0
cong.d(t) if)(
cong. nod(t) if )()1(
txba
txbatx
iDD
iIIi
27
Implication: Congestion (overload) Case
In order to get closer to efficiency and fairness after each update, decreasing of rate must be multiplicative decrease (MD) aD = 0
bD < 1
cong.d(t) if)(
cong. nod(t) if )()1(
txb
txbatx
iD
iIIi
28
efficiency: distributed linear rule
x0
no-congestion
x0
efficiency
fairness
x0
convergencex0
cong.d(t) if)(
cong. nod(t) if )()1(
txba
txbatx
iDD
iIIi
29
Implication: No Congestion Case
In order to get closer to efficiency and fairness after each update, additive and multiplicative increasing (AMI), i.e., aI > 0, bI > 1
Simply additive increase gives better improvement in fairness (i.e., getting closer to the fairness line)
Multiplicative increase is faster
cong.d(t) if)(
cong. nod(t) if )()1(
txb
txbatx
iD
iIIi
30
Four Special Cases
Additive Decrease
Multiplicative Decrease
Additive Increase
AIAD(bI=bD=1)
AIMD(bI=1, aD=0)
Multiplicative Increase
MIAD(aI=0, bI>1,
bD=1)
MIMD(aI=aD=0)
cong.d(t) if)(
cong. nod(t) if )()1(
txba
txbatx
iDD
iIIi
Discussion: state transition trace.
31
AIMD: State Transition Trace
x1
x2
x0
fairness line:x1=x2
efficiency line: x1+x2=C
overload
underload
32
Another Look
Consider the difference or ratio of the rates of two flows AIAD
MIMD
MIAD
AIMD
33
Mapping A(M)I-MD to Protocol
What do we need to apply the A(M)I-MD algorithm to a sliding window protocol?
cong.d(t) if)(
cong. nod(t) if )()1(
txb
txatx
iD
iIi
34
Mapping A(M)I-MD to Protocol
What do we need to apply the A(M)I-MD algorithm to a sliding window protocol?
cong.d(t) if)(
cong. nod(t) if )()1(
txb
txatx
iD
iIi
35
Implicit vs. Explicit
Implicit: congestion inferred by
end systems through observed loss, delay
Explicit: routers provide feedback
to end systems explicit rate sender
should send at single bit indicating
congestion (SNA, DECbit, TCP ECN, ATM)
36
Outline
Admin and recap Transport congestion control
what is congestion congestion control principle TCP congestion control: Reno
37
TCP Congestion Control Closed-loop, end-to-end, window-based
congestion control Designed by Van Jacobson in late 1980s, based
on the AIMD alg. of Dah-Ming Chu and Raj Jain Works well when the bandwidth of the Internet
has increased by more than 200,000 times Many versions
TCP/Tahoe: this is a less optimized version TCP/Reno: many OSs today implement Reno
type congestion control TCP/Vegas: not currently used TCP CUBIC
For more details: see TCP/IP illustrated; or readhttp://lxr.linux.no/source/net/ipv4/tcp_input.c for linux implementation
38
TCP/Reno Congestion Detection
• 3 dup ACKs indicates network capable of delivering some segments
• timeout is “more alarming”
Philosophy:
Detect congestion (d) in two cases and react differently:
3 dup ACKs timeout event
39
Basic Structure
Two “phases”slow-start: MIcongestion avoidance: AIMD
Important variables:cwnd: congestion window sizessthresh: threshold between the slow-
start phase and the congestion avoidance phase
40
Visualization of the Two Phases
41
Slow Start: MI
What is the goal? getting to equilibrium gradually but quickly
Implements the MI algorithm double cwnd every RTT until network
congested get a rough estimate of the optimal of cwnd
42
Slow-start
ACK for segment 1
segment 1cwnd = 1
cwnd = 2 segment 2segment 3
ACK for segments 2 + 3
cwnd = 4 segment 4segment 5segment 6segment 7
cwnd = 6
Initially:cwnd = 1;ssthresh = infinite (e.g., 64K);
For each newly ACKed segment:if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1;
cwnd = 8
43
Startup Behavior with Slow-start
See [Jac89]
44
TCP/Reno Congestion Avoidance Maintains equilibrium and reacts around
equilibrium
Implements the AIMD algorithm increases window by 1 per round-trip time
(how?) cuts window size
• to half when detecting congestion by 3DUP• to 1 if timeout• if already timeout, doubles timeout
45
TCP/Reno Congestion AvoidanceInitially:
cwnd = 1;ssthresh = infinite (e.g., 64K);
For each newly ACKed segment:if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1;else /* congestion avoidance; cwnd increases (approx.) by 1 per RTT */ cwnd += 1/cwnd;
Triple-duplicate ACKs: /* multiplicative decrease */
cwnd = ssthresh = cwnd/2;Timeout:
ssthresh = cwnd/2;cwnd = 1;
(if already timed out, double timeout value; this is called exponential backoff)
46
TCP/Reno: Big Picture
Time
cwnd
slowstart
congestionavoidance
TD
TD: Triple duplicate acknowledgementsTO: Timeout
TOssthresh
ssthresh ssthreshssthresh
congestionavoidance
TD
congestionavoidance
slow start
congestionavoidance
TD
47
A Session
Question: when cwnd is cut to half, why sending rate is not?
48
Backup Slides
High-level Idea
Ideally, we set timeout = RTT, but RTT is not a fixed value (why?)
49
Set timeout = average + safe margin
High-level Idea
Ideally, we set timeout = RTT, but RTT is not a fixed value (why?)
50
Set timeout = average + safe margin