Re: Directory Services Work coordination proposal

Masataka Ohta <mohta@necom830.cc.titech.ac.jp> Sat, 13 November 1993 06:36 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27290; 13 Nov 93 1:36 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27286; 13 Nov 93 1:36 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa05885; 13 Nov 93 1:36 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.00997-0@haig.cs.ucl.ac.uk>; Sat, 13 Nov 1993 05:57:30 +0000
Received: from necom830.cc.titech.ac.jp by bells.cs.ucl.ac.uk with Internet SMTP id <g.07349-0@bells.cs.ucl.ac.uk>; Sat, 13 Nov 1993 05:57:16 +0000
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 13 Nov 93 14:49:24 +0900
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta@necom830.cc.titech.ac.jp>
Return-Path: <mohta@necom830.cc.titech.ac.jp>
Message-Id: <9311130549.AA27719@necom830.cc.titech.ac.jp>
Subject: Re: Directory Services Work coordination proposal
To: Simon Spero <ses@hillary.oit.unc.edu>
Date: Sat, 13 Nov 1993 14:49:23 -0000
Cc: jcurran@nic.near.net, ses@tipper.oit.unc.edu, leiner@nsipo.nasa.gov, Erik@necom830.cc.titech.ac.jp, Huizer@necom830.cc.titech.ac.jp, "Erik.Huizer" <Erik.Huizer@surfnet.nl>, osi-ds@cs.ucl.ac.uk, ietf-wnils@ucdavis.edu, apples@surfnet.nl
In-Reply-To: <Mailstrom.B53.8456.1101.ses@hillary.oit.unc.edu>; from "Simon Spero" at Nov 13, 93 11:40 pm
X-Mailer: ELM [version 2.3 PL11]

> If and when it becomes possible to get live, useful, congestion information out
> of the network then the paradigm changes slightly. The search technique
> described in my previous message doesn't guarantee optimal results; it merely
> predicts good results. 
> The obvious mechanism for extending the algorithm would be to get the first
> result, and  check to see if it is "good enough" for some definition of "good
> enough".  If the check fails, then the search should be continued where it left
> off.

I think it the issue is not necessarily searching but the selection
of the best servers.

Selection by the client side is the issue to be solved by policy routing.
That is, if a policy is rich enough to select the best route to some server,
it is also good enough to select the server with the best route.

But, if we urgently need it some static scheme should be developed.

Selection by the servers' side was once addressed in DNS load balancing
sub WG and, I think, a solution was presented.

						Masataka Ohta