Design Issues

Back-pressure flow control. In case the communication system or the sender cannot accept any further messages the sender is forced to delay the sending of
further messages until the overload condition has disappeared. We say that backpressure is exercised on the sender.

Explicit flow control. Inexplicit flow control (a form of back-pressure flow control) the receiver sends an explicit acknowledgment message back to the sender, informing the sender that the sender’s previous message arrived correctly, and that the receiver is now ready to accept the next message. The most important protocol with explicit flow control is the well-known Positive-Acknowledgment-or- Retransmission (PAR) protocol.

Backpressure flow control and explicit flow control are based on the sometimesoverlooked assumption that the sender is within the sphere of control (SOC) of the
receiver, i.e., that the receiver can control the transmission speed of the sender. This is not the case in many real-time scenarios, since the progress of the physical process cannot be influenced by the communication protocol.

Best-effort flow control. In best effort flow control, the communication system provides intermediate buffer-storage for messages in case the link for the further
transport of messages to the final receiver is not available. If a buffer overflows, messages are dropped.

Best-effort flow control cannot be used in hard real-time systems, since the uncontrollable delay or the throw away of messages is not acceptable.
Rate-constrained flow control. In rate-constrained flow control, the sender, the communication system and the receiver agree a priori, i.e., before the communication starts, on the maximum message rate. The communication system and the receiver will accept all messages sent by the sender, as long as the sender rate remains below the agreed maximum.
Implicit flow-control. Inimplicit flow control, the sender and receiver agree a priori, i.e., before the communication starts, on the instants when messages are sent and received. This requires the availability of a global time-base. The sender commits itself to send a message only at the agreed instants, and the receiver commits itself to accept all messages sent by the sender, as long as the sender fulfills its obligation. No acknowledgment messages are exchanged during run time. Error detection is the responsibility of the receiver that can determine (by looking at its global clock) when an expected message fails to arrive. Error detection latency is short, since it is determined by the precision of the clock synchronization. Implicit flow-control is the most appropriate flow-control strategy for the exchange of real-time data.

Thrashing: The often-observed phenomenon of the throughput of a system decreasing abruptly with increasing load is called thrashing. Thrashing can be observed in many systems and is not limited to computer systems.

Many systems can be characterized by a throughput-load dependency as shown in Fig. 7.4. An ideal system exhibits the load throughput curve labeled ideal in Fig. 7.4. The throughput increases with increasing load until the saturation point has been reached. From thereon, the throughput remains constant. A system has a controlled load-throughput characteristic if the throughput increases monotonically

with the load and reaches the maximum throughput asymptotically. If the throughput increases up to a certain point, the thrashing point, and thereafter decreases
abruptly, we say the system is thrashing. Real-time systems must be free of the thrashing phenomena. If a real-time system contains a mechanism that can cause thrashing, then, it is likely that the system fails in the important rare-event scenarios discussed in Sect. 1.5.
Mechanisms that can cause thrashing. Mechanisms that require a more than proportional increase in resources as the load increases are prone to cause thrashing. Two examples of such mechanisms are:
1. A time-monitored retry mechanism (a type of PAR protocol) in a request-reply protocol: If a communication system slows down because it can barely handle
the offered load, a request-reply protocol reaches its time-outs, and generates additional load.
2. Operating system services: In a dynamic scheduling environment, the time needed to find a feasible schedule increases more than linearly as the requested load reaches the capacity limit. This increase in the amount of scheduling overhead further decreases the computational resources that are available for the application tasks.

Similar arguments hold for the overhead required for queue management.

A successful technique to avoid thrashing in explicit flow-control schemes is to monitor the resource requirements of the system continuously and to exercise a stringent backpressure flow control at the system boundaries as soon as a decrease in the throughput is observed.