Subject: Re: [alto] Clarifying Cost Map Dependencies on a Network Map

From: Wendy Roome <[email-masked]>
Date: Thu, 25 Jul 2013 11:17:54 -0400

I don't think that's necessary, because p2p trackers are specialized ALTO
clients, with specialized needs. ALTO discovery won't work for busy
trackers; they'll need to be manually configured with the ALTO server.

Here's why. A tracker gets 10's, if not 100's, of requests for peers per
second. For each request, the tracker must evaluate the costs from the
client to 1000's of other peers. A tracker cannot afford to contact an
ALTO server for every peer request. And if it tried, it would overload the
ALTO server.

In short, a tracker is a high-volume client that needs low latency. A
tracker will retrieve and cache the full network and cost maps, and
evaluate costs using those maps, without going to the ALTO server each
time.

Furthermore, a tracker needs a network map with a uniform level of
granularity. That is, the pids should be roughly the same size for all
regions. A network map that's fine-grained near the tracker, and
coarse-grained farther away, isn't very useful. Furthermore, a tracker
does NOT need a fine-grained network map. A map with 15 or 20
sub-continent level PIDs would be fine. Why? Because a tracker doesn't
need to return the "lowest cost" peers. A tracker really just needs to
avoid returning the very high cost peers. For example, when a Japanese
peer asks for peers, the tracker would like to return peers in Japan, or
at least Asia, before it returns peers in Europe. The Japanese peer can
then pass those addresses to its (local) ALTO server and determine the
best ones.

	- Wendy Roome

>Date: Wed, 24 Jul 2013 15:00:57 -0400
>From: "Y. Richard Yang" <[email-masked]>
>Subject: Re: [alto] Clarifying Cost Map Dependencies on a Network Map
>
>Hi Sebastian,
>
>On Wed, Jul 24, 2013 at 2:48 PM, Sebastian Kiesel
><[email-masked]>wrote:
>
>>Hi Richard,
>>
>>On Wed, Jul 24, 2013 at 01:57:31PM -0400, Y. Richard Yang wrote:
>>> Hi Sebastian,
>>>
>>>......
>>>
>>But how
>>would we do that in the third-party use case, e.g., if a P2P tracker
>>issues ALTO queries on behalf of (topologically distant) resource
>>consumers? Is there a way to explicitly tell the resource consumer's
>>ID/IPaddress when requesting an IRD?
>>
>
>Third party is a more challenging case. It is interesting that you appear
>to suggest that the requestor of the IRD can indicate the end user that
>the request is for, say in X-Forwarded-For. This will require that the
>ALTO
>Server check the field, and the (third-party) requestor set the field.
>Interesting
>idea. I am not sure if we want to take on this in the base protocol. But
>it
>is quite interesting, and I never thought about this possibility.
>
>Thanks!
>
>Richard

---

From: Wendy Roome <[email-masked]>
Date: Thu, 25 Jul 2013 11:47:19 -0400

Suggestion: Instead of adding a POST parameter to the IRD request, how
about defining a new service: "Default Network Map"?

It would be a POST request with "endpoint" as parameter.
Returns "network-map-id-name" with the id name of the default network map
for that client.
MIME types might be "alto-defaultnetworkmap+json" for the response, and
"alto-defaultnetworkmaparams+json" for the POST parameters.

The IRD would would have an entry for that service. This lets the server
confirm that the service is available. I suggest we add this as well as
defining a "default network map" attribute, so the server can use whatever
mechanism it likes.

	- Wendy Roome

>Date: Wed, 24 Jul 2013 15:29:54 -0400
>On Wed, Jul 24, 2013 at 3:16 PM, Sebastian Kiesel
>>   .......
>In addition to a reaction of it being a hack, some other reactions that I
>can "hear" include that this creates cross-layer issues (against); we
>should use existing mechanisms whenever possible (for).
>
>maybe  GET http://altoserver.example/ird&rc=192.0.2.55
>>(RC=ressource consumer) or what would be a RESTful solution approach?
>>
>>
>>> This will require that the ALTO
>>if we cannot find a very simple solution that still can be added to the
>>base protocol without the risk of side effects, I could imagine a future
>>extension that uses POST to request the IRD and give more information
>>about the client and its expectations wrt. the ALTO guidance.
>>
>>
>The idea of introducing parameters in the request for IRD (i.e., filtered
>IRD)
>is an interesting one. I will think more about it.
>
>Thanks!
>
>Richard