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? 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 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
