Hi Wendy,
On Mon, Jul 14, 2014 at 02:19:11PM -0400, Wendy Roome wrote:
> I think the relative ease depends on your point of view.
Right. So we need to ask those who will have to run ALTO.
> 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.
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
> use DNS.
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.
> 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?
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
> single query to an ALTO server?
probably yes. but I think it will be fast enough[tm].
> 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?
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.
> 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?
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
> 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?
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.
> 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.
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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
