Chapter 6-2

The Transport Layer

TCP, UDP and
Performance Issues
TANENBAUM Computer Networks II 1
The Internet Transport Protocols:
UDP

• Introduction to UDP
• Remote Procedure Call
• The Real-Time Transport
Protocol

TANENBAUM Computer Networks II 2

 UDP (User Data Protocol)
• Provides a way to send IP datagrams without establishing
a connection
• A UDP segment has 8-byte header followed by data
• UDP length includes header and data
• UDP checksum includes the same format pseudoheader as
in TCP

TANENBAUM Computer Networks II 3

 Remote Procedure Call
• Allows programs to call procedures located on
remote hosts
• Looks as much possible as local call
• Two library procedures called client stub and
server stub hide the fact that call is remote
– The client program makes a local call to client stub to
handle the RPC
• Information is transported in parameters
– For this purpose, client stub packs parameters into a
message (parameter marshalling)
TANENBAUM Computer Networks II 4
 Remote Procedure Call
Steps in making a remote procedure call. The stubs are
shaded.

TANENBAUM Computer Networks II 5

 Problems with RPC
• Passing pointers is impossible
• Array size must be specified and fixed
• It may not be possible to deduce the types
of the parameters
• Global variables can not be used
• RPC commonly uses UDP

TANENBAUM Computer Networks II 6

 Real Time Transport Protocol
(RTP)
• Used to transport multimedia streams
• Can multiplex different streams such as the audio and video into a
single UDP socket
• Each packet is given a unique increasing number
• No flow control, no error control, no acks,no retransmission
mechanism
• Contains a payload type field to specify encoding that allows
changing quality of the multimedia data when available bandwidth
drops
• Contains timestamps that are used to synchronize streams.
However, these timestamps are used to compute the relative time
from the start rather than absolute time
• Has a sister protocol, Real Time Control Protocol (RTCP) that
carries delay, jitter, bandwidth and congestion information for
feedback purposes

TANENBAUM Computer Networks II 7

 The Real-Time Transport Protocol
(a) The position of RTP in the protocol stack. (b)
Packet nesting.

TANENBAUM Computer Networks II 8

 The Real-Time Transport Protocol (2)
The RTP header.

TANENBAUM Computer Networks II 9

 The Internet Transport Protocols: TCP
• Introduction to TCP
• The TCP Service Model
• The TCP Protocol
• The TCP Segment Header
• TCP Connection Establishment
• TCP Connection Release
• TCP Connection Management Modeling
• TCP Transmission Policy
• TCP Congestion Control
• TCP Timer Management
• Wireless TCP and UDP
• Transactional TCP
TANENBAUM Computer Networks II 10
 TCP Basic Functionality
• Provides reliable end-to-end byte stream over an
unreliable internetwork
• Transport entity
– A piece of software that is either
• A user process or
• Part of kernel
– Accepts user data streams from local processes
– Breaks them into pieces not exceeding 64K bytes
– Send each piece as an IP datagram
– At the receiver, it reconstructs original byte streams

TANENBAUM Computer Networks II 11

 The TCP Service Model
• The sender and receiver create end points
called sockets
• Each socket has
– IP address
– Port number (16 bit and local)
• A socket may be used for multiple
connections at the same time
• Some port numbers are reserved
– FTP: 21
– Telnet: 23
TANENBAUM Computer Networks II 12
 The TCP Service Model
Some assigned ports.
Port Protocol Use
21 FTP File transfer
23 Telnet Remote login
25 SMTP E-mail
69 TFTP Trivial File Transfer Protocol
79 Finger Lookup info about a user
80 HTTP World Wide Web
110 POP-3 Remote e-mail access
119 NNTP USENET news

TANENBAUM Computer Networks II 13

 The TCP Service Model (2)

(a) Four 512-byte segments sent as separate IP datagrams.

(b) The 2048 bytes of data delivered to the application in a single READ
CALL.

A TCP connection is a byte stream, not a message stream

Message boundaries are not preserved end to end

TANENBAUM Computer Networks II 14

The TCP Service Model (cont’d)
• When an application passes data to TCP, TCP
may send it immediately or buffer it at its
discretion
• To force data out, applications can use PUSH
flag, which tells TCP not to delay transmission
• At the receiver side, the same effect can be
obtained by using URGENT flag
• However, at the receiver side, on the contrary of
PUSH flag, URGENT flag causes an interrupt to
the application (provides signaling)

TANENBAUM Computer Networks II 15

 The TCP Protocol
• Every byte on a TCP connection has its own 32-
bit sequence number to be used for acks and
sliding window sequencing
• Window mechanism has its own 32-bit header
• Data is exchanged in form of segments
– A segment consists of a 20-byte header and zero or
more bytes
– A segment must fit into a IP payload (65635 bytes) or
Maximum Transfer Unit, MTU of the underlying
network (further segmentation is a major problem)
– Sliding window acks next expected sequence number

TANENBAUM Computer Networks II 16

 The TCP Segment Header

TANENBAUM Computer Networks II 17

TCP Header.
 The TCP Segment Header (2)
The pseudoheader included in the TCP
checksum.

TANENBAUM Computer Networks II 18

The TCP Segment Header (cont’d)
• Every segment begins with a fixed format
20-byte header
• Segments without any data are legal
– Ack messages or other control messages
• Ack: Next byte expected
• Options
– Specifies beginning of data
• Urgent pointer specifies offset of urgent
data when URG flag is set
• ACK bit indicates that the ack field is valid
TANENBAUM Computer Networks II 19
The TCP Segment Header (cont’d)
• PSH flag indicates pushed data
• RST flag indicates problem with connection
• SYN flag indicates connection request or
connection accepted together with ACK flag
• FIN flag is used to release a connection
• Window Size field indicates how many bytes can
be accepted starting at the byte acknowledged.
• Checksum is a control field on header, data and
pseudo header that indicates portions of IP
header

TANENBAUM Computer Networks II 20

 The TCP segment Header
(cont’d)
• Options
– A host may specify the maximum TCP
payload it is willing to accept
• If not specified, the default is 536 bytes
– Window scale option
• In general 16 bit window size is not sufficient for
current systems
• This option scales up the window size
– Selective Reject instead of go back n can be
indicated via options field
TANENBAUM Computer Networks II 21
 TCP Connection Management
• Server waits for an incoming connection by executing
the LISTEN and ACCEPT primitives
• Client executes CONNECT primitive
– IP address, port number and options specified
• Destination checks to see if a process has done a
LISTEN on the indicated port
– If not,request is rejected
• If there is a process which has done a LISTEN, it is
asked if it would accept the connection
– If process rejects, destination sends a segment with RST set. If
process accepts, request is acked

TANENBAUM Computer Networks II 22

 TCP Connection Establishment

6-31

(a) TCP connection establishment in the normal

case.
(b) Call collision.
TANENBAUM Computer Networks II 23
 TCP Connection Management
(cont’d)
• If simultaneous connection request happens
only one connection is established
• TCP connections are full duplex
• However, they are considered as two simplex
connections and each of them is released
independently
• To release, a node sends a segment with FIN bit
set and the other side acks the release
• Same procedure is repeated for the other
simplex connection.

TANENBAUM Computer Networks II 24

 TCP Connection Management
(cont’d)
• To avoid two-army problem, timers are
used in release process
• That is, if ack for release does not arrive
on time, timer goes off and client releases
the connection
• After release, both sides wait for maximum
packet lifetime to erase tables

TANENBAUM Computer Networks II 25

 TCP Connection Management
Modeling
The states used in the TCP connection management finite
state machine.

TANENBAUM Computer Networks II 26

 TCP Connection
Management
Modeling (2)
TCP connection
management finite state
machine. The heavy solid
line is the normal path for a
client. The heavy dashed
line is the normal path for a
server. The light lines are
unusual events. Each
transition is labeled by the
event causing it and the
action resulting from it,
separated by a slash.

TANENBAUM Computer Networks II 27

 TCP Transmission Policy
• Window management is not directly tied to
acks as in data link protocols
• Exclusive buffer messages manage the
transmission
• If no buffer at receiver, then no
transmission by sender except
– Urgent data may be sent
– One byte segment can be sent to ask receiver
to renounce its buffer status (to prevent
deadlock)
TANENBAUM Computer Networks II 28
 TCP
Transmission
Policy

TANENBAUM
Window management
Computer Networks II
in TCP. 29
 TCP Transmission Policy
(cont’d)
• Sender and receiver are not forced to
transmit or receive as soon as they
receive data from the application. This
improves performance as follows:
– If one byte messages are sent (like in
TELNET) then use NAGLE’s algorithm
• Send first byte and keep the rest until ack comes
back
• As ack comes in send the rest and keep the further
incoming bytes until ack is received
TANENBAUM Computer Networks II 30
 TCP Transmission Policy (2)

• Silly Window Syndrome: Receive bytes one by

one and send window messaging accordingly
TANENBAUM Computer Networks II 31
 TCP Transmission Policy
(cont’d)
• Clark’s Solution to Silly Window Syndrome
– Prevent receiver from sending one byte
updates and make it wait until decent amount
of space available before it sends buffer
messages
– Sender may also pospone sending messages
• Nagle’s Algorithm and Clark’s solution are
complementary and they can be used at
the same time
TANENBAUM Computer Networks II 32
 TCP Congestion Control
• When congestion occurs, IP has limited
effect on managing congestion
• Most of the congestion control is done by
TCP by cutting down the data rate
• Indication of congestion
– Timeouts
– Packet discards
– In fiber optic cable transmission errors are
minimized so timeouts mainly due to
congestion
TANENBAUM Computer Networks II 33
 Congestion Window
• In addition to receiver’s buffer information,
the sender also maintains a congestion
window.
• This is mainly due to the fact that even if
receiver may have space for fast data
transfer, network may not carry it due to
congestion.
• The number of bytes to be sent is the
minimum of the two windows
TANENBAUM Computer Networks II 34
 TCP Congestion Control
(a) A fast network feeding a low capacity receiver.
(b) A slow network feeding a high-capacity receiver.

TANENBAUM Computer Networks II 35

 Slow Start Algorithm
• Initialize the size of the congestion window
to the maximum segment size
• If no timeout occurs increase the size of
the window by one segment and send
again.
• Repeat above n times. If no timeout, then
increase the window by n segments.
• Internet uses threshold in addition to the
above algorithm
TANENBAUM Computer Networks II 36
 TCP Congestion Control (2)

An example of the Internet congestion algorithm.

TANENBAUM Computer Networks II 37
 TCP Timer Management:
Retransmission Timer
• When goes off, segment is retransmitted
• Setting the timer value is much more
difficult than that of data-link layer,
beacuse the delay is not easily predictable
• TCP uses a dynamic algorithm to solve
this problem
• For each connection, TCP maintains a
variable called RTT (round trip time)
TANENBAUM Computer Networks II 38
 TCP Timer Management

(a) Probability density of ACK arrival times in the data link layer.
(b) Probability density of ACK arrival times for TCP.
TANENBAUM Computer Networks II 39
 Retransmission Timer (cont’d)
• M: The time to receive ack
• :Smoothing factor, usually 7/8
• RTT=RTT+(1-)M
• D=D+(1-)|RTT-M|
• Timeout=RTT+4D
• Karn’s Algorithm
– Do not update RTT on any segments that
have been retransmitted (difficult to figure out
for what segment the ack is)
TANENBAUM Computer Networks II 40
 TCP Timers (cont’d)
• Persistence Timer
– Used to prevent deadlock when buffer
management messages are lost
• Keepalive Timer
– Check the other side if the line is idle for a
long time
• Timed Wait
– Used to close the connection

TANENBAUM Computer Networks II 41

 Wireless TCP and UDP
• In theory, transport protocol should be
independent of the technology of the
underlying network layer
• However, if the transmission is wireless,
performance of TCP degrades drastically
– Wired connections
• Timeouts are considered to be caused by
congestion not by lost packets
– Wireless Connections
• Timeouts are primarily due to lost packets

TANENBAUM Computer Networks II 42

Wireless TCP and UDP (cont’d)
• Wired TCP Timeout
– Slowdown to alleviate congestion
• Wireless TCP Timeout
– Retransmit as soon as possible
• Indirect TCP
– Split TCP connection into two separate
connections
• Sender-to-base station
• Base station to mobile host
TANENBAUM Computer Networks II 43
 Wireless TCP and UDP
Splitting a TCP connection into two
connections.

TANENBAUM Computer Networks II 44

 Indirect TCP
• Snooping Agent
– Observes and caches TCP segments going
out to the mobile host and acknowledges
coming back from it
– When an ack for a segment to mobile host is
late, it retransmits the segment to mobile host
without telling anything to the source
– Congestion control algorithm will never start
unless there is congestion on the wired part
• Wireless UDP
– Stations should not expect reliability
TANENBAUM Computer Networks II 45
 Translational TCP
• If RPC requires long replies, then UDP is
not suitable and TCP becomes the choice
• However, TCP requires nine packets and
this not efficient
• A variant of TCP called T/TCP
(Translational TCP) solves this problem
– Allows transfer of data during setup

TANENBAUM Computer Networks II 46

 Transitional TCP
(a) RPC using normal TCP.
(b) RPC using T/TCP.

TANENBAUM Computer Networks II 47

 Performance Issues

• Performance Problems in Computer

Networks
• Network Performance Measurement
• System Design for Better Performance
• Fast TPDU Processing
• Protocols for Gigabit Networks

TANENBAUM Computer Networks II 48

 PERFORMANCE ISSUES:
Performance Problems
• Fast line-slow CPU
• Broadcast storm
• Power failure (RARP density when
machines are up)
• Lack of memory allocation
• Timeouts set incorrectly
• Bandwidth-delay product (BDP)
– The receiver window should be at least BDP
• Jitter
TANENBAUM Computer Networks II 49
 Performance Problems in Computer
Networks
The state of transmitting one megabit from San Diego to Boston
(a) At t = 0, (b) After 500 μsec, (c) After 20 msec, (d) after 40 msec.

TANENBAUM Computer Networks II 50

 Measuring Network
Performance
• Make sure that the sample size is large enough
• Make sure that the samples are representative
• Be careful when using a coarse-grained clock
• Be sure that nothing unexpected is going on
during your tests
• Caching can wreak havoc with measurements
• Understand what you are measuring
• Be careful about extrapolating the results

TANENBAUM Computer Networks II 51

 Network Performance
Measurement

The basic loop for improving network

performance.
• Measure relevant network parameters,
performance.
• Try to understand what is going on.
• Change one parameter.
TANENBAUM Computer Networks II 52
 System Design for Better
Performance
Rules:
• CPU speed is more important than network speed.
• Reduce packet count to reduce software overhead.
• Minimize context switches.
• Minimize copying.
• You can buy more bandwidth but not lower delay.
• Avoiding congestion is better than recovering from it.
• Avoid timeouts.

TANENBAUM Computer Networks II 53

 System Design for Better
Performance (2)
Response as a function of load.

TANENBAUM Computer Networks II 54

 System Design for Better
Performance (3)
Four context switches to handle one packet
with a user-space network manager.

TANENBAUM Computer Networks II 55

 Fast TPDU Processing
• Main obstacle is protocol software
• Processing overhead components
– Overhead per TPDU
– Overhead per byte
• Optimization for overhead per TPDU
– Minimize tests if in ESTABLISHED state
– Headers of consecutive data TPDU’s are
almost the same
• Store a prototype header and overwrite the
changing values
TANENBAUM Computer Networks II 56
 Fast TPDU Processing
The fast path from sender to receiver is shown with a
heavy line.
The processing steps on this path are shaded.

TANENBAUM Computer Networks II 57

 Fast TPDU Processing (2)

(a) TCP header. (b) IP header. In both cases, the shaded fields
are taken from the prototype without change.
TANENBAUM Computer Networks II 58
 Optimizations for high speed
networks
• Buffer management
– Avoid unnecessary copying
• Timer Management
– Use linked list of timer events sorted by expiry
time
• At every clock tick, the counter in the head entry is
decremented
– Timer wheel
• More efficient if timer interval is known in advance
TANENBAUM Computer Networks II 59
 Timer
Wheel

TANENBAUM Computer Networks II 60

 Protocols for Gegabit Networks
• 32 bit sequence number is small
• Communication speed is much faster than
computing speed
• Go back n is not good when bandwidth-
delay product is high
• Gegabit lines are delay limited rather than
bandwidth limited
• Variance of packet arrival time may be
very important
TANENBAUM Computer Networks II 61
 Protocols for Gigabit Networks
Time to transfer and acknowledge a 1-megabit file
over a 4000-km line.

TANENBAUM Computer Networks II 62

 Gegabit (cont’d)
• Design for speed not for bandwidth optimization
• Make protocols simple and let the main CPU do
the work
• Reserve necessary sources at the connection
set up time rather than implementing e.g. Slow
start algorithm
• Minimize header length and copy time
• Checksum the header and data separately
• Concentrate on succesful cases rather than
failures

TANENBAUM Computer Networks II 63

 Required Reading
• Tanenbaum Sections
– 6.4
– 6.5
– 6.6

TANENBAUM Computer Networks II 64