replica sites,
which may all be under separate administrative control. Like SSM, all
metadata for the write is stored on the client. However, Palimpsest
is intended for the wide area; storage sites may
be under different administrative domains. Palimpsest gives no
guarantees to its users in terms of storage lifetime; SSM gives
probabilistic guarantees.
Several projects have focused on the design and management of persistent state stores [17,28,1,13,19]. FAB [13] shares many of the same motivations as SSM, including ease of management and recovery; however, FAB is intended at a very different level in the storage hierarchy. FAB is a logical disk system for persistent storage that is intended to replace enterprise-class disk arrays, while in SSM we focus on temporal storage of session state. In addition, in SSM, all metadata is stored at the client, while FAB employs a majority-voting algorithm. Similarly, DStore [19] shares many of the motivations as SSM, but it focuses on unbounded-persistence storage for non-transactional, single-key-index state.
Petal [24] attempts to make data highly available by placing data on a node, and placing a backup copy on either the predecessor or the successor. Upon failure, the load is divided by the predecessor and successor, whereas in SSM the load redistribution is even across all nodes. In Petal, the loss of any two adjacent nodes implies data loss, while in SSM, the number of replicas is configurable.
SSM's algorithm is different from that of quorums [15]. In quorum systems, writes must be propagated
to 
of the nodes in a replica group, and reads must be successful
on 
of the nodes, where 
, the total number of nodes in a
replica group. A faulty node will often cause reads to be slow, writes
to be slow, or possibly both. Our solution obviates the need for such
a system, since the cookie contains the references to up-to-date
copies of the data.
DDS [17] is similar to SSM in that it focuses on state accessible by single-key lookups. A detailed discussion of the differences between SSM and DDS can be found in previous work [25,26]. We share many of the same motivations as Berkeley DB [30], which stressed the importance of fast-restart and treating failure as a normal operating condition, and recognized that the full generality of databases is sometimes unneeded.
The windowing mechanism used by the stubs is motivated by the TCP algorithm for congestion control [22]. The need to include explicit support for admission control and overload management at service design time was demonstrated in SEDA [39]; we appeal to this argument in our use of windowing to discover the system's steady-state capacity and our use of ``backpressure'' to do admission control to prevent driving the system over the saturation cliff.
Zwaenepoel et al [11] are also looking at using generic, low-level statistical metrics to infer high-level application behaviors. In their case, they are looking at CPU counters such as number of instructions retired and number of cache misses to make inferences about the macro-level behavior of the running application.