Apologies for being late to the party :) Circling back to prepare for a round of updates to the draft, and a few responses and a proposed way to move forward.
On Wed, Aug 31, 2011 at 11:23 AM, Vijay K. Gurbani <[email protected]> wrote: > <As individual> > > Bill Roome says: >> >> Basically, I think adding a "quality" modifier to the cost -- be it >> a binary "authoritative vs non-" flag, or a continuous "reliablity" >> value -- is an exercise in futility. >> >> Why? At best, the cost reported by an ALTO server is an indication of >> the recent performance of the network. [...] > > I think this depends on the type of cost being reported. > > Clearly, if the cost is derived from some monetary agreements > between transit partners or some reciprocal agreement between > peering partners, then the ISP operating that ALTO server is > in the best position to act as an authority for the cost metric. > > As such, I don't see why we would not indicate this. > > On the other hand, if the cost is derived from some characteristics > of the network itself (instantaneous queue length at routers, > percent of network link in use, etc.) I agree that reporting > this has diminishing value, irrespective of whether or not > the ISP is authoritative or not. > > A third-party ALTO server or even an ALTO server being operated > by an ISP will not have much knowledge about the topology and > any costs associated with the parts of the network it does not > "own". > > Therefore, we need to make sure that the protocol can answer > a routing queries of the type we saw during the interoperability > event: wanting to know the routing cost from of a peer in a > peering network to another peer in a transit network. In such > a case, both the ISP ALTO server and a third party ALTO server > are indulging in a guess. And if so, this should be reflected > in the response. > > My personal feeling is that we should not preclude an authoritative > qualifier on the response. We can make it optional and leave > it to the server to insert one. >From this discussion it sounds like the general agreement is that a continuous value is probably not a good way to go (cool - I agree with that decision :) ). My personal opinion is that I could imagine where an ALTO Server might be able to venture a guess (with the intention of being helpful) from external sources that it has that are not immediately accessible to an ALTO Client (meaning the ALTO Client might not be able to arrive at that conclusion). Thus, one proposal would be the following: (1) An ALTO Server determine a cost from its own perspective (note that I'm purposefully not saying that it knows exactly what the cost is). In this case, it puts an entry in the cost matrix just like today. (2) ALTO Server might not have any idea at all (in which case the entry is simply omitted from the matrix -- this can be a big efficiency win if there are many PIDs with addresses outside of an ISP's administrative domain). Regardless of the authoritative / non-authoritative bit, I strongly believe this should be done anyways. (3) An ALTO Server ventures a guess to help the client. These can be marked with an extra 'non-authoritative' bit in the cost matrix. Note that this inverts Vijay's proposal of marking things as authoritative; I tend to think that authoritative should be the default, and non-authoritative be the exception since the protocol document is already clear that "An ALTO Server conveys the network information from the perspective of a network region." >From the client side, a simple implementation might be to just ignore anything that is non-authoritative if there is any other information available at all (of course this is left to implementation-defined policy, though). Additionally, (3) could be done as an extension if we wanted to table this for later. Thoughts? Thanks, Rich > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / [email protected] > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
