TCP, TCP Congestion Control and Common AQM Schemes: Quick Revision
w2_1 - TCP Congestion Control_2014_update
-
Upload
trinhquangvi -
Category
Documents
-
view
240 -
download
0
Transcript of w2_1 - TCP Congestion Control_2014_update
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 1/36
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 2/36
Introduction to TCP
Communication abstraction: Reliable Ordered Point-to-point Byte-stream
Full duplex Flow and congestion controlled
Sliding window with cumulative acks Ack field contains last in-order packet received
Duplicate acks sent when out-of-order packet received
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 3/36
Evolution of TCP
1975 1980 1985 1990
1982
TCP & IPRFC 793 & 791
1974
TCP described by
Vint Cerf and Bob Kahn
In IEEE Trans Comm
1983
BSD Unix 4.2supports TCP/IP
1984
Nagel’s algorithm
to reduce overhead
of small packets;
predicts congestion
collapse
1987
Karn’s algorithm
to better estimate
round-trip time
1986Congestion collapse
observed
1988Van Jacobson’s algorithms
congestion avoidance and
congestion control
(most implemented in
4.3BSD Tahoe)
1990
4.3BSD Reno
fast retransmit
delayed ACK’s
1975
Three-way handshake
Raymond Tomlinson
In SIGCOMM 75
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 4/36
TCP Through the 1990s
1993 1994 1996
1994ECN
(Floyd)
Explicit
Congestion
Notification
1993TCP Vegas
(Brakmo et al)
real congestion
avoidance
1994
T/TCP
(Braden)
Transaction
TCP
1996
SACK TCP
(Floyd et al)
Selective
Acknowledgement
1996Hoe
Improving TCP
startup
1996FACK TCP
(Mathis et al)
extension to SACK
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 5/36
5
Flow Control vs. Congestion Control
Flow control Keeping one fast sender from overwhelming a slow
receiver
Congestion control Keep a set of senders from overloading the network
Different concepts, but similar mechanisms
TCP flow control: receiver window
TCP congestion control: congestion window
TCP window: min{congestion window, receiver window}
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 6/36
6
Three Key Features of Internet
Packet switching A given source may have enough capacity to send data
… and yet the packets may encounter an overloaded link
Connectionless flows No notions of connections inside the network
… and no advance reservation of network resources
Still, you can view related packets as a group (“flow”)
… e.g., the packets in the same TCP transfer
Best-effort service No guarantees for packet delivery or delay
No preferential treatment for certain packets
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 7/36
7
Congestion is Unavoidable
Two packets arrive at the same time The node can only transmit one
… and either buffer or drop the other
If many packets arrive in a short period of time
The node cannot keep up with the arriving traffic
… and the buffer may eventually overflow
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 8/36
Why prevent congestion ?
Congestion is bad for the overall performance inthe network.
Excessive delays can be caused.
Retransmissions may result due to dropped packets
• Waste of capacity and resources.
Note: Main reason for lost packets in the Internet is dueto congestion -- errors are rare.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 9/36
The Congestion Window
In order to deal with congestion, a new state variable called “CongestionWindow” is maintained by the source.
Limits the amount of data that it has in transit at a giventime.
MaxWindow = Min(Advertised Window, CongestionWindow)
EffectiveWindow = MaxWindow - (LastByteSent -LastByteAcked).
TCP sends no faster than what the slowest component --
the network or the destination host --can accommodate.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 10/36
Managing the Congestion Window
Decrease window when TCP perceives high congestion. Increase window when TCP knows that there is not much
congestion.
How ? Since increased congestion is more catastrophic,
reduce it more aggressively. Increase is additive, decrease is multiplicative -- called
the Additive Increase/Multiplicative Decrease (AIMD)behavior of TCP.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 11/36
Computer Networks: TCP Congestion Control 11
Additive Increase
Additive Increase is a reaction to perceivedavailable capacity.
Linear Increase basic idea:: For each “cwnd’sworth” of packets sent, increase cwnd by 1
packet.
In practice, cwnd is incremented fractionally foreach arriving ACK.
increment = MSS x (MSS /cwnd)
cwnd = cwnd + increment
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 12/36
Computer Networks: TCP Congestion Control 12
Multiplicative Decrease
* The key assumption is that a dropped packet and theresultant timeout are due to congestion at a router ora switch.
Multiplicate Decrease:: TCP reacts to a timeout byhalving cwnd.
Although cwnd is defined in bytes, the literature oftendiscusses congestion control in terms of packets (or
more formally in MSS == Maximum Segment Size).cwnd is not allowed below the size of a single packet.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 13/36
Where does AIMD come in now ?
Slow start is used to increase the rate to a “targetwindow size” prior to AIMD taking over.
What is this target window size ?
In addition, we now have to do book keeping for two
windows -- the congestion window and the “targetcongestion window” where Slow start ends and AIMDbegins.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 14/36
The Congestion Threshold
Initially no target window -- when a packet loss occurs,divide the current CW by 2 (due to multiplicativedecrease) -- this now becomes the target window.
Define this to be the “Congestion Threshold”.
Reduce actual CW to 1.Use Slow Start to ramp up to the Congestion Threshold
(or simply threshold). Once this is reached use AIMD.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 15/36
TCP Slow Start
Additive Increase is good when source is operating atnear close to the capacity of the network.
Too long to ramp up when it starts from scratch.
Slow start --> increase congestion window rapidly at
cold start. Slow start allows for exponential growth in the beginning.
E.g. Initially CW =1, if ACK received, CW = 2.
If 2 ACKs are now received, CW = 4. If 4 ACKs are
now received, CW =8 and so on.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 16/3616
Slow Start Example
The congestion windowsize grows very rapidly
For every ACK, weincrease cwnd by 1
irrespective of thenumber of segments ACK’ed
TCP slows down the
increase of cwnd whencwnd > ssthresh
Source Destination
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 17/3617
Congestion Avoidance
Congestion avoidance phase is started if cwnd hasreached the slow-start threshold value
If cwnd ≥ ssthresh then each time an ACK isreceived, increment cwnd as follows:
• cwnd = cwnd + 1/ cwnd
So cwnd is increased by one only if all cwnd segments have been acknowledged.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 18/36
18
Example ofSlow Start/Congestion Avoidance
Assume that ssthresh =8
cwnd = 1
cwnd = 2
cwnd = 4
cwnd = 8
cwnd = 9
cwnd = 10
0
2
4
6
8
10
12
14
t = 0
t = 2
t = 4
t = 6
Roundtrip times
C w n d ( i n s e g m e n t s )
ssthresh
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 19/36
Summary: TCP Tahoe
Thus: When CW is below the threshold, CW grows exponentially
When it is above the threshold, CW grows linearly.
Upon time-out, set “new” threshold to half of current CW and
the CW is reset to 1. This version of TCP is called “TCP Tahoe”.
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
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 20/36
Fast Retransmit
What are duplicate acks (dupacks)? Repeated acks for the same sequence
When can duplicate acks occur? Loss
Packet re-ordering
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 21/36
Duplicate ACKs
When a duplicate ACK is seen bythe sender, it infers that the otherside must have received a packetout of order.
Delays on different paths could bedifferent -- thus, the missing packetsmay be delivered.
So wait for “some” number of
duplicate ACKs before resending data. This number is usually 3.
1K SeqNo=0
AckNo=102 4
AckNo=102 4
1K SeqNo=1024
SeqNo=20481K
AckNo=102 4
SeqNo=307 21K
SeqNo=4096
1K
1. duplicate
2. duplicate
AckNo=102 4
SeqNo=10241K
SeqNo=51201K
3. duplicate
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 22/36
Fast Recovery
When the fast retransmit mechanism signalscongestion, the sender, instead of returning toSlow Start uses a pure AIMD.
Simply reduces the congestion window by half andresumes additive increase.
Thus, recovery is faster -- this is called FastRecovery.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 23/36
TCP Reno
Duplicate ACKs:• Fast retransmit
• Fast recovery
Fast Recovery avoids slow start
Timeout:• Retransmit
• Slow Start
TCP Reno improves upon TCP Tahoe when asingle packet is dropped in a round-trip time.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 24/36
24
TCP Tahoe and TCP Reno(for single segment losses)
Reno
time
c w n d
time
c w n d
Taho
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 25/36
Summary - TCP Congestion Control
LNSon - Bộ môn MMT&VT - Khoa CNTT - ĐH KHTN Tp. HCM 25
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 26/36
Transport Layer 3-26
Summary: TCP Congestion Control
when cwnd < ssthresh, sender in slow-start
phase, window grows exponentially.
when cwnd >= ssthresh, sender is in congestion-
avoidance phase, window grows linearly.
when triple duplicate ACK occurs, ssthresh set tocwnd/2, cwnd set to ~ ssthresh
when timeout occurs, ssthresh set to cwnd/2,cwnd set to 1 MSS.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 27/36
Other flavors
TCP NewReno
TCP Vegas
SACK TCP
FACK TCP
LNSon - Bộ môn MMT&VT - Khoa CNTT - ĐH KHTN Tp. HCM 27
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 28/36
28
Queuing Mechanisms
Random Early Detection (RED)
Explicit Congestion Notification (ECN)
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 29/36
29
Bursty Loss From Drop-Tail Queuing
TCP depends on packet loss Packet loss is the indication of congestion
In fact, TCP drives the network into packet loss
… by continuing to increase the sending rate
Drop-tail queuing leads to bursty loss When a link becomes congested…
… many arriving packets encounter a full queue
And, as a result, many flows divide sending rate in half
… and, many individual flows lose multiple packets
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 30/36
30
Slow Feedback from Drop Tail
Feedback comes when buffer is completely full … even though the buffer has been filling for a while
Plus, the filling buffer is increasing RTT
… and the variance in the RTT
Might be better to give early feedback
Get one or two flows to slow down, not all of them
Get these flows to slow down before it is too late
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 31/36
31
Random Early Detection (RED)
Basic idea of RED Router notices that the queue is getting backlogged
… and randomly drops packets to signal congestion
Packet drop probability
Drop probability increases as queue length increases
If buffer is below some level, don’t drop anything
… otherwise, set drop probability as function of queue
Average Queue Length
P r o b a b i l i t y
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 32/36
32
Properties of RED
Drops packets before queue is full In the hope of reducing the rates of some flows
Drops packet in proportion to each flow’s rate
High-rate flows have more packets … and, hence, a higher chance of being selected
Drops are spaced out in time
Which should help desynchronize the TCP senders
Tolerant of burstiness in the traffic
By basing the decisions on average queue length
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 33/36
More RED Details
With RED, two thresholds are maintained -- theMinThreshold and MaxThreshold.
If AvgLen <= MinThreshold queue packet
If AvgLen >= MaxThreshold drop arriving packet.
If MinThreshold <= AvgLen <= MaxThreshold, then,calculate a drop probabilty P and drop the arriving packetwith the probability P.
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 34/36
34
Problems With RED
Hard to get the tunable parameters just right How early to start dropping packets?
What slope for the increase in drop probability?
What time scale for averaging the queue length?
Sometimes RED helps but sometimes not If the parameters aren’t set right, RED doesn’t help
And it is hard to know how to set the parameters
RED is implemented in practice But, often not used due to the challenges of tuning right
Many variations With cute names like “Blue” and “FRED”…
8/10/2019 w2_1 - TCP Congestion Control_2014_update
http://slidepdf.com/reader/full/w21-tcp-congestion-control2014update 35/36
35
Explicit Congestion Notification
Early dropping of packets Good: gives early feedback
Bad: has to drop the packet to give the feedback
Explicit Congestion Notification
Router marks the packet with an ECN bit … and sending host interprets as a sign of congestion
Surmounting the challenges Must be supported by the end hosts and the routers
Requires two bits in the IP header (one for the ECN mark,and one to indicate the ECN capability)
Solution: borrow two of the Type-Of-Service bits in the IPv4packet header