Los funerales del poeta

economic policies, and other incentive-based policies. Security policies specify hard con-straints on which information and functionality can and cannot be made available across specified boundaries and by whom. Pricing constraints allow for perhaps a sliding or de-gree based decision. Other forms of incentives may be designed specifically to encourage cooperation, in the face of proprietary and other security constraints.

The fourth kind is performance. Applications may have to run with a set of efficiency criteria, which may determine the placements of agents. For example, if it is important to have low latency, then paths between agents should be selected on that basis; if the amount of network traffic should be low, then agents may be collocated on the same nodes as much as possible.

The fifth kind is shared resource usage. This requires that the spec-KPs, in determining their organizations, know enough about others which may be sharing resources to make a possible compromise in order that the spec-KPs not interfere unnecessarily with each, as best possible. We take a lead from previous work, beginning with a set of information similar to that of CoMon [93] from PlanetLab. CoMon provides a monitoring statistics for PlanetLab at both a node level and a slice level. It can be used to see what is affecting the performance of nodes, and to examine the resource profiles of individual experiments. In the longer run, it will be necessary for this sort of information to be distributed in the KP, unlike what is currently being built in PlanetLab.

3.4.2 Agent Organization in Spec-KPs

Generic agent and region operations in the spec-KPs are similar to that in the NetKP. Within a region, agents can be organized in different ways, depending on the size of the region and the distribution of the distance metrics. When the size is small, a full mesh will suffice.

That is, each one knows all the others. When the size is large, a structured peer-to-peer organization, such as distributed hash table, may be preferred. In general, we want to limit the size of a region so as to simplify its organization and recommend a full mesh structure.

There is no single answer to the region size. It will depend on what they are doing under what conditions. Cross-region organization in the spec-KPs depends on the nature of the

spec-KP itself. In Chapter 6 and 7, we present two case studies to demonstrate different organizations for different tasks.

An important issue in the spec-KPs is how to discover agents in the same problem domain when an agent joins. There are two steps. The first is to find a spec-KP that matches its interest, and if no such spec-KP exists, to create a new spec-KP. This can be done using the broadcast mechanism presented in Chapter 5 to broadcast the request to all the regional leaders in the NetKP. Note that all the spec-KPs register their information in the NetKP.

The second is to find an appropriate region after the spec-KP is found or formed. If there are multiple regions formed in order to partition the set of agents, when an agent comes into existence, the choice of how regions are defined is going to drive which region the agent will end up with. In this work, the discovery procedure uses the underlying NetKP. Each region in the NetKP maintains a list of local agents in the spec-KPs and their interests. A request looking for agents with similar interests is propagated from the local region to neighboring regions. In most cases there is already a spec-KP with this interest, and the new agent only needs to find one that is already in this network to join the spec-KP.

Furthermore, a high-level task may involve multiple agents belonging to different spec-KPs. For example, to diagnosis a web access failure, we need help from agents on DNS diagnosis, routing diagnosis, server status monitoring, etc. To find those agents, we need to first find local agents in the NetKP, and then search for agents in each spec-KP.

3.4.3 Request Propagation in Spec-KPs

Request resolution in a spec-KP depends on the nature of the spec-KP itself. A simple example is as follows. When an agent issues a request, it is propagated to all agents in the same region, and also to one or a few agents in every region within a certain number of region hops, say n. When a piece of knowledge is issued, it is also disseminated in the same way. Therefore, the knowledge within n region hops is guaranteed to be found by a request.

Figure 3-3 shows an example with n=2. This shows how regions help to improve scalability and efficiency. To further extend this, we can consider many factors, such as the location

n m

x

region agent

request propagate

links between regions

knowledge propagate

Figure 3-3: Request and knowledge propagation in the spec-KPs. This shows a request from agent m and a piece of knowledge from agent n meet at agent x.

of an agent, the cost model, and even the diameter of a specialized KP, etc. In Chapter 6 and Chapter 7, I present different propagation mechanisms based on the functionality and constraints of the spec-KPs.