Rather than attempting to model precisely the behaviour of the network, the evaluation is confined to that subset of the network's characteristics which are relevant to the application in question and which are suitable for this sort of abstract consideration.
It is especially important to note that when the application of IP multicast is limited to a particular problem domain, the number of unknowns in any model will be greatly reduced - by comparison with all the courses of action which may be taken in an arbitrary multicast solution to an arbitrary problem. Examples of this include cases where it can be expected that there will be a large number of clients and a small number of servers, or vice versa, or that the maximum TTL used will be restricted to a given figure. Perhaps the most significant of these restrictions is the use of SDP as the multicast application protocol. Since SDP can be used for any number of different purposes, it provides a common foundation for the evaluation as a whole.
Knowledge of the current MBONE topology makes it feasible to predict the outcome of an event or a series of events, though perhaps not all their ramifications. The mcollect tool, developed at the Department of Computer Science at the University College of London, tells us how many of the Internet subnets connected to the MBONE can be reached with a multicast transmission at a given TTL from an arbitrary part of the MBONE. Whilst these figures are very useful, it should be noted that they do not give an indication of performance indicators such as the number of multicast aware hosts connected to each subnet, or typical response times, packet loss and duplication. This is not believed to be a problem in the evaluation, because it is not essential to go down to such a level of detail. The rationale behind this assumption should become clear in the paragraphs which follow.
The amount of work an SDP server is required to do in servicing
a request can be written as 
, where r indicates the
type of the request. If a multicast request is sent with a TTL high
enough to reach this server, and to the appropriate multicast group
and UDP port number, 
units of work will result from the
request. How the figure is arrived at is not particularly important
in this context, except in so far as to note that different types of
request are likely to entail different amounts of work on the server's
part.
If this approach is applied to the MBONE as a whole, it can be seen that the total amount of work done for a given request is a function of the amount of work required for this type of request, and the scope (TTL) of the transmission, or
where 
is the number of MBONE connected subnets which are
reachable for transmissions with the TTL t. Appendix
gives a table of these mappings for the
MBONE topology which was in place at the time this report was written.
This was compiled by post-processing the output of mcollect.
Figure 1 illustrates the relationship between
the TTL of the transmission and the fraction of the MBONE which the
transmission can be expected to reach.
Figure 1: Transmission TTL and MBONE coverage
It can be seen that in some cases the information in the first table alone is enough to mitigate against a multicast approach, because of the coarseness of the TTL mechanism being used to scope multicast traffic. In particular, it is very difficult to send multicast traffic which only reaches a small fraction of the MBONE - as can be seen from the graph.
The situation can often actually be more complex, as there may be any
number of servers for a particular protocol on an MBONE connected subnet.
Appendix shows the amount of work which would
be required in servicing multicast requests with varying numbers of
servers per subnet. These figures are derived from the equation
i.e. the number of servers 
required to do work in servicing
a request depends on have the amount of work 
required for
that request type r, multiplied by the number of subnets 
reached at this TTL t, and by the number of servers s of that
protocol per subnet. The 
figure is excluded, since this
is application dependent.
In addition to the amount of work done by servers, the network loading imposed by requests which are widely propagated must also be considered. This is particularly significant when the number of clients and servers increases, e.g. in the event that the protocol becomes widely used. In this report the number of subnets reached by a multicast transmisison and the number of servers required to do work will be taken as an indication of network loading. In practice there are likely to be other considerations, such as the bandwidth required to run the protocol effectively, and the impact of one protocol upon another.
So far, it has been assumed that there is only only client. The impact of multiple clients can be simulated by adding the number of clients to the equation for the total number of servers required to do work in processing a request:
where c is the number of clients. There is work involved on the client side in handling the results of a request and deciding on, say, a re-transmission strategy should there be no acceptable results. This decision-making work done by the client, can be ignored since it should be negligible, but the re-transmission strategy chosen is of great importance. For example, if the client were to successively add 1 to the TTL of its requests, the same hosts would end up being required to do work over and over again until a satisfactory answer was arrived at. This is undesirable, to say the least, but is a fundamental problem with multicast protocols.
When caching is taken into account, the number of clients may become less of a problem. This depends on the frequency with which information which has been cached is requested, also known as the cache's hit rate. Clearly, when the answer to a request has not been cached the amount of work done and network loading is as before. Bringing a cache server into the model requires there to be a mechanism for informing the cache when the client receives a response or responses considered worth caching.
In SDP this mechanism is the quench request. Depending on the number and arrangement of cache servers, there will be some amount of work associated with the quench request itself. This is particularly true if the cache servers are listening on the same multicast group as used for the regular application. With a cache server in place, the maximum TTL required is the TTL of the cache server itself. If the clients are aware of the cache server's IP address, they may choose to communicate directly with it via unicast rather than multicast. Similarly, the client which wishes to use multicast when making requests might record the TTLs of any cache servers it encountered. This information could be used to determine a minimum TTL for future requests.
For the purposes of this discussion, it will be assumed that not only is there only one cache server, but also that a separate multicast group is used from that associated with the applications themselves. In practice, different applications could be expected to have differing requirements from a cache server, and individual applications might require their own specially tailored form of cache service.