TCP/IP Review: Key Features and Reliability Illustration

1. Internetworking Technologies • Transmission Control Protocol (TCP)

2. IP review • IP provides just enough 'connectedness' • Global addressing • Hop-by-hop routing • IP over everything • Ethernet, ATM, X.25, SONET, etc. • Lack of state in the network • Unreliable packet (datagram) switching

3. TCP key features • Sequencing • Byte-stream delivery • Connection-oriented • Reliability

4. TCP feature summary Provides a completely reliable (no data duplication or loss), connection-oriented, full-duplex stream transport service that allows two application programs to form a connection, send data in either direction and then terminate the connection.

5. Apparent contradiction • IP offers best-effort (unreliable) delivery • TCP uses IP • TCP provides completely reliable transfer • How is this possible?

6. Achieving reliability • Reliable connection startup • Reliable data transfer • Sender starts a timer • Receiver sends ACK when data arrives • Sender retransmits if timer expires before ACK is returned • Reliable connection shutdown

7. Reliability illustrated

8. How long to wait before retransmitting? • Time for ACK to return depends on: • Distance between sender/receiver • Network traffic conditions • End system conditions • Packets can be lost, damaged or fragmented • Traffic conditions can change rapidly

9. Solving the retransmission problem • Keep running average of round trip time (RTT) for each TCP connection • Current average (estimate) determines retransmission timer • How does each RTT affect the average? • This is known as adaptive retransmission • Key to TCP's success

10. Adaptive retranmission illustrated

11. Flow control • Match sending rate to receiver rate • TCP uses a sliding window • Receiver advertises available buffer space • Also known as the window • Sender can transmit a full window size before receiving an ACK

12. Window advertisement • Each ACK carries the current window size • Called the window advertisement • Can be zero (a closed window) • Interpretation of window advertisement: • Receiver: I can accept X octets or less unless I tell you otherwise

13. Window advertisement illustrated

14. Another view: the sliding window

15. Byte stream sequencing • Each segment contains a sequence number • Sequencing helps ensure in-order delivery • TCP sequence numbers are fixed at 32 bits • Is the byte stream of limited size (232 bytes)? • Initial sequence numbers (ISN) are exchanged at connection startup • ACKs acknowledgement cumulative bytes

16. TCP segment format

17. Application multiplexing • Separation of functionality from IP • In the beginning TCP and IP were one • No unused bits to encode application process • Cannot use OS dependent quality • Process ID • Task number • Job name • Semantics must work on all end systems

18. Port numbers • Separation of functionality from IP • In the beginning TCP and IP were one • No unused bits to encode application process • Cannot use OS dependent quality • Process ID • Task number • Job name • Semantics must work on all end systems

19. TCP ports • Each application assigned a unique integer • Server • Follows a standard (e.g. Well know ports) • Uses a well known port number • Usually uses lower port numbers • Client • Obtains unused port from protocol software • Usually uses high numbered ports

20. TCP connection startup • Uses a three message exchange • AKA 3-way handshake • Necessary and sufficient for unambiguous and reliable startup • Sequence number exchange is primary goal • Can also exchange other parameters • e.g. maximum segment size

21. 3-way handshake illustrated

22. TCP connection shutdown

23. Congestion • Flow control • Congestion control • Avoidance

24. Useful terms before proceding • Maximum segment size (MSS) • Window • Retransmission • Timer • Delayed ACK • Duplicate ACK

25. Congestion window • Sender based flow control • Rather than by a window advertisement • Sender uses min(cwnd, advertised window) • This is the transmission window • Infer network conditions and adjust • Use timers, ACKs and network feedback

26. TCP segment retransmission • TCP starts timer after sending a segment • If ACK returns, reset timer • If not, retransmit and set (timer = timer x 2) • This is backoff • Can't retransmit forever, error may occur • Timer is the estimate of round trip time (RTT) • Current, running average of RTT

27. Round trip time (RTT) • TCP measures RTT • TCP uses estimated RTT to calculate timers • If ACKs return quickly, timers are short • If loss occurs, recovery is quicker • The converse is also true • RTT too high = throughput suffers • RTT too low = unnecessary retransmits

28. TCP slow start • Initialize cwnd to 1 MSS • Increase cwnd by 1 MSS for every ACK • Not really that slow

29. TCP congestion avoidance • When timer expires (loss?), slow down! • Set ssthresh = (transmission window x ½) • Set cwnd = 1 • Transmit min(cwnd, transmission window) • Slow start until transmission window = sshtresh • Thereafter, increase cwnd by 1/cwnd per ACK

30. Congestion avoidance illustrated

31. TCP fast retransmit • If 3 or more duplicate ACKs are received before timer has expired • Sender assumes loss • Assumes out of order packets had enough time to be reassembled • Retransmit without waiting for timer to expire • Enter TCP fast recovery

32. TCP fast recovery • Sender assumes data is still flowing • Due to the reception of duplicate ACKs • Loss was probably a temporary event • Go into congestion avoidance, not slow start • Just cut cwnd in half • Resume additive increase (1/cwnd) per ACK

33. Other mechanisms • Selective acknowledgements (SACK) • Traffic shaping • ACK pacing • AQM (FIFO and RED and variants) • ECN, ICMP source quench, back pressure • Fair queueing • Class/uality of service (CoS/QoS)

34. Congestion collapse • When network load increases and less actual work gets done due to packet drops • Fragmented packets are especially bad • As retransmissions increase, goodput drops