Chapter 3: Transport Layer

our goals:
v understand v learn about Internet
principles behind transport layer protocols:
transport layer § UDP: connectionless
services: transport
§ multiplexing, § TCP: connection-oriented
demultiplexing reliable transport
§ reliable data transfer § TCP congestion control
§ flow control
§ congestion control

32
Transport Layer 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

33
Transport layer
v Moving “down” a layer

v Current perspective:
§ Application is the boss….
§ Usually executing within the OS Kernel
§ The network layer is ours to command !!

34
Network layer (context)
v What it does: finds paths through network
§ Routing from one end host to another

v What it doesn’t:
§ Reliable transfer: “best effort delivery”
§ Guarantee paths
§ Arbitrate transfer rates

v For now, think of the network layer as

giving us an “API” with one function:
sendtohost(data, host)
§ Promise: the data will go to that (usually!!)

35
Transport services and protocols
application
transport
v provide logical communication network
data link
between app processes physical

running on different hosts

v transport protocols run in
end systems
§ send side: breaks app
messages into segments,
passes to network layer
§ rcv side: reassembles application
segments into messages, transport
network
passes to app layer data link
physical

§ Exports services to
application that network
layer does not provide

36
 READ THIS IN TEXT

Transport vs. network layer

v network layer: logical household analogy:
communication
between hosts 12 kids in Ann’s house sending
letters to 12 kids in Bill’s
v transport layer: house:
logical v hosts = houses

communication v processes = kids

between processes v app messages = letters in

envelopes
§ relies on, enhances, v transport protocol = Ann
network layer and Bill who demux to in-
services house siblings
v network-layer protocol =
postal service

37
Why a transport layer?
many application
processes
browser
browser

mmedia
telnet

ftp

Application
Operating Transport
System
Network
IP Datalink
Physical
Drivers Datalink
+NIC Physical

Host A Host B
38
Why a transport layer?
many application
processes

Communication
between processes
browser
browser

mmedia

server
HTTP
telnet

telnet
ftp

ftp
at hosts

Transport Transport

IP IP

Datalink Datalink
Physical Communication Physical
between hosts
(128.4.5.6 ßà162.99.7.56)
Host A Host B
39
 Quiz: Transport Layer Services

How many of these services might we provide at the transport layer ? Which ?

v Reliable transfers v Latency guarantees

v Error detection v Encryption
v Error correction v Message ordering
v Bandwidth guarantees v Link sharing fairness

A: 4 or fewer
B: 5
C: 6
D: 7
E: All 8
40
Transport Layer 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

41
 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

Note: The network is a shared resource. It does not care about your applications, sockets, etc.

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

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

v when host receives UDP IP datagrams with same

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

44
Connectionless demux: example
DatagramSocket
DatagramSocket serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); application (5775);
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: ?
45
Connection-oriented demux
v TCP socket identified v 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 v web servers have
v demux: receiver uses different sockets for
all four values to direct each connecting client
segment to appropriate § non-persistent HTTP will
socket have different socket for
each request

46
Revisiting TCP Sockets

Client Process Server Process

Welcoming, port X
TCP handshake Socket

Client Connection, port X

Socket Socket 1
pipe
Connection, port X
Socket 2

Client
Socket
Client Process 47
 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 48
 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

49
May I scan your ports?
http://netsecurity.about.com/cs/hackertools/a/aa121303.htm
v Servers wait at open ports for client requests
v Hackers often perform port scans to determine open,
closed and unreachable ports on candidate victims
v Several ports are well-known
§ <1024 are reserved for well-known apps
§ Other apps also use known ports
• MS SQL server uses port 1434 (udp)
• Sun Network File System (NFS) 2049 (tcp/udp)
v Hackers can use exploit known flaws with these known
apps
§ Example: Slammer worm exploited buffer overflow flaw in the
SQL server
http://www.auditmypc.com/
v How do you scan ports?
§ Nmap, Superscan, etc https://www.grc.com/shieldsup
50
 Quiz: TCP Sockets

v Suppose 100 clients are simultaneously

communicating with (a traditional HTTP/TCP)
web server. How many sockets are respectively
open at the server and at each client?
A. 1,1
B. 2,1
C. 200,2
D. 100,1
E. 101, 1

51
 Quiz: TCP Sockets

v Suppose 100 clients are simultaneously

communicating with (a traditional HTTP/TCP)
web server. Do all of the sockets at the server
have the same server-side port number?

A. Yes
B. No

52
Transport Layer 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

53
UDP: User Datagram Protocol [RFC 768]
v “no frills,” “bare bones” Internet transport protocol
v “best effort” service, UDP segments may be:
§ lost
§ delivered out-of-order to app

v connectionless:
§ no handshaking between UDP sender, receiver
§ each UDP segment handled independently of
others

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

length checksum
why is there a UDP?
v no connection
application establishment (which can
data add delay)
(payload)
v simple: no connection
state at sender, receiver
v small header size
UDP segment format v no congestion control:
UDP can blast away as
fast as desired
55
UDP checksum
• Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
• Router memory errors
• Driver bugs
• Electromagnetic interference
sender: receiver:
v treat segment contents, v Add all the received
including header fields, as together as 16-bit integers
sequence of 16-bit integers v Add that to the checksum
v checksum: addition (one’s v If the result is not 1111
complement sum) of 1111 1111 1111, there are
segment contents
errors !
v sender puts checksum value
into UDP checksum field
56
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

57
 Quiz: Checksum

v If the checksum addition at the receiver

yields all ones, can the receiver guarantee
that the received packet is error-free?

v A: Yes

v B: No

v C: Schrodinger’s Cat
58
 Quiz: Checksum

v Let’s denote a UDP packet as (checksum, data) ignoring

other fields for this question. Suppose a sender sends
(0010, 1110) and the receiver receives (0011,1110).
Which of the following is true of the receiver?

A. Thinks the packet is corrupted and discards the

packet.
B. Thinks only the checksum is corrupted and delivers
the correct data to the application.
C. Concludes that nothing is wrong with the packet.
D. Receiver explodes.

59
UDP Applications
v Latency sensitive/time critical
v Quick request/response (DNS, DHCP)
v Network management (SNMP)
v Routing updates (RIP)
v Voice/video chat
v Gaming (especially FPS)

v Error correction unnecessary (periodic messages)

60
 Quiz: Reliability over UDP?

v What if you want something more reliable than UDP, but

faster/not as full featured as TCP?

A. Sorry, you’re out of luck.

B. Write your own transport protocol.

C. Add in the features you want at the application layer.

61
Transport Layer 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

62
Reliable Transport

l In a perfect world, reliable transport is easy

@Sender @Receiver
§ send packets § wait for packets

63
Reliable Transport

l In a perfect world, reliable transport is easy

l All the bad things best-effort can do
l a packet is corrupted (bit errors)
l a packet is lost
l a packet is delayed (why?)
l packets are reordered (why?)
l a packet is duplicated (why?)

64
 TheThe
Two Generals
Two Problem
Generals Problem

Twoarmy
• vTwo armydivisions
divisions (blue)
(blue) surround
surround enemy
enemy(red)
(red)
Eachdivision
– §Each division led
led by
by aageneral
general
§ Both must agree when to simultaneously attack
– Both must agree when to simultaneously attack
§ If either side attacks alone, defeat
– If either side attacks alone, defeat
v Generals can only communicate via messengers
• Generals can may
§ Messengers onlyget
communicate via messengers
captured (unreliable channel)
– Messengers may get captured (unreliable channel)
65
TheThe
TwoTwo
Generals Problem
Generals Problem

•v How to coordinate?
How to coordinate?
–§ Send messenger:
Send messenger: “Attack
“Attack at dawn”
at dawn”
What ififmessenger
–§ What messenger doesn’t makemake
doesn’t it? it?

66
 TheThe
Two Generals
Two Problem
Generals Problem

• vHow to be sure messenger made it?

How to be sure messenger made it?
– §Send
Send acknowledgment: “I delivered
acknowledgement: “We message”
received message”

67
 Quiz: Reliability

v In the “two generals problem”, can the two

armies reliably coordinate their attack?

§ A: Yes (explain how)

§ B: No (explain why not)

68
 Engineering
v Concerns v Our toolbox
§ Message corruption § Checksums
§ Message duplication § Timeouts
§ Message loss § Acks and Nacks
§ Message reordering § Sequence numbering
§ Performance § Pipelining

We will use these to build Automatic Repeat Request (ARQ) protocols

• Stop-and-wait
• Pipelining
• Go-back-N
• Selective Repeat
69
 Self Study

Principles of reliable data transfer

v important in application, transport, link layers
§ top-10 list of important networking topics!

v characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)
70
 Self Study

Principles of reliable data transfer

v important in application, transport, link layers
§ top-10 list of important networking topics!

v characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)
71
 Self Study

Principles of reliable data transfer

v important in application, transport, link layers
§ top-10 list of important networking topics!

v characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)
72
 Self Study

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

73
Reliable data transfer: getting started
we’ll:
v incrementally develop sender, receiver sides of
reliable data transfer protocol (rdt)
v consider only unidirectional data transfer
§ but control info will flow on both directions!
v 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 state state
uniquely determined 1 event
by next event 2
actions

74
 Self Study

rdt1.0: reliable transfer over a reliable channel

v underlying channel perfectly reliable
§ no bit errors
§ no loss of packets
v 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

READ UP ON STATE MACHINES IN THE TEXTBOOK 75

rdt2.0: channel with bit errors
v underlying channel may flip bits in packet
§ checksum to detect bit errors
v 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 receipt from
recover of NAK“errors”
v new mechanisms in rdt2.0 (beyond rdt1.0):
§ error detection
during conversation?
§ receiver feedback: control msgs (ACK,NAK) rcvr-
>sender

76
rdt2.0: channel with bit errors
v underlying channel may flip bits in packet
§ checksum to detect bit errors
v 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
v new mechanisms in rdt2.0 (beyond rdt1.0):
§ error detection
§ feedback: control msgs (ACK,NAK) from receiver to
sender

77
 Self Study

rdt2.0: FSM specification

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

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
Λ
call from
sender below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

78
 Self Study
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(sndpkt) corrupt(rcvpkt)
above NAK
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)

79
 Self Study
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(sndpkt) corrupt(rcvpkt)
above NAK
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)

80
Global Picture of rdt2.0
sender receiver
data

Dotted line: erroneous transmission

Solid line: error-free transmission
NACK

data

ACK

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

82
 Self Study

rdt2.1: sender, handles garbled ACK/NAKs

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

udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)

83
 Self Study

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) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below 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)

84
rdt2.1: discussion
sender: receiver:
v seq # added to pkt v must check if received
v two seq. #’s (0,1) will packet is duplicate
suffice. Why? § state indicates whether
0 or 1 is expected pkt
v must check if received
seq #
ACK/NAK corrupted
v note: receiver can not
v twice as many states know if its last ACK/
§ state must NAK received OK at
“remember” whether sender
“expected” pkt should
have seq # of 0 or 1

85
Another Look at rdt2.1 Dotted line: erroneous transmission
Solid line: error-free transmission

sender receiver

data (0)
waiting for 0
NACK

sending # data (0
)
0

ACK

data (0
) waiting for 1

Duplicate Packet
ACK Discard !!

sending data (1
)
#1

waiting for 0
86
rdt2.2: a NAK-free protocol
v same functionality as rdt2.1, using ACKs only
v instead of NAK, receiver sends ACK for last pkt
received OK
§ receiver must explicitly include seq # of pkt being ACKed
v duplicate ACK at sender results in same action as
NAK: retransmit current pkt

87
rdt2.2: Example Dotted line: erroneous transmission
Solid line: error-free transmission

sender receiver

sending # data (0)

0 waiting for 0
)
ACK (0

data (1
)

sending waiting for 1

AK)
lies a N
#1 ACK (0
) (imp

Duplicate ACK data (1

Resend old )
packet
)
ACK (1

data (0
)
sending #
0
waiting for 0
88
 Self Study
rdt2.2: sender, receiver fragments
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK isACK(rcvpkt,1) )
call 0 from
above 0 udt_send(sndpkt)
sender FSM
fragment rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || Λ
has_seq1(rcvpkt)) Wait for receiver FSM
0 from
udt_send(sndpkt) below fragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) 89
 Quiz: RDT 2.2 with only NACKs
v RDT 2.2 uses only ACKs and is robust against packet
errors. Would it be possible to implement RDT 2.2 with
only NACKs?

A. YES

B. NO

Please explain your rationale

90
 Quiz: Reliable Data Transfer
v If packets (and ACKs and NACKs) could be lost, which of
the following is true of rdt 2.1 (or 2.2)?

A. Reliable, in-order delivery is still achieved.

B. The protocol will get get stuck.

C. The protocol will continue making progress but may

skip delivering some messages.

91
rdt3.0: channels with errors and loss

new assumption: approach: sender waits

underlying channel can “reasonable” amount of
also lose packets time for ACK
(data, ACKs) v retransmits if no ACK
§ checksum, seq. #, received in this time
ACKs, retransmissions v 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
v requires countdown timer

92
 Self Study

rdt3.0 sender
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer Λ
Λ Wait for Wait
for timeout
call 0from
ACK0 udt_send(sndpkt)
above
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Wait Wait for
timeout for call 1 from
udt_send(sndpkt) ACK1 above
start_timer rdt_rcv(rcvpkt)
rdt_send(data) Λ
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
Λ

93
 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

94
 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 (do nothing)
send pkt0
rcv pkt0
ack0 send ack0

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

95
 Quiz: RDT 3.0 Performance
v Suppose we have a modest 8 Mbps link. Our RTT is
100ms, and we send 1024 byte (1K) segments. What is
our link utilization with a stop-and-wait protocol such as
RDT 3.0?

A. < 0.1 %

B. Approx. 0.1%

C. Approx 1%

D. 1-10%

E. > 10%
96
 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

L/R 1ms
U sender = = (100+1)ms= 0.01 (i.e. 1%)
RTT + L / R

Bottom Line: network protocol limits use of physical resources!

97
Transport Part 1: Summary
v Next Week:
v principles behind
§ Pipelined Protocols for
transport layer services: reliable data transfer
§ multiplexing, § TCP
demultiplexing • TCP Flow Control
§ reliable data transfer • TCF Connection
Management
• TCP Congestion
v UDP Control

Transport Layer 98