Transport Layer

Ante Prodan
School of Computer, Data and
Mathematical Sciences

1
Housekeeping
 Case Study Report
 Have you chosen your topic?
 Deadline by the end of the next week
 I can list your name and contact
detail during the lecture if you need a
partner and I can put the list on
screen during the break
 Next tutorial good opportunity to find
partner and select your topic…

2
Housekeeping
 For your study use resources on vUWS
 Learning guide
 Lecture notes
 Study questions
 Multimedia
 URLs
 Video Resources accessible by using web
links provided and videos accessible via
vUWS

3
 Comparing OSI and TCP/IP
models
Layer OSI Model TCP/IP Model
I
7 Application M
6 Presentation Application P
5 Session O
R !!!
4 Transport Transport T
3 Network Internet A
2 Data link N
Link T
1 Physical
OSI: Open Systems Interconnection (OSI) model (ISO/IEC 7498-1)
TCP/IP: Internet protocol suite is the set of communications protocols used for
the Internet and similar networks (names of the layers from RFC 1122)
 Encapsulation of application data
descending through the TCP/IP
layers
I
M
TCP TCP P
header data or O
R
T
A
N
T
Multiplexing / Demultiplexing

IMPORTANT 6
Important Concepts
 Logical communication between two processes.
 transport-layer protocol provides logical communication
between processes
 network-layer protocol provides logical communication
between hosts
 Multiplexing and demultiplexing
 Connectionless and connection-oriented
demultiplexing
 Reliable data transfer (RDT)
 Because packets can have bit errors as well as be lost, RDT
protocols are surprisingly complicated, requiring
acknowledgements, timers, checksums, sequence numbers,
and acknowledgement numbers.
 Pipelined reliable data transfer
 Flow control
 Congestion control
7
 Chapter 3 outline
 3.1 Transport-layer  3.5 Connection-oriented
services transport: TCP
segment structure
3.2 Multiplexing and


reliable data transfer
demultiplexing


 flow control
 3.3 Connectionless  connection management
transport: UDP
 3.6 Principles of
 3.4 Principles of reliable congestion control
data transfer
 3.7 TCP congestion
control

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

on different hosts
 transport protocols run in end
systems
 send side: breaks app

messages into segments,

passes to network layer
 rcv side: reassembles application
transport
segments into messages, network
data link
passes to app layer physical

 more than one transport

protocol available to apps
 Internet: TCP and UDP

9
 Internet transport-layer protocols
application

 reliable, in-order delivery transport

network
data link
(TCP) physical
network
data link
 congestion control physical
network
data link
physical
 flow control
 connection setup
network

 unreliable, unordered data link

physicalnetwork

delivery: UDP data link

physical
network
 no-frills extension of “best- data link
physical
application
network
effort” IP data link
transport
network
physical data link
 services not available: physical

 delay guarantees
 bandwidth guarantees

10
 Multiplexing/demultiplexing
Demultiplexing at rcv host: Multiplexing at send host:
gathering data from multiple
delivering received segments
sockets, enveloping data with
to correct socket
header (later used for
demultiplexing)
= socket = process

P3 P1
P1 P2 P4 application
application application

transport transport transport

network network network

link link link

physical physical physical

host 2 host 3
host 1
11
 How demultiplexing works

32 bits

 host receives IP datagrams source port # dest port #

 each datagram has source

IP address, destination IP other header fields

address
 each datagram carries 1

transport-layer segment
application
 each segment has source,
data
destination port number (message)
 host uses IP addresses & port
numbers to direct segment to
appropriate socket TCP/UDP segment format

12
 Connectionless demultiplexing
 When host receives UDP
 Create sockets with port segment:
numbers:  checks destination port
DatagramSocket mySocket1 = number in segment
new DatagramSocket(12534);  directs UDP segment to
DatagramSocket mySocket2 = socket with that port
new DatagramSocket(12535); number
 UDP socket identified by  IP datagrams with
two-tuple: different source IP
addresses and/or source
(dest IP address, dest port number) port numbers directed to
same socket

13
 Connectionless demux (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);

P2 P1
P1
P3

SP: 6428 SP: 6428

DP: 9157 DP: 5775

SP: 9157 SP: 5775

client DP: 6428 DP: 6428 Client
server
IP: A IP: C IP:B

SP provides “return address”

14
 Connection-oriented demux
 TCP socket identified  Server host may
by 4-tuple: support many
 source IP address simultaneous TCP
 source port number sockets:
 dest IP address  each socket identified
 dest port number by its own 4-tuple
 recv host uses all  Web servers have
four values to direct different sockets for
segment to each connecting client
appropriate socket  non-persistent HTTP
will have different
socket for each request15
 Connection-oriented demux
(cont)

P1 P4 P5 P6 P2 P1P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

SP: 9157 SP: 9157

client DP: 80 DP: 80 Client
server
IP: A S-IP: A
IP: C S-IP: B IP:B
D-IP:C D-IP:C

SP: Source Port S-IP: Source IP address

DP: Destination Port D-IP: Destination IP address
16
 Connection-oriented demux:
Threaded Web Server

P1 P4 P2 P1P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

SP: 9157 SP: 9157

client DP: 80 DP: 80 Client
server
IP: A S-IP: A
IP: C S-IP: B IP:B
D-IP:C D-IP:C

17
 TCP Multiplexing Service
• Multiple processes within a host can
simultaneously access the network via a
single TCP entity.
• Each process within a host which uses TCP
services is identified with a port.
• A port, when concatenated with an IP address,
forms a socket, which is unique throughout the
internet.
• Service by TCP is provided by means of a
logical connection between a pair of sockets.
18
 TCP Multiplexing Service
As an example, the diagram on the next slide
shows three hosts A, B and C connected over the
internet. The multiplexing service of TCP would
enable a process X, say in host A to establish a
connection to a process Y in host B. This might
involve use of port 2 in A and port 1 in B. At the
same time a process P in B could establish a
connection to a process Q in A using port 2
of B and port 1 of A. Finally, a process M in A might
establish a link to a process N in host C using ports
3 of A and 1 of C.
19
TCP Multiplexing Service

Thus multiple users or processes

within a host can employ
simultaneously the services of
TCP to exchange data with remote
processes.

20
TCP Multiplexing Service

21
 http://etc.ch/EP88
Question 1

When sharing a communication channel by two

or more users/devices _______ is necessary.

(a) Modulation
(b) Encoding
(c) Code division
(d) Demultiplexing

22
 Chapter 3 outline
 3.1 Transport-layer  3.5 Connection-oriented
services transport: TCP
 3.2 Multiplexing and  segment structure
demultiplexing  reliable data transfer
flow control
 3.3 Connectionless 

connection management
transport: UDP 

 3.6 Principles of
 3.4 Principles of reliable
congestion control
data transfer
 3.7 TCP congestion
control

23
 UDP: User Datagram Protocol [RFC
768]
 “no frills,” “bare bones”
Internet transport protocol Why is there a UDP?
 “best effort” service, UDP  no connection establishment
segments may be: (which can add delay)
 lost
 simple: no connection state
at sender, receiver
 delivered out of order to

app  small segment header

 connectionless:  no congestion control: UDP
can blast away as fast as
 no handshaking between
desired
UDP sender, receiver
 each UDP segment
handled independently of
others

24
 UDP: more
32 bits
 often used for streaming
multimedia apps Length, in source port # dest port #
 loss tolerant bytes of UDP length checksum
segment,
 rate sensitive
including
 other UDP uses header
 DNS
 SNMP
Application
data
 reliable transfer over UDP:
(message)
add reliability at application
layer
 application-specific error
UDP segment format
recovery!

25
 UDP checksum
Goal: detect “errors” (e.g., flipped bits) in
transmitted segment
Sender: Receiver:
 treat segment contents as  compute checksum of received
sequence of 16-bit integers segment
 checksum: addition (1’s  check if computed checksum
complement sum) of equals checksum field value:
segment contents  NO - error detected

 sender puts checksum  YES - no error detected.

value into UDP checksum But maybe errors

field nonetheless? More later ….

26
 Internet Checksum Example
 Note
 When adding numbers, a carryout from the

most significant bit needs to be added to

the result
 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

27
 Chapter 3 outline
 3.1 Transport-layer  3.5 Connection-oriented
services transport: TCP
 segment structure
 3.2 Multiplexing and
 reliable data transfer
demultiplexing
 flow control
 3.3 Connectionless  connection management
transport: UDP
 3.6 Principles of
 3.4 Principles of reliable congestion control
data transfer
 3.7 TCP congestion
control

28
Principles of Reliable data transfer
 important in app., transport, link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)
29
 Principles of Reliable data transfer
 important in app., transport, link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)
30
 Principles of Reliable data transfer
 important in app., transport, link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt) 31
 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

32
 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 state
“state” next state event
1 2
uniquely actions
determined by next
event
33
 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 read 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

34
 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
 receiver feedback: control msgs (ACK,NAK) rcvr->sender

35
 rdt2.0: FSM specification
rdt_send(data)
snkpkt = 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
L
call from
sender below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK) 36
 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
L call from
below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
37
 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
L call from
below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
38
rdt2.0 has a fatal flaw!
What happens if ACK/NAK Handling duplicates:
corrupted?  sender retransmits current
 sender doesn’t know what pkt if ACK/NAK garbled
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

39
 Chapter 3 outline
 3.1 Transport-layer  3.5 Connection-oriented
services transport: TCP
segment structure
3.2 Multiplexing and


reliable data transfer
demultiplexing


 flow control
 3.3 Connectionless  connection management
transport: UDP
 3.6 Principles of
 3.4 Principles of reliable congestion control
data transfer
 3.7 TCP congestion
control

40
 TCP: Overview RFCs: 793, 1122, 1323, 2018,
2581

 point-to-point:  full duplex data:

 one sender, one receiver  bi-directional data flow in
 reliable, in-order byte same connection
steam:  MSS: maximum segment
size
 no “message boundaries”
 connection-oriented:
 pipelined:
 handshaking (exchange of
 TCP congestion and flow control msgs) init’s
control set window size sender, receiver state
 send & receive buffers before data exchange
 flow controlled:
application application
socket
writes data reads data
socket  sender will not overwhelm
receiver
door door
TCP TCP
send buffer receive buffer
segment

41
 TCP segment structure
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UA P R S F Receive window
(generally not used) # bytes
checksum Urg data pnter
rcvr willing
RST, SYN, FIN: to accept
Options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

42
 TCP seq. #’s and ACKs
Seq. #’s: Host A Host B
 byte stream User
“number” of first types
‘C’
byte in segment’s host ACKs
data receipt of
‘C’, echoes
ACKs: back ‘C’
 seq # of next byte

expected from other

host ACKs
side receipt
 cumulative ACK of echoed
‘C’
Q: how receiver handles
out-of-order segments
 A: TCP spec doesn’t time
say, - up to simple telnet scenario
implementor
43
 Chapter 3 outline
 3.1 Transport-layer  3.5 Connection-oriented
services transport: TCP
 3.2 Multiplexing and  segment structure
demultiplexing  reliable data transfer
 flow control
 3.3 Connectionless
 connection management
transport: UDP
 3.6 Principles of
 3.4 Principles of reliable
congestion control
data transfer
 3.7 TCP congestion
control

44
 TCP reliable data transfer
 TCP creates rdt  Retransmissions are
service on top of IP’s triggered by:
unreliable service  timeout events
 Pipelined segments  duplicate acks

 Cumulative acks  Initially consider

simplified TCP
 TCP uses single
sender:
retransmission timer
 ignore duplicate
acks
 ignore flow control,
congestion control
45
 TCP sender events:
data rcvd from app: timeout:
 Create segment with  retransmit segment that
seq # caused timeout
 seq # is byte-stream  restart timer

number of first data Ack rcvd:

byte in segment  If acknowledges
 start timer if not already previously unacked
running (think of timer segments
as for oldest unacked  update what is known to
segment) be acked
 expiration interval:  start timer if there are
TimeOutInterval outstanding segments

46
 TCP: retransmission scenarios
Host A Host B Host A Host B

Seq=92 timeout
timeout

X
loss

Sendbase
= 100

Seq=92 timeout
SendBase
= 120

SendBase
= 100 SendBase
= 120 premature timeout
time time
lost ACK scenario 47
TCP retransmission scenarios
(more)
Host A Host B

timeout

X
loss

SendBase
= 120

time
Cumulative ACK scenario
48
 Chapter 3 outline
 3.1 Transport-layer  3.5 Connection-oriented
services transport: TCP
 segment structure
 3.2 Multiplexing and
 reliable data transfer
demultiplexing
 flow control
 3.3 Connectionless  connection management
transport: UDP
 3.6 Principles of
 3.4 Principles of reliable congestion control
data transfer
 3.7 TCP congestion
control

49
 TCP Flow Control
flow control
sender won’t overflow
 receive side of TCP receiver’s buffer by
connection has a transmitting too much,
receive buffer: too fast

 speed-matching
service: matching
the send rate to the
receiving app’s drain
 app process may be rate
slow at reading from
buffer
50
TCP Flow control: how it works
 Rcvr advertises spare
room by including
value of RcvWindow
in segments
(Suppose TCP receiver  Sender limits
discards out-of-order unACKed data to
segments) RcvWindow
 spare room in buffer  guarantees receive
= RcvWindow buffer doesn’t
overflow
= RcvBuffer-
[LastByteRcvd -
LastByteRead] 51
 http://etc.ch/EP88
Question 2
 Which one of the protocols listed below
can prevent buffer overflow (overrun)?
(a) UDP
(b) HTTP
(c) DNS
(d) TCP

52
 Chapter 3 outline
 3.1 Transport-layer  3.5 Connection-oriented
services transport: TCP
 3.2 Multiplexing and  segment structure
demultiplexing  reliable data transfer
flow control
3.3 Connectionless


connection management
transport: UDP


 3.6 Principles of
 3.4 Principles of reliable
congestion control
data transfer
 3.7 TCP congestion
control

53
 TCP Connection Management

Recall: TCP sender, receiver Three way handshake:

establish “connection” before
exchanging data segments Step 1: client host sends TCP SYN
 initialize TCP variables: segment to server
 specifies initial seq #
 seq. #s
 no data
 buffers, flow control info

(e.g. RcvWindow) Step 2: server host receives SYN,

 client: connection initiator replies with SYNACK segment
Socket clientSocket = new
Socket("hostname","port
 server allocates buffers
 specifies server initial seq.
number");
#
 server: contacted by client
Socket connectionSocket =
Step 3: client receives SYNACK,
welcomeSocket.accept(); replies with ACK segment,
which may contain data
54
 TCP Connection Management (cont.)

client server
Closing a connection: close

client closes socket:

clientSocket.close();
close
Step 1: client end system
sends TCP FIN control
segment to server

Step 2: server receives FIN, timed wait

replies with ACK. Closes
connection, sends FIN. closed

55
 TCP Connection Management (cont.)

client server

Step 3: client receives FIN, closing

replies with ACK.
 Enters “timed wait” - will
respond with ACK to closing
received FINs

Step 4: server, receives ACK.

timed wait
Connection closed.
closed
Note: with small modification,
can handle simultaneous
FINs. closed

56
 Chapter 3 outline
 3.1 Transport-layer  3.5 Connection-oriented
services transport: TCP
 3.2 Multiplexing and  segment structure
demultiplexing  reliable data transfer
 flow control
 3.3 Connectionless
 connection management
transport: UDP
 3.6 Principles of
 3.4 Principles of reliable
congestion control
data transfer
 3.7 TCP congestion
control

57
Principles of Congestion Control
Congestion:
 informally: “too many sources sending too
much data too fast for network to handle”
 different from flow control!
 manifestations:
 lost packets (buffer overflow at routers)

 long delays (queueing in router buffers)

 a top-10 problem!

58
 TCP congestion control: additive
increase, multiplicative decrease

 Approach: increase transmission rate (window size),

probing for usable bandwidth, until loss occurs
 additive increase: increase CongWin by 1 MSS every

RTT until loss detected

 multiplicative decrease: cut CongWin in half after

loss congestion
window
congestion window size

24 Kbytes

Saw tooth
behavior: probing
16 Kbytes

for bandwidth
8 Kbytes

time
time

59
 http://etc.ch/EP88
Question 3
At which devices TCP congestion control
detection is implemented?

(a) at the end hosts

(b) at the path routers
(c) at all of the network interfaces
(d) everywhere on the Internet

60
External links
 Protocols at Transport Layer
 https://www.youtube.com/watch?v=Vdc8T
CESIg8
 UDP
 http://www.youtube.com/watch?v=77VVjODrJiQ&fea
ture=related
 TCP
 https://www.youtube.com/watch?v=FdwNzb1CQPg
 http://www.tcpipguide.com/free/t_TCPWindowSizeA
djustmentandFlowControl.htm
 http://www.youtube.com/watch?v=7Z-h9SZZ22g

61