High Performance Networking with TCP. TCP properties, UDP, flow control, Congestion Avoidance & Control, slow start, Congestion Control Review, TCP Tahoe & Reno

1. TCP
CS4482 High Performance Networking
Dilum Bandara
Dilum.Bandara@uom.lk
Some slides extracted from Dr. Dan Massey’s CS557 class at Colorado
State University

2. TCP Properties
 Point-to-point
 One sender & one receiver
 Connection-oriented
 Handshaking (exchange of control msgs)
 Initialize sender & receiver state before data
exchange
 Flow controlled
 Sender will not overwhelm receiver
 Send & receive buffers
2

3. TCP Properties (Cont.)
 Full duplex
 Bi-directional data flow within same connection
 Reliable, in-order byte stream
 No “message boundaries”
 Maximum Segment Size (MSS)
 Pipelined
 TCP congestion & flow control set window size
 Fair
3

4. TCP UDP
Reliable Best effort
Connection oriented Connection less
Segmented retransmission
& flow control through
windowing
No
Segmented sequencing No
Acknowledge segments No
Slow start Full speed
TCP vs. UDP
4

5. TCP Connection Establishment &
Termination
5
http://pic.dhe.ibm.com/infocenter/tpfhelp/

6. http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx
TCP Flow Control
 Sender won’t overflow receiver’s buffer by transmitting too
much, too fast
 Receiver advertises spare room by including value of
RcvWindow in segments
 Sender limits unACKed data to RcvWindow
 Guarantees receive buffer doesn’t overflow
6

7. TCP Flow Control (Cont.)
 Seq. Nos
 Byte stream “number” of 1st
byte in segment’s data
 ACKs
 Seq No of next byte
expected from other side
 Cumulative ACK
7

8. Challenges
 Connection never reaches equilibrium
 Too many initial packets drives network into
congestion & then hard to recover
 Sender adds packets before one leaves
 Poor timer causes retransmission of packets that are
still in-flight on network
 Equilibrium can’t be reached due to resource
limits on path
 Assume packet loss is due to congestion & back off
by multiplicative factor
8

9. TCP – Retransmission Scenarios
9

10. TCP – Retransmission Scenarios
(Cont.)
10

11. Congestion Avoidance & Control
 “Congestion Avoidance and Control” by
Jacobson and Karels, 1988
 Objective
 Techniques for dealing with network congestion
 Approach
 Slow start
 Adaptive timers
 Additive increase/multiplicitive decrease
 Contributions
 Essential points of TCP congestion control
11

12. Motivation
 Network collapsing due to congestion
 Throughput dropped from 32 Kbps to 40 bps
 Conclusion  packet switching failed…
 Paper says we can fix the problem
 Conservation of packets
 Can’t have collapse if packets entering network =
packets leaving network
12

13. Slow Start
 TCP is self-clocking
 Receipt of ACK triggers sending a new packet
 Good if network is in stable state
 How to ramp up at start?
 Start slow
 Initially send 1 packet
 Each ACK triggers 2 packets
 Quickly ramp up window to correct size
13

14. Slow Start
14
http://user.it.uu.se/~carle/Notes/43_TCP.html

15. TCP Timeout Values
 How to set TCP timeout value?
 Longer than RTT
 But RTT varies
 Too short  premature timeout , unnecessary
retransmissions
 Too long  slow reaction to segment loss
 How to estimate RTT?
 SampleRTT
 Measured time from segment transmission until ACK receipt
 Ignore retransmissions
 SampleRTT will vary, want estimated RTT to be “smoother”
 Average several recent measurements, not just current
SampleRTT 15

16. RTT Distribution
16
http://user.it.uu.se/~carle/Notes/43_TCP.html

17. RTT Estimation
EstimatedRTT = (1 – α) ×EstimatedRTT +
α×SampleRTT
 Exponential weighted moving average
 Influence of past sample decreases exponentially fast
 Typical value: α=0.125
 Setting timeout
 EstimtedRTT plus “safety margin”
 Large variation in EstimatedRTT  Larger safety margin
 1st estimate of how much SampleRTT deviates from
EstimatedRTT
17

18. Example RTT Estimation
18

19. TCP Congestion Control Review
 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
 i.e., four ACKs acknowledging the same packet
 Threshold set to CongWin/2 & CongWin set to
Threshold
 When timeout occurs
 Threshold set to CongWin/2 & CongWin is set to 1 MSS
19

20. TCP Window Size Over Time
20

21. TCP Tahoe & Reno
 Tahoe
 Triple duplicate ACKS are treated same as a timeout
 Perform fast retransmit
 Set slow start threshold to ½ current congestion
window, reduce congestion window to 1 MSS
 Go to slow-start state
 Reno
 Three duplicate ACKs are received
 Perform fast retransmit
 ½ the congestion window, set slow start threshold to
new congestion window
 Enters a phase called “Fast Recovery” 21

22. Fast Retransmit
 Time-out period is often relatively long
 Long delay before resending lost packet
 Detect lost segments via duplicate ACKs
 Sender often sends many segments back-to-back
 If segment is lost, there will likely be many duplicate
ACKs
 If sender receives 3 ACKs for same data, it
supposes that segment after ACKed data was
lost
 Fast retransmit – Resend segment before timer
expires
22

23. Fast Retransmit (Cont.)
23
http://cnp3book.info.ucl.ac.be/transport/tcp/

24. TCP ACK Generation [RFC 1122, RFC 2581]
24
Event at Receiver TCP Receiver Action
Arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
Delayed ACK. Wait up to 500ms for
next segment. If no next segment,
send ACK
Arrival of in-order segment with
expected seq #. One other
segment has ACK pending
Immediately send single cumulative
ACK, ACKing both in-order
segments
Arrival of out-of-order segment
higher-than-expect seq # . Gap
detected
Immediately send duplicate ACK,
indicating seq. # of next expected
byte
Arrival of segment that partially or
completely fills gap
Immediate send ACK, provided that
segment starts at lower end of gap

25. Review: Automatic Repeat Request
(ARQ)
 Stop-and-Wait ARQ
 One packet/frame at a time
 Go-Back-N ARQ
 Window of packets/frames on flight
 If a negative ACK is received, restart from lost
packet/frame
 Selective-Repeat ARQ
 Window of packets/frames on flight
 If a negative ACK is received, only lost packet/frame
is send
 Typically used by TCP implementations
 See http://www.ccs-labs.org/teaching/rn/animations/gbn_sr/ 25

26. ARQ (Cont.)
26

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 is fair
 Additive increase gives slope of 1, as throughput
increases
 Multiplicative decrease drops throughput proportionally
27

28. TCP Concerns
 TCP over wireless links
 Packet losses due to errors are no longer insignificant
 Multiplicative decrease is too conservative
 TCP over high bandwidth, low-latency links
 Millions of packets may be on the fly
 Few of those packets will get lost or contain errors
 Multiplicative decrease is too conservative
 Various extensions are proposed to address
these
28