Re: [alto] Inter-ALTO

[Wendy Roome <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/alto