Minutes of the Wide Area Service Location (wasrv) Working Group
There were 76 people in attendance.
I. Agenda Bashing
Web page is http://www.bell-labs.com/mailing-lists/wasrv/
Mailing list: wasrv@lists.research.bell-labs.com
To subscribe: wasrv-request@lists.research.bell-labs.com
(Use "subscribe" in the body).
II. Architectural Principles (e.g., What is the problem?)
An issue was raised about what is "location". Location is to be taken about "location in the Internet".
Another issue was raised about what type of server was being discussed. The question was deferred for a later slide.
During the Server Model slide, the question of what constituted a service was raised again. Specifically, is a service a user or a machine? The answer is that for this context restrict a "service" to a machine rather than a user.
A supporting comment was made that we are picking some from many rather than one from many and that is not as optimal for finding people.
Another issue raised was that no discussion of load distribution had been made and would it be discussed and if so, how was it to be done. Answer is that at this point, the phrase "mildly dynamic" is to be taken as changing on a time scale that is slower than that possible for considering load distribution, so it would not be considered. There was agreement on this point.
An issue was raised about "can you be looking for a group, or only one" (i.e., can anycast or wildcard searches be used), suggestion that it is desirable to return a group rather than one.
The issue of authentication was raised. It was agreed that any scheme would require authentication.
The point was made that the Answer Consortium in the UK solved this 3 or 4 years ago with the concept of a "federated trader". A service would register in terms of an IDL and a client would go to a trade and do bounded request. Bounds could be modified. Further, if a desired service was not available traders were equipped with factories to instantiate the desired service. Erik was familiar with this and looked into it 2.5 to 3 years ago, but was concerned that it seemed to lose impetus about 6 months later. What seems to have happened is that it is still be used in the UK and Australia and that the consortium moved on to other things. Erik took this issue of looking into this to see how much of it would be applicable to what is being discussed here.
Issue raised on whether "mildly dynamic" implies quality of service. At this point, "mildly dynamic" is not a concrete definition, but quality of service might be part of the query rather than the service.
Issue raised about content. Where is the line between "associated with foo" and "content based". Answer that the system is "mildly content based" (after some discussion, which included the agreement that a full content system was not the intent, but that content discussions were a slippery slope). This position was supported by later discussions.
Points were made that this is a meta-system for finding stuff.
The discussion of measure distance was raised. It was pointed out that in some applications it would be good to get the closest server. The HOPS BOF was discussed with some of the outstanding issues. The ADs feel, however, that the problem of finding the closest server is outside the scope of this BOF (or resulting WG).
As the discussion progressed, the question was raised that how much of this is actually different from the problem as solved by SVRLOC. The point is that extending SVRLOC is one possible way to solve the problem. However, it was agreed that extension has scalability issues. Another opinion was that this is profoundly different than what was handled in the SVRLOC WG.
At this point, the discussion shifted to talking about the problem space.
The point was raised that there were a lot of protocols that dealt with portions of this problem space and that a lot of analysis work for determining if a new protocol was needed would be necessary. This was agreed to and that the existing analysis was crude at this point.
A question was raised about the economics of use. Charlie Perkins presented a proposal to leverage off of existing Web Crawler and Spider technology. The idea is to embed templates as meta-info on the home page. Crawlers would pick this information up and then users would query the crawlers for information.
After this proposal, the issue of reliability was raised. Should a WASRV server give all answers or just some answer. The reply is that the web is not reliable and still works, so it is possible to build a service where links are unreliable.
Jonathan Rosenberg then gave a presentation on a scheme to extend SRVLOC to the wide area. An (or the) outstanding issue is that it is based on wide area multicast that doesn't exist today.
Another outstanding issue is that even if it did exist, how long would it take to deploy the technology. In addition, it is possible to build a solution using existing technology today. Problem is, it doesn't scale. While it was admitted that deployment is an open issue, this approach does allow some bootstrapping and is not incompatible with the first proposal. It could evolve from one to the other as it grows.
Another issue brought up was that the use of broker advertising implies an underlying distributed database which adds responsibility for ensuring that data is not stale. In SVRLOC, info is aged out and if this approach was used for WASRV, a similar mechanism would be used. Alternatively, a protocol could be designed to ferret out the stale info.
Another approach is the approach used by Kohei Ohta, et al in which they use passive monitoring of RMON messages to populate a directory.
At this point, it was proposed that focusing on having a particular taxonomy would be useful. If interested parties went off a determined a common schema for spiders to find would be a large step forward in giving folks something to experiment with. There was general support for breaking the problem down into manageable pieces and solving each one. It was agreed that this would be a first step for interested parties on the mailing list. Intent is to take the template from SVRLOC and see if they apply to WASRV, removing those that don't and adding those that do.
WASRV - Problem Definition, Protocol Overview, and Open Issues
WASRV Architectural Principles
WASRV and LDAP