This model is expected to scale quite well to approximately one hundred users. When the population involved in a collaboration grows beyond that, the elab server and the user's broker may become bottlenecks, although not for every application. For example, if the interaction is broadcast or multicast over an insecure channel, any number of people will be able to tune in and participate (much like MBone videos). Should the channel need to be limited to a thousand specific people, they could all be given a particular access key that the elab broker would require to authenticate the session, but even the state traffic in the elab server is likely to be excessive.
We feel that a hundred users will be quite satisfactory for the first years of the project. However, as mentioned above, one goal of the project is to develop a more distributed, peer-to-peer elab architecture that will scale arbitrarily.
We do not expect broker traffic to be a significant problem, as the broker is primarily involved with control information, not actual data. If broker traffic is too heavy and creates a bottleneck, however, methods of delegating responsibilities will be explored, including using several brokers as proxy agents, and dividing responsibilities across multiple processes or machines.
In general, the scalability of the collaboration is more likely to be limited by human constraints rather than technical restrictions. A thousand people watching a presentation is not difficult to manage, but a thousand people having a conversation is not going to be a success (unless you consider total anarchy a success), regardless of how well the tools are built.