Professional Documents
Culture Documents
Transport Layer
lo
different hosts
gi
ca
le
❖ transport protocols run in
nd
end systems
-e
nd
▪ send side: breaks app
tra
ns
messages into segments,
po
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 12 kids analogy:
in Ann’s house sending
communication 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
delivery (TCP)
data link
physical
network
lo
data link physical
gi
▪ flow control
physical
ca
network
le
data link
nd
▪ connection setup
physical
-e
n
d
network
unreliable, unordered
tra
❖
data link
ns
physical
delivery: UDP
po
network
rt
data link
▪ no-frills extension of
physical
network
data link application
“best-effort” IP physical
network
data link
transport
network
▪ delay guarantees
▪ bandwidth guarantees
▪ destination port #
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
Transport Layer 3-17
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in
transmitted segment
sender: receiver:
❖ treat segment contents, ❖ compute checksum of
including header fields, received segment
as sequence of 16-bit ❖ check if computed
integers checksum equals checksum
❖ checksum: addition field value:
(one’s complement
sum) of segment ▪ NO - error detected
contents ▪ YES - no error detected.
❖ sender puts checksum But maybe errors
value into UDP nonetheless? More later
checksum field ….
Transport Layer 3-18
Internet checksum: example
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
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 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
‘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]
event at receiver TCP receiver action
arrival of in-order segment with delayed ACK. Wait up to 500ms
expected seq #. All data up to for next segment. If no next segment,
expected seq # already ACKed send ACK
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 from sender
too much, 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
req_conn(x)
❖ can’t “see” other side
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 req_conn(x) forgets x
ESTAB ESTAB
data(x+1)
half open connection! accept
data(x+1)
(no client!)
Transport Layer 3-79
TCP 3-way handshake
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
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
λout
due to full buffers retransmissions but
asymptotic goodput
❖ sender only resends if is still R/2 (why?)
Host B
Transport Layer 3-90
Causes/costs of congestion: scenario 2
Realistic: duplicates R/2
❖ packets can be lost, dropped
at router due to full buffers when sending at R/2,
some packets are
λout
❖ sender times out retransmissions
including duplicated
prematurely, sending two that are delivered!
copies, both of which are λin R/2
delivered
λ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
at router due to full buffers when sending at R/2,
some packets are
λout
❖ sender times out retransmissions
including duplicated
prematurely, sending two that are delivered!
copies, both of which are λin R/2
delivered
“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-99
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
ACKed sent,
not-yet
sent
more 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-108
Fairness (more)
Fairness and UDP Fairness, parallel TCP
❖ multimedia apps connections
often do not use TCP ❖ application can open
▪ do not want rate multiple parallel
throttled by connections between two
congestion control
hosts
❖ instead use UDP:
❖ web browsers do this
▪ send audio/video at
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