From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199404271433.AA21700@oit.gatech.edu>
Subject: Re: Selecting URL from "equal" sites
To: hoymand@gate.net (Dirk Herr-Hoyman)
Date: Wed, 27 Apr 1994 10:33:05 -0400 (EDT)
In-Reply-To: <m0pw7xe-0004IXC@inca.gate.net> from "Dirk Herr-Hoyman" at Apr 27, 94 07:39:00 am
Dirk Herr-Hoyman said this:
> We've been chatting a bit about what might go in a URC to allow for URL
> selection. There's one case we haven't dealt with and it's one that's in
> front of us right way. How can you choose between "equal" sites? For
> example, how does one pick an archie server or GNN server?
>
> The "correct" URL in this case would be "closest" to me. Close could be
> hops or response time or some other metric. This is a tough nut to crack,
> but without it, we are likely to beat up on one server or pick a bad one.
I think this should probably be left up to the guys who work lower on
the protocol stack...
> There are 2 cases of equal servers that I am seeing:
>
> 1. Geographically/network. distributed.
One solution that I havn't had a chance to look at in depth is either
multicast or something called anycast that was being mulled about in
Houston. Basically it boils down to
a) multicast: you advertise a 'need' for something with a TTL that grows as you
'expand' your idea of closeness.
b) anycast: you connect to bla.gnn where bla.gnn will give you an IP address
that is an anycast address. Anycast means that any host can respond but
the first one is the one that the connection is setup to. This 'should'
give you the 'closest' occurence of a machine that advertises itself
as a gnn site.
I don't profess to know everything about anycast so if someone else can
elaborate I'd appreciate it.
> 2. Local load sharing.
I think this can easily be done with DNS shuffle records. Or am I
misunderstanding what your saying?
> I don't see that there's anything a publisher could put in the URC that
> would help for #1. Knowing the physical location doesn't always work. Top
> level domainnames are not always close. The only thing I see working, in
> my understanding of TCP/IP, would be to probe the net ala traceroute. But,
> that might really slow the resolution down (imagine probing ALL the archie
> servers when the link to australia is slow). The URC server could maintain
> a table of response times, but that doesn't necessarily apply to the
> client's route.
I'm sure there has to be some work going on in other areas of the IETF
on this. I know the servloc group has done something along these lines.
[Author trundles off to browse the IETF archives.]
> For #2, the URC server could perhaps randomly order the URLs in the UYRC,
> presuming that the 1st one will be chosen. I guess this is the fallback
> strategy for #1, where the URLs that are "close" (all archie servers in
> North America) are grouped and then returned in a random order. Then, a
> geographic location might be useful.
What might be usefull is a field for specifying either a) what
geographic area your in or b) what 'set of networks' you consider yourself
close too. For example, a URC for a document I mirror locally might be
URN:bla
URL:bla
Close-Nets: 128.61.0.0,130.207.0.0,[Suranet networks],[etc..]
Location-Geographic: US-East Cost
That way we 'know' atleast what I as the mirror site considers close.
-MM--
------------------------------------------------------------------------------
Michael Mealling ! Hypermedia WWW, WAIS, and gopher will be
Georgia Institute of Technology ! here soon via MIME. Your view of the
Michael.Mealling@oit.gatech.edu ! internet is about to change completely!