chapter 3 transport layer tcp: connection oriented udp: connectionless application presentation...
TRANSCRIPT
Chapter 3Transport Layer
TCP: connection orientedUDP: connectionless
application
presentation
session
transport
network
link
physical
Transport Layer: copyright J.F Kurose and K.W. Ross 3-2
Transport services and protocols transport protocols run in
end systems send side: breaks app
messages into segments, passes to network layer
rcv side: reassembles segments into messages, passes to app layer
more than one transport protocol available to apps Internet: TCP and UDP
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
logical end-end transport
04/18/23
HtHn M
segment Ht
datagramHtHnHl M
message M
Ht M
Hn
frame
Transport Layer: copyright J.F Kurose and K.W. Ross 3-3
Internet transport-layer protocols reliable, in-order
delivery (TCP) congestion control flow control connection setup
unreliable, unordered delivery: UDP no-frills extension of
“best-effort” IP
application
transportnetworkdata linkphysical network
data linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
application
transportnetworkdata linkphysical
logical end-end transport
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-4
Recall
TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number
receiving host uses all four values to direct segment to appropriate socket
Muxing/Demuxing
Server host may support many simultaneous TCP sockets: each socket identified
by its own 4-tuple
Web servers have different sockets for each connecting client non-persistent HTTP will
have different socket for each request
04/18/23
1. Create a socket with the socket() system call2. Bind socket to address using the bind() (port and ip
address)3. Listen for connections with the listen() system call4. Accept a connection with the accept() system call. 5. Send and receive data over socket returned by accept
1. Create a socket with the socket() system call2. Connect the socket to the address of the server using the
connect() system call3. Send and receive data.
Transport Layer: copyright J.F Kurose and K.W. Ross 3-5
UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internet transport protocol
“best effort” service, UDP segments may be: lost delivered out of order
to app connectionless:
no handshaking between UDP sender, receiver
each UDP segment handled independently of others
Why is there a UDP? no connection
establishment (which can add delay)
simple: no connection state at sender, receiver
small segment header no congestion control:
UDP can blast away as fast as desired
04/18/23
Ports
Well-known ports 0 to 1023 are the well-known
ports. FTP 20/21, HTTP 80, Mail 25
Registered ports 1024 to 49151 are the
registered ports and are assigned by Internet Assigned Numbers Authority (IANA)
Dynamic, private or ephemeral ports 49152–65535
04/18/23 Application Layer: copyright J.F Kurose and K.W. Ross 6
0Well-known
1023
1024Registered
49151
49152Private65535
Transport Layer: copyright J.F Kurose and K.W. Ross 3-7
UDP: more
often used for streaming multimedia apps loss tolerant rate sensitive
other UDP uses DNS SNMP
reliable transfer over UDP: add reliability at application layer application-specific
error recovery!
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksumLength, in
bytes of UDPsegment,including
header
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-8
UDP checksum
Sender: treat segment contents
as sequence of 16-bit integers
checksum: addition (1’s complement sum) of segment contents
sender puts checksum value into UDP checksum field
Receiver: compute checksum of
received segment check if computed checksum
equals checksum field value: NO - error detected YES - no error detected.
But maybe errors nonetheless? More later ….
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-9
Internet Checksum Example Note
When adding numbers, a carryout from the most significant bit needs to be added to the result
Example: add two 16-bit integers
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
wraparound
sumchecksum
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-10
TCP
04/18/23
How ensure reliable data transfer?
Could acknowledge each packet Based on old character-based protocols
ASCII/EBCDIC (ACK = 06/2E, NAK = 15/3D) Acknowledgements (ACKs): receiver
explicitly tells sender that pkt received OK Negative acknowledgements (NAKs):
receiver explicitly tells sender that pkt had errors
sender retransmits pkt on receipt of NAK In packet might be a bit in the TCP
header
04/18/23 Transport Layer: copyright J.F Kurose and K.W. Ross 3-11
Transport Layer: copyright J.F Kurose and K.W. Ross 3-12
ACK/NAK has a fatal flaw!
What happens if ACK/NAK corrupted?
sender doesn’t know what happened at receiver!
can’t just retransmit: possible duplicate
Handling duplicates: sender retransmits current
pkt if ACK/NAK garbled sender adds sequence
number to each pkt receiver discards (doesn’t
deliver up) duplicate pkt
Sender sends one packet, then waits for receiver response
stop and wait
04/18/23
Efficient?
Could go NAK-free protocol instead of NAK, receiver sends ACK for
last pkt received OK receiver must explicitly include seq # of pkt
being ACKed duplicate ACK at sender results in same
action as NAK: retransmit current pkt
04/18/23 Transport Layer: copyright J.F Kurose and K.W. Ross 3-13
Transport Layer: copyright J.F Kurose and K.W. Ross 3-14
Cuts out one exchange: efficient?
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-15
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver
Two generic forms of pipelined protocols: go-Back-N, selective repeat
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-16
Pipelining Protocols
Go-back-N: overview sender: up to N
unACKed pkts in pipeline
receiver: only sends cumulative ACKs doesn’t ACK pkt if
there’s a gap sender: has timer for
oldest unACKed pkt if timer expires:
retransmit all unACKed packets
Selective Repeat: overview
sender: up to N unACKed packets in pipeline
receiver: ACKs individual pkts
sender: maintains timer for each unACKed pkt if timer expires:
retransmit only unACKed packet
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-17
Go-Back-NSender: k-bit seq # in pkt header “window” of up to N, consecutive unACKed pkts allowed
ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs (see receiver)
timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq # pkts in window
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-18
GBN inaction
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-19
Selective Repeat
receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order
delivery to upper layer
sender only resends pkts for which ACK not received sender timer for each unACKed pkt
sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-20
Selective repeat: sender, receiver windows
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-21
Selective repeat in action
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-22
TCP seq. #’s and ACKsSeq. #’s:
byte stream “number” of first byte in segment’s data
ACKs: seq # of next byte
expected from other side
cumulative ACKQ: how receiver handles
out-of-order segments A: TCP spec doesn’t
say, - up to implementer
Host A Host B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Usertypes
‘C’
host ACKsreceipt
of echoed‘C’
host ACKsreceipt of
‘C’, echoesback ‘C’
timesimple telnet scenario
04/18/23
Full DuplexFull Duplex
Transport Layer: copyright J.F Kurose and K.W. Ross 3-23
TCP segment structure
source port # dest port #
32 bits
applicationdata
(variable length)
sequence number
acknowledgement numberReceive window
Urg data pointerchecksum
FSRPAUheadlen
notused
Options (variable length)
URG: urgent data (generally not used)
ACK: ACK #valid
PSH: push data now(generally not used)
RST, SYN, FIN:connection estab(setup, teardown
commands)
# bytes rcvr willingto accept
countingby bytes of data(not segments!)
Internetchecksum
(as in UDP)
04/18/23
length
Transport Layer: copyright J.F Kurose and K.W. Ross 3-24
TCP Round Trip Time and TimeoutQ: how to set TCP
timeout value? longer than RTT
but RTT varies too short: premature
timeout unnecessary
retransmissions too long: slow
reaction to segment loss
Q: how to estimate RTT? SampleRTT: measured time
from segment transmission until ACK receipt ignore retransmissions
SampleRTT will vary, want estimated RTT “smoother” average several recent
measurements, not just current SampleRTT
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-25
TCP Round Trip Time and TimeoutEstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
Exponential weighted moving average influence of past sample decreases exponentially fast typical value: = 0.125
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-26
Example RTT estimation:RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RTT
(mill
isec
onds
)
SampleRTT Estimated RTT
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-27
TCP Round Trip Time and TimeoutSetting the timeout EstimtedRTT plus “safety margin”
large variation in EstimatedRTT -> larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT:
TimeoutInterval = EstimatedRTT + 4*DevRTT
DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|
(typically, = 0.25)
Then set timeout interval:
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-28
How does TCP ACK [RFC 1122, RFC 2581]
Event at Receiver
Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed
Arrival of in-order segment withexpected seq #. One other segment has ACK pending
Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected
Arrival of segment that partially or completely fills gap
TCP Receiver action
Delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK
Immediately send single cumulative ACK, ACKing both in-order segments
Immediately send duplicate ACK, indicating seq. # of next expected byte
Immediate send ACK, provided thatsegment starts at lower end of gap
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-29
Host A
tim
eout
Host B
time
X
resend seq X2
seq # x1seq # x2seq # x3seq # x4seq # x5
ACK x1
ACK x1ACK x1ACK x1
tripleduplicate
ACKs
04/18/23
Fast retransmit time-out period
often relatively long: long delay before
resending lost packet
detect lost segments via duplicate ACKs. sender often sends
many segments back-to-back
if segment is lost, there will likely be many duplicate ACKs for that segment
Transport Layer: copyright J.F Kurose and K.W. Ross 3-30
TCP Flow Control
receive side of TCP connection has a receive buffer:
speed-matching service: matching send rate to receiving application’s drain rate
app process may be slow at reading from buffer
sender won’t overflow
receiver’s buffer bytransmitting too
much, too fast
flow control
IPdatagrams
TCP data(in buffer)
(currently)unused buffer
space
applicationprocess
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-35
TCP congestion control: goal: TCP sender should transmit as fast as possible, but without congesting network
Q: how to find rate just below congestion level
decentralized: each TCP sender sets its own rate, based on implicit feedback: ACK: segment received (a good thing!), network not congested, so increase sending
rate lost segment: assume loss due to congested network, so decrease sending rate
04/18/23
Transport Layer: copyright J.F Kurose and K.W. Ross 3-36
TCP congestion control: bandwidth probing
“probing for bandwidth”: increase transmission rate on receipt of ACK, until eventually loss occurs, then decrease transmission rate continue to increase on ACK, decrease on loss (since available bandwidth
is changing, depending on other connections in network)
ACKs being received, so increase rate
X
X
XX
Xloss, so decrease rate
send
ing r
ate
time
TCP’s“sawtooth”behavior
04/18/23
The End
04/18/23 Transport Layer: copyright J.F Kurose and K.W. Ross 3-40