lecture 7 transport protocols: udp, tcp eecs 122 university of california berkeley

Lecture 7Transport Protocols: UDP, TCP

EECS 122University of California

Berkeley

EECS 122 Walrand 2

TOC: Transport Protocols

Why? Overview UDP TCP Summary

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 Features Illustration Ports UDP TCP Headers

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: 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 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

Application

Sender

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 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 12

Transport: TCP Service Steps 3-Way Handshake State Diagram: 1 State Diagram: 2 Header Sliding 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+1

DATA 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

Description Rationale

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: 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 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 Protocol

ObjectivesStop & WaitGo-Back-n

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

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

123

456

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: Algorithm

Use 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 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 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