1 / 37

Transport Protocols: UDP, TCP - Lecture 7

This lecture covers the reasons for transport protocols, an overview of UDP and TCP, and the basic features, ports, and headers of these protocols.

sharber
Download Presentation

Transport Protocols: UDP, TCP - Lecture 7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related