1. Autumn 2000John Kristoff1 Transport Layer Computer Networks

2. Autumn 2000John Kristoff2 Where are we?

3. Autumn 2000John Kristoff3 Recall ÑNetwork Layer ÑProvides host-to-host communication ÑSource and destination addresses identify host interfaces ÑMachine-to-machine networking

4. Autumn 2000John Kristoff4 Transport Protocols Ñ Provide application-to-application communication Ñ Need extended addressing mechanism to identify applications Ñ Called end-to-end Ñ Optionally provide: ÑReliability ÑFlow Control ÑCongestion Control

5. Autumn 2000John Kristoff5 Example Transport Layer: Transmission Control Protocol (TCP) Ñ Standardized by IETF as RFC 793 Ñ Most popular layer 4 protocol Ñ Connection-oriented protocol Ñ Conceptually between applications and IP Ñ Full-duplex operation Ñ Byte-stream interface Ñ Of utmost importance for this class! Ñ The book: TCP/IP Illustrated, Volume I - W.R. Stevens Ñ Also see: http://condor.depaul.edu/~jkristof/tcp.htmlhttp://condor.depaul.edu/~jkristof/tcp.html

6. Autumn 2000John Kristoff6 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.

7. Autumn 2000John Kristoff7 Relationship Between TCP and Other Protocols Ñ TCP on one computer uses IP to communicate with TCP on another computer

8. Autumn 2000John Kristoff8 Apparent Contradiction ÑIP offers best-effort (unreliable) delivery ÑTCP uses IP ÑTCP provides completely reliable transfer ÑHow is this possible?

9. Autumn 2000John Kristoff9 Achieving Reliability ÑReliable connection setup ÑReliable data transmission ÑReliable connection shutdown

10. Autumn 2000John Kristoff10 Reliable Data Transmission ÑPositive Acknowledgement Ñ Receiver returns short message when data arrives Ñ Call an acknowledgement ÑRetransmission Ñ Sender starts timer whenever message is transmitted Ñ If timer expires before acknowledgement arrives, sender retransmits message

11. Autumn 2000John Kristoff11 Retransmission Illustrated

12. Autumn 2000John Kristoff12 How Long Should TCP Wait Before Retransmitting? ÑTime for acknowledgement to arrive depends on ÑDistance to destination ÑCurrent traffic conditions ÑMultiple connections can be open simultaneously ÑTraffic conditions change rapidly

13. Autumn 2000John Kristoff13 Important Point The delay required for data to reach a destination and an acknowledgement to return depends on traffic in the internet as well as the distance to the destination. Since it allows multiple application programs to communicate with multiple destinations concurrently, TCP must handle a variety of delays that can change rapidly.

14. Autumn 2000John Kristoff14 Solving the Retransmission Problem ÑKeep estimate of round trip time on each connection ÑUse current estimate to set retransmission timer ÑKnown as adaptive retransmission  Key to TCP ’ s success

15. Autumn 2000John Kristoff15 Adaptive Retransmission Illustrated Ñ Timeout depends on current round-trip estimate

16. Autumn 2000John Kristoff16 TCP Flow Control ÑReceiver ÑAdvertises available buffer space ÑCalled the window ÑSender ÑCan send up to entire window before ACK arrives ÑAlso called a sliding window protocol

17. Autumn 2000John Kristoff17 Window Advertisement ÑEach acknowledgement carries new window information ÑCalled window advertisement ÑCan be zero (called closed window) ÑInterpretation: I have received up through X and can take Y more octets

18. Autumn 2000John Kristoff18 Window Advertisement Illustrated

19. Autumn 2000John Kristoff19 Another View: Sliding Window Illustrated

20. Autumn 2000John Kristoff20 Startup and Shutdown ÑConnection Startup ÑMust be reliable ÑConnection Shutdown ÑMust be graceful ÑDifficult

21. Autumn 2000John Kristoff21 Why Startup/Shutdown is Difficult ÑSegments can be Ñ lost Ñ duplicated Ñ delayed Ñ delivered out of order Ñ either side can crash Ñ either side can reboot  Need to avoid duplicate shutdown "message ” from affecting later connection

22. Autumn 2000John Kristoff22 TCP ’ s Startup Solution ÑUse three-message exchange ÑKnown as the 3-way handshake ÑNecessary and sufficient for unambiguous, reliable startup ÑSYN messages used for connection establishment

23. Autumn 2000John Kristoff23 3-Way Handshake Illustrated

24. Autumn 2000John Kristoff24 TCP ’ s Shutdown Illustrated

25. Autumn 2000John Kristoff25 Byte Stream Sequencing Ñ Segments are labeled with a sequence number Ñ Protects from out-of-order delivery Ñ 32-bit number Ñ Limited size of byte stream? Ñ Initial Sequence Numbers (ISNs) must be exchanged at TCP connection establishment

26. Autumn 2000John Kristoff26 More Complete Illustration of the 3-Way Handshake

27. Autumn 2000John Kristoff27 Application Multiplexing ÑCannot extend IP address ÑNo unused bits ÑCannot use OS dependent quantity ÑProcess ID ÑTask number ÑJob name ÑMust work on all computer systems

28. Autumn 2000John Kristoff28 Application Multiplexing Illustrated

29. Autumn 2000John Kristoff29 Protocol Ports Ñ Each application assigned a unique integer Ñ Server Ñ Follows standard Ñ Always uses same port number Ñ Usually uses lower port numbers Ñ Client Ñ Obtains unused port from protocol software Ñ Usually uses higher port numbers

30. Autumn 2000John Kristoff30 Protocol Port Example Ñ Web server application is assigned port 80 Ñ Web client application obtains port 32938 Ñ TCP segment sent from client to server has Ñ source port number 32938 Ñ destination port number 80 Ñ When web server responds, TCP segment has Ñ source port number 80 Ñ destination port number 32938

31. Autumn 2000John Kristoff31 Standard Protocol Ports Ñ See http://www.iana.org for standard protocol port assignments Ñ See /etc/services in UNIX systems and \winnt\system32\drivers\etc\services in Windows NT

32. Autumn 2000John Kristoff32 TCP Segment Format

33. Autumn 2000John Kristoff33 Example Transport Layer: User Datagram Protocol (UDP) ÑUnreliable message delivery ÑConnectionless protocol ÑNo flow control (no window) ÑNo error recovery (no ACKs) ÑProvides application multiplexing ÑError detection optional (checksum field)

34. Autumn 2000John Kristoff34 UDP Message Format