1. Introduction

Even the best-designed computer networks are susceptible to failure sometimes. In failure events, data segments transmitted from one point to another may be lost midway. Due to that possibility, some protocols of the transport layer of the OSI and TCP/IP models employ mechanisms for detecting and retransmitting segments lost during networked transmissions.

In particular, stop-and-wait is one of the simplest protocols that enable entities to detect lost data in end-to-end communication.

In this tutorial, we’ll specifically explore such a protocol. First, we’ll review basic concepts about the transmission layer required to understand the overall execution context of the stop-and-wait protocol. Thus, we’ll technically learn stop-and-wait. Finally, we’ll discuss the feasibility of the stop-and-wait protocol in real scenarios and briefly check some alternatives.

2. Background Concepts

Modern networks are based on the TCP/IP model. In this model, the third layer is the transport one. The transport layer, in turn, deals with end-to-end data exchange among different entities connected to a reachable network.

It is relevant to note that end-to-end communications abstract the underlying network that connects entities. So, at this abstraction level, the only things that matter are the sender and receiver of data.

The transport layer embraces two categories of protocols: connection-oriented and connectionless.

In connection-oriented protocols, the entities communicating agree on establishing the communication. In other words, there is an initial and final moment to the communication. Connectionless protocols, however, work in a best-effort mode, and the entities do not previously agree to communicate, only send and receive data between each other.

The most prominent example of a connection-based protocol is TCP, while an example of a connectionless protocol is UDP.

In particular, a typical feature of connection-based protocols is managing transmission errors, solving them by retransmitting data lost in the path between the sender entity and the receiver one.

One of these transmission errors managing mechanisms is the stop-and-wait one. We’ll understand how this protocol works in the following section.

3. Stop-and-Wait

As we studied in the previous section, connection-based transport protocols can use the stop-and-wait mechanism to manage transmission errors in communication. It is the simplest protocol of a category called Automatic Repeat-Request (ARQ).

The stop-and-wait mechanism employs a strategy to confirm the receiving of each sent data segment.

This strategy is pretty simple: for each segment sent, the receiver (destination) sends an acknowledgment message, typically called ACK, to the sender (origin). So, the sender only has the guarantee that a data segment reaches its destination after receiving an ACK message.

The stop-and-wait uses the acknowledgment strategy to ensure the receiver has all the already sent segments. To do that, the sender waits for the acknowledgment message of the last sent data segment before sending a new one.

So, let’s consider an entity that should send three data segments to another one. By employing the stop-and-wait protocol, the process occurs as depicted in the following image:

stop and wait

3.1. Failure Cases

Of course, both the transmissions of data segments and ACK can fail. In such cases, the sender transmits the same message again to the receiver entity.

The stop-and-wait mechanism infers that a transmission failed based on timeouts. We have three main message-transmitting failure types: (i) not receiving a data segment in the destination; (ii) not receiving the ACK message in the source, and (iii) receiving an ACK message after the timeout event.

If a data segment does not reach the destination, a timeout event will occur in the sender entity, thus indicating that the ACK message never arrived. In such a case, this entity will send the message again. We can see this scenario in the image next:

ACK message

A second case is when the data segment reaches the destination, but there is a failure in the ACK message transmission. So, a timeout occurs on the sender side, which retransmits the data segment. Thus, the receiver will get a duplicate segment, ignore it, and send the corresponding ack message again. We can check the described scenario in the following image:

duplicate segment

Finally, the third scenario we’ll study is when the ACK messages arrive after the timeout. In such a scenario, the sender retransmits the data segment, receiving the ack from the first transmission after that. At this point, the sender entity can already send the following segment. The other entity will receive a duplicate packet, ignore it, and send a new ACK. So, the sender will receive a duplicate ACK message, ignoring it.

The image next shows the last message-transmitting failure scenario:

last message transmitting failure

It is important to note that potential problems related to data segment transmission can happen. For example, when the receiver entity gets different segments with the same sequence number in the second or third scenario, caused due to some interference in the transmission. We can use other strategies to detect and correct data errors in these scenarios.

4. A Brief Discussion About Stop-and-Wait

Although stop-and-wait is a functional mechanism to control the data segments transmission in the transport layer of networks, it is pretty unfeasible for production networks.

The reason for such an unfeasibility is simple – its performance is poor.

The first limitation consists of only sending a segment at a time. It differs from other Automatic Repeat-Query mechanisms, such as the Go-Back-N and Selective Repeat ones, that can tackle simultaneous transmissions.

It is relevant to note we can use the stop-and-wait mechanism with the well-known sliding window algorithm by configuring a window length size of one.

Another limitation regarding the stop-and-wait mechanism is that as the distance between the sender and receiver gets large, the propagation also delay increases. So, stop-and-wait is very distance-sensitive since we can send only one data segment at a time and wait for its acknowledgment message.

But, the stop-and-wait mechanism also presents some benefits. The first one is that it is easy to implement and test. This mechanism does not employ complex logic, being very straightforward to develop and deploy.

Moreover, it is a definitely accurate mechanism. The following data segment sent or received is, without a doubt, the next segment of the transmitting sequence. Thus, no checks about that are needed.

5. Conclusion

In this tutorial, we studied the stop-and-wait ARQ mechanism. Initially, we got some background concepts regarding the context in which ARQ mechanisms are employed in modern networks. Then, we explored the stop-and-wait mechanism, understanding how it works in multiple scenarios. Finally, we investigated some advantages and disadvantages of stop-and-wait and its relation with other ARQ options and networking algorithms.

We can conclude that stop-and-wait is not a feasible mechanism for production networks. However, it is relevant in introducing ARQ mechanisms, highlighting their most essential concepts. So, stop-and-wait has an important application in the educational field.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.