Re: Directory Services Work coordination proposal

Simon Spero <ses@hillary.oit.unc.edu> Sat, 13 November 1993 04:55 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25137; 12 Nov 93 23:55 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25133; 12 Nov 93 23:55 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03452; 12 Nov 93 23:55 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.00705-0@haig.cs.ucl.ac.uk>; Sat, 13 Nov 1993 04:43:12 +0000
Received: from tipper.oit.unc.edu by bells.cs.ucl.ac.uk with Internet SMTP id <g.17249-0@bells.cs.ucl.ac.uk>; Sat, 13 Nov 1993 04:42:54 +0000
Received: from hillary.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA11380; Fri, 12 Nov 93 23:42:18 EST
Date: Sat, 13 Novermber 1993 23:40:56 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Simon Spero <ses@hillary.oit.unc.edu>
To: John Curran <jcurran@nic.near.net>
Subject: Re: Directory Services Work coordination proposal
Cc: Simon E Spero <ses@tipper.oit.unc.edu>, "Barry M. Leiner" <leiner@nsipo.nasa.gov>, Erik Huizer <Erik.Huizer@surfnet.nl>, RARE & IETF OSI-DS wg <osi-ds@cs.ucl.ac.uk>, ietf-wnils@ucdavis.edu, apples@surfnet.nl
Message-Id: <Mailstrom.B53.8456.1101.ses@hillary.oit.unc.edu>
In-Reply-To: Your message <9311130355.AA11331@tipper.oit.unc.edu> of Fri, 12 Nov 1993 22:51:53 -0500
Content-Type: TEXT/plain; charset=US-ASCII

  > Long term, it would be preferable if the network could actually answer
>some questions regarding the path to a given destination.  This would allow
>the client to make a decision based on it's priorities.  For example, you may 
>have different criteria for the "site to retrieve RFC big.ps from right now"
>and the "site which my archive mirrors from".
>   Does this make any sense?

It didn't for a bit then I read it carefully, and then it did :-)

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.

Mirroring is a totally separate issue; there the prime concern is making sure
what you're mirroring is actually the right version. Secondary sites can very
easily get out of sync,
especially when it comes to removing invalid files. Studying the aftermath of
the great X11/contrib/JIS whoops of 93 showed the latencies that could be
involved. It also showed  some of the real limitations of polling based systems
like archie.
 
Simon
p.s. 
 (For people who don't run archive sites, or who don't mirror X11; the incident
I'm referring to was the time when some enterprising individuals discovered a
writable directory on expo.lcs.mit.edu, and uploaded 600Mb of pornographic jpegs
just before the weekend. When it came time for everybodies nightly mirror, all
these files got transferred to all mirroring sites. Then along came archie,
which found saw all these nice new files and added them to its listings, where
they would stay for the next N weeks until it 
was polling time again. For weeks afterwards we were getting requests for people
to be allowed access to the "secret files" which archie said were there.)