I guess I'm a bit late to the party, so I can keep this simple and say how the draft was currently intended: (1) The choice of the term "endpoint" (those thingy's that are contained in PIDs) was not an accident :) (2) As such, each entry of the Cost Map is the *end-to-end* cost from the source to the destination (I think this is what Ben meant by "mesh"). That is, the ALTO Server has already added up the costs on the physical links along the path for you. (3) If there is an entry missing from the Cost Map, it means the ALTO Server doesn't know the cost from that source to destination (or isn't willing to tell you). I guess you could generate a path, but the point about whether a packet can actually traverse that path is a good one -- ALTO doesn't make any claims on routing capabilities offered by endpoints.
Given that particular meaning, you could imagine doing overlay routing on that (e.g., in a P2P swarm). In that sense, each endpoint is a node on a graph, and you could imagine doing shortest path on that. However, that's quite different than doing shortest path on the actual network topology. This was the reason for my comments a few times (I guess not on the list, it was probably at the mic during a WG session) that if we were to ever expose raw network topology via ALTO, then we need to explicitly denote that it would be a different interpretation of the Cost Map than we have today (an adjacency matrix seems like a reasonable model here). Along those lines, I'm a little bit hesitant of the proposal to add a "transit" attribute to a PID, since that seems to conflate the two possible interpretations of the cost map (end-to-end costs vs. adjacency matrix). If we wanted to convey the actual graph, how about have an attribute for the entire cost map that indicates explicitly that it is to be interpreted as an adjacency matrix (and obviously, ordinal costs would not make sense there). Given this discussion and the confusion it caused, we'll have to go back and ensure this is explicitly stated in the draft. Thoughts? Rich On Mon, Jan 30, 2012 at 9:03 AM, Ben Niven-Jenkins <[email protected]> wrote: > Colleagues, > > In the current specification of ALTO, are costs always End to End? > > What I mean by that is when looking at ALTO cost maps is it possible to > safely assume that of there is a cost between PIDX & PID Y and a cost between > PIDY & PIDZ then the cost between PIDX & PIDZ can be calculated as > cost(PIDX,PIDY)+cost(PIDY,PIDZ)? [If this assumption does hold, it is > obviously not applicable to ordinal cost types]. > > I suspect the answer is no, but I wanted to check what the definitive answer > is. > > > For example if a cost map contains: > > "map" : { > "PID1": { "PID2": 1 }, > "PID2": { "PID1": 1, "PID3": 2 }, > "PID3": { "PID2": 2 } > > Can one assume that the cost between PID1 & PID3 is 3 (PID1->PID2 + > PID2->PID3)? > > How about if the cost map contains: > > "map" : { > "PID1": { "PID2": 1, "PID3": 3 }, > "PID2": { "PID1": 1, "PID3": 2 }, > "PID3": { "PID2": 2, "PID1": 3 } > > Can one assume PID2 is on a path between PID1 & PID3? > > Thanks > Ben > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
