Lecture 7Transport Protocols: UDP, TCP

EECS 122University of California

Berkeley

EECS 122 Walrand 2

TOC: Transport Protocols

Why?OverviewUDPTCPSummary

EECS 122 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

EECS 122 Walrand 4

Transport: Overview

Basic FeaturesIllustrationPortsUDPTCPHeaders

EECS 122 Walrand 5

Overview: Basic Features

Can provide more reliability, in order delivery, at most once deliverySupports messages of arbitrary lengthProvide a way to decide which packets go to which applications (multiplexing/demultiplexing)Govern when hosts should send data

EECS 122 Walrand 6

Overview: Illustration

IP

Transport

A B C

[A | B | p1 | p2 | …]

p1 p2 p1 p2 p3 p1 p2

portsApplication

HTTP DNSRA

UDP: Not reliableTCP: Ordered, reliable, well-paced

EECS 122 Walrand 7

Overview: PortsNeed to decide which application gets which packetsSolution: map each socket to a portClient must know server’s portSeparate 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 8

Overview: UDPUser Datagram Protocolminimalistic transport protocolsame best-effort service model as IPmessages of up to 64KBprovides multiplexing/demultiplexing to IPdoes not provide congestion controladvantage over TCP: does not increase end-to-end delay over IPapplication example: video/audio streaming

EECS 122 Walrand 9

Overview: TCPTransmission Control Protocolreliable, in-order, and at most once deliverymessages can be of arbitrary lengthprovides multiplexing/demultiplexing to IPprovides congestion control and avoidanceincreases end-to-end delay over IPe.g., file transfer, chat

EECS 122 Walrand 10

Overview: HeadersIP header ? used for IP routing, fragmentation, error detection… (we study that when we explore IP)UDP header ? used for multiplexing/demultiplexing, error detectionTCP header ? used for multiplexing/demultiplexing, flow and congestion control

IP

TCP UDPdataTCP/UDP

dataTCP/UDPIP

ApplicationSender

data

IP

TCP UDP

Application

Receiver

dataTCP/UDP

dataTCP/UDPIP

data

EECS 122 Walrand 11

Transport: UDPService:? Send datagram from (IPa, Port 1) to (IPb, Port 2)? Service is unreliable, but error detection possible

Header:

Source port Destination port0 16 31

UDP length UDP checksumPayload (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 12

Transport: TCPServiceSteps3-Way HandshakeState Diagram: 1State Diagram: 2HeaderSliding Window Protocol

EECS 122 Walrand 13

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 14

SYN k

SYN n; ACK k+1DATA k+1; ACK n+1

ACK k+n+1data exchange

FIN

FIN ACK½ close

FIN

FIN ACK ½ close

TCP: Steps

3-way handshake

EECS 122 Walrand 15

TCP: 3WH

DescriptionRationale

EECS 122 Walrand 16

3WH: DescriptionGoal: agree on a set of parameters: the

start sequence number for each side?Starting sequence numbers are random.

Client (initiator) Server

SYN, SeqNum = x

SYN and ACK, SeqNum = y and Ack = x + 1

ACK, Ack = y + 1

ActiveOpen

PassiveOpen

connect() listen()

accept()

allocatebuffer space

EECS 122 Walrand 17

3WH: RationaleThree-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 18

TCP: State Diagram 1

A

B

SYNSYN + ACK

Data + ACKACK …

FINFIN.ack FIN FIN.ack

Listen

SYN received

Established

Close Wait

Last Ack

Closed

ClosedSYN sent

EstablishedFIN Wait-1

FIN Wait-2

Timed WaitClosed

(1)

(1): A waits in case B retransmits FIN and A must ack again

EECS 122 Walrand 19

TCP: State Diagram 2

EECS 122 Walrand 20

TCP: Header

Sequence number, acknowledgement, and advertised window – used by sliding-window based flow controlFlags:? 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

Source port Destination port

Options (variable)

Sequence numberAcknowledgement

Advertised windowChecksum Urgent pointer

FlagsHdrLen

0 4 10 16 31

Payload (variable)

EECS 122 Walrand 21

TCP: Sliding Window ProtocolObjectivesStop & WaitGo-Back-n

EECS 122 Walrand 22

SWP: ObjectivesRetransmit missing packets?Numbering of packets and ACKs

Do this efficiently?Keep transmitting whenever possible?Detect missing ACKs and retransmit quickly

EECS 122 Walrand 23

SWP: Stop & Wait

ACK

DATA

Time

Sender

Receiver

RTT

Send; wait for ackIf timeout, retransmit; else repeat

Inefficient ifTRANS << RTTInefficient ifTRANS << RTT

TRANS

EECS 122 Walrand 24

SWP: Go-Back-n (GBN)DefinitionIllustration without errorsIllustration with errorsSliding window rulesSliding window exampleObservationsRound-Trip TimingThe question of ACKs

EECS 122 Walrand 25

GBN: DefinitionTransmit up to n unacknowledged packetsIf timeout for ACK(k), retransmit k, k+1, …

EECS 122 Walrand 26

GBN: Example without errors

Time

n = 9 packets in one RTT instead of 1

? Fully efficient

EECS 122 Walrand 27

GBN: Example with errors

Time

Window size = 3 packets

Sender Receiver

123456

7TimeoutPacket 5

567

EECS 122 Walrand 28

GBN: Sliding Window Ruleswindow = collection of adjacent sequence numbersthe 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 29

GBN: Sliding Window Ex.

1

23

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

45

6

5

67

Last ACKed (without gap) Last received (without gap)

7

EECS 122 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 retransmissionReceiver may be able to accept out-of-order packets, but only up to its buffer limits

EECS 122 Walrand 31

GBN: Timing ObjectiveIllustrationAdaptationAlgorithm

EECS 122 Walrand 32

Timing: Objective So, the sender needs to set timers in order to know when to retransmit a packet the may have been lostHow 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 33

Timing: Illustrations

1

1

Timer too long

1

1

Timer too short

1RTT

EECS 122 Walrand 34

Timing: AdaptationThe amount of time the sender should wait is about the round-trip time (RTT) between the sender and receiverFor link-layer networks (LANs), this value is essentially knownFor multi-hop WANS, rarely knownMust work in both environments, so protocol should adapt to the path behaviorMeasure successive ack delays T(n)Set timeout = average + 4 deviations

EECS 122 Walrand 35

Timing: AlgorithmUse exponential averaging:

Time

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 transmissions2. 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

EECS 122 Walrand 36

GBN: The question of ACKsWhat 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 37

Transport: SummaryUDP: Multiplex, detect errorsTCP: 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