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
On 07/14/2014, 12:42, "Sebastian Kiesel" <[email protected]> wrote:
>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
>
>
>On Mon, Jul 14, 2014 at 12:18:14PM -0400, Wendy Roome wrote:
>> 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
>>
>>
>>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
