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: Transport Layer
our goals:
 understand principles  learn about Internet
behind transport transport layer protocols:
layer services:  UDP: connectionless
 multiplexing, transport
demultiplexing  TCP: connection-oriented
 reliable data transfer reliable transport
 flow control  TCP congestion control
 congestion control

Transport Layer 3-2

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-3

Transport services and protocols
application
transport
 provide logical communication network
data link
between app processes running on physical

different hosts

lo
 transport protocols run in end

gi
ca
systems

enl
d -e
 send side: breaks app messages

nd
tra
into segments, passes to

ns
network layer

po
rt
 rcv side: reassembles segments application
into messages, passes to app transport
network
layer data link
physical
 more than one transport protocol
available to apps
 Internet: TCP and UDP
Transport Layer 3-4
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
 relies on, enhances, and Bill who demux to in-
network layer house siblings
services  network-layer protocol =
postal service

Transport Layer 3-5

Internet transport-layer protocols
application
 reliable, in-order transport
network

delivery (TCP) data link

physical
network
 congestion control network data link

lo
data link physical

gi
physical
 flow control

ca
network

le
data link

nd
 connection setup physical

-en
network

d
unreliable, unordered

tra
 data link
physical

ns
delivery: UDP

po
network

rt
data link
physical
 no-frills extension of network
data link application

“ best-effort” IP physical
network
data link
transport
network
data link
services not available:
physical
 physical

 delay guarantees
 bandwidth guarantees

Transport Layer 3-6

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-7

Multiplexing/demultiplexing
multiplexing at sender: demultiplexing at receiver:
handle data from multiple
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-8

How demultiplexing works
 host receives IP datagrams 32 bits
 each datagram has source IP address,
destination IP address source port # dest port #
 each datagram carries one transport-layer
segment
 each segment has source, destination other header fields
port number
 host uses IP addresses & port
numbers to direct segment to application
appropriate socket
data
(payload)

TCP/UDP segment format

Transport Layer 3-9

Connectionless demultiplexing
 recall: created socket has  recall: when creating datagram to
send into UDP socket, must specify
host-local port #:  destination IP address
DatagramSocket mySocket1  destination port #
= new
DatagramSocket(12534);

 when host receives UDP IP datagrams with same

segment: dest. port #, but different
 checks destination port # source IP addresses and/or
in segment source port numbers will
be directed to same socket
 directs UDP segment to at dest
socket with that port #

Transport Layer 3-10

Connectionless demux: example
DatagramSocket serverSocket
= new DatagramSocket
DatagramSocket mySocket2 (6428); DatagramSocket
= new DatagramSocket mySocket1 = new
(9157); DatagramSocket (5775);

application
application P1 application
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

source port: 6428 source port: ?

dest port: 9157 dest port: ?

source port: 9157 source port: ?

dest port: 6428 dest port: ?
Transport Layer 3-11
Connection-oriented demux
 TCP socket identified  server host may support
by 4-tuple: many simultaneous TCP
 source IP address sockets:
 source port number  each socket identified by
 dest IP address its own 4-tuple
 dest port number  web servers have
 demux: receiver uses different sockets for
all four values to direct each connecting client
segment to appropriate  non-persistent HTTP will
have different socket for
socket each request

Transport Layer 3-12

 Connection-oriented demux: example

application
application P4 P5 P6 application
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets Transport Layer 3-13
 Connection-oriented demux: example
threaded server
application
application application
P4
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80

Transport Layer 3-14

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-15

UDP: User Datagram Protocol [RFC 768]
 “ no frills,” “ bare bones”  UDP use:
Internet transport protocol  streaming multimedia
 “ best effort” service, UDP apps (loss tolerant, rate
segments may be: sensitive)
 lost  DNS
 delivered out-of-order to  SNMP
app  reliable transfer over
 connectionless:
UDP:
 no handshaking between
UDP sender, receiver  add reliability at
application layer
 each UDP segment
handled independently  application-specific error
of others recovery!

Transport Layer 3-16

UDP: segment header
length, in bytes of
32 bits UDP segment,
source port # dest port # including header

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
 no congestion control:
UDP segment format
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 checksum
integers equals checksum field value:
 checksum: addition (one’s  NO - error detected
complement sum) of
segment contents  YES - no error detected.
 sender puts checksum But maybe errors
value into UDP checksum nonetheless? More later ….
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

Note: when adding numbers, a carryout from the most

significant bit needs to be added to the result

Transport Layer 3-19

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-20

Principles of reliable data transfer
 important in application, transport, link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

Transport Layer 3-21

Principles of reliable data transfer
 important in application, transport, link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

Transport Layer 3-22

Principles of reliable data transfer
 important in application, transport, link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

Transport Layer 3-23

Reliable data transfer: getting started

rdt_send(): called from above, deliver_data(): called by

(e.g., by app.). Passed data to rdt to deliver data to upper
deliver to receiver upper layer

send receive
side side

udt_send(): called by rdt, rdt_rcv(): called when packet

to transfer packet over arrives on rcv-side of channel
unreliable channel to receiver

Transport Layer 3-24

 Reliable data transfer: getting started
we’ll:
 incrementally develop sender, receiver sides of
reliable data transfer protocol (rdt)
 consider only unidirectional data transfer
 but control info will flow on both directions!
 use finite state machines (FSM) to specify sender,
receiver
event causing state transition
actions taken on state transition
state: when in this “state
” next state uniquely state state
determined by next 1 event
event 2
actions

Transport Layer 3-25

rdt1.0: reliable transfer over a reliable channel
 underlying channel perfectly reliable
 no bit errors
 no loss of packets
 separate FSMs for sender, receiver:
 sender sends data into underlying channel
 receiver reads data from underlying channel

Wait for rdt_send(data) Wait for rdt_rcv(packet)

call from call from extract (packet,data)
above packet = make_pkt(data) below deliver_data(data)

udt_send(packet)

sender receiver

Transport Layer 3-26

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

Transport Layer 3-27

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
 new mechanisms in rdt2.0 (beyond rdt1.0):
 error detection
 feedback: control msgs (ACK,NAK) from receiver to
sender

Transport Layer 3-28

rdt2.0: FSM specification
rdt_send(data)
receiver
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)

rdt_rcv(rcvpkt) &&
Wait for
isNAK(rcvpkt)
Wait for call rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
from above ACK or NAK
udt_send(sndpkt)
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for call
 from below

sender
rdt_rcv(rcvpkt) &&
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) &&
Wait for
isNAK(rcvpkt)
Wait for call rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
from above ACK or NAK
udt_send(sndpkt)
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for call
 from below

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) &&
Wait for
isNAK(rcvpkt)
Wait for call rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
from above ACK or NAK
udt_send(sndpkt)
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for call
 from below

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 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

Transport Layer 3-32

rdt2.1: sender, handles garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
Wait for call 0 Wait for ACK
from above or NAK 0
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)



Wait for ACK Wait for
or NAK 1 call 1 from
rdt_rcv(rcvpkt) && above
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt) udt_send(sndpkt)

Transport Layer 3-33

 rdt2.1: receiver, handles garbled ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) &&

(corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)

Wait for Wait for

0 from 1 from
rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) &&
below below
not corrupt(rcvpkt) && not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)

sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)

udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

Transport Layer 3-34

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 corrupted  note: receiver can not
 twice as many states
know if its last
 state must “ remember” ACK/NAK received
whether “ expected” OK at sender
pkt should have seq #
of 0 or 1

Transport Layer 3-35

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

Transport Layer 3-36

 rdt2.2: sender, receiver fragments
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
Wait for call Wait for ACK
0 from above 0
udt_send(sndpkt)
sender FSM
fragment rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)

rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt)) 
Wait for
0 from receiver FSM
sndpkt = make_pkt(ACK1,
below
fragment
chksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK0, chksum)
udt_send(sndpkt)

Transport Layer 3-37

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

Transport Layer 3-38

 rdt3.0 in action
sender receiver sender receiver
send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack0 send ack0 ack0 send ack0
rcv ack0 rcv ack0
send pkt1 pkt1 send pkt1 pkt1
rcv pkt1 X
ack1 send ack1 loss
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) no loss rcv pkt0
ack0 send ack0

(b) packet loss

Transport Layer 3-39
 rdt3.0 in action
sender receiver
sender receiver send pkt0 pkt0
send pkt0 pkt0 rcv pkt0
ack0 send ack0
rcv pkt0
send ack0 rcv ack0
ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
send pkt1 pkt1
rcv pkt1 send ack1
ack1 ack1
send ack1
X
loss timeout
resend pkt1 pkt1
rcv pkt1
timeout
resend pkt1 pkt1 rcv ack1 pkt0 (detect duplicate)
rcv pkt1 send pkt0 send ack1
(detect duplicate) ack1
ack1 send ack1 rcv ack1 rcv pkt0
rcv ack1 ack0 send ack0
pkt0 send pkt0 pkt0
send pkt0 rcv pkt0
rcv pkt0 ack0 (detect duplicate)
ack0 send ack0 send ack0

(c) ACK loss (d) premature timeout/ delayed ACK

Transport Layer 3-40

Performance of rdt3.0
 rdt3.0 is correct, but performance stinks
 e.g.: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:
L 8000 bits
Dtrans = R = = 8 microsecs
109 bits/sec

 U sender: utilization – fraction of time sender busy sending

U L/R .008
sender = = = 0.00027
RTT + L / R 30.008

 if RTT=30 msec, 1KB pkt every 30 msec: 33kB/sec thruput over 1 Gbps link
 network protocol limits use of physical resources!

Transport Layer 3-41

 rdt3.0: stop-and-wait operation
sender receiver
first packet bit transmitted, t = 0
last packet bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send ACK

ACK arrives, send next

packet, t = RTT + L / R

U L/R .008
sender = = = 0.00027
RTT + L / R 30.008

Transport Layer 3-42

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
Transport Layer 3-43
 Pipelining: increased utilization
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
3-packet pipelining increases
utilization by a factor of 3!

U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008

Transport Layer 3-44

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

Transport Layer 3-45

Go-Back-N: sender
 k-bit seq # in pkt header
 “ window” 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

Transport Layer 3-46

GBN: receiver extended FSM

ACK-only: always send ACK for correctly-received

pkt with highest in-order seq #
 may generate duplicate ACKs
 need only remember expectedseqnum
 out-of-order pkt:
 discard (don’t buffer): no receiver buffering!
 re-ACK pkt with highest in-order seq #

Transport Layer 3-47

 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)
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

Transport Layer 3-48

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
 limits seq #s of sent, unACKed pkts

Transport Layer 3-49

Selective repeat: sender, receiver windows

Transport Layer 3-50

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
 if n smallest unACKed
otherwise:
pkt, advance window base
 ignore
to next unACKed seq #

Transport Layer 3-51

 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)
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 ack5
pkt 2 timeout
012345678 send pkt2
012345678 record ack4 arrived
012345678 rcv pkt2; deliver pkt2,
record ack5 arrived
012345678 pkt3, pkt4, pkt5; send ack2

Q: what happens when ack2 arrives?

Transport Layer 3-52

 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
 receiver sees no difference in two (a) no problem
scenarios!
 duplicate data accepted as new in (b) receiver can’t see sender side.
receiver behavior identical in both cases!
Q: what relationship between seq # size something’s (very) wrong!
and window size to avoid problem in
(b)? pkt0
0123012
0123012 pkt1 0123012
0123012 pkt2 0123012
X 0123012

timeout
X
retransmit pkt0 X
0123012 pkt0
will accept packet
with seq number 0
(b) oops!
Transport Layer 3-53