View
217
Download
0
Embed Size (px)
Citation preview
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