I throw myself upon the humble mercy of the gods that I might not make a
fool of myself (again) in front of the IETF. Nevertheless, here goes...
As I understand it, a goal of IPv6 Anycast is to provide implicit
connectivity to the "nearest" netwise instance of a given member of a
group of service providers. Now, granted, this is based on an "address",
not an address / port tuple, so it's more like a group of machines, than
service providers, right?
What work has been done to provide a "nearest service" type of implicit
addressing? From what I gather, SLP is for service *discovery*, but what
I'm really on about is not "what services are available", but "where can I
find *this* service, closest to me?"
The canonical example of this is (duh) FTP mirrors. CPAN does a pretty
good job of multiplexing you to the netwise closest mirror, but it's all
done relatively heuristically, if I understand it correctly, and it's done
from the CPAN main server side, which means it can't tune the response for
*you* in particular.
Is there work underway to "canonicalize" such discovery procedures and
formalize them into, perhaps, a "Services: Optimization of Reachability to
Those Available" (SORTA)?
This next bit, please generalize as much as possible. FTP is what I'm
thinking of this instant, because it's what triggered the thoughts, but I
wouldn't want to shoe-horn a perfectly non-crappy idea into one
application alone. Also, note that my thoughts on implementation might
suck, so feel free to "improve" them in the inimitable IETF way.
What I'm thinking of is something in which a client (say, FTP) is given a
list of, e.g., URLs of available instances of the *particular* service
(that is, mirrors that actually contain the data you seek). Thus, a list
of hostnames and ports, and, implicit in the protocol field of the URL, a
protocol intended to be used for the actual desired exchange.
The client then plugs all of this into the SORTA mechanism, which queries
an upstream SORTA cache, asking it for the nearest, fastest "match" out
of that set, based a loose characterization of that service.
So, for instance, the SORTA cache might know (based on statistics
collected over time) that the mirror at foo.example.com is close to me and
very fast for small FTP transactions, but unstable over time. It might
furthermore know that bar.example.com is slower, but very stable, so it's
better for big files.
Based on that knowledge, and the list of potential candidates I gave it,
it would respond with foo.example.com for a small file, and
bar.example.com for a large file.
Of course, that's not to say that an implementation has to be this
complex. An upstream cache may pick one at random :) Or it may pick one
solely based on ping times. And so on...
Some reasons I'm thinking along these lines are:
- ping / traceroute routinely get dumped on the floor by
congested routers and picky firewalls
- having every single client determine reachability to the entire
mirror list is a huge duplication of effort and waste of b/w
- having the server side determine reachability heuristically is a
guessing game, possibly educated (no offense to the CPAN folk)
I'm aware that FreeNet might provide much of this functionality implicitly
in its core architecture, but I've not yet looked into it too deeply.
SORTA also seems like a sort of (no pun intended) "reverse" approach to
things like Harvest (and, I suppose, FreeNet). Both Harvest and FreeNet,
as I understand it, look to bring the content closer to frequent
requestors of it. SORTA would take a less dynamic approach. Content would
stay where it is, but clients would be routed to the best instance.
Actually, that's not entirely true. Content *could* stay where it is, or
it could move, provided the master lists remained up to date (or there was
a mechanism for propagating changes throughout the SORTA cachespace). In
fact, SORTA could work together with the mirroring tools themselves to
move content to near mirrors based on SORTA caching information. Which
then *would* be like FreeNet :) Whee!
I'm also aware that there are "global load-balancing" tricks for doing
this. However, they require that you be in collusion with all mirror
instances, more or less. What I'm looking for is something that could
easily be joined / left by mirror members simply by adding / removing
entries from the master mirror list handed to a client.
Thanks for listening!
--
Tripp Lilley * tripp(_at_)perspex(_dot_)com *
http://stargate.sg505.net/~tlilley/
------------------------------------------------------------------------------
Me: "That was pretty gross, Andy. I can't believe you ate it after
I stuck it up your nose."
Andy: "It was a big grape and a small nose. It didn't get very far."
- outtake from perspex imageworks, inc., design meeting, circa 1994