UNIT-5
COMPUTER NETWORKING (CN)
ACFW, BHATKAL
Transport
Layer
• Services provided to 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.
• Services provided to 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.
• 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.
• Each transport service has its own interface
• 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
• 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.
• 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 interested in handling 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.
• 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.
Elements of Transport Protocols
1. Addressing
2. Connection Establishment
3. Connection Release
4. Flow Control And Error Control
5. Multiplexing And Demultiplexing
6. Crash Recovery
Addressing
A process on the local host, called a client, needs services from a process usually on
the remote host, called a server.
A remote computer can run several server programs at the same time.
The local host and the remote host are defined using IP addresses.
To define the processes, we need an identifiers, called port numbers.
In the TCP/IP protocol suite, the port numbers are integers between 0 and 65,535 (16
bits).
Socket Addresses
A transport-layer protocol in the TCP suite needs both the IP address and the port number,
at each end, to make a connection.
The combination of an IP address and a port number is called a socket address.
Socket address defines the process uniquely
• Connection Establishment
• Establishing a connection sounds easy, but it is actually surprisingly tricky.
• At first glance, it would seem sufficient for one transport entity to just send
a CONNECTION REQUEST segment to the destination and wait for a
CONNECTION ACCEPTED reply.
• The problem occurs when the network can lose, delay, corrupt, and
duplicate packets.
• This behavior causes serious complications.
Three way handshake
This establishment protocol involves one peer checking with the
other that the connection request is indeed current.
The normal setup procedure when host 1 initiates is shown in Fig. 6-
11(a).
Host 1 chooses a sequence number, x, and sends a CONNECTION REQUEST
segment containing it to host 2.
Host 2 replies with an ACK segment acknowledging x and announcing its own
initial sequence number, y.
Finally, host 1 acknowledges host 2’s choice of an initial sequence number in
the first data segment that it sends.
Now let us see how the three-way handshake works in the presence of
delayed
duplicate control segments.
In Fig. 6-11(b), the first segment is a delayed duplicate CONNECTION REQUEST
from an old connection.
This segment arrives at host 2 without host 1’s knowledge.
Host 2 reacts to this segment by sending host 1 an ACK segment
When host 1 rejects host 2’s attempt to establish a connection
Host 2 realizes that it was tricked by a delayed duplicate and abandons the
[Link] this way, a delayed duplicate does no damage.
• The worst case is when both a delayed CONNECTION REQUEST and an ACK
• are floating around in the subnet.
• This case is shown in Fig. 6-11(c). As in the previous example, host 2 gets a
delayed CONNECTION REQUEST and replies to it.
• At this point, it is crucial to realize that host 2 has proposed using y as the
initial sequence number for host 2 to host 1 traffic, knowing full well that
no segments containing sequence number y or acknowledgements to y are
still in existence.
• When the second delayed segment arrives at host 2, the fact that z
has been acknowledged rather than y tells host 2 that this, too, is an
old duplicate.
• The important thing to realize here is that there is no combination of
old segments that can cause the protocol to fail .
• TCP uses this three-way handshake to
establish connections.
Connection Release
Releasing a connection is easier than establishing one.
There are two styles of terminating a connection:
1. Asymmetric release
2. Symmetric release.
• Asymmetric release is the way the telephone system works: when
one party hangs up, the connection is broken.
• Symmetric release treats the connection as two separate
unidirectional connections and requires each one to be released
separately.
• Asymmetric release is abrupt and may result in data loss.
• Consider the scenario of Fig. 6-12.
• After the connection is established, host 1 sends a segment that arrives
properly at host 2.
• Then host 1 sends another segment.
• Unfortunately, host 2 issues a DISCONNECT before the second segment
arrives.
• The result is that the connection is released and data are lost.
• Imagine that a white army is encamped in a valley, as shown in Fig. 6-
13. On both of the surrounding hillsides are blue armies.
• The white army is larger than either of the blue armies alone, but
together the blue armies are larger than the white army.
• If either blue army attacks by itself, it will be defeated, but if the two
blue armies attack simultaneously, they will be victorious.
• The blue armies want to synchronize their attacks.
• However, their only communication medium is to
send messengers on foot down into the valley,
• where they might be captured and the message
lost
• (i.e., they have to use an unreliable
communication channel).
• The question is: does a protocol exist that allows
the blue armies to win?
• Suppose that the commander of blue army #1 sends a
message reading: ‘‘I propose we attack at dawn on March 29.
How about it?’’
• Now suppose that the message arrives, the commander of
blue army #2 agrees, and his reply gets safely back to blue
army #1.
• Will the attack happen? Probably not, because commander #2
does not know if his reply got through.
• If it did not, blue army #1 will not attack, so it would be
foolish for him to charge into battle.
• In fact, it can be proven that no protocol exists that works.
• Suppose that some protocol did exist.
• What happens if the final message does not get through?
• We just said that it was essential, so if it is lost, the attack does not
take place.
• Since the sender of the final message can never be sure of its
arrival, he will not risk attacking.
• Worse yet, the other blue army knows this, so it will not attack
either.
• In fact, it can be proven that no protocol exists that works.
• Suppose that some protocol did exist.
• What happens if the final message does not get through?
• We just said that it was essential, so if it is lost, the attack does not
take place.
• Since the sender of the final message can never be sure of its
arrival, he will not risk attacking.
• Worse yet, the other blue army knows this, so it will not attack
either.
• just substitute ‘‘disconnect’’ for ‘‘attack.’’
• If neither side is prepared to disconnect until it is convinced that
the other side is prepared to disconnect too, the disconnection will
never happen.
• In Fig. 6-14(a), we see the normal case in which one of the users sends a DR
(DISCONNECTION REQUEST) segment to initiate the connection release.
• When it arrives, the recipient sends back a DR segment and starts a timer, just in case its
DR is lost.
• When this DR arrives, the original sender sends back an ACK segment and releases the
connection.
• Finally, when the ACK segment arrives, the receiver also releases the connection.
• Releasing a connection means that the transport entity removes the information about the
connection from its table of currently open connections and signals the connection’s
owner (the transport user) somehow.
• This action is different from a transport user issuing a DISCONNECT primitive.
• If the final ACK segment is lost, as shown in Fig. 6-14(b),
• The situation is saved by the timer.
• When the timer expires, the connection is released anyway.
• Now consider the case of the second DR
being lost.
• The user initiating the disconnection will not
receive the expected response, will time out,
and will start all over again.
• In Fig. 6-14(c), we see how this works,
assuming that the second time no segments
are lost and all segments are delivered
correctly and on time
• Our last scenario, Fig. 6-14(d), is the same as Fig. 6-14(c) except that now
we assume all the repeated attempts to retransmit the DR also fail due to
lost segments.
• After N retries, the sender just gives up and releases the connection.
• Meanwhile, the receiver times out and also exits.
• While this protocol usually suffices, in theory it can fail if the initial DR and
N retransmissions are all lost.
• The sender will give up and release the connection, while the other side
knows nothing at all about the attempts to disconnect and is still fully
active.
• This situation results in a half-open connection.
• One way to kill off half-open connections is to have a
rule saying that if no segments have arrived for a
certain number of seconds, the connection is
automatically disconnected.
• That way, if one side ever disconnects, the other side
will detect the lack of activity and also disconnect.
• This rule also takes care of the case where the
connection is broken
• Error Control and Flow Control
• Error control is ensuring that the data is delivered
with the desired level of reliability, usually that all of
the data is delivered without any errors.
• Flow control is keeping a fast transmitter from
overrunning a slow receiver.
Flow Control
55
Error Control
Error control at the transport layer is responsible for
1. Detecting and discarding corrupted packets.
2. Keeping track of lost and discarded packets and resending them.
3. Recognizing duplicate packets and discarding them.
4. Buffering out-of-order packets until the missing packets arrive.
Buffering
• Since a host may have many connections, each of which is treated
separately, it may need a substantial amount of buffering for the sliding
windows. (needs buffers for storage)
• The buffers are needed at both the sender and the receiver.
• Certainly they are needed at the sender to hold all transmitted but as yet
unacknowledged segments.
• They are needed there because these segments may be lost and need to be
retransmitted..
• If most segments are nearly the same size, it is natural to organize the
buffers as a pool of identically sized buffers, with one segment per
buffer, as in Fig. 6-15(a).
• Another approach to the buffer size problem is to use variable-sized
buffers, as in Fig. 6-15(b). The advantage here is better memory
utilization, at the price of more complicated buffer management.
A third possibility is to dedicate a single large circular buffer per
connection, as in Fig. 6-15(c).
• Whenever an entity accepts items from more than one source, this is referred to as
multiplexing (many to one).
• The transport layer at the source performs multiplexing
• Whenever an entity delivers items to more than one source, this is referred
to as demultiplexing (one to many).
• the transport layer at the destination performs demultiplexing
CRASH RECOVERY
• If hosts and routers are subject to crashes or connections are long-lived (e.g.,
large software or media downloads), recovery from these crashes becomes
an issue.
• If the transport entity is entirely within the hosts, recovery from network and
router crashes is straightforward.
• The transport entities expect lost segments all the time and know how to
cope with them by using retransmissions.
• A more troublesome problem is how to recover from host crashes.
• Put in more general terms, this result can be
restated as ‘‘recovery from a layer N crash can
only be done by layer N + 1, ’’
• and then only if the higher layer retains enough
status information to reconstruct where it was
before the problem occurred.
• This is consistent with the case mentioned above
that the transport layer can recover from failures
in the network layer, provided that each end of a
connection keeps track of where it is.