1. Chapter 5 Transport Layer: UDP, TCP Professor Rick Han University of Colorado at Boulder rhan@cs.colorado.edu

2. Prof. Rick Han, University of Colorado at Boulder Announcements Netstat portion of Homework #3 on Web, due March 12 (two weeks) Programming Assignment #2 due Friday March 22 by midnight Midterm March 14 Only through Network Layer, Chapter 4 OH changed today – 4:45-5:45 due to BACTAC talk Next, transport layer

3. Prof. Rick Han, University of Colorado at Boulder Recap of Previous Lecture IP Multicast 1->N Link-State Multicast: MOSPF Piggyback off of Dijkstra’s shortest path tree Distance-Vector Multicast: DVMRP Reverse-path flooding to all nodes Reverse-path pruning Protocol Independent Multicast: PIM For sparse wide-area trees Unicast to Rendezvous Point, RP then multicasts Tree built by explicit joins Internet Group Management Protocol (IGMP) How leaf nodes join a multicast group

4. Prof. Rick Han, University of Colorado at Boulder The Layered Network Stack Physical Layer Application Layer Transport Layer (TCP/UDP) Network Layer (IP) Data Link Layer Internet Stack Physical Layer Session Layer Transport Layer Network Layer Data Link Layer OSI Stack Presentation Layer Application Layer

5. Prof. Rick Han, University of Colorado at Boulder UDP: Unreliable Transport Protocols IP Provides Best-Effort unreliable datagram delivery User Datagram Protocol (UDP) provides best- effort unreliable datagram delivery Packets may be lost Due to congestion In routers At receiver and/or sender Due to fading Packets may be reordered Packets may be duplicated

6. Prof. Rick Han, University of Colorado at Boulder UDP (2) UDP “Features” Transport protocol above IP simply passes IP through to the upper (application) layers UDP “Features”: Gives app’s the option to send packets unreliably Useful for multicast app’s Low delay transmission for interactive text/audio/video Minimal connection setup time Minimal connection state: “connectionless” No congestion control – blast away Build own application-level protocol on top of UDP

7. Prof. Rick Han, University of Colorado at Boulder UDP (3) UDP Header: Only 8 bytes! (vs. IP 20 bytes header) Source port for UDP sending process Dest port for UDP receiving process Length in bytes of UDP header + payload Checksum over UDP header + payload Source Port #Dest. Port # UDP lengthChecksum 1632 UDP payload data UDP payload IP hdr UDP hdr

8. Prof. Rick Han, University of Colorado at Boulder UDP (4) UDP Checksum calculation UDP creates a “pseudo-header” containing IP header info Doublechecks that the packet has the correct IP address and UDP port # Source Port #Dest. Port # UDP lengthChecksum 1632 UDP payload data 0 ProtocolUDP length 32-bit IP destination address 32-bit IP source address Discarded if checksum fails Pseudo-Header UDP Header

9. Prof. Rick Han, University of Colorado at Boulder UDP Multiplexing/Demultiplexing IP Host 1 IP Host 2 Eth. MAC Phys. Eth MAC Phys. IP layer inspects Protocol field = UDP Sends to buffer of waiting UDP process with matching port # UDP Port 5100 UDP Port 5200 UDP Port 6001 UDP Port 433

10. Prof. Rick Han, University of Colorado at Boulder TCP: Transmission Control Protocol – Reliable Delivery TCP provides: Reliable delivery of packets, AND Stream or in-order delivery Also, full-duplex service Why TCP, when we can build reliable protocols on top of UDP? Many applications require reliable in-order delivery of packets Web pages, email, file transfer, … Why should each application reinvent the wheel? Can concentrate expert knowledge into building one reliable protocol provided to every application

11. Prof. Rick Han, University of Colorado at Boulder TCP (2) TCP is a true transport protocol, above IP TCP “Features”: Flow control Congestion control Connection setup Connection state machine Reliability, at the cost of some delay Achieves reliability by: Retransmission of a segment after a timeout or duplicate ACK Sliding window with sequence #’s TCP payload IP hdr TCP hdr

12. Prof. Rick Han, University of Colorado at Boulder TCP (3) TCP Header: 20 bytes Source port for TCP sending process Dest port for TCP receiving process 32-bit Sequence # (host is sender) 32-bit ACK # (host is receiver ACK’ing data sent by other endpoint) Source Port #Dest. Port # 32-bit Sequence # 32-bit Acknowledgement # Checksum Window Size Urgent Pointer Flags 1632

13. Prof. Rick Han, University of Colorado at Boulder TCP (3) TCP Header: Flags: SYN: synchronize sequence #’s to initiate connection FIN: sender is finished sending data RST: reset the connection, More… Source Port #Dest. Port # 32-bit Sequence # 32-bit Acknowledgement # Checksum Window Size Urgent Pointer Flags 1632

14. Prof. Rick Han, University of Colorado at Boulder TCP (4) TCP Header: Flow control window size: Receiver advertises how many bytes it is willing to accept into its buffer Checksum: computed over TCP header + payload Similar to UDP, prepends an IP Pseudo-Header Urgent Pointer points to where there is emergency data in payload Source Port #Dest. Port # 32-bit Sequence # 32-bit Acknowledgement # Checksum Window Size Urgent Pointer Flags 1632

15. Prof. Rick Han, University of Colorado at Boulder TCP (5) TCP Header: Variable-sized (not just 20 bytes), can have Options after the Urgent Pointer field Signalled in Flags field Most common option: Maximum Segment Size (MSS) exchanged during setup Source Port #Dest. Port # 32-bit Sequence # 32-bit Acknowledgement # Checksum Window Size Urgent Pointer Flags 1632

16. Prof. Rick Han, University of Colorado at Boulder High-Level TCP Characteristics Protocol implemented entirely at the ends –Fate sharing Protocol has evolved over time and will continue to do so –Nearly impossible to change the header –Uses options to add information to the header –Change processing at endpoints –Backward compatibility is what makes it TCP

17. Prof. Rick Han, University of Colorado at Boulder Connection Setup A and B must agree on initial sequence number selection Use 3-way handshake AB SYN + Seq A SYN+ACK-A + Seq B ACK-B

18. Prof. Rick Han, University of Colorado at Boulder Connection Setup (2) Why a three-way handshake? –Three-way handshake is necessary and sufficient for unambiguous setup/teardown even under conditions of Loss Duplication Delay

19. Prof. Rick Han, University of Colorado at Boulder Two-Way Handshake Handshake pictures courtesy of UMass Amherst

20. Prof. Rick Han, University of Colorado at Boulder Two-Way Handshake: Old Accepts

21. Prof. Rick Han, University of Colorado at Boulder Two-Way Handshake: Duplicate Requests

22. Prof. Rick Han, University of Colorado at Boulder Two-Way Handshake: Failure

23. Prof. Rick Han, University of Colorado at Boulder Two-Way Handshake W/ Timers

24. Prof. Rick Han, University of Colorado at Boulder 3-way Handshake: Unique ID’s Both sender and receiver choose unique ID’s to label their (x,y) connection x chosen by Sender, y by receiver Prevents Failure scenario in two-way handshakes w/o timers Client: (active) Server (passive)