The transport Layer
The Transport Layer
The transport layer is the secretary of the application layer. In most of the cases, it provides
a sense of responsibility to the actual communication by deploying various techniques.
The jobs of transport layer include direct communication to the transport layer at the other
end. We have already seen that the secretary in our example sends a letter and receives an
acknowledgement to confirm to the manager that the job is done.
Suppose we are using an application like Telnet (technically called the Telnet client).
When we press ls (this is a command to list all the files on the remote Telnet server running
Linux or UNIX), Telnet passes on that command to the TCP process running on our machine.
The TCP process running on our machine establishes a connection and sends the message
is to the TCP on the other end", and gets the acknowledgement back. When the Telnet
server sends a list of files to us using the TCP connection, our TCP process sends the
acknowledgement back and passes on the content (the list of files) to our Telnet client so
that we can see the list on our screen.
For data transmission, usually a connection-oriented service is preferred, but in case
of real-time transmission, particularly live audio or video, it is essential to have a connectionless
service. Here the transport layer is not supposed to provide connection-oriented, reliable
service to the application layer. Why? We will find the answer in the following paragraphs.
The transport layer ensures reliability by employing a simple technique of timing out
and retransmission. Let us try to understand the same using an example.
Suppose A is sending a file to B. The file contains five paragraphs. The paragraphs are
numbered as I to 5. Suppose A starts sending the file at time. Thus the TCP process running
at that place receives the file at time / from our application. Suppose at the same time, the
TCP process of our machine sends the first paragraph to the other end. After a time delay,
of Ar, the second paragraph is sent and so on. The TCP, after sending each paragraph,
starts a timer. The value of timer indicates the time when the acknowledgement of the paragraph
is expected. The timer value is decided by the TCP using a well-designed algorithm and it is usually a good enough estimate of the round-trip time to other end and gets a rise, it is always via all a layers below it and all layers up to the transport r of the receiving party
Suppose the round-trip time is calculated as x. the timer value is set to (usually) 7+ 2x for the first packet and r+&+2x for the second packet and so on. The timer value is more than the actual round-trip time (we have unnecessary retransmission in case of negligible delays. If the acknowledgement does not come back by that time, the timer is said to expire and the TCP process retransmits that paragraph (without consulting the sending application, FTP in our case).
There can be various reasons for no receipt of acknowledgement in time. It is possible the paragraph gets lost in transit and the TCP process at the other end has not received it at all. So obviously there would be no acknowledgment. The other possible reason is that is that neither the paragraph nor the process has received the paragraph and sent an acknowledgement as well, but the acknowledgement is lost in transit. The third may be the case that either the paragraph possibility the acknowledgement of the transmission is lost. It may took more time in reaching took more time in reaching the s e receiver or the acknowledgement us. It can occur due to an accidental congestion in the network. Our timer, without really knowing about dusy, has timed out waiting for the acknowledgement.
Now assume that the 3 paragraph is lost. It is retransmitted after the 5 paragraph as the timer expires just when the 5 paragraph is transmitted Now we are sending the 4th paragraph after retransmitted 3 paragraph and the reciver is receiving that. If the receiver presents the paragraphs in the order in which they arrived, then the user will get the one and similarly the 3 paragraph will be presented after the 5" one. This might To avoid this situation, the receiver should collect all the paragraphs initially, create chaos and then give it out to the user. This is a usual mechanism for file arrange thein order transfer (FTP). remote login (Telnet), or even Internet browsing (HTTP) to provide reliability in data transfer Data transmission using TCP automatically ensures retransmission of those data which has not been delivered.
The mechanism of resending the missing data later does not work well in case of real time audio and video. You have to display each video frame immediately when it reaches to make the movie look continuous What happens if a frame or two is missed? Can we display them later? The best option is to skip them! Similarly in am audio transfer, if a word of two is lost in transit, just keep on listening to other words after that! A human viewer or listener has a great ability to pick up what is missing in the presentation. If in a live video, a frame of a sequence of frames is missed for a short period, than the user can always can the missing content from the context. There for, it is OK if the lost data is kept lost. If we provide retransmission and display frame at a later time, then it will create more confusion.
Let us take an example to reinforce the issue. Suppose in a cartoon movie, Mickey Mouse is shown moving from left to right. There is a creature sitting in the middle of the screen. Frame by frame, Mickey is coming closer to that creature. In one of the frames, Mickey kicks that creature, the next frame shows the creature in the sky, and the next sequence shows the creature falling on top of Mickey. Now assume the frames are sent one by one and the kicking frame is lost. Then the viewers will automatically assume that the creature must have been kicked. It is absolutely fine till now. If the kicking frame is retransmitted, then we have a sequencing problem. If Mickey is shown kicking that creature after the creature falls down, then it will create a confusion in the minds of the viewers as to how Mickey came out from beneath the crashed creature and kicked it. So it is better not to transmit the lost frame and keep it lost. Now the question arises-if we do not need retransmission of lost data, then what is the necessity to have timers and count the number of transmitted frames? If nothing is required, TCP becomes an overhead.
For all such cases, UDP (User Datagram Protocol, an alternative to TCP as a transport layer protocol in Internet) is preferred. UDP is a protocol which skips a few checks that TCP normally does and it is comparatively lightweight. Almost all real-time transmissions use UDP as their transport layer protocol.
Thus we have two different protocols at the transport layer One which provides a connection-oriented service over a connectionless network layer (TCP over IP) and another which provides a connectionless service over a connectionless network layer (UDP over IP). Both these protocols are representatives of the two different possible transport layer 15 services. The application layer is responsible to model applications written by the user. So when two different transport layers are provided, an application writer (a programmer) can have two choices for the application. The TCP/IP model provides just that.
In the OSI model, the network layer is where the choice is provided. It is an interesting case. In the OSI protocol stack, a network layer can be either connection-oriented or connectionless. Thus the data transfer can be done either way. It gives a choice to the service provider (ISP). He can provide either a connectionless data transfer (like IP) or a connection-oriented transfer (like ATM). Unfortunately, the choice in this case is not directly given to an application. The transport layer has a choice of selecting a network layer, but
an application layer does not have a choice. What is the advantage of providing two different types of network layer? Why were they provided? It is because the ISP gets the advantage of choosing between two services. He can either pick the service he prefers or provide both the services.
Is there any advantage to have two different network layers? There does not seem to be any. Then the question is, why was it provided in the OSI model? It is because the OSI model was influenced by telephone companies and therefore it provided only connection oriented transfer at the network layer. So the data transfer is billed on the basis of the time of connection rather then the volume of data. As this mechanism failed and the connectionless mechanism of the TCP/IP model became successful, some of the committee members demanded for the connectionless version of the network layer. It was provided as an addition to the original connection-oriented scheme:
The transport layer does one more important job. There can be multiple applications running on our machine, all of them taking services of the same transport layer. (Single secretary is being shared by multiple managers!) In such cases, it is important to track the requirements of each applications and provide requisite services accordingly. This process: is known as multiplexing. It is important to note that this issue arises in other layers as well, but the amount, the complexity, and the dynamism in numbers is much more in the transport layer as compared to others.
The transport layer does almost everything a data link layer does. The only difference.