MACAW

While there are a lot of different corner cases that this paper presents, and a lot of different reasons for the algorithms presented, the final protocol is quite simple to explain. The protocol is essentially RRTS-RTS-CTS-DS-DATA-ACK. This is improved over the MACA algorithm, which only had RTS-CTS-DATA. The paper lists one-by-one the reasons for this algorithm. Let's start with the DS (data sending). Whenever there is congestion, a node must wait until all data has already been sent before sending an RTS. However, when the node doesn't have the ability to detect whether or not data is being sent, it has no way of knowing when to send the RTS. The DS message solves this problem by describing how much time it will take the data to be sent, thereby letting all nodes know when they can send their next RTS.

We can continue with the RRTS. If a node cannot send a CTS because it is currently overhearing traffic from some other stream, then it must notify potential senders when that traffic is done. It does so by using an RRTS, which tells the potential senders that they may now send an RTS message. Without the RRTS, potential senders would randomly send RTS messages, with almost no chance of doing so at a time when there was no interference.

The last addition to the protocol is the ACK. This comes straight out of the E2E paper, which says that if something can be done more efficiently at the lower levels, it should be done there, rather than pushed to the ends. In this case, the use of the ACK allows for much higher throughput, because wireless links are considerably noisier and less reliable than physical links. Since the loss of a packet does not necessarily mean congestion of the link in question, TCP's congestion avoidance is not an appropriate reliability mechanism for wireless networks. Thus, the reliability is programmed in at the link layer.

There is one more significant issue that this paper raises, which is the question of the back-off counter. The paper suggests using a shared value for this back-off counter, since everyone should have a consistent view of the network. Anyone that receives a back-off value immediately stores it. The paper also suggests multiple back-off values: one for the sender and one for the receiver. If an RTS is sent but not received, this means that there is congestion at the receiver. If a CTS is sent but not received, this means that there is congestion at the sender. The back-off counters are decremented accordingly. At the same time, to avoid massive fluctuations in back-off counters, the increase/decrease algorithm is changed to a increase by a factor of 1.5, and a decrease by a constant of 1. All of these, when put together, allow a conistent view of the network by all nodes, as well as a fairly stable back-off counter.

This paper mentions almost nothing about nodes entering and leaving the ranges of base stations. Suppose a node leaves the range of a base station while the base station is transmitting to it? Does the lack of an ACK mean that the base station will try to retransmit? Similarly, suppose a node enters the network. How does it go about making contact with a base station, while making sure not to cause interference with transmissions that are currently in progress? It could listen for DS messages, and then send an RTS at the next available time slot, but this would certainly not work if it were alone in the network. These questions seem to be left unanswered by the paper.