Chapter - 3 - V7.01-Transport Layer
Chapter - 3 - V7.01-Transport Layer
Transport
Layer
Computer
Networking: A
Top Down
Approach
7th Edition, Global Edition
Jim Kurose, Keith Ross
Pearson
April 2016
Transport Layer 2-1
Chapter 3: Transport Layer
our goals:
understand learn about
principles Internet transport
behind transport layer protocols:
layer services: • UDP:
• multiplexing, connectionless
demultiplexing transport
• reliable data • TCP: connection-
transfer oriented reliable
• flow control transport
• congestion • TCP congestion
control control
Transport Layer 3-2
Chapter 3 outline
3.1 transport-layer services
3.5 connection-
oriented
3.2 multiplexing and demultiplexing
transport:
3.3 connectionless transport: UDP TCP
• segment
3.4 principles of reliablestructure
data
transfer • reliable data
transfer
• flow control
• connection
management
3.6 principles of
congestion Transport Layer 3-3
Transport services and
protocols applicatio
provide logical n
transport
communication between network
data link
app processes running on physical
different hosts, as if
lo
gi
ca
processes directly
enl
connected
d-
en
transport protocols run in
d
tr
end systems
a
ns
po
• send side: breaks app
rt
messages into segments, applicatio
passes to network layer n
transport
• rcv side: reassembles network
lo
network data link
gi
• flow control data link physical
ca
physical
network
l
• connection setup
en
data link
unreliable, unordered
d-
physical
en
network
d
delivery: UDP data link
tr
a
physical
ns
• no-frills extension of network
po
data link
“best-effort” IP
r
physical
t
network
services not available: data link
physical
applicatio
network n
• delay guarantees data link transport
network
physical
• bandwidth guarantees data link
physical
application
length checksum
why is there a UDP?
no connection
application establishment (which can
data add delay)
(payload) simple: no connection
state at sender, receiver
small header size (8B, TCP
20B)
no congestion control:
UDP segment format
UDP can blast away as fast
as desired
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
send receive
side side
sender receiver
notcorrupt(rcvpkt)
extract(rcvpkt,data
)
deliver_data(data)
udt_send(ACK)
Transport Layer 3-29
rdt2.0: operation with no
errors
rdt_send(data)
snkpkt = make_pkt(data,
checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt)
call from ACK or udt_send(sndp &&
above NAK kt) corrupt(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data
)
deliver_data(data)
udt_send(ACK)
Transport Layer 3-30
rdt2.0: error scenario
rdt_send(data)
snkpkt = make_pkt(data,
checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt)
call from ACK or udt_send(sndp &&
above NAK kt) corrupt(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data
)
deliver_data(data)
udt_send(ACK)
Transport Layer 3-31
rdt2.0 has a fatal flaw!
what happens if handling duplicates:
ACK/NAK sender retransmits
corrupted? current pkt if ACK/NAK
sender doesn’t know corrupted
what happened at sender adds sequence
receiver! number to each pkt
can’t just retransmit: receiver discards
possible duplicate (doesn’t deliver up)
duplicate pkt
stop and wait
sender sends one
packet,
then waits for receiver
response
1-bit sequence # is Transport Layer 3-32
rdt2.1: sender, handles garbled
ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data,
checksum) rdt_rcv(rcvpkt) &&
udt_send(sndpkt) ( corrupt(rcvpkt) ||
Wait for Wait for
ACK or
isNAK(rcvpkt) )
call 0
NAK 0 udt_send(sndpkt)
from
rdt_rcv(rcvpkt) above
&& rdt_rcv(rcvpkt)
notcorrupt(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt) && isACK(rcvpkt)
L
L
Wait for Wait for
ACK or call 1
rdt_rcv(rcvpkt) NAK 1 from
&& above
( corrupt(rcvpkt) rdt_send(data)
||
udt_send(sndpk sndpkt = make_pkt(1, data,
isNAK(rcvpkt)
t) ) checksum)
udt_send(sndpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
U L/R .008
sender = = = 0.00027
RTT + L / R 30.008
U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008
dilemma 0 1 2 3 0 1 2 pkt0
pkt1 0123012
0123012
0123012 pkt2 0123012
example: 0123012 pkt3
0123012
User
types
‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
Seq=79, ACK=43, data = ‘C’ back ‘C’
host ACKs
receipt
of echoed piggybacked
‘C’ Seq=43, ACK=80 ACK
350
300
250
RTT (milliseconds)
200
sampleRTT
150
EstimatedRTT
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
time Transport Layer 3-63
SampleRTT Estimated RTT
TCP round trip time,
timeout
timeout interval: EstimatedRTT plus “safety
margin”
• large variation in EstimatedRTT -> larger safety margin
estimate
DevRTT =SampleRTT deviation
(1-)*DevRTT + from EstimatedRTT:
*|SampleRTT-EstimatedRTT|
(typically, = 0.25)
if (y > SendBase) {
SendBase = y
/* SendBase–1: last cumulatively ACKed byte */
if (there are currently not-yet-acked segments)
start timer
else stop timer
} Transport Layer 3-68
TCP: retransmission
scenarios
Host A Host B Host A Host B
SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data
timeout
timeout
Seq=100, 20 bytes of data
ACK=100
X
ACK=100
ACK=120
SendBase=120
ACK=100
X
ACK=120
cumulative ACK
Transport Layer 3-70
TCP ACK generation [RFC 1122, RFC
2581]
ACK=100
timeout
ACK=100
ACK=100
ACK=100
Seq=100, 20 bytes of data
从罗列的情况可看出:
• 在报文未丢失情况下,有 40% 的可能出现 3 次冗余 ACK
• 在乱序情况下,必定出现 2 次冗余 ACK
• 在丢失情况下,必定出现 3 次冗余 ACK
IP
flow control code
receiver controls sender,
so sender won’t overflow
receiver’s buffer by from sender
transmitting too much,
receiver protocol stack
too fast
choose x choose x
req_conn(x) req_conn(x)
ESTAB ESTAB
retransmit acc_conn(x) retransmit acc_conn(x)
req_conn( req_conn(
x) x)
ESTAB ESTAB
data(x+1) accept
req_conn(x)
retransmit data(x+1
data(x+1) )
connection connection
client x completes server x completes server
client
terminat forgets x terminat forgets x
es req_conn(x)
es
ESTAB ESTAB
data(x+1) accept
half open connection! data(x+1
(no client!) )
Transport Layer 3-82
TCP 3-way handshake
Socket connectionSocket =
welcomeSocket.accept();
L Socket clientSocket =
SYN(x) newSocket("hostname","port
number");
SYNACK(seq=y,ACKnum=x+1)
create new socket for listen SYN(seq=x)
communication back to client
SYN SYN
rcvd sent
SYNACK(seq=y,ACKnum=x+1)
ESTAB ACK(ACKnum=y+1)
ACK(ACKnum=y+1)
L
LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime
CLOSED
R/2
delay
lout
finite shared
Host B
output link buffers
Transport Layer 3-90
Causes/costs of congestion:
scenario 2
idealization: perfect R/2
knowledge
lout
sender know whether the
router buffers is free
sender sends only when lin R/2
router buffers available
lin : original
copy l'in: original data,
data lout
plus retransmitted
data
A free buffer space!
finite shared
Host B
output link buffers
Transport Layer 3-91
Causes/costs of congestion:
scenario 2
Idealization: known
loss packets can be
lost, dropped at router
due to full buffers
sender only resends if
packet known to be lost
lin : original
copy lout
l'in: original data,
data
plus retransmitted
data
A no buffer space!
Host B
Transport Layer 3-92
Causes/costs of congestion:
scenario 2
Idealization: R/2
lout
are
router due to full retransmissions
but asymptotic
buffers goodput is still R/2
R/2
sender only resends if lin (why?)
Host B
Transport Layer 3-93
Causes/costs of congestion:
scenario 2
Realistic: duplicates R/2
packets can be lost,
dropped at router due to when sending at
R/2, some packets
lout
full buffers are
sender times out retransmissions
including
prematurely, sending two R/2
duplicated that
lin
copies, both of which are are delivered!
delivered lin
copy
timeo lout
ut l'in
Host B
Transport Layer 3-94
Causes/costs of congestion:
scenario 2
Realistic: duplicates R/2
packets can be lost,
dropped at router due to when sending at
R/2, some packets
lout
full buffers are
sender times out retransmissions
including
prematurely, sending two R/2
duplicated that
lin
copies, both of which are are delivered!
delivered
“costs” of congestion:
more work (retrans) for given “goodput”
unneeded retransmissions: link carries multiple
copies of pkt
• decreasing goodput
Host
D Host
C
lin’ C/2
time
Transport Layer 3-99
TCP Congestion Control:
details
sender sequence number space
cwnd
RTT
• initially cwnd = 1 MSS
• double cwnd every RTT two segm
ents
• done by incrementing cwnd
for every ACK received
summary: initial rate is four segm
e nt
slow but ramps up s
exponentially fast
time
Implementation:
variable ssthresh
on loss event, Fast recovery
ssthresh is set to 1/2
of cwnd just before
loss event
* Check out the online interactive exercises for
more examples: Transport Layer 3-103
http://gaia.cs.umass.edu/kurose_ross/interactive/
Summary: TCP Congestion
Control New
New ACK!
duplicate ACK ACK!
dupACKcount++ new ACK
new ACK
.
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS transmit new segment(s), as allowed
dupACKcount = 0
L transmit new segment(s), as allowed
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0
slow L congestion
start timeout avoidance
ssthresh = cwnd/2
cwnd = 1 MSS duplicate ACK
timeout dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 retransmit missing segment
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment New
timeout
ACK!
ssthresh = cwnd/2
cwnd = 1 New ACK
dupACKcount = 0
cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 retransmit missing segment dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmit missing segment retransmit missing segment
fast
recovery
duplicate ACK
cwnd = cwnd + MSS
transmit new segment(s), as allowed
W/2
bottleneck
router
capacity R
TCP connection 2
Connection 1 throughput R
IP datagram
Transport Layer 3-110
ECN
• 00 :发送主机不支持 ECN
• 01 或者 10 :发送主机支持 ECN
• 11 :路由器正在经历拥塞
应用
• 一个支持 ECN 的主机发送数据包时将 ECN 设为 01
或 10 。如果路径上的路由器支持 ECN 并经历拥塞,它
将 ECN 域设置为 11 。
• 如果该数值已被设为 11 ,那么下游路由器不会修改该值
TCP 对 ECN 的支持
• 当一个 IP 包的 ECN 域被路由器设置为 11 时,接收端
而非发送端被通知路径上发生了拥塞。
• ECN 使用 TCP 头部来告知发送端网络正在经历拥塞,
并且告知接收端发送段已收到接收端发来的拥塞通告,已降低
了发送速率。