Implosion

Congestion is common to unicast communications as well as multicast, and occurs whenever the number and rate of packets arriving at a host exceed the capability of the recipient to buffer temporarily the packets. The congestion is normally relieved by temporarily storing messages until they can be processed, buffering working because congestion is normally a temporary problem, in that the input pauses allowing time for the output to reduce the buffer storage. However, a pause may not occur early enough to prevent packets being discarded. With the transfer rates of networks increasing rapidly, an increase that is not matched by similar increases in the speeds of other components, such as computer buses and processors, buffer overrun is expected to become even more of a problem, not just for multicast, but also for uni­ cast. However, for positively acknowledged and transactional multicast protocols the problem is not controlling the flow from originator to recipients, but the control of replies, especially positive acknowledgements, which are not traditionally flow con­ trolled.

The mechanism for buffer overrun in multicast is based on time. A transactional or positively acknowledged protocol design is compelled to return a message of some form to the originator in response to a multicast. Many protocols require that this reply be transmitted as soon as possible, after the reception of a multicast. Therefore, if each recipient receives the multicast within a small period of time, as will happen on a broadcast based LAN, then each recipient will attempt to reply, also within a short

time period, given a certain amount of variability in the processing time of each recip­ ient. It is here that dispersion is significant as it implies that if the dispersion is smaller than the time required to transmit a packet over the network then when the first reply is transmitted by a recipient, all of the other replies will be queued waiting for access. The network architecture imposes rules of its own on these replies to ensure that packets do not collide on the network itself, which implies that packets are

transmitted as soon as possible by each recipient, given the network constraints of the minimum inter-packet gap. Therefore, the characteristics of the network and the number of recipients replying combine to potentially cause implosion which in turn may result in buffer overrun and the loss of replies.

Some argue that buffer overrun is not a problem, as a protocol can be designed to reduce the number of acknowledgements, others arguing that acknowledgements can be missed as only the first response is required. Although both of these can be justi­ fied in a limited context the problem of buffer overrun must be addressed in the design of a multicast protocol.

Danzig [Da89a] investigated the implosion effect at length, using a statistical repre­ sentation of a typical network with attached hosts. The statistical model identified three buffer overrun points, figure 4.1, within a host.

Network Buffer

Level Buffers Protocol Level ___ Buffers Process Level Buffers

Network

Figure 4.1 Danzig’s Host Model

Each buffer overrun point has an associated overhead between the reception of a mes­ sage and the subsequent removal of that message, either by passing it to the next level, or by being destroyed after processing completion.

Implosion does not just affect hosts, being also a problem for certain network archi­ tectures, specifically those which use some form of collision to resolve media conflict. These are generically titled Carrier Sense Multiple Access networks, being exempli­ fied by the Ethernet [Me76a,Bo88a,Bo89a] network. Implosion affects these networks because if many hosts attempt to access the network within a short collision period

their respective packets interfere with each other. The Ethernet protocol senses this collision, each host then stopping their transmission and executing an algorithm to calculate a retransmission interval. One of the more serious, from the implosion point of view, is that network’s ability to discard packets which have had a number of attempts at transmission which resulted in a collision. The effect of multicast on an Ethernet was investigated, statistically, by Crowcroft and Paliwoda [Cr88a], the

subsequent protocol design used a delay algorithm to increase the efficiency of the protocol.

It can be argued that buffer overrun can be dealt with by increasing the number of buffers available for the gathering of replies. However, adding extra buffering to hosts is only a temporary measure, as soon as the combination of network characteris­ tics and number of recipients exceeds the new limit the problem will re-occur.

In order to investigate scalability, the parameters of implosion need to be mapped, so that these limits may be explored. Having described where implosion occurs, methods of overcoming implosion, that is using a protocol method to combat implosion, may be effectively employed. Given that the cause of implosion is a combination of the network environment and the number of replies exceeding the buffering capabilities of a host, three methods may be employed. The first would be to apply those flow control techniques described previously to the replies, as already discussed flow con­ trol is not traditionally applied to positive acknowledgements for the simple reason that often the acknowledgement is the flow control mechanism. The second is to reduce the number of replies to the host so that the buffering is able to cope. The third is to increase the time between replies to give the host more time to process already received messages.