ken@gvax.cs.cornell.edu (Ken Birman) (11/28/89)
In article <SYLVAIN.89Nov25141240@burden.chorus.fr> sylvain@burden.chorus.fr (Sylvain Langlois) writes: >It seems to me that YP-like service is not suited at all for wide area >networks. Work has been done with X500, or X500-like, service. I admit >that X500 it far too complicated for handling "small" databases, but >it may be more accurate for huge volume of entries.... Let me comment that I have seen 3 comments along these lines; two came from "people" in "industry" working on YP redesign efforts of one sort or another, but neither had the appropriate permissions to post anything. I'll summarize what I understand to be the criticism here in a moment, but I also want to remind people that the idea here was to come up with a cute ISIS problem that could be solved in spare time, more or less for fun, but would also illustrate the power of the underlying system. So, we aren't really trying to replace YP/X500 with some ISIS service but rather to ask how far we can get with the least amount of effort possible using ISIS as a tool in our work! To summarize the criticisms I am hearing: 1) The scheme I am suggesting won't scale very well. 2) Any commercially viable product these days needs to be multilingual, e.g. speaking DEC, IBM and Japanese. 3) Why should anyone use ISIS to build a YP server, anyhow? The real issues are fault-tolerance, reconfiguration, etc, and unless ISIS makes these easier, it won't address the complex aspect of the problem. Sylvain only speaks about comment (1), my anonymous contacts raised (2) and (3) in their messages. A quick reaction 1) It isn't clear that the solution I suggest shouldn't scale. Recall that I argue for small (say 3-process) servers that "own" chunks of the YP data but with an import/export scheme whereby other servers can cache parts of this information. My reasoning is that 3 is a small enough set for fast updates, but a large enough one for fault-tolerance. The cached copies can be updated using a lazy call-back scheme (slow cbcasts). Viewed in the context of a huge system, this is a primary copy replication scheme. We would need a clever way to propagate updates, but I see no inherent reason that this should scale more poorly than other schemes. One can learn a lot from the papers on the Andrew file system in this regard -- they do a similar kind of caching. The choice seems to be between refreshing the remote cached copies and just invalidating them. Perhaps we can design a mechanism that mixes these modes depending on the frequency of reference to cached data? 2) Well, this is just a homework problem. I agree, if I were trying to commercial product I might have to worry about these things. But, we could always jam some sort of gateway into our model after we get the basic thing straight, so it (again) isn't clear to me that we can't end up with a heterogeneous solution starting from what I propose. Who knows, maybe the comp.sys.isis "product" can get to market first and cover these issues too? 3) This argument was made by someone who actually pointed out how hard it is to deal with failures, reconfiguration, replication and consistency and hence said that we _shouldn't_ try to build the thing on ISIS. My guess is that the writer actually knows a lot about YP and hence realized that these are important issues, but doesn't know much about ISIS at all and hence didn't realize that this is what makes the problem attractive in an ISIS context! (In fact, the comment was prefaced by a remark that the writer wasn't a regular reader of this newsgroup). The whole point, in my view, is that our solution will have many of these properties more or less for free. An "ad-hoc" solution is far less likely to have these necessary characteristics. I'll add one concern of my own: 4) What about network partitioning? A reasonablly scalable YP service will need to span LAN's and hence it isn't reasonable to envision a single ISIS environment spanning all servers. My hope is that we can use the ISIS long-haul scheme to get around this. More comments? Rebutals from our anoymous readers? (Forward them to me and, if you so desire, I will be happy to repost without names or affiliations). Ah, the pleasures of academic life! Ken