On Wed, Feb 1, 2012 at 12:57 AM, stefano previdi <[email protected]> wrote: > Hi Rich, > > On Feb 1, 2012, at 9:04 AM, Richard Alimi wrote: >> 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. > > > do you intend that a cost map is supposed to be a full mesh of leaf > nodes (as per analogy to SPF algorithm) ? IOW: you're not expected to > transit across PIDs ?
Correct. Transiting across PIDs would be an application-level concern (e.g., constructing a P2P overlay) and outside of the scope of ALTO. Since we're dealing with applications endpoints who are sending resources back and forth (at least thats what ALTO was chartered for :) ), the cost map indicates the cost of sending that resource from one endpoint to another endpoint. Now, in the CDN world, I agree those assumptions begin to change and we start getting closer to an actual network topology (or aggregated view of it)... hence this whole discussion.. :) > >> (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). > > > I believe we have two orthogonal elements: > > 1. Information that can be leveraged by traditional SPF/Dijktra > algorithm so to compute a topology using same algorithm/paradigms > than the ones used in the network. This can be a cost map, I don't > mind, as long as the semantic of the information is compatible with > what we want to do with it. In this respect, Ben asked a valid > question. Yes - my only point is that if a cost map is to be interpreted this way, it seems much cleaner/understandable to me if this mode is explicitly indicated by the ALTO server. More on this below... > 2. The ability, for an ALTO server, to deliver a partial or aggregated > or virtual topology that would NOT represent the reality of the > network infrastructure but rather the topology that the application > needs in order to optimize its business. Right - I agree that is orthogonal. > > Implementors have worked quite a bit on the latter. > > >> 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). > > > FYI: routing protocols do have such node attribute. In ISIS we call > it "overload-bit" and allows an operator to define a router as a > non-transit device. Having the same capability in ALTO doesn't look > unreasonable to me. > > I'd go a bit further and I believe having PID Capabilities TLV would > probably help. Okay, so let me try to put this all in perspective :) Imagine being an application presented with a Cost Map from some ALTO Server. Let's assume for a minute that you don't have any pre-existing knowledge of the ALTO Server and policies it uses to generate that information. So far on this thread we have discussed two possible ways to determine the cost of sending some bytes from A -> B: (1) Lookup (A, B) in the cost map [ this is what the protocol draft currently prescribes ] (2) Treat the cost map as an adjacency matrix, construct the corresponding graph, compute the shortest path from A->B, and then compute the cost based on that path (the particular mathematical operation will depend on the cost type). The application needs to know which algorithm to use. What I'm proposing is if an application is to interpret this as (2), then the cost map returned by the ALTO Server be marked with an attribute indicating that. If when computing (2), certain PIDs were marked as non-transit, that seems reasonable. I would start to worry about scope-creep though. There should be some dividing line to ensure we're not going to end up building a generic data structure to carry what looks like a (perhaps aggregated) link-state database. In any case, thats probably a topic for after (2) gets proposed/documented as an extension :) The application of the non-transit PID attribute in (1) is less clear to me, but I might imagine a few application-level heuristics that could use that as input. For example, don't treat an endpoint in a non-transit PID as a seed in a high-bandwidth peer in a P2P swarm. However, it seems like those kinds of heuristics could equally be gained by adjusting the costs in the Cost Map instead of introducing a new attribute. Thanks, Rich > > s. > > >> 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 >> > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
