Subject: Anycast and related frobs

From: Tripp Lilley <[email-masked]>
Date: Mon, 26 Jun 2000 07:43:03 +0000 (/etc/localtime)

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  *  [email-masked]  *  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

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 26 Jun 2000 11:22:27 +0200

From: Tripp Lilley <[email-masked]>
Subject: Anycast and related frobs
Date: Mon, 26 Jun 2000 07:43:03 +0000 (/etc/localtime)

Tripp,

> find *this* service, closest to me?"

At the 46th IETF in Washington there was a Anycast BOF, chaired by
Steve Deering. In there where a few presentations on diffrent aspects of
anycast. Then, when the question was raised to the floor on weither there
was a need to form a anycast group few hands where raised.

The conclusion was that the real need of Anycast was limited (i.e. DNS,
PIM RPs and possibly a few other services) and that no specific architecture
where needed. Whatever needed was allready there or few trimmings where
required.

For instance was UUNETs usage of Anycast for PIM Rendez-vous Points presented.
They used a trick which seems to be accepted as the only thing really
required to acheive the anycast service. They uses an unicast IP address which
they set common for all the RPs that so require, then they insert this IP
address into the normal unicast routing and the routing will find the
"best" path. While it migth be a bit confusing that it is actually diffrent
physical positions this is really not diffrent than having a multihomed box
having access to widely separated network segments.

Mr. Ohta presented the usage of Anycast in DNS root server handling over
multiple ASs.

The GIA proposal was a proposal for a complete anycast architecture according
to the ideas as presented with IPv6.

Anyway, you check these presentations and the report from the meeting in case
you have not yeat done so.

So, there is even some form of Anycast support in IPv4.

I am sure that Mr. Deering, Mr. Alvestrand and Mr. Ohta can contribute further
on this issue if so required.

Cheers,
Magnus