On Feb 1, 2012, at 11:16 AM, Richard Alimi wrote: > 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.
yes, well, this was the original context and therefore your point is right. > 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.. :) exactly. And keep in mind that CDN is just another use case. Others are being addressed by existing alto application as well (e.g.: alto/topology guided DNS, Cloud Networking, ...). >>> (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... Agreed, hence the capability/characteristics TLV. >> 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. which is the case most of the time. > 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). just for completion, there's a 3rd way: ECS which allows an app not to deal with mechanisms ALTO uses for building topology and doesn't require the app to have any topology computational intelligence. > 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. yes, I agree. > 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 :) so if I understand your point, we could have: 1. an attribute describing the whole map (graph vs. tree vs. mesh) 2. a pid attribute describing pid characteristics/capabilities if so, then we are in agreement. > 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. again, there are many other non-p2p apps out there. > 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. You _MAY_ handle some cases with costs but it can become VERY complex and also you MUST have a cost for each direction of the link/branch connecting two PIDs. As an implementor, I'd discourage that way... s. > > 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
