Computer Networks and Applications

COMP 3331/COMP 9331

Week 4
Major Concepts:

1. Multiplexing-demultiplexing
2. Checksum
3. Reliable data transfer
Transport Layer Part 1

Reading Guide:
Chapter 3, Sections 3.1 – 3.5.2
Transport layer: overview
Our goal:
§ understand principles § learn about Internet transport
behind transport layer layer protocols:
services: • UDP: connectionless transport
• multiplexing, • TCP: connection-oriented reliable
demultiplexing transport
• reliable data transfer
• flow control
• congestion control

2
Transport layer: roadmap
v Transport-layer services
v Multiplexing and demultiplexing
v Connectionless transport: UDP
v Principles of reliable data transfer
v Connection-oriented transport: TCP
v Principles of congestion control
v TCP congestion control
v Evolution of transport-layer functionality

3
Transport layer
v Moving “down” a layer

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

4
Network layer (some 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 transmission 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!!)

5
Transport services and protocols
application
transport

§ provide logical communication network

mobile network
data link
physical
between application processes national or global ISP

running on different hosts

lo g
i ca
l en
§ transport protocols actions in end

d -e
systems:

nd
local or

tra
• sender: breaks application messages regional ISP

n sp
into segments, passes to network layer

o rt
home network content
• receiver: reassembles segments into provider
network
messages, passes to application layer application
transport
datacenter
network
network

§ two transport protocols available to data link

physical

Internet applications enterprise

network
• TCP, UDP
6
Transport Layer Actions

Sender:
application § is passed an application- application
app. msg
layer message
transport § determines segment TThhtransport
app. msg
header fields values
network (IP) § creates segment network (IP)

link § passes segment to IP link

physical physical

7
Transport Layer Actions

Receiver:
application § receives segment from IP application
§ checks header values
app. msg
transport § extracts application-layer transport
message
network (IP) network (IP)
§ demultiplexes message up
link to application via socket link

physical physical
Th app. msg

8
Two principal Internet transport protocols
application
transport

§ TCP: Transmission Control Protocol network

mobile network
data link
physical
• reliable, in-order delivery national or global ISP

congestion control

lo g
•

i ca
• flow control

l en
d -e
• connection setup

nd
local or
§ UDP: User Datagram Protocol

tra
regional ISP

n sp
• unreliable, unordered delivery

o rt
home network content
provider
• no-frills extension of “best-effort” IP network
application
datacenter
network
§ services not available: transport
network
data link

• delay guarantees physical

• bandwidth guarantees enterprise

network

9
Transport layer: roadmap
v Transport-layer services
v Multiplexing and demultiplexing
v Connectionless transport: UDP
v Principles of reliable data transfer
v Connection-oriented transport: TCP
v Principles of congestion control
v TCP congestion control
v Evolution of transport-layer functionality

10
 HTTP server
client
application application
HTTP msg
transport

transport network transport

network link network
link physical link
physical physical

11
 HTTP server
client
application application
HTTP msg
transport
Ht HTTP msg

transport network transport

network link network
link physical link
physical physical

12
 HTTP server
client
application application
HTTP msg
transport
Ht HTTP msg

Hnnetwork
Ht HTTP msg
transport transport
network link network
link physical link
physical physical

13
 HTTP server
client
application application

transport

transport network transport

network link network
link physical link
physical physical

Hn Ht HTTP msg

14
 HTTP server
client1 client2
application P-client1 P-client2 application

transport

transport network transport

network link network
link physical link
physical physical

15
Multiplexing/demultiplexing
multiplexing at sender: demultiplexing at receiver:
handle data from multiple use header info to deliver
sockets, add transport header received segments to correct
(later used for demultiplexing) 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.
16
How demultiplexing works
§ host receives IP datagrams 32 bits
• each datagram has source IP source port # dest port #
address, destination IP address
(not shown in the pic) other header fields
• each datagram carries one
transport-layer segment
application
• each segment has source, data
destination port number (payload)
§ host uses IP addresses & port
numbers to direct segment to TCP/UDP segment format
appropriate socket
17
Connectionless demultiplexing (UDP)
Recall: when receiving host receives
§ when creating socket, either UDP segment:
specify host-local port # (or let • checks destination port # in
OS pick random available port): segment
DatagramSocket mySocket1 = new • directs UDP segment to
DatagramSocket(12534);
socket with that port #
§ when creating datagram to
send into UDP socket, must
specify IP/UDP datagrams with same dest.
port #, but different source IP
• destination IP address addresses and/or source port
• destination port # numbers will be directed to same
socket at receiving host
18
(UDP) Connectionless demultiplexing: an example
DatagramSocket
serverSocket = new
DatagramSocket
DatagramSocket mySocket2 = DatagramSocket mySocket1 =
new DatagramSocket (6428); new DatagramSocket (5775);
(9157); application
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

source port: 6428 source port: 6428

dest port: 9157 dest port: 5775

source port: 9157 source port: 5775

dest port: 6428 dest port: 6428
19
Connection-oriented demultiplexing (TCP)
§ TCP socket identified by § server may support many
4-tuple: simultaneous TCP sockets:
• source IP address • each socket identified by its
• source port number own 4-tuple
• dest IP address • each socket associated with
• dest port number a different connecting client
§ demux: receiver uses all
four values (4-tuple) to
direct segment to
appropriate socket
20
Revisiting TCP Sockets
Client Process Server Process

Welcoming, port X
TCP handshake Socket

Client Connection, port X

Socket Socket 1
connection
Connection, port X
Socket 2
ti on
ec
nn
Client co
Socket
Client Process
21
Connection-oriented demultiplexing: example
Browser process p2 uses port 5775, and p3
Browser process p1 uses port 9157 uses port 9157
application
application P4 P5 P6 application
P1 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
22
Summary
§ Multiplexing, demultiplexing: based on segment, datagram
header field values
§ UDP: demultiplexing using destination IP and port number
(only)
§ TCP: demultiplexing using 4-tuple: source and destination IP
addresses, and port numbers
§ Multiplexing/demultiplexing happen at all layers (more later in
the course)

23
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 exploit known flaws with these known apps
§ Example: Slammer worm exploited buffer overflow flaw in the SQL server
v How do you scan ports?
§ Nmap, Superscan, etc http://www.auditmypc.com/

https://www.grc.com/shieldsup
24
Quiz: UDP Sockets

Suppose we use UDP instead of TCP for communicating with a web

server where all requests and responses fit in a single UDP segment.
Suppose 100 clients are simultaneously communicating with this web
server. How many sockets are respectively active at the server and each
client?

a) 1, 1
b) 2, 1
c) 200, 2
d) 100, 1
e) 101, 1

25
Quiz: TCP Sockets

Suppose 100 clients are simultaneously communicating with a

traditional HTTP/TCP web server. How many sockets are active
respectively at the server and each client?

a) 1, 1
b) 2, 1
c) 200, 2
d) 100, 1
e) 101, 1

26
Quiz: TCP Sockets

Suppose 100 clients are simultaneously communicating with a

traditional HTTP/TCP web server. Do all the TCP sockets at the server
have the same server-side port number?

a) Yes
b) No

27
Transport layer: roadmap
v Transport-layer services
v Multiplexing and demultiplexing
v Connectionless transport: UDP
v Principles of reliable data transfer
v Connection-oriented transport: TCP
v Principles of congestion control
v TCP congestion control
v Evolution of transport-layer functionality

28
UDP: User Datagram Protocol
Why is there a UDP?
§ “no frills,” “bare bones”
Internet transport protocol § no connection
establishment (which can
§ “best effort” service, UDP add RTT delay)
segments may be: § simple: no connection state
• lost at sender, receiver
• delivered out-of-order to app § small header size
§ connectionless: § no congestion control
• no handshaking between UDP § UDP can blast away as fast as
desired!
sender, receiver § can function in the face of
• each UDP segment handled congestion
independently of others
30
UDP: User Datagram Protocol
§ Applications that use UDP:
§ streaming multimedia apps (loss tolerant, rate sensitive)
§ DNS
§ SNMP
§ HTTP/3
§ if reliable transfer needed over UDP (e.g., HTTP/3):
§ add needed reliability at application layer
§ add congestion control at application layer

31
UDP: User Datagram Protocol [RFC 768]

32
UDP: Transport Layer Actions
SNMP client SNMP server

application application

transport transport
(UDP) (UDP)

network (IP) network (IP)

link link

physical physical

33
UDP: Transport Layer Actions
SNMP client SNMP server
UDP sender actions:
application § is passed an application- application
SNMP msg
layer message
transport transport
§ determines UDP segment UDP
UDPhh SNMP msg
(UDP) header fields values (UDP)

network (IP) § creates UDP segment network (IP)

link § passes segment to IP link

physical physical

34
UDP: Transport Layer Actions
SNMP client SNMP server
UDP receiver actions:
application § receives segment from IP application
§ checks UDP checksum
transport transport
SNMP msg header value
(UDP) (UDP)
§ extracts application-layer
network
UDPh SNMP(IP)
msg message network (IP)
§ demultiplexes message up
link link
to application via socket
physical physical

35
UDP segment header
32 bits
source port # dest port #
length checksum

application length, in bytes of

data UDP segment,
(payload) including header

data to/from
UDP segment format application layer

36
UDP checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
1st number 2nd number sum

Transmitted: 5 6 11

Received: 4 6 11

receiver-computed
checksum
= sender-computed
checksum (as received)

37
Internet checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
sender: receiver:
§ treat contents of UDP § compute checksum of received
segment (including UDP header segment
fields and IP addresses) as
sequence of 16-bit integers § check if computed checksum equals
§ checksum: addition (one’s checksum field value:
complement sum) of segment • not equal - error detected
content • equal - no error detected. But maybe
errors nonetheless? More later ….
§ checksum value put into
UDP checksum field

38
Internet checksum: an example
example: add two 16-bit integers
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
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 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 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

39
Internet checksum: weak protection!
example: add two 16-bit integers
0 1
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0
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 Even though
numbers have
sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 changed (bit
flips), no change
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 in checksum!

40
UDP Checksum in Practice
Ø Checksum is the 16-bit one's complement of the one's complement sum of
a pseudo header of information from the IP header, the UDP header, and
the data, padded with zero octets at the end (if necessary) to make a
multiple of two octets.
Ø Checksum header, data and pre-pended IP pseudo-header (some fields
from the IP header)
Ø But the header contains the checksum itself?

IP pseduo-header

UDP header

UDP payload

41
Checksum: example

Note: TCP Checksum computation is exactly similar

42
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 managed by periodic messages

43
Summary: UDP
§ “no frills” protocol:
• segments may be lost, delivered out of order
• best effort service: “send and hope for the best”
§ UDP has its plusses:
• no setup/handshaking needed (no RTT incurred)
• can function when network service is compromised
• helps with reliability (checksum)
§ build additional functionality on top of UDP in application layer
(e.g., HTTP/3)

44
Transport layer: roadmap
v Transport-layer services
v Multiplexing and demultiplexing
v Connectionless transport: UDP
v Principles of reliable data transfer
v Connection-oriented transport: TCP
v Principles of congestion control
v TCP congestion control
v Evolution of transport-layer functionality

45
 Principles of reliable data transfer

sending receiving
process process
application data data
transport
reliable channel

reliable service abstraction

46
 Principles of reliable data transfer

sending receiving sending receiving

process process process process
application data data application data data
transport transport
reliable channel
sender-side of receiver-side
reliable service abstraction reliable data of reliable data
transfer protocol transfer protocol

transport
network
unreliable channel

reliable service implementation

47
Principles of reliable data transfer

sending receiving
process process
application data data
transport

sender-side of receiver-side
Complexity of reliable data reliable data
transfer protocol
of reliable data
transfer protocol
transfer protocol will depend
(strongly) on characteristics of transport
network
unreliable channel (lose, unreliable channel
corrupt, reorder data?)
reliable service implementation

48
Principles of reliable data transfer

sending receiving
process process
application data data
transport

sender-side of receiver-side
Sender, receiver do not know reliable data
transfer protocol
of reliable data
transfer protocol
the “state” of each other, e.g.,
was a message received? transport
network
§ unless communicated via a unreliable channel

message
reliable service implementation

49
 Reliable data transfer protocol (rdt): interfaces
rdt_send(): called from above, deliver_data(): called by rdt
(e.g., by app.). Passed data to to deliver data to upper layer
deliver to receiver upper layer
sending receiving
process process
rdt_send() data data
deliver_data()

sender-side data receiver-side

implementation of implementation of
rdt reliable data packet rdt reliable data
transfer protocol transfer protocol

udt_send() Header data Header data rdt_rcv()

unreliable channel
udt_send(): called by rdt rdt_rcv(): called when packet
to transfer packet over Bi-directional communication over arrives on receiver side of
unreliable channel to receiver unreliable channel channel
50
 Reliable data transfer: getting started
We will:
§ incrementally develop sender, receiver sides of reliable data transfer
protocol (rdt)
§ consider only unidirectional data transfer
• but control info will flow in both directions!
§ Book uses finite state machines (FSM) to specify sender, receiver
§ We won’t use them in the lecture, and you won’t be asked exam questions on them
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

51
rdt1.0: reliable transfer over a reliable channel
§ underlying channel perfectly reliable
• no bit errors
• no loss of packets
• Nothing to do

52
Global Picture of rdt1.0

sender receiver
data

Solid line: error-free transmission

data

53
rdt2.0: channel with bit errors
§ underlying channel may flip bits in packet
• checksum (e.g., Internet checksum) to detect bit errors
§ the question: how to recover from errors?

How do humans recover from “errors” during conversation?

54
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
§ retransmission
stop and wait
sender sends one packet, then waits for receiver response
55
Global Picture of rdt2.0
sender receiver
data

Dotted line: erroneous transmission

Solid line: error-free transmission
NACK

data

ACK

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

stop and wait

sender sends one packet, then
waits for receiver response

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

New Measures: Sequence Numbers, Checksum for ACK/NACK, Duplicate detection

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

As we will see, TCP uses this approach to be NAK-free

60
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

K)
li es a NA
#1 ACK (0
) (imp

Duplicate ACK data (1

Resend old )
packet
)
ACK (1

data (0
)
sending #
0
waiting for 0
61
rdt3.0: channels with errors and loss
New channel assumption: underlying channel can also lose
packets (data, ACKs)
• checksum, sequence #s, ACKs, retransmissions will be of help …
but not quite enough

Q: How do humans handle lost sender-to-

receiver words in conversation?

62
rdt3.0: channels with errors and loss
Approach: sender waits “reasonable” amount of time for ACK
§retransmits if no ACK received in this time
§if pkt (or ACK) just delayed (not lost):
• retransmission will be duplicate, but seq #s already handles this!
• receiver must specify seq # of packet being ACKed
§ use countdown timer to interrupt after “reasonable” amount of time
§ No retransmission on duplicate ACKs

timeout

63
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

64
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
timeout rcv pkt1
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 (ignore)
send pkt0
rcv pkt0
ack0 send ack0

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

65
Quiz: Reliable Data Transfer

Which of the following are needed for reliable data transfer with only
packet corruption (and no loss or reordering)? Use only as much as is
strictly needed.

a) Checksums
b) Checksums, ACKs, NACKs
c) Checksums, ACKs
d) Checksums, ACKs, sequence numbers
e) Checksums, ACKs, NACKs, sequence numbers

66
Quiz: Reliable Data Transfer

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 stuck
c) The protocol will continue making progress but may skip delivering some
messages

67
Quiz: Reliable Data Transfer

Which of the following are needed for reliable data transfer to handle
packet corruption and loss? Use only as much as is strictly needed.

a) Checksums, timeouts
b) Checksums, ACKs, sequence numbers
c) Checksums, ACKs, timeouts
d) Checksums, ACKs, timeouts, sequence numbers
e) Checksums, ACKs, NACKs, timeouts, sequence numbers

68
Performance of rdt3.0 (stop-and-wait)
§ U sender: utilization – fraction of time sender busy sending

§ example: 1 Gbps link, 15 ms prop. delay, 8000 bit packet

• time to transmit packet into channel:
L 8000 bits
Dtrans = R = 9 = 8 microsecs
10 bits/sec

69
rdt3.0: stop-and-wait operation
sender receiver
first packet bit transmitted, t = 0

first packet bit arrives

RTT last packet bit arrives, send ACK

ACK arrives, send next

packet, t = RTT + L / R

70
rdt3.0: stop-and-wait operation
sender receiver

L/R L/R
Usender=
RTT + L / R
.008 RTT
=
30.008
= 0.00027

§ rdt 3.0 protocol performance is very poor!

§ Protocol limits performance of underlying infrastructure (channel)

71
rdt3.0: pipelined protocols operation
pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged
packets
• range of sequence numbers must be increased
• buffering at sender and/or receiver

• Go Back N, Selective Repeat

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

73
Go-Back-N: sender
§ sender: “window” of up to N, consecutive transmitted but unACKed pkts
• k-bit seq # in pkt header

§ cumulative ACK: ACK(n): ACKs all packets up to, including seq # n

• on receiving ACK(n): move window forward to begin at n+1
§ timer for oldest in-flight packet
§ timeout(n): retransmit packet n and all higher seq # packets in window
Applets: http://media.pearsoncmg.com/aw/aw_kurose_network_2/applets/go-back-n/go-back-n.html
http://www.ccs-labs.org/teaching/rn/animations/gbn_sr/ 74
Go-Back-N: receiver
§ ACK-only: always send ACK for correctly-received packet so far, with
highest in-order seq #
• may generate duplicate ACKs
• need only remember rcv_base
§ on receipt of out-of-order packet:
• can discard (don’t buffer) or buffer: an implementation decision
• re-ACK pkt with highest in-order seq #

Receiver view of sequence number space:

received and ACKed

… … Out-of-order: received but not ACKed

rcv_base
Not received
75
Go-Back-N 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

76
Selective repeat
§receiver individually acknowledges all correctly received
packets
• buffers packets, as needed, for eventual in-order delivery to upper
layer
§sender times-out/retransmits individually for unACKed packets
• sender maintains timer for each unACKed pkt
§sender window
• N consecutive seq #s
• limits seq #s of sent, unACKed packets
Applet: http://media.pearsoncmg.com/aw/aw_kurose_network_3/applets/SelectRepeat/SR.html
http://www.ccs-labs.org/teaching/rn/animations/gbn_sr/
77
Selective repeat: sender, receiver windows

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

79
Selective Repeat in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5
receive pkt4, buffer,
record ack3 arrived send ack4
receive pkt5, buffer,
pkt 2 timeout send ack5
012345678 send pkt2
012345678 (but not 3,4,5)
012345678 rcv pkt2; deliver pkt2,
012345678 pkt3, pkt4, pkt5; send ack2

Q: what happens when ack2 arrives?

80
Selective repeat:
sender window receiver window
(after receipt) (after receipt)

pkt0

a dilemma!
0123012
0123012 pkt1 0123012
0123012 pkt2 0123012

example:
0123012
0123012 pkt3
X
0123012
§ seq #s: 0, 1, 2, 3 (base 4 counting) pkt0 will accept packet
with seq number 0
§ window size=3 (a) no problem

0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 X 0123012
X 0123012
X
timeout
retransmit pkt0
0123012 pkt0
will accept packet
with seq number 0
(b) oops!
81
Selective repeat:
sender window receiver window
(after receipt) (after receipt)

pkt0

a dilemma!
0123012
0123012 pkt1 0123012
0123012 pkt2 0123012

example:
0123012
0123012 pkt3
X
§ seq #s: 0, 1, 2, 3 (base 4 counting) § receiver can’t
0123012
pkt0 will accept packet
see sender side with seq number 0
§ window size=3 (a) no problem
§ receiver
behavior
identical in both
cases!
§0something’s
123012 pkt0
Q: what relationship is needed (very) wrong!
0123012 pkt1 0123012

between sequence # size and 0123012 pkt2 X

X
0123012

window size to avoid problem

0123012
X
in scenario (b)? timeout
retransmit pkt0
0123012 pkt0
A: Sender window size <= ½ of will accept packet
with seq number 0
Sequence number space (b) oops!
82
Recap: components of a solution
v Checksums (for error detection)
v Timers (for loss detection)
v Acknowledgments
§ cumulative
§ selective
v Sequence numbers (duplicates, windows)
v Sliding Windows (for efficiency)

v Reliability protocols use the above to decide when and what to

retransmit or acknowledge

83
Practical Reliability Questions
v How do the sender and receiver keep track of outstanding
pipelined segments?
v How many segments should be pipelined?
v How do we choose sequence numbers?
v What does connection establishment and teardown look like?
v How should we choose timeout values?

We will answer these questions when we cover TCP

84
 Quiz: GBN, SR

Which of the following is not true?

a) GBN uses cumulative ACKs, SR uses individual ACKs

b) Both GBN and SR use timeouts to address packet loss
c) GBN maintains a separate timer for each outstanding packet
d) SR maintains a separate timer for each outstanding packet
e) Neither GBN nor SR use NACKs

85
 Quiz: GBN, SR

Suppose a receiver that has received all packets up to and including

sequence number 24 and next receives packet 27 and 28. In response,
what are the sequence numbers in the ACK(s) sent out by the GBN and
SR receiver, respectively?

a) [27, 28], [28, 28]

b) [24, 24], [27, 28]
c) [27, 28], [27, 28]
d) [25, 25], [25, 25]
e) [nothing], [27, 28]

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

87
TCP: overview RFCs: 793,1122, 2018, 5681, 7323
§ point-to-point: § cumulative ACKs
• one sender, one receiver § pipelining:
§ reliable, in-order byte • TCP congestion and flow control
stream: set window size
• no “message boundaries" § connection-oriented:
§ full duplex data: • handshaking (exchange of control
• bi-directional data flow in messages) initializes sender,
same connection receiver state before data exchange
• MSS: maximum segment size § flow controlled:
application
writes data
application
reads data
• sender will not overwhelm receiver
socket socket
door door
TCP TCP
send buffer receive buffer
segment
88
 TCP segment structure
32 bits

source port # dest port # segment seq #: counting

ACK: seq # of next expected sequence number bytes of data into bytestream
byte; A bit: this is an ACK (not segments!)
acknowledgement number
length (of TCP header) head not
len used C E UAP R S F receive window flow control: # bytes
Internet checksum checksum Urg data pointer receiver willing to accept

options (variable length)

C, E: congestion notification
TCP options
application data sent by
RST, SYN, FIN: connection data application into
management (variable length) TCP socket

89
TCP segmentTCP
structure
Segments
32 bits

source port # dest port #

20 Bytes sequence number

(UDP was 8)
acknowledgement number
head not
len used
UAP R S F receive window
checksum Urg data pointer

options (variable length)

application
data
(variable length)

90
Summary
v Multiplexing/Demultimplexing
v UDP
v Reliable Data Transfer
§ Stop-and-wait protocols
§ Sliding winding protocols
v TCP - intro
v Up Next:
§ TCP – continued in more detail
§ Congestion Control

91