Lyle, On Mon, Sep 14, 2015 at 8:18 PM, Lyle Bertz <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> >>> 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= >>> >>> >> >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
