Specification and space complexity of collaborative text editing

Abstract

Collaborative text editing systems allow users to concurrently edit a shared document, inserting and deleting elements (e.g., characters or lines). There are a number of protocols for collaborative text editing, but so far there has been no abstract, high-level specification of their desired behavior, which is decoupled from their actual implementation. Several of these protocols have been shown not to satisfy even basic expectations. This paper provides a precise specification of a replicated abstract list object, which models the core functionality of replicated systems for collaborative text editing. We define a strong list specification, which we prove is implemented by an existing protocol, as well as a weak list specification, which admits additional protocol behaviors.

A major factor determining the efficiency and practical feasibility of a collaborative text editing protocol is the space overhead of the metadata that the protocol must maintain to ensure correctness. We show that for a large class of list protocols, implementing either the strong or the weak list specification requires a metadata overhead that is at least linear in the number of elements deleted from the list. The class of protocols to which this lower bound applies includes all list protocols that we are aware of, in particular CRDT and OT protocols, and we show that one of these protocols almost matches the bound. The result holds for peer-to-peer protocols, even if the network guarantees causal atomic broadcast. The result also holds for the metadata cost at the clients in client/server protocols.¹

Introduction

Collaborative text editing systems, like Google Docs [10], [9], Apache Wave [1], or wikis [17], allow users at multiple sites to concurrently edit the same document. To achieve high responsiveness and availability, such systems often replicate the document in geographically distributed sites or on user devices. A user can modify the document at a nearby replica, which propagates the modifications to other replicas asynchronously. This propagation can be done either via a centralized server or peer-to-peer. An essential feature of a collaborative editing system is that all changes eventually propagate to all replicas and get incorporated into the document in a consistent way. In particular, such systems aim to guarantee eventual consistency: if users stop modifying the document, then the replicas will eventually converge to the same state [36], [35].

Fig. 1(a) gives an example scenario of a document edited at several replicas. First, replica $R_2$ inserts x at the first position (zero-indexed) into the empty list. This insertion then propagates to replica $R_1$, which inserts a to the left of x, and to $R_3$, which inserts b to the right of x. Later the modifications made by $R_1$ and $R_3$ propagate to all other replicas, including $R_2$; when the latter reads the list, it observes axb. In this scenario, the desired system behavior is straightforward, but sometimes this is not the case. To illustrate this point, consider the scenario in Fig. 1(b) (also known as the TP2 puzzle [21]), where $R_2$ deletes x from the list before the insertions of a and b propagate to it. One might expect the read by $R_2$ to return ab, given the orderings ax and xb established at other replicas. However, some implementations allow ba as a response [27]; e.g., we demonstrate in Appendix A that this is the case in the Jupiter protocol [20] used in public collaboration systems [37].

Users would like to have highly available protocols, which respond to their operations immediately, without performing any communication. There have been a number of proposals of highly available collaborative editing protocols, using techniques such as operation transformations (OT) [12], [25], [29], [30] and conflict-free replicated data types (also known as CRDTs) [23], [39], [26]. It is challenging to specify the desired behavior of collaborative editing protocols, without referring to the actual implementation, in particular, for identifying the visible operations that should be reflected in the responses of operations. Abstracting away implementation details is essential for studying inherent properties and limitations. Instead, existing specifications [30], [18] refer to implementation details, e.g., messages sent and received; this does not provide a common ground on which to compare different implementation approaches for the same specification [32]. In addition, several of the protocols have been shown not to satisfy even the basic expectation of eventual consistency [15].

We introduce an implementation-independent specification of a replicated $\mathsf{list}$ object. The $\mathsf{list}$ object allows its clients to insert and delete elements into the list at different replicas and thereby captures the core aspects of collaborative text editing [12] (Section 3). Our specification has two flavors. The strong specification ensures that orderings of list elements observed by different clients are consistent. This includes transitive consequences of orderings over subsequently deleted elements, such as x in Fig. 1(b), and thus, the strong specification disallows the response ba for the read in this figure. The weak specification does not take transitivity into account, thus allowing the read in Fig. 1(b) to return either ba or ab. We show that both of these specifications ensure eventual consistency.

We prove that the strong specification is correctly implemented by a variant of the RGA (Replicated Growable Array) protocol [26], which is in the style of replicated data types [23] (Section 4). The protocol represents the list as a tree, with read operations traversing the tree in a deterministic order. Inserting an element a right after an element x (as in Fig. 1(b)) adds a as a child of x in the tree. Deleting an element x just marks it as such; the node of x is left in the tree, creating a so-called tombstone. Keeping the tombstone enables the protocol to correctly incorporate insertions of elements received from other replicas that are ordered right after x (e.g., that of b in Fig. 1(b)).

The simplicity of handling deletions via tombstones in the RGA protocol comes with a high space overhead. More precisely, the metadata overhead [6] of a list implementation is the ratio between the size of a replica's state (in bits) and the size of the user-observable content of the state, i.e., the list that will be read in this state. As we show, the metadata overhead of the RGA protocol is $O(D\lg k)$, where D is the number of deletions issued by clients and k is the total number of operations (Section 4). The number of deletions can be high. For example, a 2009 study [39] indicates that the “George W. Bush” Wikipedia page has about 500 lines. However, since modifications are usually handled as deleting the original line and then inserting the revised line, the page had accumulated about 1.6 million deletions.²

Other CRDT protocols do not keep tombstones, e.g., Treedoc [23], Logoot [39] or WOOT [22], but the replica state contains metadata, e.g., labels, that grows linearly in the number of deletions. OT protocols [12] pay metadata overhead by logging unacknowledged updates in each replica.

Our main result is that this overhead is indeed, in some sense, inherent. We prove that any push-based protocol that implements the weak list specification for $n\ge 3$ replicas incurs a metadata overhead of $\mathrm{\Omega }(D)$, where D is the number of deletions. In a push-based protocol, each replica propagates list updates to its peers as soon as possible, and merges remote updates into its state as soon as they arrive (we give a precise definition in Section 5). This assumption captures the operation of all highly-available protocols that we are aware of and it includes both CRDT and OT protocols. The lower bound holds even if the network guarantees causal atomic broadcast [11].

We first establish our lower bound for the peer-to-peer model. Client/server protocols attempt to save space on replicas by keeping it on a central server. Replicas communicate only with the server and not directly with each other, and so the server does more than merely relay messages between replicas. Using the fact that the lower bound holds for a network with causal atomic broadcast, we extend it to show that, in a push-based client/server list protocol, the metadata overhead at the clients is still $\mathrm{\Omega }(D)$. This shows that relying on a central server does not reduce the metadata overhead at the clients.

We prove our lower bound using an inductive information-theoretic argument, which we consider to be the novel technical contribution of this paper. For every $d\approx D/2$-bit string w, we construct a particular execution ${\alpha }_w$ of the protocol such that, at its end, the user-observable state ${\sigma }_w$ of some replica is a list of size $O(1)$ bits. We then show that, given ${\sigma }_w$, we can decode w by exercising the protocol in a black-box manner. This implies that all states ${\sigma }_w$ must be distinct and, since there are $2^d$ of them, one of these states must take at least d bits. The procedure that decodes w from ${\sigma }_w$ is nontrivial and represents the key insight of our proof. It recovers w one bit at a time using a “feedback loop” between two processes: one performs a black-box experiment on the protocol to recover the next bit of w, and the other reconstructs the corresponding steps of the execution ${\alpha }_w$; the messages sent in the reconstructed part of ${\alpha }_w$ then form the basis for the experiment to decode the next bit of w.

The class of push-based protocols, to which our metadata overhead lower bound proof applies, is specified with low-level properties that partially restrict implementation details of the protocol. We show, however, that under a weaker network model (defined in Section 7), if a protocol has invisible reads (which do not change the state of the replica), then being push-based follows from guaranteeing the higher-level property of eventual consistency. Hence, our lower bound also applies to protocols satisfying the latter property.