Re: [alto] Inter-ALTO

[Sebastian Kiesel <[e-mail]>]

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