Hi Haibin, On Fri, Jun 4, 2010 at 3:42 AM, Song Haibin <[email protected]> wrote: > Hi all, > > I would like to make a clarification on how CPID works and in which way it > will benefit. > > First the ALTO server collects network topology and policy information from > network equipments. And then constructs a cost/priority matrix among the > network aggregation points. And after a mathematical decomposition, the > original cost/priority matrix turns into the multiply products of two > matrixes. And each cost/priority value in the original matrix is the > multiply product of two vectors in the latter two matrixes. And these > vectors become the CPIDs for peers under those aggregation points. There are > two kinds of CPIDs, CPIDsource and CPIDdestination in the case the > priority/cost from one area to another area is not equal to the cost vice > versa. A small map indicates the priority from the current ISP/AS to other > ISP/AS (one to many) will also be needed.
Is the mechanism for interdomain specified in any more detail somewhere? In particular, how does an ALTO Client determine that a peer's CPID is not "compatible" with its own (i.e., it is not generated by the same ALTO Service Provider)? What is the structure of this map and why is it small? > > Second, the CPID for each area and the the very small map could be delivered > to the local DHCP server in that area, and the end user will get their CPID > through the DHCP server. The ALTO server does not have to process any user > requests. The end user does not need to know more information than that got > from the DHCP server. This is of course presuming that the ALTO Client can access any DHCP options? Looking briefly on my linux machine, this appears to require installing hooks (as root). The situation appears to be somewhat easier on Windows, which has a DhcpRequestParams() function. > Third, as each end user or resource provider all have their own CPIDs. The > end user will choose peers according to the source and destination CPIDs and > priority from its ISP/AS to others. It may also be good to enumerate assumptions that CPID has on the Resource Consumer and Resource Providers so that one can more explicitly judge in which deployment scenarios it might apply. There are a couple that I can think of off the top of my head: - Both Resource Consumer and Resource Provider must have ALTO Clients - Both Resource Consumer and Resource Provider must have the same ALTO Service Provider (my initial interpretation is that the "small map" you mentioned above looks a lot like the Network Map and Cost Map currently in the protocol -- is that right?) - The application protocol between the Resource Consumer and Resource Provider can be changed > I would agree that the network map and cost/priority map could be > re-calculated by efforts if an application has millions of users and wants > to collect this kind of information (CPID and IP addresses). If users can recompute such information, that is fine. However, I strongly object to making any claims as to any increase in ISP privacy beyond the level currently offered by the Network Map and Cost Map approach. In addition, such considerations should be stated clearly so that ISPs don't fall into a false sense of privacy. > But ALTO server > does not have to process user requests (offload to local DHCP server, no > burst load on the ALTO server, you even do not need ALTO server discovery in > this case). Okay. > And the end user does not have to search the big map to find all > the PIDs for destination peers and then search the costs in the cost map. As I mentioned before, I think the computational overhead for a single network map lookup (i.e., a longest-prefix match) and a single matrix lookup (indexing into a 2-dimensional array) is extremely minor especially for an ALTO Client deployed at an end-user's machine. Our benchmarks for a single peer join and peer selection at a tracker with 1,000,000 registered peers (which included a few longest-prefix matches, 50 lookups into a peering weight matrix the size of a cost map, as well as various other bookkeeping and lookup operations) took under 40 microseconds. The burden on an ALTO Client would presumably be much less in the use case you mentioned above. Thanks, Rich > > > > My two cents, > Haibin > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
