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

[Lyle Bertz <[e-mail]>]

Richard,

You are correct.  The containment constraint by a network map membership in
a cost map is actually a bonus as it implies I can put something cheap such
as a Bloom Filter on the network to determine if there is no point in
further search for the cost map.

It is a minor optimization but every little bit counts.

Lyle




On Tue, Sep 15, 2015 at 4:13 PM, Y. Richard Yang <[e-mail]> wrote:

> Lyle,
>
> On Mon, Sep 14, 2015 at 8:18 PM, Lyle Bertz <[e-mail]> wrote:
>
>> Richard,
>>
>> Thanks for the response.
>>
>> My concern here is the costmap references a network map.   Per Section 6
>> of RFC 7285
>>
>> For a given ALTO network map, an ALTO cost map defines path costs
>>    pairwise amongst the set of source and destination network locations
>>    defined by the PIDs contained in the network map
>>
>>
>> This implies a measurement between endpoint in a network map and one in a
>> location NOT covered by the network map MUST be in the endpoint costmap.
>> It doesn't seem like much of an issue until you think about building an
>> endpoint cost service.
>>
>> If there is no fine grained result present in the server, then it is my
>> understanding that the ONLY way you will have a coarse grained result is to
>> find a network map (and corresponding costmap for it and the specific
>> metric in question) where both endpoints belong to the same network map.
>>
>> At least, I *think* that is the way I understand it.
>>
>> If that is the case then it implies that 'off network map' measurements
>> are fine grained only.   I was wondering if this was intentional in the
>> design of ALTO or not?
>>
>
> This is a very interesting aspect. I tend to think that Network Map/Cost
> Map provides coarse-grained info, relative to endpoint cost (ECS). If we go
> down the path of hierarchical network maps (endpoint is the finest level),
> then a finer grained map provides finer-grained info:Assume we have
> info(N11 -> N12), info(N21 -> N22), where N11 \subset N21, N12 \subset N22,
> then
> info(N11 -> N12) is more-fine-grained-than info(N21 -> N22)
>
> I believe the preceding is the framework you are referring to, right?
>
> Richard
>
>
>
>>
>> Lyle
>>
>>
>>
>>
>> On Fri, Sep 11, 2015 at 5:36 PM, Y. Richard Yang <[e-mail]> wrote:
>>
>>> Hi Lyle,
>>>
>>> It is cool to hear about this Erlang implementation! Please see below.
>>>
>>> On Tue, Sep 8, 2015 at 9:53 PM, Lyle Bertz <[e-mail]>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> Agree. One cannot determine how fine-grained (precision) of given costs
>>> of a cost map.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>>
>>> Not sure I understand the setting. A bit more elaboration?
>>>
>>>
>>>> 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.
>>>>
>>>
>>> A cost map can have an entry between the same PID. Hence, an ALTO server
>>> can give some hint about the cost of endpoints in the same group. I
>>>
>>>
>>>> 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.
>>>>
>>>>
>>> Interesting comment. RFC7285 does require a network map to be complete
>>> and hence covers the entire Internet. But it does not require a cost map to
>>> be complete. Hence, if an ALTO server puts a default 0.0.0.0/0
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__0.0.0.0_0&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=iV57t_vRLqOgSHg5pf_s9H5FctpmQf9NMkWqYyNciXA&s=KREJOtvUI7sBkXlzjmY41cBWg5F35KYIT_9VSEN_ZdE&e=>
>>> as a PID say pid0, it covers the entire Internet. But it can refuse to
>>> provide costs to/from pid0.
>>>
>>>
>>>> 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.
>>>>
>>>>
>>> If I understand the issue here correctly, the intent is that cost map
>>> provides coarse grained network info, while endpoint cost map (service) is
>>> for more (set in terms of number of endpoints) fine-grained cost.
>>>
>>> Make sense?
>>>
>>> Richard
>>>
>>>
>>>> Thanks.
>>>>
>>>> Lyle
>>>>
>>>> PS - Code for Erlang ALTO server (very Alpha) can be found at
>>>> https://github.com/lylebe/e__alto
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lylebe_e-5F-5Falto&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=V6BO-mpxdlTkTsfyM8KeZ7QAbLJZ7ArKc9tWMGcqzao&s=NBUJR9B5zgQYJPqVTFWSVrAEoXRa2UwyK3rktOydCJs&e=>
>>>>
>>>>
>>>>
>>> Cool! I am eager to take a look!
>>>
>>>
>>>> _______________________________________________
>>>> alto mailing list
>>>> [e-mail]
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=V6BO-mpxdlTkTsfyM8KeZ7QAbLJZ7ArKc9tWMGcqzao&s=a24W9DyuITBo8KhFisJSOfGIpGXNM4YLYXIiJZzSeXE&e=
>>>>
>>>>
>>>
>>
>