Chap.

3: Transport Layer

The design of a transport protocol is more challenging than

the design of a data link protocol due to a major difference
between the environments in which the two layers operate.

• Two data link protocol entities communicate directly via

a physical channel.

• At the transport layer, the protocol entities communicate

through a set of networks (not always known).

1. Introduction
The transport layer aims at ensuring end to end reliable data
transfer.

In order to do so, transport protocol performs is function on

top of a network layer.

The complexity of the transport layer depends on the service

provided by the network layer.

Virtual Circuit Service:

• The messages are delivered in order from sender to
receiver, without error, loss, or duplication.
• The transport protocol becomes relatively simple.

Datagram Services:
• Packet can be lost, corrupted, etc. It is up to the hosts
to make sure that messages are delivered in order
without loss, error, or duplication.

1
 • The transport protocol becomes complex and
sophisticated.

OSI defines 5 classes of transport protocols: TP0 to TP4.

TP0 is supposed to work on top of a perfect network, while
TP4 is for the worst kind of networks.

Simplified view of protocol architecture (importance of

transport layer)

2
2. Quality of Service
QoS can be characterized by a number of specific
parameters. OSI transport service allows the applications to
specify preferred, acceptable, and unacceptable values for
these parameters at the time a connection is set up.

It is up to the transport layer to examine these parameters,

and depending on the kind of network services available to
it, determine whether it can provide the required service.

1. Connection establishment delay

2. Connection establishment failure probability

3. Throughput

4. Transit delay

5. Residual error rate

6. Transfer failure probability

7. Connection release delay

8. Connection release failure probability

9. Protection

10. Priority

3
3. Transport Service
Provided to the session layer.

Connection-less Service:

Service Primitives:
T - UNITDATA.request (callee, caller, qos, user_data)
T - UNITDATA.indication (callee, caller, qos, user_data)

Connection Oriented Service:

Three phases:
• Transport Connection (TC) establishment
(This is a logical connection)
• Data Transfer
• Transport Connection Release

Service Primitives:
T - CONNECT.request (callee, caller, exp_wanted, qos, user_data)
T - CONNECT.indication (callee, caller, exp_wanted, qos, user_data)
T - CONNECT.response (qos, responder, exp_wanted, user_data)
T - CONNECT.confirm (qos, responder, exp_wanted, user_data)
T - DISCONNECT.request (user_data)
T - DISCONNECT.indication (reason, user_data)
T - DATA.request (user_data)
T - DATA.indication (user_data)
T - EXPEDITED - DATA. request (user_data)
T - EXPEDITED - DATA. indication (user_data)

4
Terminology:
• Callee: Transport address (TSAP) to be called
• Caller: Transport address (NSAP) used by calling
transport entity
• Exp_wanted: Boolean flag specifying whether
expedited data will be sent
• Qos: Quality of service desired
• User_data: 0 or more bytes of data transmitted but
not examined
• Reason: Why did it happen
• Responder: Transport address connected to at the
destination

Do in class: Explore a few scenarios for connection phase

(successful and un-successful), disconnection, data phase
…

4. Transport Protocol
Two transport layer entities communicate with each other by
exchanging TPDUs.

The different TPDU types necessary to implement the basic

set of services introduced earlier are as follows:

CR: Connection request

CC: Connection Confirm
DR: Disconnect request
DC: Disconnect confirm
DT: Data
AK: Acknowledgement

5
The use of each TPDU will be described in relation to the
various services previously described.

Do in class: Revisit some of the service scenarios and

make them protocol scenarios…

5. Examples of Transport Protocols

In this section we will look at specific transport protocols
from the TCP/IP architecture.

5.1 (Transmission Control Protocol) TCP

Connection oriented, reliable end to end.

5.1.1. Header format

Go through the header format ….

6
5.1.2. TCP connection establishment
• Allow each end to now the other exists and willing to
communicate
• Negotiation of optional parameters for the
communication
• At both ends: Allocation of transport entity resources
done at this time.

First attempt to establish a connection: 2-way handshaking

States of TCP entities: Active Open vs. Passive Open

Actually A sends SYN j and B sends SYN j …

7
2-way handshake Æ obsolete SYN Æ problems …

Check the following scenario …

SYNi has been traveling in the Internet for a while and

suddenly shows up at the B side.

8
There is a need for 3-way handshaking

9
5.1.3. Connection Termination

Either or both sides can initiate the termination of the connection.

Termination can be abrupt or graceful (must accept incoming data
until FIN received)

One scenario:

On one side:
• A Transport Service (TS) user calls Close request primitive
• Transport entity (TE) sends FIN segement, requesting
termination
• Connection on this side is placed in FIN WAIT state
• Continue to accept data from the other TE and deliver data to
user
• User does not send any more data from this side
• When FIN received from the other TE, informs user and closes
connection

The other side:

• The TE receives FIN segment
• Informs TS user, and goes into CLOSE WAIT state
• Continues to accept data from TS user and transmit it
• When TS user issues CLOSE primitive, TE sends FIN

Now, the connection is closed

5.1.4 TCP Entity state diagram: state and

transitions …

10
11
5.1.5. Flow Control
Fixed size Sliding Window does not work properly, because
of unreliable networks, and variable conditions for the TCP
entity …

Credit scheme: make the size of the window variable Æ

receiver can acknowledge and still can restrain the sender
window, because receiver is not ready to receive all what
sender can send after receiving the ACK.

Credit Scheme:

Data transfer as a stream of octets numbered modulo 223

Flow control by credit allocation of number of octets

12
5.1.6. Error Detection
Checksum Algorithm is used: It is more adapted to software
implementations than CRC.

Checksum not only for the header, but for the whole
segment.

5.1.7. Congestion Control (Issues)

We will discuss a few issues here:

Retransmission timer management

• Estimate round trip delay by observing pattern of delays
• Set time to value somewhat greater than estimate
• Simple average
• Exponential average
• RTT Variance Estimation (Jacobson’s algorithm)

Window Management

• Slow start
1. awnd = MIN[credit, cwnd]
2. Start connection with cwnd=1
3. Increment cwnd at each ACK, to some max
Problems …

• Dynamic windows sizing on congestion

1. When a timeout occurs, set slow start threshold to half
current congestion window: ssthresh=cwnd/2
2. Set cwnd = 1 and slow start until cwnd = ssthresh
Increasing cwnd by 1 for every ACK

3. For cwnd >=ssthresh, increase cwnd by 1 for each RTT

13
5.2 User Datagram Protocol (UDP)
Connectionless service: Segments may arrive in disorder,
corrupted, and forwarded to the application as they
arrive.

Some applications such as Simple Network Management

Protocol (SNMP) are implemented on top of UDP.

Reliability is not an important criterion for these applications.

Fewer overheads than TCP.

Header format

Checksum for header only.

Very simple interface for programming …

Socket programming: see project notes for more details.

14
15