Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!batcomputer!llenroc!cornell!ken From: ken@gvax.cs.cornell.edu (Ken Birman) Newsgroups: comp.sys.isis Subject: lazy replication Message-ID: <53124@cornell.UUCP> Date: 14 Mar 91 20:09:00 GMT Sender: nobody@cornell.UUCP Reply-To: ken@cs.cornell.edu (Ken Birman) Distribution: comp Organization: Cornell Univ. CS Dept, Ithaca NY Lines: 56 > From: jyl@Eng.Sun.COM (Jacob Levy) > Message-Id: <9103131904.AA01088@noam.Eng.Sun.COM> > To: ken@cs.cornell.edu > Subject: Interesting Paper > Status: R > Barbara Liskov's paper about Lazy Replication in the 1990 PODC > proceedings seems to contain protocols which are very similar > to ISIS. They compare their approach to ISIS and seem to claim > that their one is more efficient for both the > normal case (no failures) and for failure detection, and also > that it is more robust for network partition. > Can you post a comparison to comp.sys.isis? A comparison between our work with the lazy replication protocols appears in the most recent TR on our version ("Lightweight Causal and Atomic Group Multicast"). Basically, their paper compared the Lazy Replication scheme with the old ISIS protocols. Our new protocols are at least as efficient as Lazy Replication in all of these aspects, and actually include some performance enhancements that the LR scheme didn't have (at the time they wrote the PODC paper, at any rate). For example, our new paper includes faster group view management protocols and a VT compression scheme that appear to be big wins. As it happens, the measured latency of our OLD protocols was comparable to the LR figures in the PODC paper (our cbcast protocol, used asynchronously, runs at the same speed as the protocol they evaluate in section 3.6.1 of their paper). Our recent paper reports the performance of the NEW cbcast protocol, which runs about 5 times faster than either our old protocols or the LR scheme. Regarding the robustness issue, LR uses a stable storage/logging scheme, while ISIS only uses logging if you explicitly enable it. When you do use logging in ISIS (or long-haul spooling) you can get the same level of availability out of our system as you can from theirs. We prefer not to log in the normal case because we prefer to reduce the overhead as much as possible for the average cbcast -- this is part of the reason our stuff is faster. In more general terms, it is worth noting that the basic LR protocol and the ISIS "lightweight causal cbcast" protocol are really very similar in the single group cases. The main differences, unless you focus on detail, are that we support large numbers of overlapped groups, and that our handling of client/server structures is somewhat more general then theirs. We do this because we need both features in ISIS; one implication is that our scheme scales well, even to very large networks. Their scheme could be extended the same way, of course -- perhaps even using our methods. I can provide more details on the fine points if people request them. Ken Birman ---------------------------------- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office)