1. Spring 2000John Kristoff1 Transport Layer Computer Networks

2. Spring 2000John Kristoff2 Where are we?

3. Spring 2000John Kristoff3 Recall zNetwork Layer yProvides host-to-host communication ySource and destination addresses are computers yMachine-to-machine networking

4. Spring 2000John Kristoff4 Transport Protocols zProvide application-to-application communication zNeed extended addressing mechanism to identify applications zCalled end-to-end zOptionally provide: xReliability xFlow Control xCongestion Control

5. Spring 2000John Kristoff5 Example Transport Layer: Transmission Control Protocol (TCP) zStandardized by IETF as RFC 793 zMost popular layer 4 protocol zConnection-oriented protocol zConceptually between applications and IP zFull-duplex operation zByte-stream interface zOf utmost importance for this class! zThe book: TCP/IP Illustrated, Volume I - W.R. Stevens

6. Spring 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. Spring 2000John Kristoff7 Relationship Between TCP and Other Protocols zTCP on one computer uses IP to communicate with TCP on another computer

8. Spring 2000John Kristoff8 Apparent Contradiction zIP offers best-effort (unreliable) delivery zTCP uses IP zTCP provides completely reliable transfer zHow is this possible?

9. Spring 2000John Kristoff9 Achieving Reliability zReliable connection setup zReliable data transmission zReliable connection shutdown

10. Spring 2000John Kristoff10 Reliable Data Transmission zPositive Acknowledgement yReceiver returns short message when data arrives yCall an acknowledgement zRetransmission ySender starts timer whenever message is transmitted yIf timer expires before acknowledgement arrives, sender retransmits message

11. Spring 2000John Kristoff11 Retransmission Illustrated

12. Spring 2000John Kristoff12 How Long Should TCP Wait Before Retransmitting? zTime for acknowledgement to arrive depends on yDistance to destination yCurrent traffic conditions zMultiple connections can be open simultaneously zTraffic conditions change rapidly

13. Spring 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. Spring 2000John Kristoff14 Solving the Retransmission Problem zKeep estimate of round trip time on each connection zUse current estimate to set retransmission timer zKnown as adaptive retransmission zKey to TCP’s success

15. Spring 2000John Kristoff15 Adaptive Retransmission Illustrated zTimeout depends on current round-trip estimate

16. Spring 2000John Kristoff16 TCP Flow Control zReceiver yAdvertises available buffer space yCalled the window zSender yCan send up to entire window before ACK arrives zAlso called a sliding window protocol

17. Spring 2000John Kristoff17 Window Advertisement zEach acknowledgement carries new window information yCall window advertisement yCan be zero (called closed window) zInterpretation: I have received up through X and can take Y more octets

18. Spring 2000John Kristoff18 Window Advertisement Illustrated

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

20. Spring 2000John Kristoff20 Startup and Shutdown zConnection Startup yMust be reliable zConnection Shutdown yMust be graceful zDifficult

21. Spring 2000John Kristoff21 Why Startup/Shutdown is Difficult zSegments can be ylost yduplicated ydelayed ydelivered out of order yeither side can crash yeither side can reboot zNeed to avoid duplicate shutdown “message” from affecting later connection

22. Spring 2000John Kristoff22 TCP’s Startup Solution zUse three-message exchange zKnown as the 3-way handshake zNecessary and sufficient for unambiguous, reliable startup zSYN messages used for connection establishment

23. Spring 2000John Kristoff23 3-Way Handshake Illustrated

24. Spring 2000John Kristoff24 TCP’s Shutdown Illustrated

25. Spring 2000John Kristoff25 Byte Stream Sequencing zSegments are labeled with a sequence number zProtects from out-of-order delivery z32-bit number zLimited size of byte stream? zInitial Sequence Numbers (ISNs) must be exchanged at TCP connection establishment

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

27. Spring 2000John Kristoff27 Application Multiplexing zCannot extend IP address yNo unused bits zCannot use OS dependent quantity yProcess ID yTask number yJob name zMust work on all computer systems

28. Spring 2000John Kristoff28 Application Multiplexing Illustrated

29. Spring 2000John Kristoff29 Protocol Ports zEach application assigned a unique integer zServer yFollows standard yAlways uses same port number yUsually uses lower port numbers zClient yObtains unused port from protocol software yUsually uses higher port numbers

30. Spring 2000John Kristoff30 Protocol Port Example zWeb server application is assigned port 80 zWeb client application obtains port 32938 zTCP segment sent from client to server has ysource port number 32938 ydestination port number 80 zWhen web server responds, TCP segment has ysource port number 80 ydestination port number 32938

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

32. Spring 2000John Kristoff32 TCP Segment Format

33. Spring 2000John Kristoff33 Example Transport Layer: User Datagram Protocol (UDP) zUnreliable message delivery zConnectionless protocol zNo flow control (no window) zNo error recovery (no ACKs) zProvides application multiplexing zError detection optional (checksum field)

34. Spring 2000John Kristoff34 UDP Message Format