THE TRANSPORT SERVICE

➢ To make the issue of transport service more concrete, we will examine two sets of

transport layer primitives.

➢ First comes a simple (but hypothetical) one to show the basic ideas.

➢ Then comes the interface commonly used in the Internet

Services Provided to the Upper Layers

➢ The ultimate goal of the transport layer is to provide efficient, reliable, and cost-

effective data transmission service to its users, normally processes in the application

layer.

➢ To achieve this, the transport layer makes use of the services provided by the

network layer.

➢ The software and/or hardware within the transport layer that does the work is called

the transport entity.

➢ The transport entity can be located in the operating system kernel, in a library

package bound into network applications, in a separate user process, or even on the

network interface card.

➢ The first two options are most common on the Internet.

➢ The (logical) relationship of the network, transport, and application layers is

illustrated in Fig. 6-1.

➢ Just as there are two types of network service, connection-oriented and

connectionless, there are also two types of transport service.

DR V RAMA KRISHNA TOTTEMPUDI 1

 ➢ The connection-oriented transport service is similar to the connection-oriented

network service in many ways.

➢ In both cases, connections have three phases: establishment, data transfer, and

release.

➢ Addressing and flow control are also similar in both layers.

➢ Furthermore, the connectionless transport service is also very similar to the

connectionless network service.

➢ However, note that it can be difficult to provide a connectionless transport service

on top of a connection-oriented network service, since it is inefficient to set up a

connection to send a single packet and then tear it down immediately afterwards.

➢ The transport code runs entirely on the users’ machines, but the network layer

largely runs on the routers, which are operated by the carrier (at least for a wide area

network).

➢ Problems occur, that’s what.

DR V RAMA KRISHNA TOTTEMPUDI 2

 ➢ The users have no real control over the network layer, so they cannot solve the

problem of poor service by using better routers or putting more error handling in the

data link layer because they don’t own the routers.

➢ The only possibility is to put on top of the network layer another layer that improves

the quality of the service.

➢ If, in a connectionless network, packets are lost or mangled, the transport entity can

detect the problem and compensate for it by using retransmissions.

➢ If, in a connection-oriented network, a transport entity is informed halfway through

a long transmission that its network connection has been abruptly terminated, with

no indication of what has happened to the data currently in transit, it can set up a

new network connection to the remote transport entity.

➢ Using this new network connection, it can send a query to its peer asking which data

arrived and which did not, and knowing where it was, pick up from where it left off.

➢ In essence, the existence of the transport layer makes it possible for the transport

service to be more reliable than the underlying network, which may not be all that

reliable.

➢ Furthermore, the transport primitives can be implemented as calls to library

procedures to make them independent of the network primitives.

➢ The network service calls may vary considerably from one network to another (e.g.,

calls based on a connectionless Ethernet may be quite different from calls on a

connection- oriented network).

DR V RAMA KRISHNA TOTTEMPUDI 3

 ➢ Hiding the network service behind a set of transport service primitives ensures that

changing the network merely requires replacing one set of library procedures with

another one that does the same thing with a different underlying service.

➢ Having applications be independent of the network layer is a good thing.

➢ Thanks to the transport layer, application programmers can write code according to

a standard set of primitives and have these programs work on a wide variety of

networks, without having to worry about dealing with different network interfaces

and levels of reliability.

➢ If all real networks were flawless and all had the same service primitives and were

guaranteed never, ever to change, the transport layer might not be needed.

➢ However, in the real world it fulfills the key function of isolating the upper layers

from the technology, design, and imperfections of the network.

➢ For this reason, many people have made a qualitative distinction between layers one

through four on the one hand and layer(s) above four on the other.

➢ The bottom four layers can be seen as the transport service provider, whereas the

upper layer(s) are the transport service user.

➢ This distinction of provider versus user has a considerable impact on the design of

the layers and puts the transport layer in a key position, since it forms the major

boundary between the provider and user of the reliable data transmission service.

Transport Service Primitives

➢ To allow users to access the transport service, the transport layer must provide some

operations to application programs, that is, a transport service interface.

DR V RAMA KRISHNA TOTTEMPUDI 4

 ➢ Each transport service has its own interface. In this section, we will first examine a

simple (hypothetical) transport service and its interface to see the bare essentials.

➢ In the following section, we will look at a real example.

➢ The transport service is similar to the network service, but there are also some

important differences.

➢ The main difference is that the network service is intended to model the service

offered by real networks, warts and all.

➢ Real networks can lose packets, so the network service is generally unreliable.

➢ The connection-oriented transport service, in contrast, is reliable.

➢ Of course, real networks are not error-free, but that is precisely the purpose of the

transport layer—to provide a reliable service on top of an unreliable network.

➢ As an example, consider two processes on a single machine connected by a pipe in

UNIX (or any other interprocess communication facility).

➢ They assume the connection between them is 100% perfect.

➢ They do not want to know about acknowledgements, lost packets, congestion, or

anything at all like that.

➢ What they want is a 100% reliable connection.

➢ Process A puts data into one end of the pipe, and process B takes it out of the other.

➢ This is what the connection-oriented transport service is all about—hiding the

imperfections of the network service so that user processes can just assume the

existence of an error-free bit stream even when they are on different machines

➢ As an aside, the transport layer can also provide unreliable (datagram) service.

DR V RAMA KRISHNA TOTTEMPUDI 5

 ➢ However, there is relatively little to say about that besides ‘‘it’s datagrams,’’ so we

will mainly concentrate on the connection-oriented transport service.

➢ Nevertheless, there are some applications, such as client-server computing and

streaming multimedia, that build on a connectionless transport service, and we will

say a little bit about that later on.

➢ A second difference between the network service and transport service is whom the

services are intended for.

➢ From the perspective of network endpoints, the network service is used only by the

transport entities.

➢ Few users write their own transport entities, and thus few users or programs ever

see the bare network service.

➢ In contrast, many programs (and thus programmers) see the transport primitives.

➢ Consequently, the transport service must be convenient and easy to use.

➢ To get an idea of what a transport service might be like, consider the five primitives

listed in Fig. 6-2.

➢ This transport interface is truly bare bones, but it gives the essential flavor of what

a connection-oriented transport interface has to do.

DR V RAMA KRISHNA TOTTEMPUDI 6

 ➢ It allows application programs to establish, use, and then release connections,

which is sufficient for many applications.

➢ To see how these primitives might be used, consider an application with a server and

a number of remote clients.

➢ To start with, the server executes a LISTEN primitive, typically by calling a library

procedure that makes a system call that blocks the server until a client turns up.

➢ When a client wants to talk to the server, it executes a CONNECT primitive.

➢ The transport entity carries out this primitive by blocking the caller and sending a

packet to the server.

➢ Encapsulated in the payload of this packet is a transport layer message for the

server’s transport entity.

➢ A quick note on terminology is now in order. For lack of a better term, we will use

the term segment for messages sent from transport entity to transport entity.

➢ TCP, UDP and other Internet protocols use this term. Some older protocols used the

ungainly name TPDU (Transport Protocol Data Unit).

➢ That term is not used much any more now but you may see it in older papers and

books.

➢ Thus, segments (exchanged by the transport layer) are contained in packets (which

are exchanged by the network layer).

➢ In turn, these packets are contained in frames (exchanged by the data link layer).

➢ When a frame arrives, the data link layer processes the frame header and, if the

destination address matches for local delivery, passes the contents of the frame

payload field up to the network entity.

DR V RAMA KRISHNA TOTTEMPUDI 7

 ➢ The network entity similarly processes the packet header and then passes the

contents of the packet payload up to the transport entity.

➢ This nesting is illustrated in Fig. 6-3.

➢ Getting back to our client-server example, the client’s CONNECT call causes a

CONNECTION REQUEST segment to be sent to the server.

➢ When it arrives, the transport entity checks to see that the server is blocked on a

LISTEN (i.e., is ready to handle requests). If so, it then unblocks the server and sends

a CONNECTION ACCEPTED segment back to the client.

➢ When this segment arrives, the client is unblocked and the connection is established.

➢ Data can now be exchanged using the SEND and RECEIVE primitives.

➢ In the simplest form, either party can do a (blocking)RECEIVE to wait for the other

party to do a SEND.

➢ When the segment arrives, the receiver is unblocked.

➢ It can then process the segment and send a reply.

➢ As long as both sides can keep track of whose turn it is to send, this scheme works

fine.

DR V RAMA KRISHNA TOTTEMPUDI 8

 ➢ In the transport layer, even a simple unidirectional data exchange is more

complicated than at the network layer.

➢ Every data packet sent will also be acknowledged (eventually).

➢ The packets bearing control segments are also acknowledged, implicitly or explicitly.

➢ These acknowledgements are managed by the transport entities, using the network

layer protocol, and are not visible to the transport users.

➢ Similarly, the transport entities need to worry about timers and retransmissions.

➢ None of this machinery is visible to the transport users.

➢ To the transport users, a connection is a reliable bit pipe: one end stuffs bits in and

they magically appear in the same order at the other end.

➢ This ability to hide complexity is the reason that layered protocols are such a

powerful tool.

➢ When a connection is no longer needed, it must be released to free up table space

within the two transport entities. Disconnection has two variants: asymmetric and

symmetric.

➢ In the asymmetric variant, either transport user can issue a DISCONNECT primitive,

which results in a DISCONNECT segment being sent to the remote transport entity.

➢ Upon its arrival, the connection is released.

➢ In the symmetric variant, each direction is closed separately, independently of the

other one.

➢ When one side does a DISCONNECT, that means it has no more data to send but it is

still willing to accept data from its partner.

➢ In this model, a connection is released when both sides have done a DISCONNECT.

DR V RAMA KRISHNA TOTTEMPUDI 9

 ➢ A state diagram for connection establishment and release for these simple primitives

is given in Fig. 6-4.

➢ Each transition is triggered by some event, either a primitive executed by the local

transport user or an incoming packet.

➢ For simplicity, we assume here that each segment is separately acknowledged.

➢ We also assume that a symmetric disconnection model is used, with the client going

first.

➢ Please note that this model is quite unsophisticated.

➢ We will look at more realistic models later on when we describe how TCP works.

DR V RAMA KRISHNA TOTTEMPUDI 10