Transcript Chapter3transport

Chapter 3
Transport Layer
application
presentation
session
transport
TCP: connection oriented
UDP: connectionless
network
link
physical
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
message
segment
M
datagram Hn Ht
M
3/28/2016
application
transport
network
data link
physical
M
Ht
frame Hl Hn Ht
application
transport
network
data link
physical
M
Transport Layer: copyright J.F Kurose and K.W. Ross
3-2
Internet transport-layer protocols
 reliable, in-order
application
transport
network
data link
physical
delivery (TCP)



congestion control
flow control
connection setup
 unreliable, unordered
delivery: UDP

no-frills extension of
“best-effort” IP
3/28/2016
network
data link
physical
network
data link
physical
network
data link
physicalnetwork
network
data link
physical
data link
physical
network
data link
physical
application
transport
network
data link
physical
Transport Layer: copyright J.F Kurose and K.W. Ross
3-3
Recall
1.
1.
2.
2.
3.
4.
3.
5.
Create a socket with the socket() system call
Create a socket with the socket() system call
Bind socket to address using the bind() (port and ip address)
Connect the socket to the address of the server using the
Listen for connections with the listen() system call
connect() system call
Accept a connection with the accept() system call.
Send and receive data.
Send and receive data over socket returned by accept
 TCP socket identified
by 4-tuple:




source IP address
source port number
dest IP address
dest port number
many simultaneous TCP
sockets:

each socket identified by
its own 4-tuple
 Web servers have
 receiving host uses all
four values to direct
segment to appropriate
socket
 Muxing/Demuxing
3/28/2016
 Server host may support
different sockets for
each connecting client

non-persistent HTTP will
have different socket for
each request
Transport Layer: copyright J.F Kurose and K.W. Ross
3-4
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
3/28/2016
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
Transport Layer: copyright J.F Kurose and K.W. Ross
3-5
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
3/28/2016
0
Well-known
1023
1024
Registered
49151
49152
Private
65535
Application Layer: copyright J.F Kurose and K.W. Ross
6
UDP: more
 often used for streaming
multimedia apps
 loss tolerant
 rate sensitive
Length, in
bytes of UDP
segment,
including
header
 other UDP uses
 DNS
 SNMP
 reliable transfer over UDP:
add reliability at
application layer
 application-specific
error recovery!
3/28/2016
32 bits
source port #
dest port #
length
checksum
Application
data
(message)
UDP segment format
Transport Layer: copyright J.F Kurose and K.W. Ross
3-7
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
Sender:
Receiver:
 treat segment contents
 compute checksum of
as sequence of 16-bit
integers
 checksum: addition (1’s
complement sum) of
segment contents
 sender puts checksum
value into UDP checksum
field
3/28/2016
received segment
 check if computed checksum
equals checksum field value:
 NO - error detected
 YES - no error detected.
But maybe errors
nonetheless? More later
….
Transport Layer: copyright J.F Kurose and K.W. Ross
3-8
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 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-9
TCP
 How ensure
reliable data
transfer?
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-10
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
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross 3-11
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
stop and wait
Sender sends one packet,
then waits for receiver
response
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-12
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
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross 3-13
Cuts out one exchange: efficient?
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-14
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-tobe-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
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-15
Pipelining Protocols
Go-back-N: overview
 sender: up to N
unACKed pkts in
pipeline
 receiver: only sends
cumulative ACKs

Selective Repeat: overview
 sender: up to N unACKed
packets in pipeline
 receiver: ACKs individual
pkts
 sender: maintains timer
for each unACKed pkt
doesn’t ACK pkt if
there’s a gap
 sender: has timer for
oldest unACKed pkt


if timer expires: retransmit
only unACKed packet
if timer expires:
retransmit all unACKed
packets
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-16
Go-Back-N
Sender:
 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

3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-17
GBN in
action
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-18
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
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-19
Selective repeat: sender, receiver windows
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-20
Selective repeat in action
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-21
TCP seq. #’s and ACKs
Seq. #’s:
 byte stream
“number” of first
byte in segment’s
data
ACKs:
 seq # of next byte
expected from
other side
 cumulative ACK
Q: how receiver handles
out-of-order segments
 A: TCP spec doesn’t
say, - up to
implementer
3/28/2016
Host A
User
types
‘C’
Full Duplex
Host B
host ACKs
receipt of
‘C’, echoes
back ‘C’
host ACKs
receipt
of echoed
‘C’
simple telnet scenario
Transport Layer: copyright J.F Kurose and K.W. Ross
time
3-22
TCP segment structure
32 bits
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)
3/28/2016
source port #
dest port #
sequence number
acknowledgement number
head not
UA P R S F
len used
checksum
Receive window
Urg data pointer
Options (variable length)
application
data
(variable length)
counting
by bytes
of data
(not segments!)
# bytes
rcvr willing
to accept
length
Transport Layer: copyright J.F Kurose and K.W. Ross
3-23
TCP Round Trip Time and Timeout
Q: 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
3/28/2016
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
Transport Layer: copyright J.F Kurose and K.W. Ross
3-24
TCP Round Trip Time and Timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
 Exponential weighted moving average
 influence of past sample decreases exponentially fast
 typical value:  = 0.125
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-25
Example RTT estimation:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
RTT (milliseconds)
300
250
200
150
100
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
106
time (seconnds)
SampleRTT
3/28/2016
Estimated RTT
Transport Layer: copyright J.F Kurose and K.W. Ross
3-26
TCP Round Trip Time and Timeout
Setting the timeout
 EstimtedRTT plus “safety margin”

large variation in EstimatedRTT -> larger safety margin
 first estimate of how much SampleRTT deviates from
EstimatedRTT:
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typically,  = 0.25)
Then set timeout interval:
TimeoutInterval = EstimatedRTT + 4*DevRTT
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-27
How does TCP ACK
[RFC 1122, RFC 2581]
Event at Receiver
TCP Receiver action
Arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
Delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
Arrival of in-order segment with
expected seq #. One other
segment has ACK pending
Immediately send single cumulative
ACK, ACKing both in-order segments
Arrival of out-of-order segment
higher-than-expect seq. # .
Gap detected
Immediately send duplicate ACK,
indicating seq. # of next expected byte
Arrival of segment that
partially or completely fills gap
Immediate send ACK, provided that
segment starts at lower end of gap
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-28
Fast retransmit
 time-out period often
seq # x1
seq # x2
seq # x3
seq # x4
seq # x5
relatively long:

Host A
long delay before
resending lost packet
 detect lost segments


ACK x1
ACK x1
ACK x1
ACK x1
triple
duplicate
ACKs
sender often sends
many segments back-toback
if segment is lost, there
will likely be many
duplicate ACKs for that
segment
3/28/2016
X
timeout
via duplicate ACKs.
Host B
time
Transport Layer: copyright J.F Kurose and K.W. Ross
3-29
TCP Flow Control
flow control
sender won’t overflow
receiver’s buffer by
transmitting too much,
too fast
 receive side of TCP
connection has a
receive buffer:
(currently)
TCP data application
IP
unused buffer
(in buffer)
process
datagrams
space
 speed-matching
service: matching
send rate to receiving
application’s drain rate
 app process may be
slow at reading from
buffer
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-30
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
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-35
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)
sending rate
ACKs being received,
so increase rate
X
X loss, so decrease rate
X
X
TCP’s
“sawtooth”
behavior
X
time
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-36
The End
3/28/2016
Transport Layer: copyright J.F Kurose and K.W. Ross
3-40