Subject: Re: [alto] Inter-ALTO

From: Wendy Roome <[email-masked]>
Date: Wed, 25 Mar 2015 09:02:02 -0500

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

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 25 Mar 2015 16:31:53 +0100

Hi Wendy,

2.1 and 2.2 are similar because both would require some kind of mesh
between ALTO servers for exchanging authority information.

2.3 and 2.4 are also similar, because the authority information is
collected, stored, and used for (re)direction on logical entities that
are not ALTO servers (of course they could be co-located on the same box).

2.3 would use some kind of web search engine technology. I did not
register my web site at google or bing but they can be found there.
Maybe somthing like that would also work for ALTO servers.  I'm just
wondering what would be the incentive to operate such an engine - banner
ads or sponsored links probably won't make sense here.

2.4 requires an explicit registration of the ALTO server in a database.
This could be either a new database (alto4alto) with its own
administrative organization (who is willing to run that office?) 
or it could re-use an existing service such as DNS (xdom-disc).

My preference is the last option because it allows for gradual
deployment and the "owners" (ISPs, large companies, universities) of
IP prefixes can announce which ALTO server (either their own or one
operated by a third party) has authoritative information about costs
for traffic from/to that prefix, without the need to talk to anyone
(assuming that DNS configuration is already in place).

Thanks
Sebastian

p.s.  partitioned knowledge and the fact that every ALTO server may
define its own set of PIDs are indeed problematic. So exchange of
authority information (approaches 2.1 and 2.2) should be based on IP
prefixes only, or on a common network map. The other approaches would
require re-mapping of PIDs in order to assemble the map snippets
received from other ALTO servers into a virtual full map - this can be
done server-side (1.2), search engine side (2.3) or client-side (2.4).

---

From: Piotr Wydrych <[email-masked]>
Date: Wed, 25 Mar 2015 10:54:22 -0500

Richard, Sebastian, Wendy,
All,

Thank you very much for your comments.

I liked very much that Richard brought the issue of partitioned 
networks, which I was not thinking of before. The solutions for various 
sets may be totally different and we may have to discuss it thoroughly.

> between ALTO servers for exchanging authority information.

What I'm trying to solve though inter-ALTO is, among others, the issue 
that the current version of ALTO protocol can provide only a cost of 
uploading data, not downloading them. A local ALTO server (local ~= in 
the same ISP as the client) can easily gather all needed information 
(i.e., BGP upstream paths, IGP paths, link charging policies) to compare 
endpoints wrt. the cost of uploading data to them. Thus, a client can 
easily send a query to the server and get maps and/or a rating. 
Contrary, if a client queries ALTO servers in remote ISPs, it will get 
routing costs or ordinal ratings that it cannot compare, as each ISP 
applies its own metrics. Even if a local ALTO server ask remote ones for 
rating of its clients, it can do nothing with the gathered information. 
This issue is significant for both old (P2P) and recent (VPN, CDNs) ALTO 
use-cases. Using Sebastian's notation (thanks!), I was thinking of 
something like 2.1 + common method for exchanging an extract of network 
topologi information between ALTO servers.

Best,
Piotr 'GhosT' Wydrych
-- 
Piotr 'GhosT' Wydrych .. xmpp:wydrych//agh.edu.pl .. http://wydrych.net/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

---

From: Wendy Roome <[email-masked]>
Date: Wed, 25 Mar 2015 16:30:11 -0500

For download costs, can't the client do an ECS request with dst=my-addr and src=server-addr? Or did I misunderstand your problem?

    - Wendy Roome

> On Mar 25, 2015, at 10:54, Piotr Wydrych <[email-masked]> wrote:
> 
> What I'm trying to solve though inter-ALTO is, among others, the issue that the current version of ALTO protocol can provide only a cost of uploading data, not downloading them.

---

From: Piotr Wydrych <[email-masked]>
Date: Wed, 25 Mar 2015 17:41:41 -0500

Wendy,
All,

> For download costs, can't the client do an ECS request with dst=my-addr and src=server-addr? Or did I misunderstand your problem?

Indeed, a client may ask for such a ranking (or search for needed 
information in the maps). The issue is that:
1. If it asks a remote ALTO server, it will get the remote ISP's cost of 
uploading data from server to a client, not local ISP's cost of 
downloading them.
2. If it asks a local ALTO server, the server may be unable to assist 
the client. I.e., it may return nothing valuable or totally nothing. To 
compute a cost of downloading the data (and/or rank endpoints according 
to the download cost) the ALTO server needs to know the download path 
(e.g., the interface through which the traffic is entering the local 
network or number of AS hops).
In my opinion we must assume that a client connects to the local ALTO 
server, as this gives the ISP more control (and, thus, inventives to 
provide ALTO information to its clients). I can imagine easily that an 
ISP provides the service for its clients and disallows remote clients to 
use it.
Thus, the entity that need to gather more information is the local ALTO 
server. And this is one of my primary use-cases for inter-ALTO.

Best,
Piotr 'GhosT' Wydrych

---

From: Wendy Roome <[email-masked]>
Date: Thu, 26 Mar 2015 09:59:03 -0400

Ah! Now I see the problem. To restate it, suppose a client uses an
ISP-centric ALTO erver. It has detailed data for the ISP¹s networks, but
(as an extreme) puts everything else in one PID.

Then if the client asks for costs to (or from) the client to N servers,
all of which are in the ³other² PID, the client will get the same cost for
all N servers. So if some of those N servers have really bad connectivity,
because of conditions known only to the ISP at the remote end, the local
client will try to use those bad servers.

I don¹t think that has anything to do with upload vs download, though. It
is just a general problem that an ISP-centric ALTO server¹s costs will not
be able to reflect problems outside the ISP¹s network.

	- Wendy Roome

On 03/25/2015, 18:41, "Piotr Wydrych" <[email-masked]> wrote:

>> For download costs, can't the client do an ECS request with dst=my-addr
>>and src=server-addr? Or did I misunderstand your problem?
>

---

From: Piotr Wydrych <[email-masked]>
Date: Thu, 26 Mar 2015 09:11:11 -0500

Wendy,
All,

> be able to reflect problems outside the ISP¹s network.

I used the upload-download asymmetry use-case just because everybody is 
(should be?) aware of the asymmetry of routes in the Internet and it is 
easy to explain. You got to the point - I would like to be able to 
provide the ALTO servers with more information than available from the 
local topology information sources.

Best regards,
Piotr 'GhosT' Wydrych