Professional Documents
Culture Documents
Chapter 3 V7.01
Chapter 3 V7.01
Transport Layer
▪ provide logical
transport
network
data link
communication between app physical
processes running on
lo
different hosts
g
ica
▪ transport protocols run in
le
nd
-e
end systems
nd
tra
• send side: breaks app
ns
po
messages into segments,
rt
passes to network layer
application
• rcv side: reassembles transport
network
segments into messages, data link
physical
passes to app layer
▪ more than one transport
protocol available to apps
• Internet: TCP and UDP
Transport Layer 3-4
Transport vs. network layer
▪ network layer: household
logical
communication 12 kidsanalogy:
in Ann’s house sending
letters to 12 kids in Bill’s
between hosts house:
▪ transport layer: ▪ hosts = houses
logical ▪ processes = kids
communication ▪ app messages = letters in
envelopes
between processes ▪ transport protocol = Ann
• relies on, enhances, and Bill who demux to
network layer in-house siblings
services ▪ network-layer protocol =
postal service
lo
data link physical
gica
physical
• flow control network
le
data link
nd
• connection setup physical
-e
nd
▪ unreliable, unordered
network
tra
data link
ns
physical
delivery: UDP
po
network
rt
data link
physical
• no-frills extension of network
data link application
“best-effort” IP physical
network transport
network
• delay guarantees
• bandwidth guarantees
application
application P4 P5 P6 application
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical physical
server: IP
address B
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
UDP segment format ▪ no congestion control:
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
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
dilemma 0123012
0123012
pkt0
pkt1 0123012
0123012 pkt2 0123012
example: 0123012
▪ seq #’s: 0, 1, 2, 3
0123012 pkt3
X
0123012
▪ window size=3 pkt0 will accept packet
with seq number 0
▪ receiver sees no (a) no problem
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
‘C’ Seq=43, ACK=80
sampleRTT
EstimatedRTT
SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data
timeo
ACK=100
ut
ut
X
ACK=100
ACK=120
SendBase=120
X
ut
ACK=120
cumulative ACK
Transport Layer 3-69
TCP ACK generation [RFC 1122, RFC 2581]
ACK=100
timeo
ACK=100
ut
ACK=100
ACK=100
Seq=100, 20 bytes of data
IP
flow code
receiver controls sender, so
control
sender won’t overflow receiver’s
buffer by transmitting too much, from sender
too fast
receiver protocol stack
application application
network network
2-way handshake:
Q: will 2-way handshake
always work in
Let’s talk
network?
ESTAB ▪ variable delays
OK
ESTAB ▪ retransmitted messages (e.g.
req_conn(x)) due to
message loss
▪ message reordering
choose x ▪ can’t “see” other side
req_conn(x)
ESTAB
acc_conn(x)
ESTAB
choose x choose x
req_conn(x) req_conn(x)
ESTAB ESTAB
retransmit acc_conn(x) retransmit acc_conn(x)
req_conn(x) req_conn(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
terminates forgets x terminates forgets x
req_conn(x)
ESTAB ESTAB
data(x+1) accept
half open connection!
data(x+1)
(no client!)
Transport Layer 3-79
TCP 3-way handshake
closed
Socket connectionSocket =
welcomeSocket.accept();
Λ
Socket clientSocket =
SYN(x) newSocket("hostname","port
number");
SYNACK(seq=y,ACKnum=x+1)
create new socket for SYN(seq=x)
communication back to client listen
SYN SYN
rcvd sent
SYNACK(seq=y,ACKnum=x+1)
ESTAB ACK(ACKnum=y+1)
ACK(ACKnum=y+1)
Λ
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
▪ no retransmission
Host B
R/2
delay
λout
Host A
λout
▪ sender sends only when
router buffers available
λin R/2
A no buffer space!
Host B
Transport Layer 3-89
Causes/costs of congestion: scenario 2
Idealization: known R/2
loss packets can be lost, when sending at R/2,
dropped at router due some packets are
λout
to full buffers retransmissions but
asymptotic goodput
▪ sender only resends if is still R/2 (why?)
packet known to be lost λin R/2
Host B
Transport Layer 3-90
Causes/costs of congestion: scenario 2
Realistic: duplicates R/2
▪ packets can be lost, dropped
when sending at R/2,
at router due to full buffers some packets are
▪ sender times out prematurely,
λout
retransmissions
including duplicated
sending two copies, both of that are delivered!
which are delivered R/2
λin
λin
copy
timeout
λ'in λout
Host B
Transport Layer 3-91
Causes/costs of congestion: scenario 2
Realistic: duplicates R/2
▪ packets can be lost, dropped
when sending at R/2,
at router due to full buffers some packets are
▪ sender times out prematurely,
λout
retransmissions
including duplicated
sending two copies, both of that are delivered!
which are delivered R/2
λin
“costs” of congestion:
▪ more work (retrans) for given “goodput”
▪ unneeded retransmissions: link carries multiple copies of pkt
• decreasing goodput
Host D
Host C
C/2
λout
λin’ C/2
time
Transport Layer 3-96
TCP Congestion Control: details
sender sequence number space
cwnd TCP sending rate:
▪ roughly: send cwnd
bytes, wait RTT for
last byte last byte
ACKS, then send more
ACKed sent,
not-yet
sent bytes
ACKed
(“in-flight”) cwnd
▪ sender limits transmission: rate ~
~
RTT
bytes/sec
RTT
loss event:
• initially cwnd = 1 MSS two segme
nts
• double cwnd every RTT
• done by incrementing
cwnd for every ACK four segme
nts
received
▪ summary: initial rate is
slow but ramps up
exponentially fast time
Implementation:
▪ variable ssthresh
▪ on loss event, ssthresh
is set to 1/2 of cwnd just
before loss event
W/2
TCP connection 1
bottleneck
router
capacity R
TCP connection 2
Connection 1 throughput R
Transport Layer 3-105
Fairness (more)
Fairness and UDP Fairness, parallel TCP
▪ multimedia apps often connections
do not use TCP ▪ application can open
• do not want rate multiple parallel
throttled by congestion connections between
control
two hosts
▪ instead use UDP:
• send audio/video at ▪ web browsers do this
constant rate, tolerate ▪ e.g., link of rate R with 9
packet loss existing connections:
• new app asks for 1 TCP, gets
rate R/10
• new app asks for 11 TCPs, gets
R/2
ECN=00 ECN=11
IP datagram
Transport Layer 3-107
Chapter 3: summary
▪ principles behind transport
layer services: next:
• multiplexing, ▪ leaving the network
demultiplexing “edge” (application,
• reliable data transfer transport layers)
• flow control ▪ into the network
• congestion control “core”
▪ instantiation, ▪ two network layer
implementation in the chapters:
Internet • data plane
• UDP • control plane
• TCP
Transport Layer 3-108