IDENTIFICACION DE ZONAS

While scalability is described as a function of group size, the effect that group size has depends on the issues described in chapter 2. Three of these are considered to be design issues, reliability, order and group management.

Group management impacts on the scalability of multicast because of the relation­ ship between the number of group members and the amount of management informa­ tion maintained. Scalability is therefore affected by the storage requirements of this information, which may be physically limited in some way, and by the need to main­ tain the management information is such a way to ensure that the protocol operates properly, which may be limited by the data transfer capabilities of the protocol that supports the group management.

Order impacts on scalability mainly because of the extra overhead imposed on the normal transfer of data to ensure the various ordering paradigms are maintained. Therefore, the main limitation is the actual data transfer process, which may be effec­ tively reduced by this extra overhead and may therefore be substantially subsumed into considering the scalability of data transfer.

Reliability impacts on scalability because of the use of replies by reliability mecha­ nisms and is the area investigated here. Because data transfer occurs more often than group management, the scalability of this is of relatively greater importance, and also because, apart from the storage aspect of management information, it is the mainte­ nance of the management information that impacts on scalability, which may also be considered a data transfer issue as maintenance implies some form of data transfer between a holder of such information and the requestor. Reliability implies that replies are transmitted from recipients to the originator in response to the reception of a forward multicast. A number of points may be made about these replies. Firstly, it is likely that the time between the reception of a multicast message and the subse­ quent transmission of the reply will be similar for each of the recipients. Secondly, each recipient will have to reply even if only one reply is actually required, because each recipient in general will have no knowledge about the status of other recipients. This leads to the observation that if there are a large number of such recipients, and that the network connecting them to the originator exhibits a low dispersion, that is the difference in reception time between the "first" and "last" recipient is small, then there will be a proportionally large number of replies attempted in a relatively short time period. Of course, the network imposes its own mediation policy on these

transmissions so that the replies are in effect transmitted sequentially, the minimum gap enforced by the network being used. If the processing rate of the host receiving these replies is less than the rate at which the replies are received from the network then there is a possibility of replies being missed. Buffering is normally used to absorb this rate mismatch. However, the number of these replies may cause this buffering to fill, again resulting in replies being missed. It is this b u ffer o v e r r u n that is considered to be the most important issue in the scalability of multicast.

Part of this buffer overrun problem is caused by the synchronizing effect of a multi­ cast, which is effected by the dispersion experienced by packets passing through the network, typically low for LANs and m a n s.Dispersion for multicast may be described as the difference in the times of arrival of a message at the group between the first message copy and the last. Multicast over WANs exhibits a greater degree of disper­ sion, reducing this problem, although DeSimone [De91b] shows that such networks possess correlation effects causing packets to cluster at routing hosts, a clear sign of possible congestion and buffer overrun.

The problem of implosion is analysed in more detail below. A related issue, affecting the transmission policy of a protocol, is also dependent on the group size and con­ cerns the loss of packets at recipients due to packet corruption in transit or by conges­ tion at the recipient or intermediate bridges. As the group size increases, it is more likely that group members will be in this situation, as a multicast also has to compete with other traffic. A simple model of this was developed [Jo91a], which assumed that each host possessed a probability of missing a packet, the accumulation of these prob­ abilities decreasing the overall probability of a packet being received by all of the members of a group. Of course, flow control may be imposed on this traffic, however many of the flow control mechanisms employed require replies, with the potential for implosion. In addition, if many originators attempt communication with a group simultaneously then flow control has not yet been established, leading to the possibil­ ity of implosion, although the synchronization necessary for this to occur is less likely than that generated by a multicast.

An obvious scalability issue relates to the number of groups that may be supported by a host, the main limitation being the number of multicast addresses which may be fil­ tered on simultaneously. One problem here relates to the need to filter packets effi­ ciently, only allowing packets for which interest is indicated to be passed higher up the protocol stack. If the number of such filters is small then either the number of

groups supported must be restricted, or all multicast must be passed by the filter increasing the number of packets passed up, and therefore potentially increasing buffer overrun. If the number of filters is large, then the time required to compare the packet address with the filter may also cause an increase in buffer overrun. Also, if a large number of packets are received at a host the processing load may result in unac­ ceptable performance from the host, a congestion issue.