High Performance Networking with Advanced TCP
Download as PPTX, PDF0 likes44 views
The document discusses key properties and mechanisms of the Transmission Control Protocol (TCP), describing its connection-oriented, reliable, and flow-controlled nature, as well as its relationship with User Datagram Protocol (UDP). It highlights challenges related to congestion, including congestion control techniques such as slow start and fast retransmit, and factors affecting round-trip time (RTT) estimation. Additionally, it addresses concerns about TCP performance in various environments, emphasizing fairness and adaptations necessary for different network conditions.
![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](https://image.slidesharecdn.com/05-tcp-240416104759-c7963cad/85/High-Performance-Networking-with-Advanced-TCP-24-320.jpg)
High Performance Networking with Advanced TCP
- 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
- 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
- 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
- 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
- 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
Editor's Notes
- #22: Fast Recovery. (Reno Only) In this state, TCP retransmits the missing packet that was signaled by three duplicate ACKs, and waits for an acknowledgment of the entire transmit window before returning to congestion avoidance. If there is no acknowledgment, TCP Reno experiences a timeout and enters the slow-start state.