Transport Protocols: UDP, TCP - Lecture 7

1. Lecture 7Transport Protocols: UDP, TCP EECS 122 University of California Berkeley

2. TOC: Transport Protocols • Why? • Overview • UDP • TCP • Summary Walrand

3. Transport: Why? • IP provides a weak, but efficient service model (best-effort) • Packets can be delayed, dropped, reordered, duplicated • Packets have limited size (why?) • IP packets are addressed to a host • How to decide which application gets which packets? • How should hosts send into the network? • Too fast is bad; too slow is not efficient Walrand

4. Transport: Overview • Basic Features • Illustration • Ports • UDP • TCP • Headers Walrand

5. Overview: Basic Features • Can provide more reliability, in order delivery, at most once delivery • Supports messages of arbitrary length • Provide a way to decide which packets go to which applications (multiplexing/demultiplexing) • Govern when hosts should send data Walrand

6. ports p1 p2 p1 p2 p3 p1 p2 A B C Overview: Illustration HTTP RA DNS Application Transport IP [A | B | p1 | p2 | …] UDP: Not reliable TCP: Ordered, reliable, well-paced Walrand

7. Overview: Ports • Need to decide which application gets which packets • Solution: map each socket to a port • Client must know server’s port • Separate 16-bit port address space for UDP and TCP • (src IP, src port, dst IP, dst port) uniquely identifies TCP connection • Well known ports (0-1023): everyone agrees which services run on these ports • e.g., ssh:22, http:80 • on UNIX, must be root to gain access to these ports (why?) • ephemeral ports(most 1024-65535): given to clients • e.g. chatclient gets one of these Walrand

8. Overview: UDP • User Datagram Protocol • minimalistic transport protocol • same best-effort service model as IP • messages of up to 64KB • provides multiplexing/demultiplexing to IP • does not provide congestion control • advantage over TCP: does not increase end-to-end delay over IP • application example: video/audio streaming Walrand

9. Overview: TCP • Transmission Control Protocol • reliable, in-order, and at most once delivery • messages can be of arbitrary length • provides multiplexing/demultiplexing to IP • provides congestion control and avoidance • increases end-to-end delay over IP • e.g., file transfer, chat Walrand

10. Overview: Headers • IP header  used for IP routing, fragmentation, error detection… (we study that when we explore IP) • UDP header  used for multiplexing/demultiplexing, error detection • TCP header  used for multiplexing/demultiplexing, flow and congestion control Receiver Sender Application Application data data TCP UDP TCP UDP TCP/UDP data TCP/UDP data IP IP IP TCP/UDP data IP TCP/UDP data Walrand

11. Transport: UDP • Service: • Send datagram from (IPa, Port 1) to (IPb, Port 2) • Service is unreliable, but error detection possible • Header: 0 16 31 Destination port Source port UDP length UDP checksum Payload (variable) • UDP length is UDP packet length • (including UDP header and payload, but not IP header) • Optional UDP checksum is over UDP packet •  Why have UDP checksum in addition to IP checksum? •  Why not have just the UDP checksum? •  Why is the UDP checksum optional? Walrand

12. Transport: TCP • Service • Steps • 3-Way Handshake • State Diagram: 1 • State Diagram: 2 • Header • Sliding Window Protocol Walrand

13. TCP: Service • Start a connection • Reliable byte stream deliveryfrom (IPa, TCP Port 1) to (IPb, TCP Port 2) • Indication if connection fails: Reset • Terminate connection Walrand

14. SYN k SYN n; ACK k+1 DATA k+1; ACK n+1 ACK k+n+1 data exchange FIN ½ close FIN ACK FIN ½ close FIN ACK TCP: Steps 3-way handshake Walrand

15. TCP: 3WH • Description • Rationale Walrand

16. SYN, SeqNum = x SYN and ACK, SeqNum = y and Ack = x + 1 ACK, Ack = y + 1 3WH: Description Goal: agree on a set of parameters: the start sequence number for each side • Starting sequence numbers are random. Server Client (initiator) ActiveOpen connect() listen() PassiveOpen accept() allocatebuffer space Walrand

17. 3WH: Rationale • Three-way handshare adds 1 RTT delay • Why? • congestion control: SYN (40 byte) acts as cheap probe • Protects against delayed packets from other connection (would confuse receiver) Walrand

18. Timed Wait SYN sent FIN Wait-1 Closed Closed Established FIN Wait-2 (1) A SYN Data + ACK FIN Established Listen FIN.ack Last Ack … FIN FIN.ack SYN + ACK ACK B SYN received Closed Close Wait (1): A waits in case B retransmits FIN and A must ack again TCP: State Diagram 1 Walrand

19. TCP: State Diagram 2 Walrand

20. TCP: Header 0 4 10 16 31 • Sequence number, acknowledgement, and advertised window – used by sliding-window based flow control • Flags: • SYN, FIN – establishing/terminating a TCP connection • ACK – set when Acknowledgement field is valid • URG – urgent data; Urgent Pointer says where non-urgent data starts • PUSH – don’t wait to fill segment • RESET – abort connection Destination port Source port Sequence number Acknowledgement Advertised window Flags HdrLen Checksum Urgent pointer Options (variable) Payload (variable) Walrand

21. TCP: Sliding Window Protocol • Objectives • Stop & Wait • Go-Back-n Walrand

22. SWP: Objectives • Retransmit missing packets • Numbering of packets and ACKs • Do this efficiently • Keep transmitting whenever possible • Detect missing ACKs and retransmit quickly Walrand

23. SWP: Stop & Wait • Send; wait for ack • If timeout, retransmit; else repeat TRANS DATA Receiver Sender Inefficient if TRANS << RTT RTT ACK Time Walrand

24. SWP: Go-Back-n (GBN) • Definition • Illustration without errors • Illustration with errors • Sliding window rules • Sliding window example • Observations • Round-Trip Timing • The question of ACKs Walrand

25. GBN: Definition • Transmit up to n unacknowledged packets • If timeout for ACK(k), retransmit k, k+1, … Walrand

26. GBN: Example without errors n = 9 packets in one RTT instead of 1  Fully efficient Time Walrand

27. GBN: Example with errors Window size = 3 packets 1 2 3 4 5 6 Timeout Packet 5 7 5 Time 6 7 Sender Receiver Walrand

28. GBN: Sliding Window Rules • window = collection of adjacent sequence numbers • the size of the collection is the window size • Let A be the last ack’d packet of sender without gap; then window of sender = {A+1, A+2, …, A+n} • Sender can send packets in its window • Let B be the last received packet without gap by receiver, then window of receiver = {B+1,…, B+n} • Receiver can accept out of sequence, if in window Walrand

29. GBN: Sliding Window Ex. 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 5 6 7 Last ACKed (without gap) Last received (without gap) Walrand

30. GBN: Observations • With sliding windows, it is possible to fully utilize a link, provided the window size is large enough. Throughput is ~ (w/RTT); Stop & Wait is like w = 1. • Sender has to buffer all unacknowledged packets, because they may require retransmission • Receiver may be able to accept out-of-order packets, but only up to its buffer limits Walrand

31. GBN: Timing • Objective • Illustration • Adaptation • Algorithm Walrand

32. Timing: Objective • So, the sender needs to set timers in order to know when to retransmit a packet the may have been lost • How long to set the timer for? • Too short: may retransmit before data or ACK has arrived, creating duplicates • Too long: if a packet is lost, will take a long time to recover (inefficient) Walrand

33. Timing: Illustrations 1 1 1 RTT 1 1 Timer too long Walrand Timer too short

34. Timing: Adaptation • The amount of time the sender should wait is about the round-trip time (RTT) between the sender and receiver • For link-layer networks (LANs), this value is essentially known • For multi-hop WANS, rarely known • Must work in both environments, so protocol should adapt to the path behavior • Measure successive ack delays T(n)Set timeout = average + 4 deviations Walrand

35. Timing: Algorithm • Use exponential averaging: A(n) = bA(n- 1) + (1 – b)T(n) D(n) = bD(n-1) + (1 – b)|T(n) – A(n)| Timeout(n) = A(n) +4D(n) • Notes: • Measure T(n) only for original transmissions • Double Timeout after timeout …Justification: timeout indicates likely congestion; Further retransmissions would make things worse • Reset Timeout = A + 4D for new packet and when receive ACK Walrand Time

36. GBN: The question of ACKs • What exactly should the receiver ACK? • Some possibilities: • ACK every packet, giving its sequence number • use cumulative ACK, where an ACK for number n implies ACKS for all k < n • use negative ACKs (NACKs), indicating which packet did not arrive • use selective ACKs (SACKs), indicating those that did arrive, even if not in order Walrand

37. Transport: Summary • UDP: Multiplex, detect errors • TCP: Reliable Byte Stream • 3WH; Exchange; Close • Reliable transmissions: ACKs… • S&W not efficient  Go-Back-n • What to ACK? (cumulative, …) • Timer Value: based on measured RTT • Next: Congestion and Flow Control Walrand