Hi Richard, > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Richard Alimi > Sent: Thursday, June 10, 2010 11:46 PM > To: Song Haibin > Cc: [email protected] > Subject: Re: [alto] ALTO with CPID extension > > 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? >
There could be an identity for each ISP, I would assume this could be assigned by IANA. Clients can use this identity for the differentiation. The size of the map is linear to the number of ISPs. The CPID draft will be updated and you will see more details. > > > > 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. > The client is required to support a new DHCP option if it wants to use this way to retrieve its CPID, this is bad, but the benefit is that it is not required to change anything to do ALTO server discovery. > > 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 That's because we hope CPID could be the basic atrribute for each client, somewhat like IP address. The cost between two clients could be calculated by the "cost attribute" of these two clients. > - Both Resource Consumer and Resource Provider must have the > same ALTO Service Provider No. We also have interdomain traffic optimization. But if you want to totally cut off the "small map" I mentioned above, that would be possible if there is an third party to get all the cost among ISPs and turns them into a portion of each CPID vector. >(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?) No Network Map. Somewhat similar to the Cost Map with only cost information from the current ISP to other ISPs. > - The application protocol between the Resource Consumer and > Resource Provider can be changed > I think either way that you can let the resource consumer to get the CPID of the resource provider is okay. > > 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. CPID is mainly based on the calculation with the source CPID and destination CPID, not lookup. > > 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. > Okay. That is for a single selection. How many user requests per second are there in the tracker you mentioned above? What is the average number of peers in each swarm? BR, Haibin > 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
