Subject: Re: [alto] Yet another ALTO discovery technique

From: Wendy Roome <[email-masked]>
Date: Mon, 14 Jul 2014 12:18:14 -0400

Sebastian et al,

Has anyone considered the following ALTO server discovery mechanism? Create
a global registry of all public ALTO servers, with a well-known, persistent
uri. We would strongly encourage anyone who fields a public ALTO server to
register it. Since (presumably!) ISPs and the like want customers to use
their ALTO servers, I think it would be easy to get them to register the
servers.

So what would the interface be? Why ALTO, of course! Specifically, the
global registry would be an ALTO server with an Endpoint Property Service
(and the PID Property Service, draft-roome-alto-pid-properties
<https://datatracker.ietf.org/doc/draft-roome-alto-pid-properties/> ,
assuming that extension is adopted) with the property
³Preferred-ALTO-Server², whose value is the URI of ALTO server with the best
local knowledge around that endpoint.

If this is a PID property, a p2p tracker could download the network map and
full set of PID properties, so it would not need to consult the global
registry for each request.

I think this is the moral equivalent of getting the ALTO server through DNS,
except that it doesn¹t require updating DNS tables. And it allows clients
like trackers to discover the ALTO server for remote regions.

Comments?

- Wendy

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 14 Jul 2014 18:42:42 +0200

Hi Wendy,

this idea sounds like draft-kiesel-alto-alto4alto-00 ...

The question is: what is less cumbersome and unlikely to happen - update
the DNS reverse tree and re-use the root name servers as a rendezvous
point, or create and maintain your own global registry and root-alto-server
infrastructure?

My personal opinion is that both options will be a pain to implement,
but the first one a little less...

What do you think?

Thanks,
Sebastian

---

From: Wendy Roome <[email-masked]>
Date: Mon, 14 Jul 2014 14:19:11 -0400

I think the relative ease depends on your point of view.

First, I must confess that I am very comfortable with writing,
provisioning & querying an ALTO server (I'm sure that's a big surprise!).
But for me, DNS is more of mystery. Yes, I looked over the RFCs once upon
a time, and I've done some simple experiments. But normally I don't query
DNS directly (I let the OS map domain names to address), and I've never
configured or maintained a production DNS server.

So I'll admit to an obvious bias for ALTO-based solutions over ones that
use DNS.

That said, I think the central ALTO server registry would be much simpler
for applications like trackers. A tracker already knows how to query an
ALTO server. But the DNS solution requires a tracker application to query
DNS servers directly, doesn't it? That would require a new set of
expertise. And even if the programmers used a standard DNS library, they
still have to learn how to use that library. And (I suspect) learn a lot
about the underpinnings of DNS while testing it.

Correct me if I'm wrong, but doesn't the DNS algorithm require multiple
queries to multiple DNS servers? So wouldn't that lookup be slower than a
single query to an ALTO server?

With a central ALTO registry, and with PID properties, a tracker could
download the entire map of ip addresses to preferred ALTO servers, and use
that local copy to lookup the server for a new client. But with the DNS
approach, wouldn't the tracker have to go through that reverse DNS
algorithm for every new client address?

>From the viewpoint of ISPs providing ALTO servers, I agree that extending
their DNS server(s) is easier than sending updates to a separate central
registry. And the DNS solution is distributed, does not have a central
bottleneck, etc.

On the other hand, if the organization running a public ALTO server does
NOT also manage the associated DNS server(s), wouldn't that organization
have to persuade whoever does to add DNS records? Will that be a major
administrative problem? And even if the same company runs the ALTO server
& DNS servers, might the company so large that there are internal
turf-wars between those departments?

Finally, a problem with the central ALTO server registry is someone must
provide & maintain it, and it's a potential bottleneck. However, if we
assume the mappings don't change often, and if we use PID properties, that
registry server only needs to provide relatively static get-mode services,
and those pages could be cached by http proxies.

	- Wendy

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 14 Jul 2014 22:44:48 +0200

Hi Wendy,

> I think the relative ease depends on your point of view.

Right. So we need to ask those who will have to run ALTO.

> configured or maintained a production DNS server.

draft-kiesel-alto-3pdisc-impl-00  gives a prototype implementation
and a small self-contained test bed for an older version of the 3pdisc
algorithm.  The algorithm has changed since, and I will have to update
the implementation, but maybe you want to have a look at it to get an
idea about the complexity. Questions welcome :)

> So I'll admit to an obvious bias for ALTO-based solutions over ones that

I get your point, but ALTO will not be run by researchers or software
engineers; it will be the network operators that will have to do the
job. Running DNS is part of the very core business of an ISP!
And many application protocols use DNS for application layer routing
and/or server discovery, e.g. SMTP, SIP, etc.  So this is a rather
well-understood topic.

> queries to multiple DNS servers? 

walking down the DNS tree may need several queries, but the DNS library
will hide that from you, and caching of (intermediate) results will make
it efficient.

> So wouldn't that lookup be slower than a

probably yes. but I think it will be fast enough[tm].

> algorithm for every new client address?

there will be caching on two layers:  

First, recursive DNS servers will cache DNS results. This is hidden
from the application (programmer).

Second, if I call the procedure with one IP address as a parameter,
I will eventually download a network map with a "cost vector" (see other
mails from today for reasoning about vector vs. matrix), which gives the
costs from one or more prefixes (!) to all other destinations in the
Internet.  If I am shortly after interested in another IP address from
within the same prefixes, I won't have to call the procedure again.

> have to persuade whoever does to add DNS records? 

My point of view is: The entity that controls reverse DNS for an IP
address is the one who controls which ALTO server should be used for
optimizing traffic from/to that address.

The question is, what happens if these people are not interested in ALTO
but someone else ("the router people") is?

> Will that be a major

Hard to tell.  We don't know the internals of all the large companies
out there ;)  But in general, DNS people will have to talk to both the
router people (for the reverse DNS) and to the applications people
(about fancy server names, mail routing, IP telephony routing, etc.).

There is a more serious issue: for some (large!) address ranges there
are no reverse DNS delegations to the organizations that the addresses
have been assigned to.  Some people in the DNS community seem to think
that reverse DNS is useless and too cumbersome to maintain and obsolete
anyway.  But I see no compelling reason why these delegations couldn't
be made, if there was an important use case (ALTO discovery! ;) ). 
RFC 7216, which is quite new, tries to do a similar thing - hopefully
the momentum will be strong enough that reverse DNS will be maintained
in the future.

> and those pages could be cached by http proxies.

I have no idea how small or large the change rate would be.  Judging
from my inbox, there seems to be a market for selling even rather small
IP prefixes.
But even if the change rate is near zero, just maintaining an address
and making sure that someone reads incoming mail on a regular basis
is a huge effort if that has to be done "forever".

To summarize, I don't think that xdom-disc is nice and easy to do. But I
think it is the least painful option we have, if the starting point is
the knowledge that an average ISP or IT department has.

Any thoughts?

Thanks
Sebastian