Re: [alto] Cost Maps, Endpoint Cost Maps and Coarse Grained Searches

[Wendy Roome <[e-mail]>]

Lyle,

Here is my opinion on Endpoint Cost Service (ECS) vs. Network Maps & Cost
Maps (NM/CM): They are two different ways to present the same data. They
are different viewports into the same data, if you will, with different
levels of detail, and different performance and ease-of-use.

To start, I believe most clients will prefer ECS. Clients really care
about costs between endpoints; PIDs and Network Maps are irrelevant. For
example, consider a Bittorrent peer which gets 50 new peers every 15
minutes or so. That ALTO client would prefer to send an ECS request to the
ALTO server to rank those peers, rather than fetching full maps,
converting endpoints to PIDs and looking up the costs between PIDs.

For a client, ECS is simple & easy to use: the client does not have to
maintain any maps, and the client gets the latest cost data.

Now consider a busy Bittorrent tracker. It gets 10+ requests/second, and
for each request, it must select 50 out of (say) 5,000 peers. If the
tracker used ECS, it would have to send 10 ECS requests a second, each
with 5,000 endpoints. That would add too much latency to the tracker
response, and would overload the ALTO server.

So a tracker client would prefer to download the full NM/CM and evaluate
costs locally, without involving the ALTO server each time. That requires
more programming effort, but is more efficient.

Here is another piece of historical motivation that is not clear in the
RFC: we expect ALTO Servers will be offered by network service providers.
Some providers will be (understandably!) reluctant to publish a detailed
breakdown of their internal network. The NM/CM model allows a service
provider to control the level of detail it wants to make available to the
outside world.

Incidentally, the RFC says an ALTO Server MUST provide an NM/CM, while ECS
is optional. Personally, I think that is a mistake. I think NM/CM should
be optional, and ECS should be required.

So if you are writing a server, I recommend you build an internal cost
map, with as high a level of detail as practical. Offer an ECS that uses
that underlying detailed map. Then to satisfy the RFC, use some form of
cluster analysis to partition the endpoints in the underlying map into
(say) 100 to 200 PIDs, and offer a Network Map & Cost Map based on that
partitioning.

I hope that helps.

	- Wendy Roome


>Date: Tue, 8 Sep 2015 20:53:37 -0500
>From: Lyle Bertz <[e-mail]>
>To: [e-mail]
>Subject: [alto] Cost Maps, Endpoint Cost Maps and Coarse Grained
>	Searches
>Message-ID:
>	<CAC5bAiYH5N2tQpr3CEZn+eO8C9kYgWttyqNrwKKe=[e-mail]>
>Content-Type: text/plain; charset="utf-8"
>
>All,
>
>I am implementing an Erlang based ALTO server and had a couple of
>questions
>based upon an observation of 7285.
>
>The Cost Map is assumed to be coarse grained and one cannot make a
>determination about whether an endpoint cost measure is fine or coarse per
>the RFC.
>
>If i am to search for a cost between two endpoints (1 source and 1
>destination) and 'miss' on the first endpoint map I am looking at the
>other
>endpoint costs responses I may have available for an answer.  In such a
>case I can just look for the two endpoints and, if present, I have a hit
>and I am good to go.
>
>However, if I am looking to Cost Maps the map dependency assumes that both
>endpoints are members of the same map.   This implies that only endpoint
>cost maps can contain metrics between two endpoints that are not in the
>same map.   I find this interesting in that as a designer if you want all
>data in Network Cost Maps you have to model the entire internet or you can
>just rely on endpoint cost maps.
>
>What was the intent in this relationship?  I like the open ended option
>the
>endpoint cost maps provide but I am a bit reluctant to begin coding
>something that may have not been an intentional feature in ALTO.
>
>Thanks.
>
>Lyle
>
>PS - Code for Erlang ALTO server (very Alpha) can be found at
>https://github.com/lylebe/e__alto
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><https://mailarchive.ietf.org/arch/browse/alto/attachments/20150908/d08924
>af/attachment.html>