Keetchi Algorithm
The
Keetchi algorithm consists of a number of software modules that operate in a node, interacting with each other to optimally disseminate data in a network.
Figure 3 shows the flow diagram of these modules and their interactions. The
Keetchi algorithm is triggered by four stimuli that activate five different software modules through the use of three message types. The modules perform the following activities.
Cache Data: Similar to any other OppNets forwarding protocol, Keetchi uses a store-carry-and-forward mechanism to disseminate data and stores all data in a cache. Every data item in Keetchi consists of the payload itself and an additional integer representing the current estimate of the popularity of that data item at this node, referred to as the goodness value of the data item. The goodness value has a range between 0 and 100, and all the data items are held in the cache sorted by descending order of this value.
Update Goodness Value: Every data item in
Keetchi that is disseminated and stored in caches carry the goodness value. When a data item (from an application or the network interface) or a user feedback (from an application) is received by
Keetchi, the goodness value is updated using simple Q-Learning. The update of the goodness value is shown in Equation (
1):
where
,
and
are the new, previous and received goodness values, respectively. The received goodness value plays the role of a reward in a Q-Learning setting and the new and old values are the new and old Q-values. The
is a constant referred to as the learning constant, where higher values result in slower learning. The goodness values are the estimates of the popularity for each data item.
Determine Change Significance: As any other forwarding protocol,
Keetchi needs information from lower protocol layers to know which nodes are in a given node’s neighbourhood. If all of these nodes are new neighbours, then it is worth sending them more popular items first. If they are all known, then we have already sent them the popular items and we have time to send them also less popular ones. We adopt a
fuzzified technique to determine whether the neighbourhood changed significantly (see
Figure 4). If the change per cent is in the
fuzzy area, the old value is kept (significant/not significant). This is important to avoid sudden fluctuations of the value, because it triggers the data sending mechanism.
Determine Data to Send: The selection of data item to send is random and the random distribution is controlled by the significance of change. In general, if the change is significant,
Keetchi will select a data item which has a higher goodness value and a data item with a lower goodness value in the case of an insignificant change. The used distribution is a Gauss-like heavy tail distribution with a moving peak, whose form is controlled by the parameter focus weight factor. The larger is this factor, the steeper is the distribution. Whenever the change is significant, the peak of the distribution is set to the highest goodness value (see
Figure 5). With continuous successive insignificant changes in the neighbourhood, the peak of this distribution is moved downwards, in the direction of lower goodness values. If the distribution peak reaches the bottom of the cache,
Keetchi stops sending data altogether. Furthermore, when there is no significant change, the inter-packet sending interval is increased, controlled by a parameter backoff increment factor. Recall that the cache is ordered by decreasing goodness values of all items. The use of a heavy tailed distribution fosters the probable selection of a wide array of data items from cache, including unpopular items. This random selection is central to our approach, because we use the broadcast advantage to send a data item to any listening neighbour.
The moving probability peak and the shape of the probability distribution are designed in a way to prevent repeatedly selecting the same message. Even if this is not guaranteed, these sporadic duplicates do not influence significantly the performance of
Keetchi, as shown in
Section 8. In a highly mobile scenario,
Keetchi anyways repeats popular messages often to serve sporadic neighbours.
Age data: Data lose their usefulness over time, e.g., jokes and news become old. This aspect in Keetchi is captured by ageing the goodness values regularly, i.e., decreasing all goodness values by an application-defined constant. This results in unpopular data items reaching the bottom of a cache and ultimately being kicked out to make way for popular data items.
The four stimuli (see
Figure 3) consist of two external and two internal triggers to activate the modules of
Keetchi:
Data from/to Applications (a): Applications running in a node generate data or expect to receive data from other nodes. Data generated by an application trigger Keetchi to store the data. Similarly, when data are received from other nodes, they are sent by Keetchi to the application.
Data from/to Network Interfaces (b): Data generated and disseminated by other nodes are received over the network interface of a node. Receipt of data items results in Keetchi updating caches and goodness values of those data items.
Neighbour Monitor Trigger (c): The underlying link layer regularly updates the available neighbours and triggers Keetchi regularly with this new information.
Data Ageing Trigger (d): Ageing of all data in a cache is done regularly through this trigger (application-dependent parameter).
Several messages are exchanged between the Keetchi modules and the different triggers. The data message carries, among other things, the data name, payload and the goodness value. In addition to disseminating and receiving these messages over the network interfaces, the software modules operating in a node, exchange them between themselves during the operations. For example, when a data message is received by the network interface, it is passed on to the caching module to recompute the goodness value and then to store it in the cache. If an application has subscribed to this type of data, a copy of the data is sent to the application.
Information messages carry information related to the internal operations of Keetchi. An example is the information about the change significance required to determine the next data item to send. feedback messages are messages internal to Keetchi and only sent by an application to the cache. These messages carry the preferences indicated by the user of the node and is used to update the goodness value in the cache. Only data messages get disseminated in the network, the others are internal to Keetchi.
A detailed example of the operation of
Keetchi is given in
Appendix A.