Transport Layer: Computer Networking: A Top Down Approach

Chapter 3
Transport Layer
A note on the use of these ppt slides: Computer

We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify, Networking: A
and delete slides (including this one) and slide content to suit your needs.
They obviously represent a lot of work on our part. In return for use, we only Top Down
ask the following:
 If you use these slides (e.g., in a class) that you mention their source Approach
(after all, we’d like people to use our book!)
 If you post any slides on a www site, that you note that they are adapted
6th edition
from (or perhaps identical to) our slides, and note our copyright of this Jim Kurose, Keith Ross
material. Addison-Wesley
Thanks and enjoy! JFK/KWR March 2012
All material copyright 1996-2013
J.F Kurose and K.W. Ross, All Rights Reserved
Transport Layer 3-1

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and  segment structure
demultiplexing  reliable data transfer
3.3 connectionless  flow control
transport: UDP  connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control
Transport Layer 3-2

Transport services and protocols
application
transport
 Provide logical network
data link
communication between app physical
processes running on
different hosts
lo
gi
ca
transport protocols run in
l

en
d
end systems
-e
nd
tra
ns
more than one transport
po

rt
protocol available to apps
application
 Internet: TCP and UDP transport
network
data link
physical
Transport Layer 3-3

Transport vs. network layer
 network layer: household analogy:
logical
communication 12 kids in Ann’s house
sending letters to 12 kids in
between hosts Bill’s house:
 transport layer:  hosts = houses
logical  processes = kids
communication  app messages = letters in

envelopes
between processes  transport protocol = Ann
and Bill who demux to in-
house siblings
 network-layer protocol =
postal service
Transport Layer 3-4

Chapter 3 outline
Transport Layer 3-5

Multiplexing/demultiplexing
multiplexing at sender:
handle data from multiple demultiplexing at receiver:
sockets, add transport header use header info to deliver
(later used for demultiplexing) received segments to correct
socket
application
application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical
Transport Layer 3-6

How demultiplexing works
 host receives segments 32 bits
from various processes source port # dest port #
 each segment has source,
destination port number other header fields
 host uses port numbers to
direct segment to
appropriate socket application
data
(payload)
TCP/UDP segment format
Transport Layer 3-7

Internet transport protocols services
TCP service: UDP service:
 reliable transport between  unreliable data transfer
sending and receiving between sending and
process receiving process
 flow control: sender won’t
overflow receiver  does not provide:
 congestion control: throttle reliability,
sender when network flow control,
overloaded congestion control,
connection setup,
 connection-oriented: setup
required between client and
server processes
Application Layer 2-8

Chapter 3 outline
Transport Layer 3-9

UDP: User Datagram Protocol [RFC 768]
 “ best effort” service,  UDP use:
UDP segments may be:  streaming multimedia
apps (loss tolerant, rate
 connectionless: sensitive)
 no handshaking  DNS
between UDP sender,
receiver  Services Provided by
UDP:
1. Multiplexing/Demultipl-
exing
Transport Layer 3-10

UDP: segment header
length, in bytes of
32 bits UDP segment,
source port # dest port # including header size
length checksum why is there a UDP?

 no connection establishment
(which can add delay)
application  simple: no connection state at
data sender, receiver
(payload)  small header size
 no congestion control: UDP
can blast away as fast as
desired
UDP segment format  It is perfect for real time apps

Chapter 3 outline

rdt1.0: reliable transfer over a reliable channel
 underlying channel perfectly reliable
 no bit errors
 no loss of packets

rdt2.0: channel with bit errors
 underlying channel may flip bits in packet
 checksum to detect bit errors
 the question: how to recover from errors:
 acknowledgements (ACKs): receiver explicitly tells
sender that pkt received OK
 negative acknowledgements (NAKs): receiver explicitly
tells sender that pkt had errors
 sender
Howretransmits
do humans pkt on NAK “errors”
receipt offrom
recover
 new mechanisms in rdt2.0 (beyond rdt1.0):
 error detectionduring conversation?
 receiver feedback: control msgs (ACK,NAK) rcvr-
>sender

rdt2.0: channel with bit errors
 underlying channel may flip bits in packet
 checksum to detect bit errors
 the question: how to recover from errors:
 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

rdt2.0 has a fatal flaw!
what happens if handling duplicates:
ACK/NAK corrupted?  sender retransmits current
 sender doesn’t know what pkt if ACK/NAK corrupted
happened at receiver!  sender adds sequence
 can’t just retransmit: number to each pkt
possible duplicate  receiver discards (doesn’t
deliver up) duplicate pkt
stop and wait

sender sends one packet,
then waits for receiver
response
rdt2.1: discussion
sender: receiver:
 seq # added to pkt  must check if received
 two seq. #’s (0,1) will packet is duplicate
suffice. Why?  state indicates whether
 must check if received
0 or 1 is expected pkt
seq #
ACK/NAK is
corrupted

rdt2.2: a NAK-free protocol
 same functionality as rdt2.1, using ACKs only
 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

rdt3.0: channels with errors and loss
new assumption: approach: sender waits

underlying channel “ reasonable” amount of
can also lose packets time for ACK
(data, ACKs)  retransmits if no ACK
 checksum, seq. #, received in this time
ACKs, retransmissions
 if pkt (or ACK) just delayed
(not lost):
will be of help … but
not enough  retransmission will be
duplicate, but seq. #’s
already handles this
 receiver must specify seq
# of pkt being ACKed
 requires countdown timer

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
Go-Back-N: sender
 k-bit seq # in pkt header
 “ window” (buffer size) of up to N, consecutive unack’ed pkts allowed
 ACK(n): ACKs all pkts up to, including seq # n - “cumulative

ACK”
 may receive duplicate ACKs (see receiver)
 timer for oldest in-flight pkt
 timeout(n): retransmit packet n and all higher seq # pkts in
window
 Buffer size (window ) N ≤ 2k - 1

GBN: receiver
ACK-only: always send ACK for correctly-received pkt
with highest in-order seq #
 may generate duplicate ACKs(Just ignore)
 need only remember expectedseqnum
 out-of-order pkt:
 discard (don’t buffer): no receiver buffering!
 re-ACK pkt with highest in-order seq #(Causes duplicate ACK)

GBN in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
send pkt3 Xloss receive pkt1, send ack1
012345678
(wait…window full)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignore duplicate ACK receive pkt5, discard,
(re)send ack1
pkt 2 timeout
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5

Selective repeat(SR)
 A problem of GBN is, it is discarding a correctly
received packet. So, there will be more and more
retransmission.
 In SR, receiver individually acknowledges all
correctly received pkts(even if it is out of order)
 buffers pkts, as needed, for eventual in-order delivery to
upper layer
 sender only resends pkts for which ACK not
received
 sender starts timer for each unACKed pkt
 sender window
 N consecutive seq #’s
 limits seq #s of sent, unACKed pkts

Selective repeat
sender receiver
data from above: pkt n in [rcvbase, rcvbase+N-1]
 if next available seq # in  send ACK(n)
window, send pkt  out-of-order: buffer
timeout(n):  in-order: deliver (also
 resend pkt n, restart timer deliver buffered, in-order
pkts), advance window to
ACK(n) in [sendbase,sendbase+N]: next not-yet-received pkt
 mark pkt n as received
pkt n in [rcvbase-N,rcvbase-1]
 if n smallest unACKed
 ACK(n)
pkt, advance window base
to next unACKed seq # otherwise:
 ignore

Selective repeat in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
send pkt3 Xloss receive pkt1, send ack1
012345678
(wait… window full)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5 receive pkt4, buffer,
send ack4
record ack3 arrived, receive pkt5, buffer,
send nothing
send ack5
pkt 2 timeout
012345678 resend pkt2
012345678 record ack4 arrived
012345678 Send nothing rcv pkt2;send ack2
012345678 record ack5 arrived,
send nothing
Q: what happens when ack2 arrives?

sender window receiver window
Selective repeat: (after receipt) (after receipt)
dilemma 0123012 pkt0

pkt1 0123012
0123012
0123012 pkt2 0123012
example: 0123012
0123012 pkt3
 seq #’s: 0, 1, 2, 3 0123012
X
 window size=3 pkt0 will accept packet
with seq number 0
(a) no problem
 receiver sees no
difference in two receiver can’t see sender side.
scenarios! receiver behavior identical in both cases!
something’s (very) wrong!
 duplicate data
accepted as new in (b) 0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 0123012
Q: what relationship X 0123012
between seq # size X
timeout
and window size to retransmit pkt0 X
avoid problem in (b)? 0123012 pkt0
will accept packet
with seq number 0
(b) oops!
Pipelined protocols: overview
Go-back-N: Selective Repeat:
 sender can have up to N  sender can have up to N
unacked packets in unack’ed packets in
pipeline pipeline
 receiver only sends  rcvr sends individual ack
cumulative ack for each packet
 doesn’t ack packet if
there’s a gap
 sender has timer for  sender maintains timer for
oldest unacked packet each unacked packet
 when timer expires,  when timer expires,
retransmit all unacked retransmit only that
packets unacked packet

Chapter 3 outline

TCP: Overview RFCs: 793,1122,1323, 2018, 2581
 point-to-point:  full duplex data:

 one sender, one receiver  bi-directional data flow in
same connection
 reliable, in-order byte
 MSS: maximum segment
stream: size
 no “ message boundaries
”
 connection-oriented:
 handshaking (exchange of
 pipelined: control msgs) initializes
 TCP congestion and flow sender, receiver state
control set window size before data exchange
 flow controlled:
 sender will not
overwhelm receiver

TCP segment structure
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
Indicates that, the
ACK # is valid acknowledgement number (not segments!)
head not Used for rdt
PSH: push data to len used
UAP R S F receive window
upper layer immidiately # bytes
checksum Urg data pointer
rcvr willing
RST, SYN, FIN: to accept
Options(negotiate the MSS size)
connection estab (Used for flow
(setup and teardown) Control)
commands)
application
Internet data
checksum (variable length)
(as in UDP)

TCP seq. numbers, ACKs
outgoing segment from sender
sequence numbers: source port # dest port #
sequence number
 For each byte in acknowledgement number
segment, there is a seq# checksum

rwnd
urg pointer
 It only sends the seq# of first window size
byte in the segment. N
acknowledgements:
sender sequence number space
 seq # of next byte
expected from other side sent sent, not- usable not
ACKed yet ACKed but not usable
 cumulative ACK (“in-flight”) yet sent
incoming segment to sender

source port # dest port #
sequence number
acknowledgement number
A rwnd
checksum urg pointer

TCP seq. numbers, ACKs
Host A Host B
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
simple telnet scenario

TCP round trip time, timeout
Q: how to set TCP Q: how to estimate RTT?
timeout value?  SampleRTT: measured
time from segment
 longer than RTT transmission until ACK
 but RTT varies receipt
 too short: premature
timeout, unnecessary  SampleRTT will vary,
retransmissions want estimated RTT
“ smoother”
 too long: slow  average several recent
reaction to segment measurements, not just
loss current SampleRTT

Sample RTT vs AVG. RTT

TCP reliable data transfer
 TCP creates rdt service
on top of IP’s unreliable
service
 pipelined segments
 cumulative acks
 single retransmission
timer
 retransmissions
triggered by:
 timeout events
 duplicate acks

TCP sender events:
data rcvd from app: timeout:
(i) create segment with  retransmit segment that
seq # caused timeout
 restart timer
(ii) seq # is byte-stream ack rcvd:
number of first data  if ack acknowledges
byte in segment previously unacked
segments
(iii) start timer if not  update what is known to
already running be ACKed
 think of timer as for  start timer if there are
oldest unacked segment still unacked segments

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
Seq=100, 20 bytes of data

timeout
timeout
ACK=100
X
ACK=100
ACK=120
Seq=92, 8 bytes of data Seq=92, 8

SendBase=100 bytes of data
SendBase=120
ACK=100
ACK=120
SendBase=120
lost ACK scenario premature timeout

TCP: retransmission scenarios
Host A Host B

ACK=100
timeout
X
ACK=120
cumulative ACK
TCP fast retransmit
 time-out period often
relatively long: TCP fast retransmit
 long delay before if sender receives 3
resending lost packet ACKs for same data
 detect lost segments (“ triple duplicate ACKs” ),
via duplicate ACKs. resend unacked
 sender often sends segment with smallest
many segments back- seq #
to-back  likely that unacked
 if segment is lost, there segment lost, so don’t
will likely be many wait for timeout
duplicate ACKs.

TCP fast retransmit
Host A Host B

X
ACK=100
timeout
ACK=100
ACK=100
ACK=100
fast retransmit after sender

receipt of triple duplicate ACK
Chapter 3 outline

TCP flow control
application
application may process
remove data from application
TCP socket buffers ….
TCP socket OS
receiver buffers
… slower than TCP
receiver is delivering
(sender is sending) TCP
code
IP
flow control code
receiver controls sender, so
sender won’t overflow receiver’s
buffer by transmitting too much, from sender
too fast
receiver protocol stack

TCP flow control
 receiver “advertises” free
buffer space by including to application process
rwnd value in TCP header
of receiver-to-sender
segments RcvBuffer buffered data
 sender limits amount of
unacked (“ in-flight” ) data
rwnd free buffer space
to receiver’s rwnd value
 guarantees receive buffer TCP segment payloads
will not overflow
receiver-side buffering

Example of TCP Transmission
 The sender buffer’s SendBase is 280.
 The last TCP sequence number sent was 650 in a segment
with 150 bytes of data.
 A segment is received with TCP acknowledgement
number 450 and window (rwnd)1200.
 The MSS is 1024.
Until another ACK is received:

a. What is the new value of SendBase?
b. What is the next byte (number) that will be sent?
c. What is the last byte (number) that can be sent with
certainty that the receiver's buffer will not overflow?
d. How many bytes still can be sent (after last segment) with
certainty that the receiver's buffer will not overflow?
Chapter 3 outline

TCP 3-way handshake
client state server state

LISTEN LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
received SYNACK(x)
ESTAB indicates server is live;
send ACK for SYNACK;
this segment may contain ACKbit=1, ACKnum=y+1
client-to-server data
received ACK(y)
indicates client is live
ESTAB

TCP: closing a connection
 client, server each close their side of connection
 send TCP segment with FIN bit = 1
 respond to received FIN with ACK
 on receiving FIN, ACK can be combined with own FIN
 simultaneous FIN exchanges can be handled

TCP: closing a connection
client state server state
ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 sendcan no longer
data but can
FINbit=1, seq=x
receive data and CLOSE_WAIT
send ack
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close
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

Chapter 3 outline

Approaches towards congestion control
two broad approaches towards congestion control:

end-end congestion network-assisted
control: congestion control:
 no explicit feedback  routers provide
from network layer
feedback to end systems
 congestion inferred from
end-system observed  single bit indicating
loss, delay(Triple Ack, congestion
Timeout)  explicit rate for sender
 RTT values can also be to send at
considered  Uses choke packets
 Approach taken by TCP

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
sent, not-
ACKed
yet ACKed
sent more bytes
(“in-flight”)
cwnd
 sender limits transmission: rate ~
~ bytes/sec
RTT
LastByteSent-
 cwnd isLastByteAcked < of
dynamic, function cwnd
perceived network congestion

TCP Slow Start
Host A Host B
 when connection begins,
increase rate
exponentially until first one segm
ent
RTT
loss event:
 initially cwnd = 1 MSS two segm
ents
 double cwnd every RTT
 done by incrementing
cwnd for every ACK four segm
ents
received
 summary: initial rate is
slow but ramps up
exponentially fast time

TCP: detecting, reacting to loss
 loss indicated by timeout:
 cwnd set to 1 MSS;
 window then grows exponentially (as in slow start) to threshold = cwnd/2, then grows
linearly
 loss indicated by 3 duplicate ACKs: TCP RENO
 dup ACKs indicate network capable of delivering some segments
 cwnd is cut in half window then grows linearly
 TCP Tahoe always sets cwnd to 1 (timeout or 3 duplicate acks)

TCP: switching from slow start to
CongestionAvoidance(CA)
Q: when should the
exponential increase
switch to linear?
A: when cwnd gets to
1/2 of its value before
timeout.
Implementation:
 variable ssthresh
 on loss event, ssthresh
is set to 1/2 of cwnd just
before loss event

TCP congestion control: additive increase
multiplicative decrease
 approach: sender increases transmission rate (window
size), probing for usable bandwidth, until loss occurs
 additive increase: increase cwnd by 1 MSS every
RTT until loss detected
 multiplicative decrease: cut cwnd in half after loss
additively increase window size …
…. until loss occurs (then cut window in half)
congestion window size
cwnd: TCP sender
AIMD saw tooth

behavior: probing
for bandwidth
time
TCP throughput
 avg. TCP thruput as function of window size, RTT?
 ignore slow start, assume always data to send
 W: window size (measured in bytes) where loss occurs
 avg. window size (# in-flight bytes) is ¾ W
 avg. thruput is 3/4W per RTT
3 W
avg TCP thruput = bytes/sec
4 RTT
W
W/2

TCP Futures: TCP over “ long, fat pipes”
 example: 1500 byte segments, 100ms RTT, want
10 Gbps throughput
 requires W = 83,333 in-flight segments
 throughput in terms of segment loss probability, L
[Mathis 1997]:
1.22 . MSS
TCP throughput =
RTT L
➜ to achieve 10 Gbps throughput, need a loss rate of L =

2·10-10 – a very small loss rate!
 new versions of TCP for high-speed

Transport Layer: Computer Networking: A Top Down Approach

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Transport Layer: Computer Networking: A Top Down Approach

Uploaded by

Copyright:

Available Formats

Chapter 3

A note on the use of these ppt slides: Computer

Transport Layer 3-1

Transport Layer 3-2

Transport Layer 3-3

logical  processes = kids

communication  app messages = letters in

Transport Layer 3-4

Transport Layer 3-5

application P1 P2 application socket

Transport Layer 3-6

TCP/UDP segment format

Transport Layer 3-7

Application Layer 2-8

Transport Layer 3-9

Transport Layer 3-10

length checksum why is there a UDP?

Transport Layer 3-11

Transport Layer 3-12

Transport Layer 3-13

Transport Layer 3-14

Transport Layer 3-15

stop and wait

Transport Layer 3-17

Transport Layer 3-18

new assumption: approach: sender waits

Transport Layer 3-19

 two generic forms of pipelined protocols: go-Back-N,

 “ window” (buffer size) of up to N, consecutive unack’ed pkts allowed

 ACK(n): ACKs all pkts up to, including seq # n - “cumulative

Transport Layer 3-21

Transport Layer 3-22

Transport Layer 3-23

Transport Layer 3-24

Transport Layer 3-25

Transport Layer 3-26

dilemma 0123012 pkt0

Transport Layer 3-29

Transport Layer 3-30

 point-to-point:  full duplex data:

Transport Layer 3-31

Transport Layer 3-32

segment, there is a seq# checksum

incoming segment to sender

Transport Layer 3-33

simple telnet scenario

Transport Layer 3-34

Transport Layer 3-35

Transport Layer 3-36

Transport Layer 3-37

Transport Layer 3-38

Seq=100, 20 bytes of data

Seq=92, 8 bytes of data Seq=92, 8

lost ACK scenario premature timeout

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

Seq=120, 15 bytes of data

Transport Layer 3-41

Seq=92, 8 bytes of data

fast retransmit after sender

Transport Layer 3-43

Transport Layer 3-44

Transport Layer 3-45