On Wed, Feb 1, 2012 at 2:56 AM, stefano previdi <[email protected]> wrote: > > 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.
Yes. I believe 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... That's true. Rich > > > 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
