1. Lecture 7 Transport Protocols: UDP, TCP
Walrand
Lecture 7
Lecture 7 Transport Protocols: UDP, TCP
EECS 122
University of California
Berkeley
EECS 122

2. TOC: Transport Protocols
Walrand
Lecture 7
TOC: Transport Protocols
Why?
Overview
UDP
TCP
Summary
EECS 122
Walrand
EECS 122

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

6. Overview: Illustrationp1 p2 p3
ports
HTTP RA
DNS
Application
Transport A B C IP
[A | B | p1 | p2 | …]
UDP: Not reliable
TCP: 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,
on UNIX, must be root to gain access to these ports (why?)
ephemeral ports(most ): given to clients
e.g. chatclient gets one of these
EECS 122
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
EECS 122
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
EECS 122
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
Sender
Receiver
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

11. Transport: UDP Service: Header: 16 31 Source port Destination port
Send datagram from (IPa, Port 1) to (IPb, Port 2)
Service is unreliable, but error detection possible
Header: 16 31
Source port
Destination 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

12. Transport: TCP Service Steps 3-Way Handshake State Diagram: 1
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. TCP: Steps 3-way handshake data exchange ½ close ½ close SYN k
SYN n; ACK k+1
DATA k+1; ACK n+1
3-way handshake
ACK k+n+1
data exchange
FIN
FIN ACK
½ close
FIN
FIN ACK
½ close
EECS 122
Walrand

15. TCP: 3WH
Description
Rationale
EECS 122
Walrand

16. SYN and ACK, SeqNum = y and Ack = x + 1
3WH: Description
Goal: agree on a set of parameters: the start sequence number for each side
Starting sequence numbers are random.
Client (initiator)
Server
Active Open
connect()
listen()
SYN, SeqNum = x
Passive Open
accept()
SYN and ACK, SeqNum = y and Ack = x + 1
ACK, Ack = y + 1
allocate buffer 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 Timed Wait SYN sent FIN Wait-1 Closed (1)
(1): A waits in case B retransmits FIN and A must ack again
Closed
Established
FIN Wait-2 A B
SYN
SYN + ACK
Data + ACK
ACK …
FIN
FIN.ack
Listen
SYN received
Established
Close Wait
Last Ack
Closed
EECS 122
Walrand

19. TCP: State Diagram 2
EECS 122
Walrand

20. TCP: Header 4 10 16 31 Source port Destination port Sequence number4 10 16 31
Source port
Destination port
Sequence number
Acknowledgement
Flags
Advertised window
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

21. TCP: Sliding Window Protocol
Objectives
Stop & Wait
Go-Back-n
EECS 122
Walrand

22. SWP: Objectives Retransmit missing packets Do this efficiently
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 Send; wait for ack
If timeout, retransmit; else repeat
TRANS
DATA
Receiver
Sender
Inefficient if
TRANS << RTT
RTT
ACK
Time
EECS 122
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
EECS 122
Walrand

25. GBN: Definition Transmit up to n unacknowledged packets
If timeout for ACK(k), retransmit k, k+1, …
EECS 122
Walrand

26. GBN: Example without errors
n = 9 packets in one RTT instead of 1
 Fully efficient
Time
EECS 122
Walrand

27. GBN: Example with errors
Window size = 3 packets 1 2 3 4 5 6
Timeout
Packet 5 7 5 6
Time 7
Sender
Receiver
EECS 122
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
EECS 122
Walrand

29. GBN: Sliding Window Ex. 1 2 3 4 5 6 7 5 6 7
Last ACKed (without gap)
Last received (without gap)
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 retransmission
Receiver may be able to accept out-of-order packets, but only up to its buffer limits
EECS 122
Walrand

31. GBN: Timing Objective Illustration Adaptation Algorithm 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 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

33. Timing: Illustrations1 1 1
RTT 1 1
EECS 122
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
EECS 122
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
EECS 122
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
EECS 122
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
EECS 122
Walrand