1. TDC365 Spring 2001John Kristoff - DePaul University1 Internetworking Technologies Transmission Control Protocol (TCP)

2. TDC365 Spring 2001John Kristoff - DePaul University2 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. TDC365 Spring 2001John Kristoff - DePaul University3 TCP key features • Sequencing • Byte-stream delivery • Connection-oriented • Reliability

4. TDC365 Spring 2001John Kristoff - DePaul University4 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. TDC365 Spring 2001John Kristoff - DePaul University5 Apparent contradiction • IP offers best-effort (unreliable) delivery • TCP uses IP • TCP provides completely reliable transfer • How is this possible?

6. TDC365 Spring 2001John Kristoff - DePaul University6 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. TDC365 Spring 2001John Kristoff - DePaul University7 Reliability illustrated

8. TDC365 Spring 2001John Kristoff - DePaul University8 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. TDC365 Spring 2001John Kristoff - DePaul University9 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. TDC365 Spring 2001John Kristoff - DePaul University10 Adaptive retranmission illustrated

11. TDC365 Spring 2001John Kristoff - DePaul University11 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. TDC365 Spring 2001John Kristoff - DePaul University12 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. TDC365 Spring 2001John Kristoff - DePaul University13 Window advertisement illustrated

14. TDC365 Spring 2001John Kristoff - DePaul University14 Another view: the sliding window

15. TDC365 Spring 2001John Kristoff - DePaul University15 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 (2 32 bytes)? • Initial sequence numbers (ISN) are exchanged at connection startup • ACKs acknowledgement cumulative bytes

16. TDC365 Spring 2001John Kristoff - DePaul University16 TCP segment format

17. TDC365 Spring 2001John Kristoff - DePaul University17 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. TDC365 Spring 2001John Kristoff - DePaul University18 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. TDC365 Spring 2001John Kristoff - DePaul University19 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. TDC365 Spring 2001John Kristoff - DePaul University20 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. TDC365 Spring 2001John Kristoff - DePaul University21 3-way handshake illustrated

22. TDC365 Spring 2001John Kristoff - DePaul University22 TCP connection shutdown

23. TDC365 Spring 2001John Kristoff - DePaul University23 Congestion • Flow control • Congestion control • Avoidance

24. TDC365 Spring 2001John Kristoff - DePaul University24 Useful terms before proceding • Maximum segment size (MSS) • Window • Retransmission • Timer • Delayed ACK • Duplicate ACK

25. TDC365 Spring 2001John Kristoff - DePaul University25 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. TDC365 Spring 2001John Kristoff - DePaul University26 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. TDC365 Spring 2001John Kristoff - DePaul University27 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. TDC365 Spring 2001John Kristoff - DePaul University28 TCP slow start • Initialize cwnd to 1 MSS • Increase cwnd by 1 MSS for every ACK • Not really that slow

29. TDC365 Spring 2001John Kristoff - DePaul University29 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. TDC365 Spring 2001John Kristoff - DePaul University30 Congestion avoidance illustrated

31. TDC365 Spring 2001John Kristoff - DePaul University31 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. TDC365 Spring 2001John Kristoff - DePaul University32 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. TDC365 Spring 2001John Kristoff - DePaul University33 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. TDC365 Spring 2001John Kristoff - DePaul University34 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