lecture 7 transport protocols: udp, tcp eecs 122 university of california berkeley
Post on 20-Jan-2016
217 views
TRANSCRIPT
![Page 1: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/1.jpg)
Lecture 7Transport Protocols: UDP, TCP
EECS 122University of California
Berkeley
![Page 2: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/2.jpg)
EECS 122 Walrand 2
TOC: Transport Protocols
Why? Overview UDP TCP Summary
![Page 3: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/3.jpg)
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
![Page 4: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/4.jpg)
EECS 122 Walrand 4
Transport: Overview
Basic Features Illustration Ports UDP TCP Headers
![Page 5: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/5.jpg)
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
![Page 6: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/6.jpg)
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
![Page 7: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/7.jpg)
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
![Page 8: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/8.jpg)
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
![Page 9: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/9.jpg)
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
![Page 10: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/10.jpg)
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
![Page 11: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/11.jpg)
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?
![Page 12: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/12.jpg)
EECS 122 Walrand 12
Transport: TCP Service Steps 3-Way Handshake State Diagram: 1 State Diagram: 2 Header Sliding Window Protocol
![Page 13: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/13.jpg)
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
![Page 14: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/14.jpg)
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
![Page 15: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/15.jpg)
EECS 122 Walrand 15
TCP: 3WH
Description Rationale
![Page 16: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/16.jpg)
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
![Page 17: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/17.jpg)
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)
![Page 18: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/18.jpg)
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
![Page 19: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/19.jpg)
EECS 122 Walrand 19
TCP: State Diagram 2
![Page 20: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/20.jpg)
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)
![Page 21: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/21.jpg)
EECS 122 Walrand 21
TCP: Sliding Window Protocol
ObjectivesStop & WaitGo-Back-n
![Page 22: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/22.jpg)
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
![Page 23: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/23.jpg)
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
![Page 24: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/24.jpg)
EECS 122 Walrand 24
SWP: Go-Back-n (GBN)DefinitionIllustration without errorsIllustration with errorsSliding window rulesSliding window exampleObservationsRound-Trip TimingThe question of ACKs
![Page 25: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/25.jpg)
EECS 122 Walrand 25
GBN: DefinitionTransmit up to n unacknowledged packetsIf timeout for ACK(k), retransmit k, k+1, …
![Page 26: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/26.jpg)
EECS 122 Walrand 26
GBN: Example without errors
Time
n = 9 packets in one RTT instead of 1
Fully efficient
![Page 27: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/27.jpg)
EECS 122 Walrand 27
GBN: Example with errors
Time
Window size = 3 packets
Sender Receiver
123
456
7TimeoutPacket 5
567
![Page 28: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/28.jpg)
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
![Page 29: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/29.jpg)
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
![Page 30: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/30.jpg)
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
![Page 31: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/31.jpg)
EECS 122 Walrand 31
GBN: Timing
ObjectiveIllustrationAdaptationAlgorithm
![Page 32: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/32.jpg)
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)
![Page 33: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/33.jpg)
EECS 122 Walrand 33
Timing: Illustrations
1
1
Timer too long
1
1
Timer too short
1RTT
![Page 34: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/34.jpg)
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
![Page 35: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/35.jpg)
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
![Page 36: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/36.jpg)
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
![Page 37: Lecture 7 Transport Protocols: UDP, TCP EECS 122 University of California Berkeley](https://reader035.vdocument.in/reader035/viewer/2022070415/56649d5f5503460f94a3f1d3/html5/thumbnails/37.jpg)
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