EE 122 Transport Protocols UDP and TCP Computer

  • Slides: 41
Download presentation
EE 122: Transport Protocols: UDP and TCP Computer Science Division Department of Electrical Engineering

EE 122: Transport Protocols: UDP and TCP Computer Science Division Department of Electrical Engineering and Computer Science University of California, Berkeley, CA 94720 -1776 October 5, 2004 Katz, Stoica F 04

Today’s Lecture Application Transport Network (IP) Link Physical Katz, Stoica F 04 2

Today’s Lecture Application Transport Network (IP) Link Physical Katz, Stoica F 04 2

Outline Ø § § § Motivation Transport layer TCP UDP Katz, Stoica F 04

Outline Ø § § § Motivation Transport layer TCP UDP Katz, Stoica F 04 3

Motivation § IP provides a weak, but efficient service model (best-effort) - Packets can

Motivation § 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 packets into the network? - Too fast may overwhelm the network - Too slow is not efficient Katz, Stoica F 04 4

Outline § Ø § § Motivation Transport layer TCP UDP Katz, Stoica F 04

Outline § Ø § § Motivation Transport layer TCP UDP Katz, Stoica F 04 5

Transport Layer § § Provide a way to decide which packets go to which

Transport Layer § § Provide a way to decide which packets go to which applications (multiplexing/demultiplexing) Can - Provide reliability, in order delivery, at most once delivery - Support messages of arbitrary length - Govern when hosts should send data can implement congestion and flow control Katz, Stoica F 04 6

Congestion vs. Flow Control § Flow Control – avoid overflowing the receiver Congestion Control

Congestion vs. Flow Control § Flow Control – avoid overflowing the receiver Congestion Control – avoid congesting the network § What is network congestion? § Katz, Stoica F 04 7

Transport Layer (cont’d) ports HTTP RA DNS Application p 1 p 2 p 3

Transport Layer (cont’d) ports HTTP RA DNS Application p 1 p 2 p 3 p 1 p 2 Transport IP A B C [A | B | p 1 | p 2 | …] UDP: Not reliable TCP: Ordered, reliable, well-paced Katz, Stoica F 04 8

Ports § § Need to decide which application gets which packets Solution: map each

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. chat clients, p 2 p networks Katz, Stoica F 04 9

Headers § § § IP IP header used for IP routing, fragmentation, error detection

Headers § § § IP IP header used for IP routing, fragmentation, error detection UDP header used for multiplexing/demultiplexing, error detection TCP header used for multiplexing/demultiplexing, flow and congestion control Receiver data Sender Application TCP/UDP data TCP UDP TCP/UDP data IP IP data TCP/UDP data Katz, Stoica F 04 10 IP

Outline § § Ø § Motivation Transport Layer UDP TCP Katz, Stoica F 04

Outline § § Ø § Motivation Transport Layer UDP TCP Katz, Stoica F 04 11

UDP: User (Unreliable) Data Protocol § § § Minimalist transport protocol Same best-effort service

UDP: User (Unreliable) Data Protocol § § § Minimalist transport protocol Same best-effort service model as IP Messages up to 64 KB Provides multiplexing/demultiplexing to IP Does not provide flow and congestion control Application examples: video/audio streaming Katz, Stoica F 04 12

UDP Service & Header § Service: - Send datagram from (IPa, Port 1) to

UDP Service & Header § Service: - Send datagram from (IPa, Port 1) to (IPb, Port 2) - Service is unreliable, but error detection possible § Header: 0 16 Source port UDP length 31 Destination port 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 Katz, Stoica F 04 13

Outline § § § Ø Motivation Transport Layer UDP TCP Katz, Stoica F 04

Outline § § § Ø Motivation Transport Layer UDP TCP Katz, Stoica F 04 14

TCP: Transport Control Protocol § § § Reliable, in-order, and at most once delivery

TCP: Transport Control Protocol § § § Reliable, in-order, and at most once delivery Stream oriented: messages can be of arbitrary length Provides multiplexing/demultiplexing to IP Provides congestion control and avoidance Application examples: file transfer, chat Katz, Stoica F 04 15

TCP Service 1) 2) Open connection: 3 -way handshaking Reliable byte stream transfer from

TCP Service 1) 2) Open connection: 3 -way handshaking Reliable byte stream transfer from (IPa, TCP_Port 1) to (IPb, TCP_Port 2) • 3) Indication if connection fails: Reset Close (tear-down) connection Katz, Stoica F 04 16

Open Connection: 3 -Way Handshaking § Goal: agree on a set of parameters: the

Open Connection: 3 -Way Handshaking § Goal: agree on a set of parameters: the start sequence number for each side - Starting sequence numbers are random Server Client (initiator) Active connect() Open listen() SYN, Seq Num = x eq. Num S , K C A YN and =x+ k c A d n =ya 1 accept() Passive Open S ACK, Ack =y+1 allocate buffer space Katz, Stoica F 04 17

3 -Way Handshaking (cont’d) § § Three-way handshake adds 1 RTT delay Why? -

3 -Way Handshaking (cont’d) § § Three-way handshake adds 1 RTT delay Why? - Congestion control: SYN (40 byte) acts as cheap probe - Protects against delayed packets from other connection (would confuse receiver) Katz, Stoica F 04 18

Close Connection (Two-Army Problem) § § Goal: both sides agree to close the connection

Close Connection (Two-Army Problem) § § Goal: both sides agree to close the connection Two-army problem: - “Two blue armies need to simultaneously attack the white army to win; otherwise they will be defeated. The blue army can communicate only across the area controlled by the white army which can intercept the messengers. ” § What is the solution? Katz, Stoica F 04 19

Close Connection § 4 -ways tear down connection Host 1 Host 2 FIN close

Close Connection § 4 -ways tear down connection Host 1 Host 2 FIN close FIN ACK timeout § Avoid reincarnation § Can retransmit FIN ACK if it is lost closed Katz, Stoica F 04 20

Reliable Transfer § Retransmit missing packets - Numbering of packets and ACKs § Do

Reliable Transfer § Retransmit missing packets - Numbering of packets and ACKs § Do this efficiently - Keep transmitting whenever possible - Detect missing ACKs and retransmit quickly § Two schemes - Stop & Wait - Sliding Window (Go-back-n and Selective Repeat) Katz, Stoica F 04 21

Stop & Wait § § Send; wait for ack If timeout, retransmit; else repeat

Stop & Wait § § Send; wait for ack If timeout, retransmit; else repeat TRANS DATA Receiver Sender RTT ACK Time Inefficient if TRANS << RTT Katz, Stoica F 04 22

Sliding Window § window = set of adjacent sequence numbers The size of the

Sliding Window § window = set of adjacent sequence numbers The size of the set is the window size § Assume window size is n § 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 § Katz, Stoica F 04 23

Go-Back-n (GBN) § § Transmit up to n unacknowledged packets If timeout for ACK(k),

Go-Back-n (GBN) § § Transmit up to n unacknowledged packets If timeout for ACK(k), retransmit k, k+1, … Katz, Stoica F 04 24

GBN Example w/o Errors Sender Window {1} {1, 2, 3} {2, 3, 4} {3,

GBN Example w/o Errors Sender Window {1} {1, 2, 3} {2, 3, 4} {3, 4, 5} {4, 5, 6}. . . 1 2 3 4 5 6 Window size = 3 packets Receiver Window {} {} {}. . . Time Sender Receiver Katz, Stoica F 04 25

GBN Example with Errors Timeout Packet 4 1 2 3 4 5 6 Sender

GBN Example with Errors Timeout Packet 4 1 2 3 4 5 6 Sender Window size = 3 packets {} {} {} {5, 6} 4 is missing {} Receiver Katz, Stoica F 04 26

Selective Repeat (SR) § § § Sender: transmit up to n unacknowledged packets; assume

Selective Repeat (SR) § § § Sender: transmit up to n unacknowledged packets; assume packet k is lost Receiver: indicate packet k is missing Sender: retransmit packet k Katz, Stoica F 04 27

SR Example with Errors {1} {1, 2, 3} {2, 3, 4} {3, 4, 5}

SR Example with Errors {1} {1, 2, 3} {2, 3, 4} {3, 4, 5} {4, 5, 6} 1 2 3 Window size = 3 packets 4 5 6 {4, 5, 6} 4 Nack = 4 Time {7} 7 Sender Receiver Katz, Stoica F 04 28

Observations § With sliding windows, it is possible to fully utilize a link, provided

Observations § With sliding windows, it is possible to fully utilize a link, provided the window size is large enough. Throughput is ~ (n/RTT) - Stop & Wait is like n = 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 Katz, Stoica F 04 29

TCP Flow Control § § § Each byte has a sequence number Initial sequence

TCP Flow Control § § § Each byte has a sequence number Initial sequence numbers negotiated via SYN/SYN-ACK packets ACK contains the sequence number of the next byte expected by the receiver Katz, Stoica F 04 30

TCP Flow Control § Receiver window (Max. Rcv. Buf – maximum buffer size at

TCP Flow Control § Receiver window (Max. Rcv. Buf – maximum buffer size at receiver) Advertised. Window = Max. Rcv. Buffer – (Last. Byte. Rcvd – Last. Byte. Read) § Sender window (Max. Send. Buf – maximum buffer size at sender) Sender. Window = Advertised. Window – (Last. Byte. Sent – Last. Byte. Acked) Max. Send. Buffer >= Last. Byte. Written - Last. Byte. Acked Sending Application Last. Byte. Written Last. Byte. Acked Last. Byte. Sent sequence number increases Receiving Application Last. Byte. Read Next. Byte. Expected Last. Byte. Rcvd sequence number increases Katz, Stoica F 04 31

Retransmission Timeout § § If haven’t received ack by timeout, retransmit packet after last

Retransmission Timeout § § If haven’t received ack by timeout, retransmit packet after last acked packet How to set timeout? Katz, Stoica F 04 32

Timing Illustration 1 1 Timeout RTT 1 Timeout too long inefficiency Timeout too short

Timing Illustration 1 1 Timeout RTT 1 Timeout too long inefficiency Timeout too short duplicate packets Katz, Stoica F 04 33

Retransmission Timeout (cont’d) § § If haven’t received ack by timeout, retransmit packet after

Retransmission Timeout (cont’d) § § If haven’t received ack by timeout, retransmit packet after last acked packet How to set timeout? - Too long: connection has low throughput - Too short: retransmit packet that was just delayed • Packet was probably delayed because of congestion • Sending another packet too soon just makes congestion worse § Solution: make timeout proportional to RTT Katz, Stoica F 04 34

RTT Estimation Use exponential averaging: Estimated. RTT § Sample. RTT Time Katz, Stoica F

RTT Estimation Use exponential averaging: Estimated. RTT § Sample. RTT Time Katz, Stoica F 04 35

Exponential Averaging Example Estimated. RTT = α*Estimated. RTT + (1 – α)*Sample. RTT Assume

Exponential Averaging Example Estimated. RTT = α*Estimated. RTT + (1 – α)*Sample. RTT Assume RTT is constant Sample. RTT = RTT Estimated. RTT (α = 0. 5) RTT Estimated. RTT (α = 0. 8) 0 1 2 3 4 5 6 7 8 9 time Katz, Stoica F 04 36

Problem How to differentiate between the real ACK, and ACK of the retransmitted packet?

Problem How to differentiate between the real ACK, and ACK of the retransmitted packet? Sender Sample. RTT Origin Receiver al Tra nsmis Retra nsmi sion ssion Sender Sample. RTT § Origin Receiver al Tra n smiss ion CK Retra A nsmi ssion ACK Katz, Stoica F 04 37

Karn/Partridge Algorithm § § Measure Sample. RTT only for original transmissions Exponential backoff for

Karn/Partridge Algorithm § § Measure Sample. RTT only for original transmissions Exponential backoff for each retransmission, double Estimated. RTT Katz, Stoica F 04 38

Jacobson/Karels Algorithm § Problem: exponential average is not enough - One solution: use standard

Jacobson/Karels Algorithm § Problem: exponential average is not enough - One solution: use standard deviation (requires expensive square root computation) - Use mean deviation instead Katz, Stoica F 04 39

TCP Header § § Sequence number, acknowledgement, and advertised window – used by sliding-window

TCP Header § § 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 0 4 10 16 31 Destination port Source port Sequence number Acknowledgement Advertised window Hdr. Len Flags Checksum Urgent pointer Options (variable) Payload (variable) Katz, Stoica F 04 40

Summary § § UDP: Multiplex, detect errors TCP: Reliable Byte Stream - 3 -way

Summary § § UDP: Multiplex, detect errors TCP: Reliable Byte Stream - 3 -way handshaking Reliable transmissions: ACKs… S&W not efficient Go-Back-n What to ACK? (cumulative, …) Timer Value: based on measured RTT Katz, Stoica F 04 41