Session and presentation layers in the OSI stack can be considered fancy layers, as they are known only by a small part of Network Engineers. This is probably because all their features blend either in transport-layer protocols or in application-layer protocols. However, with this article, you will discover all the beauty of these two layers, learning what they do and how they are implemented.
UDP limitations
Back in the CCNA course, we found out that the only place we can see the session and presentation layers truly implemented is when they are based on UDP transport. UDP leaves some room to these two layers (if compared to TCP) because it is extremely simple and lacking features. These features can be then implemented in upper layers individually, adding modularity. Just to refresh your mind, UDP has the following two limitations.
UDP, all by itself, do not order packets, and therefore the receiver cannot guess in which order they were sent originally. Moreover, it is not reliable, what is lost is just lost, no UDP component will trigger a re-transmission. Adding these features, however, would increase the complexity of the algorithm behind UDP running on hosts and will add extra fields in the UDP header sent with every segment. All of that, and specifically the extra bytes added in the segment’s header, is called overhead: the extra amount of information that allows application data to be delivered correctly. Our goal is to obtain the delivery of application data as we want it with the least overhead possible.
In the article about advanced TCP, we already explained the ways we can reduce the TCP overhead using selective ACK and header compression, but all of these complex items cannot reduce the TCP header to the size of a UDP header. Instead, with UDP we follow a different approach: we start from almost no features (only delivery to the correct application using port numbers) and we add the features we need in upper layers.
Session layer
The session layer is the one implementing one-to-one application sessions: it defines the re-transmission of data, the segment ordering method, and control the communication in general. All these features are covered by TCP for applications using that transport protocol, but applications that leverage UDP have to implement these features autonomously (within the application) or rely on an extra protocol specifically sitting at the session layer. Many applications (such as TFTP) rely on the first option, while the second alternative is the privileged one for VoIP. For VoIP traffic, the protocol we rely on for the session is the Real-time Transport Protocol (RTP). As we are talking about applications using UDP as their underlying transport, spending some time on RTP is certainly well-worth since Voice and Video are the king applications among all UDP-based applications.
The RTP header in the picture is inserted just after the UDP header, and add extra features such as the reordering of segments and their timing, which are extremely important for an application that must run real-time. Here’s the explanation of its fields.
- Version – Version of RTP, the up-to-date one is version 2
- P (Padding) – Flag used to indicate whether padding is present or not in the segment
- X (Extension) – Flag used to indicate whether extension header is present or not
- CC (CSRC count) – Number of CSRC identifiers contained in the header
- M (Marker) – Flag that, if set, indicates that this segment has some special relevance for the application
- PT (Payload Type) – Indicates the type of RTP payload (e.g. for VoIP/Video stream)
- Sequence number – Used from the receiver to reorder packets, incremented by one each segment sent
- Timestamp – Time the segment was created, used to allow the receiver to play the content of the segment (assuming that it is audio or video) at the proper interval
- SSCS – Synchronization Source Identifier, identifies a stream of UDP/RTP segments
- CSRC – Contributing Source IDs, indicates the source of the audio stream, multiple CSRCs can be specified if there are multiple sources (e.g. in a three-party conference)
- Header extension – extra header, optional and profile-specific
These fields are the minimum needed to allow the transmission and are specifically designed for real-time streams, audio, and video mainly. Looking at the header, you can still find the Sequence number as in TCP, but no acknowledgment number. This is because RTP allows the receiver to reorder segments, but not to arrange a re-transmission. This behavior is purposefully designed this way, as a VoIP call or a video stream needs to be delivered now. In case something is lost, there is no time to re-transmit it, the show must go on. If we re-transmit it, it would arrive too late so there is no point in the retransmission at all. Another interesting field adding a feature UDP is lacking is the timestamp, with that field you can know when the content was generated and reproduce the sound and video at the same interval it was generated. Otherwise, you would have audio and video streams increasing and decreasing speed according to the network connection available.
A question I’ve been asked several times when talking about reordering packets is “How they arrive in the wrong order in the first place?” and this is surely a good question. The answer has a lot to do with routing, so it lays at the Network Layer in the OSI Stack. Routers work independently from the upper layer protocols and applications, they run based on IP addressing and routes. It might happen that a node fails over the network and traffic takes a different path to avoid falling on the faulty link, or simply a router discovers a better path to a destination. Since all of this happens dynamically, at a given moment the traffic might go over a link and one second later over another. Not all links have the same speed, so it is possible that a segment sent later but over a fast link will arrive before a segment sent previously but on a slow link. Let’s have a look at the following picture.
Edge devices (computers, servers) do not know about the network infrastructure, so they just know that there is the possibility that segments are disordered during the transmission by taking different ways. Because of that, they have to implement mechanisms for reordering. Reordering is crucial to almost any application, to transfer a file we need to know the order of its part, and to transfer audio stream we need to know in which order to play the sounds.
Presentation for Real-Time applications
The presentation layer is probably the most mysterious one. This is because almost no application implements it, neither among the UDP applications. What this layer does, is to define how data should be presented to the application. Once again, coming to rescue us we have VoIP and Video stream, the ones leveraging this layer the most. Basically, when you make a VoIP call there are some parameters involved in the audio stream, such as the bitrate or the compression rate just to name a few. To have the smoothest audio stream possible, all the parties involved must agree on how they are going to exchange audio and video. RTP is the common ground that cannot be changed, here we are talking about how to write the payload of the RTP segment. In other words, we are defining the codec.
Some codecs may privilege the compression, using less bandwidth but more computational resources, others may use a lot of bandwidth but almost no computational resources or other ones require fewer resources sacrificing audio quality. No choice can be right on all occasions, the best codec for any situation depends on your needs.
Session and presentation layers in the shadow
We now know what these two layers are truly about, but let’s take a moment to check out why they are not famous like the other OSI layers. Even previously we had the chance to understand how there is almost no need to implement them, as their features are covered elsewhere, however it is time to give some examples, as in the following picture.
What the picture says is also listed below in a little more detail.
- HTTP (Hyper-Text Transfer Protocol) – Used to transfer web-pages, the session layer is handled by TCP while there is no need for a presentation layer as the information is sent in simple text or raw binary
- FTP (File Transfer Protocol) – Used to transfer files to and from a server, the session layer is handled by TCP while there is no need for a presentation layer as the information is sent in raw binary
- SMTP (Simple Mail Transfer Protocol) – Used to send emails from a server o another, the session layer is handled by TCP while there is no need for a presentation layer as the information is sent in simple text
- SSH (Secure Shell) – Used to connect to a remote device and control it via textual commands using encryption, the session layer is handled by TCP while there is no need for a presentation layer as the information is sent in simple text
- IMAP (Internet Message Access Protocol) – Used to connect to an email server and check emails, the session layer is handled by TCP while there is no need for a presentation layer as the information is sent in simple text
- VoIP (Voice over IP) – This is not a real protocol, but instead a type of application, RTP manages the session layer while the presentation layer exists and is managed at the application layer
This article was really lightweight, as UDP is. With this knowledge, you know all the differences between UDP and TCP and you are ready to discuss the technologies implemented in a network to support modern applications. In the following articles, we will start to see some application layer protocols before we can dive into the configuration items.
