After reviewing the 2.* alternatives more carefully, I think 2.1 & 2.2 are not
practical. First, they only work for Endpoint Cost queries; since the pid maps
vary from server to sever, 2.1 & 2.2 won't work for anything else. Second, the
analogy with DNS breaks down. With DNS, everyone has the same address for a
name; you just have to find the first server that has it. With alto, every
server has a cost. You need to decide which is most accurate. Right now there
is no way to determine that.
That leaves 2.3, which pushes the problem to the client. That requires a
central alto server registry, plus a way for a server to declare its area of
cost expertise.
As for incentives for an alto provider to register their server with some
central repository, I don't see that as a problem. If an ISP offers alto, they
want people to use it. So they will want to promote their alto server. Just
like someone with a public web site wants google to know about it.
The more important question is, what are the incentives for an ISP to offer an
alto server in the first place? :-)
- Wendy
> On Mar 25, 2015, at 6:23, Sebastian Kiesel <[email protected]> wrote:
>
> Hi Wendy,
>
>> On Tue, Mar 24, 2015 at 05:22:55PM -0500, Wendy Roome wrote:
>> 2.4 is fine when the client wants costs to or from the client. But it
>> will not work well for a p2p tracker, which wants costs between
>> arbitrary endpoints, even if they are all on the other side of the
>> planet.
>
> Why do you think that this will not work well? The tracker will have
> to contact a large number of ALTO servers and assemble a virtual map
> based on the snippets it can get from these ALTO servers.
> This is basically shifting the aggregation problem from server side
> to client side.
>
> approach 2.4 is analyzed in more detail in
> https://tools.ietf.org/html/draft-kiesel-alto-xdom-disc-00
>
> In addition to issues like overhead and caching efficiency, another
> aspect might be legal liability. Being an access network operator in
> Europe, I am a bit reluctant to publish costs from, say, an access
> network in Japan to an access network in the US through my ALTO server.
> This is not only a question of map size and processing load on my
> server. What happens if I wreck some other network operator's traffic
> engineering or business model by giving wrong cost information or by
> redirecting to the wrong ALTO server? That's why I would prefer
> approaches 2.3 or 2.4. (This paragraph is about an "open Internet" use
> case).
>
>> For that, you want 2.2 or 2.3. The problem with those is how do you know
>> which alto server to use?
>
> 2.1 and 2.2 is basically the same problem. All ALTO servers need to
> know which other ALTO servers are authoritative for which parts of the
> map. They need a protocol to exchange this authority information.
> Whether they fetch the data from there on behalf of the client,
> or whether they tell the client "go fetch it from there on your own"
> is mostly a question of caching efficiency.
>
> 2.3 is "why not just use your favorite web search engine to find the
> right ALTO server?" - although I have some doubts regarding the incentives
> for the operators of such search engines for indexing ALTO servers.
>
>> One possibility is to attach an "I have authoritative vista for this
>> set of endpoints" attribute to network maps. Then (given a master list
>> of alto servers) a tracker can select the alto server that is best for
>> the tracker's client.
>
> This sounds similar to draft-kiesel-alto-alto4alto.
> The question is: how would the operator of a network with his ALTO
> server join the authority map? We would have to establish an
> administration office where the can register (possibly IANA?).
> In contrast, the xdom-disc draft tries to re-use DNS as an already
> established rendez-vous point, so no new administration would have
> to be created.
>
>
> Sebastian
>
>>> On Mar 24, 2015, at 2:39, Sebastian Kiesel <[email protected]> wrote:
>>>
>>> Hi Piotr,
>>> Hi Richard,
>>> all,
>>>
>>> first of all do you have any specific multi-domain ("partitioned") use
>>> case in mind? Our original P2P use case certainly was, but it has become
>>> quiet around it. For the newer use cases such as CDN or VPN optimization
>>> or stuff related to SDN im am not so sure whether we need that.
>>>
>>> I remember that many years ago we had detailed discussions how the
>>> partitioned-knowledge-problem could be solved. We had several approaches:
>>>
>>>
>>> 1. all ALTO servers have the same knowledge
>>>
>>> 1.1. ensure synchronization in the provisioning protocol (cf.
>>> RFC 5693, Fig 1), which is currently not standardized
>>>
>>> 1.2. standardize an inter-ALTO-server data replication protocol
>>>
>>>
>>> 2. different ALTO servers operated by different organizations (e.g.
>>> ISPs) do NOT have the same (global) knowledge
>>>
>>> 2.1 ALTO clients can connect to any server and that first server
>>> will fetch the data (similar to an iterative DNS query) on behalf
>>> of the client, based on some kind of inter-ALTO-server
>>> request forwarding protocol
>>>
>>> 2.2 ALTO clients can connect to any server and that first server
>>> will redirect the client to the "right" ALTO server that has the
>>> desired information, based on some kind of inter-ALTO-server
>>> authority information exchange protocol
>>>
>>> 2.3 ALTO clients need to use some kind of "search engine" that
>>> indexes ALTO servers and redirects and/or gives cached results
>>>
>>> 2.4 ALTO clients need to use an external discovery mechanism (e.g.
>>> based on a DHT or on DNS) to discover the ALTO server that has
>>> the desired information
>>>
>>>
>>>
>>> My opinion is that for a small scenario with only a rather limited
>>> number of federated domains, approach 1.1 should be sufficient. No
>>> need to standardize anything here.
>>> For a true Internet-scale scenario (e.g., the P2P use case), I do not
>>> like the 1.? approaches, and I think that 2.4 is more realistic, for
>>> reasons that I already outlined in this post:
>>> http://www.ietf.org/mail-archive/web/alto/current/msg02547.html
>>>
>>> One possible solution that follows the 2.4 approach is the xdom-disc
>>> draft (currently expired, I'm working on a new version).
>>>
>>> Thanks
>>> Sebastian
>>>
>>> _______________________________________________
>>> alto mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
