22 Transport layer services
Prof. Bhushan Trivedi
Introduction
After completing the network layer, we will now look at the transport layer. The Internet transport layer has two protocols which are widely used, the TCP and the UDP. However, there is a third protocol called SCTP which presents a better design for multimedia solutions is not much used and we will not discuss that further here. UDP is a no-frills protocol which does not provide any service rather than sending and receiving segments. The TCP is used by most of the applications that we use in our day to day operations. We will describe services provided by the transport layer in this module, which basically includes all services provided by the TCP. We will also look at some services which TCP fails to provide but really needed. We will look at how the Internet solves this issue by extending the transport layer functionality using other protocols in conjunction with the TCP.
Transport layer services
TCP/IP model offers two choices to applications, for application demanding reliable, stream like (what is sent is delivered in the same order, as is) service, TCP is used. For applications demanding real time, no-retransmission type service, UDP is used. There is no service for multimedia traffic. UDP provides no-frills service which is augmented by some application layer protocols to provide services to multimedia traffic. SCTP is actually designed to bridge that gap but most of the operating systems do not yet provide support for SCTP so it is not in real use yet. Our major discussion in this module is, thus, on TCP services. You may refer to Reference-2 for learning more about SCTP.
The transport layer services are divided into four categories for our convenience. Figure 24.2 describes those four categories.
Figure 24.2 Types of transport layer services
Delivery based services are designed to provide better delivery to the recipient. TCP connection needs to adjust as per the connecting line, sender and receiver conditions and network load, next type of services manage them. The performance of the TCP process and connection management result into better application services and thus user satisfaction. There are few other services which we have clubbed under miscellaneous services. Let us learn about each of them one after another.
Let us begin with delivery related services.
Delivery related services
Many applications, including a file transfer or web access, demands the data to reach the recipient as it was sent by the sender. Even if the content is altered in transit, the transport layer should make sure that the content is not delivered in invalid form. TCP handles that problem by using a method called checksum we looked at while discussing data link layer and error handling methods. The receiver TCP does not respond back with proper ack when checksum do not match and the sender TCP is forced to resend that segment. This service is called reliable delivery. The reliable delivery is provided using another service called retransmission.
The TCP also makes sure that the line is completely utilized. That means, when the line is free, it sends as much data it can and when the line is constrained, it reduces its speed. When the line is free, the ack comes back fast while the line is congested, the ack takes some time to arrive. The TCP is good enough to adjust its retransmission timer as per speed of arriving of ack.
TCP also provides a guarantee to deliver the segments in the order that was sent. We know that receiver window is designed to provide this service. All out of order frames are kept on hold until proper segment in order arrives. The application running above TCP always receives segments in the order sent by the sender, independents of actual order in which they arrive.
UDP provides provisioning for real-time delivery as it does not offer retransmission and no holding back to reduce its speed. TCP, as soon as retransmission occurs, assumes segment loss and reduce its speed. Such a behavior does not suit the real-time sender who prefers a segment lost as compared to slowing down the transmission. In the case of congestion, if a few frames are lost, the human receiver can still gather the meaning of transmission. He would be unhappy if the video slows down and look jittery.
In some cases, quality of delivery is equally important. Consider a remote medical assistance problem. An image of an X-ray is sent over to a doctor to decide whether the patient is to be operated or requires an urgent medical assistance. The X-ray image must not be degraded when sent over. The doctor won’t appreciate a blurred image or an image with less resolution.
Connection related services
Managing connections at the transport layer is one of the most complicated tasks. The transport layer might have no connection at one point in time and have hundreds of connections at another moment1. Not only that, different types of connections demand different services. For example, a file download connection demands high bandwidth solution and can accept the little additional delay. On the other hand, a remote login connection demands minimum delay and can sustain low bandwidth. TCP tries to provide a few services related to connection related problems. Let us try to look at some of the most crucial services. Figure 22.4 lists those services.
The first such service is called optimum utilization of bandwidth. TCP increases and reduces its sender’s window based on the traffic as we have learned in module 15. TCP also makes sure that enough number of data is accumulated before sending it over. Every segment sent has at least 20 byte TCP and a 20 byte IP header apart from MAC layer headers, making it unacceptable if of a very small size of data within. Thus TCP normally buffers incoming data and sends only when the buffer is full. Unfortunately, such a behavior tends to disfavor interactive applications like Telnet which sends small data like ‘ls’ and ‘ps’ etc. and expects an almost immediate response. TCP is smart enough to even handle that case. For interactive applications, it smartly sends data so the user does not feel starved of attention and does not feel that system is slowed down.
1 Consider a government site where the results are published on stipulated time. There may be 10 connections before that stipulated period and then suddenly increased to thousands of connections. Another example is a site showing cricket scores. During an India-Pakistan match, the connections increase to millions which may be thousands otherwise.
Interestingly, a programmer can choose either TCP or UDP depending on his requirements. Such a flexibility is indeed a very clever move by the designers of the Internet. One size does not fit all and a single solution does not work for all, TCP and UDP provides a choice to the programmer. So if you want “a service which sends my data at the other end, maintains the order of the items that I sent, manage if there is an error in the middle, retransmit if need be but make sure to check whatever I sent is received intact” you can use TCP and if you ask for “give me a service without any fuss, send data if you can with minimum overhead, I will manage the rest myself” you can use UDP.
Other two services, multiplexing and process level addressing is already discussed in module 6 and thus we will not discuss that further here.
TCP is the first end-to-end layer. Anything which is sent at the transport layer is only opened and looked at by the final recipient only. Checking if the segment is received intact at the other end, TCP deploys the checksum method. The receiver can check if the segment is erroneous and invite sender TCP to retransmit. This is an example of end to end service. Flow control, which we have listed as a separate service, also is one type of end to end service. We have mentioned earlier that TCP provides flow control using window advertisement. Figure 24.5 indicates how TCP does so.
The sender sends 2k while the receiver has only 6k free. After receiving 2k, receiver TCP can accept only 4k now, so he advertises so. When the sender sends 3k in the next cycle, he is informed that only 1k is available at the receiver. When the sender sends 1k in the next cycle, the receiver is in no position of receiving any data from the sender on this connection and he sends back a zero window advertisement. Only when the application reads 3k, receiver allows the sender to send 3k of data by sending a nonzero ack. You can easily see how the receiver controls the process not to get swamped by the sender blasting at the full speed.
Once we have looked at connection related services, it is time for performance related services.
Performance related services
Performance related services are critical for the processing of TCP process. The process must make sure three things, as mentioned as different services in the figure 24.6.
Buffer management is the first such service. TCP has multiple connections open at any given point of time. The number of connections varies every moment as well as the memory and processing requirements of those connections. Buffer management deals with those dynamic requirements. It is also possible that connections go down once in a while and leaves the communicating TCP processes in a limbo. One of the jobs of TCP is to make sure to recover from such connection crashes. Window management which we looked at in module 15 also is a critical point in maintaining required performance.
Miscellaneous services
We have classified three services together under this head.
The first such service is related to handling multiple connections together. TCP, as mentioned before might have varieties of connections and a dynamic number of them at any given point of time. The connection management part manages connections, their status and related information in a separate database. The other service provided by TCP is related to timers, we have already seen TCP transmission timer management in module 15.
Along with retransmission, there are other timers used by TCP as well. We will look at them later in module 25. Another critical job of TCP to manage congestion, which will be covered in subsequent modules.
Services Not provided by TCP
TCP was designed in the late 70s. It is still running but in a radically different environment than for which it was designed. Today’s transport layer demands a few additional services which TCP does not supply. Let us try to brief about those services.
Session control enables us to resume that session. For example, while downloading a file, if the connection is closed and we need to restart, if session control is enabled we can restart from the place it stopped. TCP does not provide session control as it demands to store a lot of other information about the connection. Storing and processing such information is a huge overhead which outweighs the advantages of the session control.
The other such service is to provide encryption and authentication from sender’s TCP process to receiver’s TCP process. Current users demand such services and an extension to TCP called TLS (Transport Layer Security, the older version is known as SSL or secure socket layer) is used in combination with TCP. There are few other services like a user conversing over a video conferencing demand a sustained bandwidth for a specific period, or the time difference between two consecutive packets should not increase beyond 500 ns, are expected by some applications. TCP cannot provide such service. Some protocols like RTP (Real Time Protocol) and few other protocols are designed to provide some subset of these services.
When a landline or mobile phone is used for voice communication, a word spoken and a pause between are maintained as it is. When we use Skype or WhatsApp calling, such strict ordering is not maintained. This is because TCP does not provide isochronous delivery service. Unlike other services, one cannot even provide an additional protocol to solve this problem2.
2 Some application layer protocols are designed with recording actual pause at the sender and produce them at the receiver are used to provide better voice services.
Communicating parties today demands many other security-related services, for example, some of them demand authentication, making sure both parties check the identity of each other before revealing any secret information. Some others demand non-repudiation, so once a party has committed something, for example, placing an order for 100 computers, he cannot deny later of doing so.
Providing non-repudiation is also impossible for a conventional transport layer like TCP. Some additional protocols are provided to handle this case. Authentication is provided by TLS.
After looking at services provided and not provided by TCP, there is a time to look at a typical service in little more detail; how TCP calculates a retransmission timeout value for a given connection.
Timeout calculation
We have looked at segment lost or corrupted problem in module 15 and some solutions based on retransmission of a lost segment. We have assumed during that discussion that TCP (or whatever transport layer protocol we used) can calculate the timeout value somehow. We also mentioned that TCP uses a typical method to calculate timeout values. Now is the time to discuss the same.
Whenever a segment is sent, it starts a timer known as retransmission timer. It also sets the value called time out. When the ack of the segment does not reach TCP before the timeout (time elapsed is more than timeout value), the segment is retransmitted. The TCP will have to have an estimate of the time by which such ack comes back and set the timeout value accordingly. Shorter than required value inflicts unnecessary retransmission and larger than required value adds unnecessary delay to the proceedings. Such unnecessary delay, if goes beyond a limit, frustrates the user and thus is unwanted for. For example, if we type a URL which is lost and TCP waits longer than required time to resend, the page takes that much longer time to download and the user will have to wait that much longer.
The solution to this problem is to estimate the round trip time (RTT) as tight as we can. Having some default or a priori value is out of the question as two communicating parties may be part of the same LAN where the RTT is almost zero. They may also be continents apart in which case the RTT value is quite significant, in terms of a few milliseconds.
Figure 24.9 describes the process of calculating the RTT value. The sender sends the segment and record that time, receiver processes that segment and sends back the ACK of that segment. The sender records the time to receive the ACK and finds the time difference between these values and calculate the RTT. Unfortunately, this simple scheme is not perfect as the RTT for each segment does not remain constant. It changes with the current network load and the current path taken by the specific packet. The same pair of sender & receiver using the same path also experiences different delays between consecutive packets due to many reasons, including the load on intermediary routers and their queue lengths and how much data others are sending etc. So RTT is not taken as it is. The next best choice is to take a few sample RTT values and calculate an average. This is a good solution and better than the previous but with another problem. Usually, next RTT is more like recent RTT values rather than an RTT value observed 10 minutes before. So we need to take a weighted average where the recent readings have more weight than the older ones. Moreover, the connection conditions change every second and thus demands continuous tuning of the RTT values. The solution is to continue calculating this weighted average and estimate the timeout value based on latest estimated RTT value.
For each ongoing connection, TCP subtracts the ACK receipt time from the time it sent the segment to get the RTT for that segment. Before sending the segment TCP estimated the RTT value of that segment. For estimating the RTT for any segment TCP calculates estimated RTT as follows.
Estimated RTT = *(1 − a ) × previous estimated RTT] + [(a × current RTT value)]
The value a is chosen as 1/8 = 1/23 = 0.125. Choosing a multiple of 2 has a distinct advantage. The multiplication or division can be carried out by either left shifting or right shifting the number. For example, in above case, dividing by multiple of 2 is a right shift that many times so multiplying with a is right shifting 3 times. This is a very fast operation and thus preferred. Eventually, the calculation comes out to be as follows.
Estimated RTT = [(0.875 × previous estimated RTT)] + [(0.125 × current RTT value)]
When a new segment is sent, estimated RTT is calculated like above and when the ACK comes back, the actual RTT value is also found out. Armed with these two values, the TCP can calculate the estimated RTT for the next segment and the process goes on. The weighted average, as you can see, stresses more on recent values of RTT. Not only the current value which we multiply with a but previous estimate also has a larger share of latest RTT value then and so on. Thus recent values have a larger share in the calculation of estimated RTT.
Once we have learned to decide how to calculate RTT values, the next thing we need to do is to decide when to timeout. Timeout, when the RTT is over, is overkill. The estimated RTT is what it is named estimated; i.e. not exact. The segment’s RTT values do vary over a period of time and eagerly resending the segment when an ACK is marginally delayed wastes precious network bandwidth. A wiser solution is to wait a little more to avoid a retransmission when an ack is delayed by some value. The next question is to find out that additional value for which we continue waiting for the ACK after the estimated RTT is over.
To manage that part, TCP plays one more trick. With the RTT, the TCP also calculates another quantity, the variance. A variance is a difference between the actual value and an estimate. Thus, TCP estimate two things, the RTT value and the variance as well. Like RTT, the variance also is a variable quantity and continuously changing. That is why TCP also continuously manages a weighted average to calculate the variance in following way.
Estimated deviation = [(1 − b ) × previous estimate of deviation] + [(b × current deviation)]
The previous deviation is the difference between the previous estimate and current RTT value. So it is calculated as follows.
Previous deviation = (previous estimation of RTT − current actual value of RTT)
In other words, if we estimated RTT to be 0.7 ms and ACK comes back in 0.5 ms, the deviation is calculated as 0.7 – 0.5 = 0.2ms. Thus the estimated deviation is calculated as follows
Estimated deviation = *(1 − b ) × previous estimate of deviation] + [b × (previous estimation of RTT − current actual value of RTT)+
The value b is taken as ¼ = 1/22 is chosen as it only requires two right shifts. That means the estimated deviation is calculated as follows.
Estimated deviation = (0.75 × old deviation) + (0.25 × current deviation)
Once both the RTT and deviation is estimated, calculating timeout is a trivial job. The timeout is calculated as round trip time estimate plus four times the estimated deviation. That means,
Timeout value = Estimated RTT + (4 × Estimated deviation)
where the multiplier is sometimes denoted as h and thus the equation is written as follows. Timeout value = Estimated RTT + (h × Estimated deviation)
The value of h is chosen as 4 as multiplying with h is right to shift twice.
Thus the complete process of timeout calculation is summarized as follows.
1. When the ack comes back, RTT is calculated,
2. Deviation is calculated as estimate vs actual value
3. Weighted averages are recalculated based on above equations.
The same process is repeated when every packet is sent and when every ack arrives. You can now see why utmost care is taken to do this calculation swiftly.
Karn’s algorithm
The RTT calculation process runs into a problem in two different cases. Whenever there is a need to retransmit, the ack that comes back is called ambiguous as it can be attached to either of the transmission.
Attaching the RTT value to the earlier transmission when it is actually associated with the second unnecessarily stretches the timeout value too much larger than actual. This is especially true if it is expected that every transmission is lost at least once and demand such calculation, in which case RTT increases to exponentially large value and the user feels like no communication taking place. Another problem occurs when we associate the RTT with the later transmission when it actually belongs to the earlier. In this case, it inflicts unnecessary retransmission. Research has shown that in such a case, every packet is transmitted at least twice.
Solution to this problem is provided by Karn, which is ridiculously simple. It says “Do not recalculate RTT in such case, double timeout values for each of the segments in sender’s window at this point of time”. When it does not recalculate the RTT, it saves us from the first problem and when the timeout value is doubled, the second problem is attended. Simple solutions like make a lot of sense in high-speed networks of today.
Summary
We have seen different types of services offered by the TCP; the transport layer of the Internet. UDP provides simplest of its kind service of sending and receiving segments and nothing else which is good for applications, which do not demand the services TCP offers and want to manage their applications on their own. The retransmission timer is one of the most critical services of TCP as it cannot be decided a priori or default. The retransmission timer has a huge impact on TCP performance so the estimate must be as tight as it can. Such process needs to be carried out every time a segment is sent and every time an ACK comes back, so it has to be lightning fast. We have seen that TCP retransmission management meets both criteria.
| you can view video on Transport layer services | |