Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley
TOC: Transport Protocols Why? Overview UDP TCP Summary EECS 122 Walrand 2
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 EECS 122 Walrand 3
Transport: Overview Basic Features Illustration Ports UDP TCP Headers EECS 122 Walrand 4
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 EECS 122 Walrand 5
Overview: Illustration ports HTTP RA DNS Application p1 p2 p1 p2 p3 p1 p2 Transport A B C IP [A | B | p1 | p2 | …] UDP: Not reliable TCP: Ordered, reliable, well-paced EECS 122 Walrand 6
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 EECS 122 Walrand 7
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 EECS 122 Walrand 8
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 EECS 122 Walrand 9
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 EECS 122 Walrand 10
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? EECS 122 Walrand 11
Transport: TCP Service Steps 3-Way Handshake State Diagram: 1 State Diagram: 2 Header Sliding Window Protocol EECS 122 Walrand 12
TCP: Service Start a connection Reliable byte stream delivery from (IPa, TCP Port 1) to (IPb, TCP Port 2) Indication if connection fails: Reset Terminate connection EECS 122 Walrand 13
TCP: Steps 3-way handshake 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 EECS 122 Walrand 14
TCP: 3WH Description Rationale EECS 122 Walrand 15
3WH: Description Goal: agree on a set of parameters: the start sequence number for each side � Starting sequence numbers are random. Server Client (initiator) Active connect() listen() SYN, SeqNum = x Open Passive Open accept() 1 + x = k c A d n a y = m u N q e S , K C A d n a N Y S ACK, Ack = y + 1 allocate buffer space EECS 122 Walrand 16
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) EECS 122 Walrand 17
TCP: State Diagram 1 Timed Wait SYN sent FIN Wait-1 Closed Closed Established FIN Wait-2 (1) A SYN Data + ACK FIN FIN.ack … FIN FIN.ack SYN + ACK ACK B Listen Established Last Ack SYN received Closed Close Wait (1): A waits in case B retransmits FIN and A must ack again EECS 122 Walrand 18
TCP: State Diagram 2 EECS 122 Walrand 19
TCP: Header 0 4 10 16 31 Destination port Source port Sequence number Acknowledgement Advertised window Flags HdrLen Checksum Urgent pointer Options (variable) Payload (variable) 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 EECS 122 Walrand 20
TCP: Sliding Window Protocol Objectives Stop & Wait Go-Back-n EECS 122 Walrand 21
SWP: Objectives Retransmit missing packets � Numbering of packets and ACKs Do this efficiently � Keep transmitting whenever possible � Detect missing ACKs and retransmit quickly EECS 122 Walrand 22
SWP : Stop & Wait Send; wait for ack If timeout, retransmit; else repeat TRANS DATA Receiver Sender Inefficient if Inefficient if RTT ACK TRANS << RTT TRANS << RTT Time EECS 122 Walrand 23
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 EECS 122 Walrand 24
GBN: Definition Transmit up to n unacknowledged packets If timeout for ACK(k), retransmit k, k+1, … EECS 122 Walrand 25
GBN : Example without errors n = 9 packets in one RTT instead of 1 � Fully efficient Time EECS 122 Walrand 26
GBN: Example with errors Window size = 3 packets 1 2 3 4 5 6 Timeout Packet 5 7 5 Time 6 7 Sender Receiver EECS 122 Walrand 27
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 EECS 122 Walrand 28
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) EECS 122 Walrand 29
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 EECS 122 Walrand 30
GBN : Timing Objective Illustration Adaptation Algorithm EECS 122 Walrand 31
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) EECS 122 Walrand 32
Timing : Illustrations 1 1 1 RTT 1 1 Timer too long Timer too short EECS 122 Walrand 33
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 EECS 122 Walrand 34
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: 1. Measure T(n) only for original transmissions 2. Double Timeout after timeout … Justification: timeout indicates likely congestion; Further retransmissions would make things worse 3. Reset Timeout = A + 4D for new packet and when receive ACK Time EECS 122 Walrand 35
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 EECS 122 Walrand 36
Recommend
More recommend
